Five years ago last Monday, the @W3C Social Web Working Group officially closed^1. Operating for less than four years, it standardized several foundations of the #fediverse & #IndieWeb: #Webmention #Micropub #ActivityStreams2 #ActivityPub Each of these has numerous interoperable implementations which are in active use by anywhere from thousands to millions of users. Two additional specifications also had several implementations as of the time of their publication as W3C Recommendations (which you can find from their Implementation Reports linked near the top of each spec). However today they’re both fairly invisible "plumbing" (as most specs should be) or they haven’t picked up widespread use like the others: #LinkedDataNotifications (LDN) #WebSub To be fair, LDN was only one building block in what eventually became SoLiD^2, the basis of Tim Berners–Lee’s startup Inrupt. However, in the post Elon-acquisition of Twitter and subsequent Twexodus, as Anil Dash noted^3, “nobody ran to the ’web3’ platforms”, and nobody ran to SoLiD either. The other spec, WebSub, was roughly interoperably implemented as PubSubHubbub before it was brought to the Social Web Working Group. Yet despite that implementation experience, a more rigorous specification that fixed a lot of bugs, and a test suite^4, WebSub’s adoption hasn’t really noticeably grown since. Existing implementations & services are still functioning though. My own blog supports WebSub notifications for example, for anyone that wants to receive/read my posts in real time. One of the biggest challenges the Social Web Working Group faced was with so many approaches being brought to the group, which approach should we choose? As one of the co-chairs of the group, with the other co-chairs, and our staff contacts over time, we realized that if we as chairs & facilitators tried to pick any one approach, we would almost certainly alienate and lose more than half of the working group who had already built or were actively interested in developing other approaches. We (as chairs) decided to do something which very few standards groups do, and for that matter, have ever done successfully. From 15+ different approaches, or projects, or efforts that were brought^5 to the working group, we narrowed them down to about 2.5 which I can summarize as: 1. #IndieWeb building blocks, many of which were already implemented, deployed, and showing rough interoperability across numerous independent websites 2. ActivityStreams based approaches, which also demonstrated implementability, interoperability, and real user value as part of the OStatus suite, implemented in StatusNet, Identica, etc. 2.5 "something with Linked Data (LD)" — expressed as a 0.5 because there wasn’t anything user-visible “social web” with LD working at the start of the Working Group, however there was a very passionate set of participants insisting that everything be done with RDF/LD, despite the fact that it was less of a proven social web approach than the other two. As chairs we figured out that if we were able to help facilitate the development of these 2.5 approaches in parallel, nearly everyone who was active in the Working Group would have something they would feel like they could direct their positive energy into, instead of spending time fighting or tearing down someone else’s approach. It was a very difficult social-technical balance to maintain, and we hit more than a few bumps along the way. However we also had many moments of alignment, where two (or all) of the various approaches found common problems, and either identical or at least compatible solutions. I saw many examples where the discoveries of one approach helped inform and improve another approach. Developing more than one approach in the same working group was not only possible, it actually worked. I also saw examples of different problems being solved by different approaches, and I found that aspect particularly fascinating and hopeful. Multiple approaches were able to choose & priortize different subsets of social web use-cases and problems to solve from the larger space of decentralized social web challenges. By doing so, different approaches often explored and mapped out different areas of the larger social web space. I’m still a bit amazed we were able to complete all of those Recommendations in less than four years, and everyone who participated in the working group should be proud of that accomplishment, beyond any one specification they may have worked on. With hindsight, we can see the positive practical benefits from allowing & facilitating multiple approaches to move forward. Today there is both a very healthy & growing set of folks who want simple personal sites to do with as they please (#IndieWeb), and we also have a growing network of Mastodon instances and other software & services that interoperate with them, like Bridgy Fed^6. Millions of users are posting & interacting with each other daily, without depending on any large central corporate site or service, whether on their own personal domain & site they fully control, or with an account on a trusted community server, using different software & services. Choosing to go from 15+ down to 2.5, but not down to 1 approach turned out to be the right answer, to both allow a wide variety^7 of decentralized social web efforts to grow, interoperate via bridges, and frankly, socially to provide something positive for everyone to contribute to, instead of wasting weeks, possibly months in heated debates about which one approach was the one true way. There’s lots more to be written about the history of the Social Web Working Group, which perhaps I will do some day. For now, if you’re curious for more, I strongly recommend diving into the group’s wiki https://www.w3.org/wiki/Socialwg and its subpages for more historical details. All the minutes of our meetings are there. All the research we conducted is there. If you’re interested in contributing to the specifications we developed, find the place where that work is being done, the people actively implementing those specs, and even better, actively using their own implementations^8. You can find the various IndieWeb building blocks living specifications here: * https://spec.indieweb.org/ And discussions thereof in the development chat channel: * https://chat.indieweb.org/dev If you’re not sure, pop by the indieweb-dev chat and ask anyway! The IndieWeb community has grown only larger and more diverse in approaches & implementations in the past five years, and we regularly have discussions about most of the specifications that were developed in the Social Web Working Group. This is day 33 of #100DaysOfIndieWeb #100Days ← Day 32: https://tantek.com/2023/047/t1/nineteen-years-microformats → Day 34: https://tantek.com/2023/072/t1/blog-as-if-ai-trained-posts Post Glossary: ActivityPub https://www.w3.org/TR/activitypub/ ActivityStreams2 https://www.w3.org/TR/activitystreams-core/ https://www.w3.org/TR/activitystreams-vocabulary/ Linked Data Notifications https://www.w3.org/TR/ldn/ Micropub https://micropub.spec.indieweb.org/ Webmention https://webmention.net/draft/ WebSub https://www.w3.org/TR/websub/ References: ^1 https://www.w3.org/wiki/Socialwg ^2 https://www.w3.org/wiki/Socialwg/2015-03-18-minutes#solid ^3 https://mastodon.cloud/@anildash/109299991009836007 ^4 https://websub.rocks/ ^5 https://indieweb.org/Social_Web_Working_Group#History ^6 https://tantek.com/2023/008/t7/bridgy-indieweb-posse-backfeed ^7 https://indieweb.org/plurality ^8 https://indieweb.org/use_what_you_make

Nineteen years ago last Saturday, @KevinMarks.com & I introduced^1 #microformats @OReillyMedia ETech 2004, building on “semantic (x)html”. We’ve come a long way since, from methodologies to #microformats2, from publishing to peer-to-peer #IndieWeb use-cases. We named #microformats only after we had established a pattern of real world examples; even our talk proposal was named RealWorldSemantics^2, and provided examples in that broader theme. This exemplified important implicit values in ordering our efforts: 1. get real world things working first, not just theory 2. name them after a pattern emerges, not just solo efforts 3. grow the pattern with proposals, prototypes, iteration, evolution The examples at that point in time: * XFN — using rel-values for blogroll semantics, and the technology that defined rel=me in v1.1^3, now the standard for decentralized social media verification on Mastodon^4, GitHub^5, elsewhere, and the basis of RelMeAuth^6 * XMDP — XHTML MetaData Profiles, notably using an HTML class^7 with a particular value 'profile' to indicate presence of a specific semantic structure * XOXO — XHTML Outlines, formalizing existing usage of (X)HTML elements for outlines, also using an HTML class with a particular value 'xoxo' to express a semantic Growing the pattern: * rel=license — solved page licensing better than before, since widespread adopted * VoteLinks — new rel values, prototyped, only one consuming implementation (since defunct) And further brainstorming: * recommendations — initial rel="recommendation" idea eventually evolved to hReview, and today’s h-review * syndication — helped motivate HTML5 <time> element, eventually led to hAtom, and today’s h-entry * playlists — led to various ideas, proposals, & demos^8, still not really solved today The mid-2000s were a time of eager experimentation, when we were learning that very small bits of markup (yes, hence the name) could be used to build some very useful capabilities on top of the open web platform. A few observations with the benefit of years of experience since we proposed “microformats”: One: Many microformats succeeded because we solved an existing problem, with existing *complex* solutions, by providing a drastically *simpler* solution. XFN instead of FOAF. rel=license instead of Creative Commons RDF in HTML comments. By doing so, we skipped the often harder problem of defining & refining a problem worth solving, a use-case, or user scenario. Two: A few microformats succeeded because they solved existing problems, re-using *existing established* open solutions in other formats, reformatted into native HTML. hCard from vCard. hCalendar from iCalendar. This methodology leveraged years of prior hard open standards work by numerous others across numerous organizations, and deliberately avoided the bikeshedding trap of renaming things (or any other kind of non-trivial “clean-up”) while reformatting, thus making it easy for developers of one technology to see the 1:1 mapping and use the other. The primary downside with this approach was formats that were larger than perhaps necessary for HTML-specific use-cases. Eventually for microformats2 vocabularies, we adopted a subset approach, looking for web publishing use-cases for each feature, making h-card smaller than hCard, and h-event smaller than hCalendar. Three: Success in a search engine was not enough, and sometimes attracted more bad actors than good. @KevinMarks.com, myself, and others at Technorati built search engine indexing and use of rel-tag and hReview, which helped evolve their specifications. A few other small search engines indexed rel=tag markup, however none remain today. hReview was adopted by Google which led to it being heavily spammed. This pattern repeated itself with other microformats, and eventually we shifted from: → of course search is the first obvious use-case → search is one use-case among others → we need primary use-cases outside of search for longterm ecosystem success Which leads to the fourth observation. Four: Publishing alone is not a use-case. There must be multiple consuming code use-cases (beyond search) for a microformat to succeed longterm. From individual features to whole microformats vocabularies, we learned that not only did there need to be sufficient content being published already, without microformats, that could benefit, but there needed to be good enough consuming code use-cases that benefited users (not just developers). The #IndieWeb community has been exceptionally helpful in both defining such use-cases and iterating on them with implementations. We still get questions of the form: What’s the best way to mark this up? I used to very much believe that if you could mark something up more semantically, you should spend the time & effort to do so. This drove a lot of early experiments with markup, and did provide some eventual benefits, most notably when semantic HTML elements provided good hooks for accessibility tools such as screen readers. Now we know the answer to the question of “How should I mark-up this content?” must be accompanied by specific use-cases for consuming code of that markup. If there is no consuming code use-case, it is not worth the time to add the mark-up (never mind the maintenance effort over time). Sometimes one single consuming code use-case is sufficient to justify the time & effort to add more semantic mark-up. If that markup helps screenreaders, then it’s worth it. More often than not however, there must be multiple (again, beyond search) consuming code use-cases for it to be worth adding semantic markup, and certainly for developing new markup, whether microformats features or new microformats. This focus on and repeated asking of questions like: * What is the (consuming code) use-case? * Or how does it benefit readers of this content? has helped focus our modern microformats efforts on actual benefits to humans first, and machines second (if at all). If you think of IndieWeb use-cases for existing or new microformats, come join us in the developers chat: * https://chat.indieweb.org/dev If you think of other use-cases or want to chat about modern microformats methodologies in general, join us in the microformats chat: * https://chat.indieweb.org/microformats This is day 32 of #100DaysOfIndieWeb #100Days ← Day 31: https://tantek.com/2023/044/t1/unified-sent-box-universal-outbox → Day 33: https://tantek.com/2023/051/t1/five-years-ago-w3c-social-web Post glossary: h-card https://microformats.org/wiki/h-card h-entry https://microformats.org/wiki/h-entry h-event https://microformats.org/wiki/h-event h-review https://microformats.org/wiki/h-review hAtom https://microformats.org/wiki/hatom hCalendar https://microformats.org/wiki/hcalendar hCard https://microformats.org/wiki/hcard hReview https://microformats.org/wiki/hreview rel-license https://microformats.org/wiki/rel-license rel-tag https://microformats.org/wiki/rel-tag rel-values https://microformats.org/wiki/existing-rel-values XFN https://gmpg.org/xfn/ XMDP http://gmpg.org/xmdp/description XOXO https://microformats.org/wiki/xoxo Previously, previously, previously: * https://tantek.com/2019/044/t1/15-years-ago-introduced-microformats * https://tantek.com/2014/042/t2/ten-years-ago-introduced-microformats-etech * https://tantek.com/2011/042/t2/years-ago-presented-microformats-etech * https://twitter.com/t/status/701095802 References: ^1 https://tantek.com/presentations/2004etech/realworldsemanticspres.html ^2 https://tantek.com/log/2004/02.html#d04t1311 ^3 https://gmpg.org/xfn/11#me ^4 https://docs.joinmastodon.org/user/profile/#verification ^5 https://web.archive.org/web/20230314223136/https://hachyderm.io/@nova/109790530971147702 ^6 https://tantek.com/2023/032/t1/years-relmeauth-replace-openid ^7 https://tantek.com/2012/353/b1/why-html-classes-css-class-selectors ^8 http://microformats.org/wiki/events/2007-12-11-open-media-web

Share Page With... should provide Books option for PDFs like Firefox iOS Share

11 days ago I suggested^1 a unified Sent box of everything sent/reacji’d to all Slacks logged-in with the same email. Beyond Slack though, everything you write & send anywhere: txt, chat, email, web. A Universal Outbox of all content you create, including responses. A flat time ordered list of output across mediums. And a source of material to blog. The phrase “Universal Outbox” seemed obvious to describe such a feature, parallel to the idea of a universal inbox that I remember first learning of as a concept from Apple’s AOCE project^2 in the early 1990s, but called a “single universal mailbox”. Figuring someone must have come up with the idea, I did a web search, and found a minimal wiki page from 2011: http://webseitz.fluxent.com/wiki/UniversalOutbox which did vaguely describe the idea: “a single hub where someone can find all your outbound LifeStreams?” Except I don’t want “where someone can”, but rather “where I can”, which is an important distinction, because it would explicitly include things you send to a single person or other limited audience. And yes, “can find”, with full personal search. Aside: the “where someone can” use-case of the presumably more public “all your outbound LifeStreams” is essentially what an #IndieWeb site is for. One place to publish all you want, any way you want, in a composite stream. How many times have you texted, IM’d, Slacked, or emailed nearly the same thing, maybe to different people, retyped from memory, that you could have searched, and copy & pasted instead? Or how many times have you written similar public posts, replies, or emails, on the same topic, where you said the same thing just slightly differently? What if you could publish such common ideas, concepts, points once, with a permalink, and then cite that permalink rather than retyping the same thing repeatedly? The idea of a Universal Outbox feels like a logical extension of many IndieWeb practices such as owning your data^3. While all the things you post on your personal site are a part of your Universal Outbox, they are only a subset. Even if you include everything you can PESOS from other sites, that still leaves services and sites without API access, or with APIs you may not have permission to use. Another approach that may work well is a browser add-on, which would at least be able to collect everything you type into websites. Such an add-on would be more useful than a keylogger, because a browser add-on would have a much better understanding of and access to the context of where you are entering information. An add-on could keep track of permalinks to each statement, e.g. each statement in Slack has a permalink (viewable only with login). A modest prototype add-on could start with my initial suggestion, a universal sent box that aggregated everything you said across all Slack instances you use in that browser. This would be particularly useful for keeping a personal log of your statements across free Slack instances where everything you say disappears in 90 days. For now, perhaps the manual-until-it-hurts answer is to periodically check the “Drafts & sent” folder in free Slacks (from the bottom upwards, since Slack’s web UI lacks the ability to sort or reverse the order of your Drafts & sent folder), one instance at a time, blogging or otherwise copy/pasting anything you want to cite, save, or remember. This is day 31 of #100DaysOfIndieWeb #100Days ← Day 30: https://tantek.com/2023/043/t1/footnotes-unicode-links → Day 32: https://tantek.com/2023/047/t1/nineteen-years-microformats Post Glossary: composite stream https://indieweb.org/composite_stream manual-until-it-hurts https://indieweb.org/manual_until_it_hurts permalink https://indieweb.org/permalink PESOS https://indieweb.org/PESOS reacji https://indieweb.org/reacji responses https://indieweb.org/responses ^1 https://chat.indieweb.org/2023-02-02#t1675370124338700 ^2 https://en.wikipedia.org/wiki/Apple_Open_Collaboration_Environment ^3 https://indieweb.org/own_your_data

I got auto-Unicode & linking footnotes^1 working! In notes like this post, I can type "^1" (like after the word "footnotes" above) and the code on my server automatically: * turns it into a Unicode superscript '¹' * links it to the expansion at the end of my post Similarly, I can type "^1" at the start of an expansion line (e.g. at the end of a post) and that code automatically: * turns it into a Unicode superscript '¹' * links it back to the inline reference Since that code is part of my site’s CASSIS auto_link function^2, all previous posts with such "^n" style footnotes have also been updated, like my day 6 post^3 and since. Clicking an inline footnote reference scrolls to the line with the footnote expansion. Clicking the Unicode superscript number at the start of that expansion scrolls back to the inline footnote reference. I decided to postpone adding the small return arrows '⮐' at the end of a footnote expansions. Linking the superscript numbers to each other works well, and seemed sufficiently discoverable without being distracting. By using post-specific unique prefixes for the footnote reference & expansion links, those links also work even in the presence of more than one post with footnotes, e.g. on my home page^4. They’re also in my Atom feed entries. I’m curious how the footnotes links in a post work in other contexts, like when viewing in a reader. I also discovered that Unicode superscripts were inconsistent on some platforms, and added a bit of CSS to set an explicit font-family for footnotes numbers: /* CSS style rule to use a specific font for footnote refs and expansions */ a[id*='_ref-'],a[id*='_note-'] { font-family:"Arial Unicode MS",system-ui; } /* end of style rule */ I added this and some other tips to the #IndieWeb footnote page^5. This is day 30 of #100DaysOfIndieWeb #100Days ← Day 29: https://tantek.com/2023/037/t1/post-glossary → Day 31: https://tantek.com/2023/044/t1/unified-sent-box-universal-outbox ^1 https://tantek.com/2023/036/t1/footnotes-unicode-hyperlink ^2 https://tantek.com/cassis.js ^3 https://tantek.com/2023/006/t1/forward-in-time-links ^4 https://tantek.com/ ^5 https://indieweb.org/footnote

Taking a closer look at both my syntax and use-cases of footnotes in posts^1 revealed that a post glossary would suffice in many instances. In reviewing my #100DaysOfIndieWeb footnotes, I found: 1. citations in reference to “since” a date (or year) 2. citations providing deeper points beyond the definition of a term 3. citations substantiating a point or assertion 4. citations to an earlier post providing context for a term, phrase, summary 5. links to the #IndieWeb community site for a definition of a term or phrase 6. links to a Wikipedia article that defines a term in a section 7. links to open source software defining a function The latter three (5,6,7) make more sense as part of a post glossary rather than references footnotes. Using a post glossary in previous #100DaysOfIndieWeb posts would have reduced the need for footnotes, in some case up to half of them per post. There’s one more silent use-case which helped inform when I would use those (5,6,7): 8. implicit absence of linking/defining jargon where a Wikipedia look-up would suffice This analysis led me to a five-step if/else for when/how to add a term to a post glossary: When I use an unobvious (like jargon) term or phrase in prose: 1. If looking it up literally in Wikipedia (prepending it with https://enwp.org/) provides the meaning I intend (e.g. https://enwp.org/jargon), then do nothing with it and trust readers will look it up if they need to. 2. Else if an unobvious Wikipedia link would convey the intended meaning (e.g. to another page or a specific section), then add that to a glossary 3. Else if the IndieWeb wiki definition conveys the intended meaning (and is expected to in the future), then add an IndieWeb wiki link to a glossary 4. Else if there is an open source software or other reliable reference that conveys the intended meaning (and is expected to in the future), then add a link to that to a glossary 5. Else define the term in a glossary entry, and contribute that somewhere I can link to in the future. In my previous post^1 I also used a glossary syntax resembling common print conventions: term or phrase on its own line without punctuation space-indented link to a defining page, or inline definition, or both This pattern (when repeated with two or more adjacent instances) looks like it may be detectable for auto-markup with HTML definition (description) list <dl>, term <dt>, and details <dd> elements. Perhaps as part of existing auto-markup code. For fallback handling in syndication destinations that remove^2 HTML definition related elements, I’ll likely still have to include explicit linebreaks & spaces to preserve that presentation, perhaps marked-up to style them to remove their spacing when in the context of the HTML definition elements. I have started a glossary page on the IndieWeb wiki with some of these thoughts: * https://indieweb.org/glossary This is day 29 of #100DaysOfIndieWeb #100Days ← Day 28: https://tantek.com/2023/036/t1/footnotes-unicode-hyperlink → Day 30: https://tantek.com/2023/043/t1/footnotes-unicode-links Post Glossary: auto-markup code to automatically add markup to text that implies a semantic or to preserve meaningful spaces like https://indieweb.org/auto-space HTML definition list https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dl ^1 https://tantek.com/2023/036/t1/footnotes-unicode-hyperlink ^2 https://indieweb.org/sanitize#Software_Examples

In recent posts I’ve used ASCII footnotes like "^1" to indicate more information about a subject in a footnote line starting with "^1" at the bottom of the post. Both inline refs & footer notes should use Unicode superscripts like '¹' and hyperlink both ways, in contexts that support it. I have heard feedback from the #IndieWeb community that inline ASCII footnotes like "^1" are distracting and interrupt the flow of reading, and I can sympathize with that. From an authoring perspective, it’s easier to type "^2" than "²" so I’d rather keep doing so, and write code to do the conversion. I’m also considering what to change as an author, like instead of footnoting special terms/jargon, I can include them in an mini-glossary at the end of a post, thus only using footnotes for specific points or citations. I won’t include terms that mean exactly the same thing as defined by a literal page of the same name on Wikipedia (e.g. ASCII in this post means https://enwp.org/ASCII). During a run I figured out how my existing CASSIS autolink function could detect both inline footnote references and their expansions, convert them to Unicode, and add local hyperlinks in both directions, given an optional parameter to prefix their fragment IDs. I looked at Wikipedia’s references and fragments for examples, and they use "_ref-{number}" and "_note-{number}" respectively which seem sensible. The one Wikipedia design aspect I disagree with is their use of a hat character '^' at the *start* of a reference note to link back to the inline reference, which look distracting, and in my opinion are too subtle/unobvious. I prefer what I’ve seen on blogs: a small return arrow '⮐' at the *end* of a note to link back to the inline reference, which does a much better job of conveying the meaning of “return to where this was referenced / you were reading.” Lastly, I think it’s ok if POSSE copies of my posts to text-only (non-hyperlinking) destinations keep the ASCII footnote style, because such copies usually (e.g. on Twitter) lack enough space for the expansions, and there is less chance of ASCII footnotes being misunderstood as part of something else on those destinations. POSSE destinations are in general lower fidelity than a personal site, so it’s ok have this be another instance where the original looks better than the copy. I collected many of these thoughts in a brainstorming section on the IndieWeb wiki accordingly, and will update that as I make progress: https://indieweb.org/footnote#Brainstorming If you use footnotes in your personal site posts, please add yourself to the IndieWeb Examples section: https://indieweb.org/footnote#IndieWeb_Examples This is day 28 of #100DaysOfIndieWeb #100Days ← Day 27: https://tantek.com/2023/033/t1/twitter-api-log-in-web-sign-in-relmeauth → Day 29: https://tantek.com/2023/037/t1/post-glossary Post Glossary: autolink https://indieweb.org/autolink CASSIS https://indieweb.org/CASSIS POSSE https://indieweb.org/POSSE Unicode superscripts https://en.wikipedia.org/wiki/Superscripts_and_Subscripts_(Unicode_block)

Imminent end of free use^1 of the Twitter API likely also means the end of free Log in with Twitter^2 delegated signin service^3. If you use [Sign in with Twitter]^4, consider replacing it with Web sign-in^5, implementing #RelMeAuth^6 & #IndieAuth^7 (OAuth for the #openWeb^8) ASAP! If you already have your own domain (go get one^9), add a link from your home page to your GitHub profile with rel=me^10, and then test it by using your domain to sign-in to: * https://indielogin.com/ * https://indieweb.org/ Any challenges or questions? Ask in #IndieWeb chat: https://chat.indieweb.org/dev This is day 27 of #100DaysOfIndieWeb #100Days ← Day 26: https://tantek.com/2023/032/t1/years-relmeauth-replace-openid → Day 28: https://tantek.com/2023/036/t1/footnotes-unicode-hyperlink ^1 https://www.theverge.com/2023/2/2/23582615/twitter-removing-free-api-developer-apps-price-announcement ^2 https://indieweb.org/Log_in_with_Twitter ^3 https://indieweb.org/silo_sign-in ^4 https://indieweb.org/Log_in_with_Twitter#Button ^5 https://indieweb.org/Web_sign-in ^6 https://tantek.com/2023/032/t1/years-relmeauth-replace-openid ^7 https://indieauth.spec.indieweb.org/ ^8 https://indieauth.net/ ^9 https://tantek.com/2023/004/t1/choosing-domain-name-indieweb ^10 https://indieweb.org/How_to_set_up_web_sign-in_on_your_own_domain#How_to_setup_RelMeAuth

13 years ago today: created #RelMeAuth with @progrium.com, to replace OpenID 1&2 for *reasons* * modest proposal: authentication using domain as identity, rel=me link to OAuth profile with rel=me link back^1 * @progrium.com suggested RelMeAuth name^2 * I agreed, and wrote up a draft algorithm^3 All on the same day. A few months later I wrote it up as a draft spec: * https://microformats.org/wiki/RelMeAuth (could use some updates) More updates and discussion: * https://indieweb.org/RelMeAuth See those links for RelMeAuth implementations in: * PHP, Python, Node, Ruby, Go RelMeAuth is simpler for both publishers & parsers (consuming code) than OpenID. There are now more sites that support RelMeAuth (and the complementary IndieAuth) than OpenID (which is largely abandoned^4). And today, @Github.com rolled out support for multiple rel=me profile links!^5 This means you can now use @Github.com’s OAuth (and their multifactor login etc.) to authenticate as your own domain via RelMeAuth on even more services. E.g. see my profile https://tantek.com/github (not a typo^6). The left sidebar links to my personal site, Twitter, and https://micro.blog/t all with rel=me markup. This is day 26 of #100DaysOfIndieWeb #100Days ← Day 25: https://tantek.com/2023/029/t1/indieweb-beyond-blogging → Day 27: https://tantek.com/2023/033/t1/twitter-api-log-in-web-sign-in-relmeauth ^1 https://tantek.com/2010/032/t5/modest-proposal-authentication-oauth-twitter-rel-me ^2 https://twitter.com/progrium/status/8521001762 ^3 https://tantek.com/2010/032/t6/relmeauth-oauth-rel-me-auto-fallback-authentication ^4 OpenID 1&2 were abandoned for OIDC (OpenID Connect), a supposed update/replacement, despite dropping the goal of domain as identity, the use-case for OpenID in the first place, so the #IndieWeb picked up that use-case with RelMeAuth & IndieAuth. ^5 https://web.archive.org/web/20230314223136/https://hachyderm.io/@nova/109790530971147702 ^6 https://tantek.com/2022/144/t1/redirected-github-ownyourlinks

Is the #IndieWeb just blogs/blogging? What if I told you the phrase indie web^1 is older than the word blog or weblog^2? The IndieWeb, as it says on the homepage^3, also goes beyond blogging^4. And those are just the terms. It should come as no surprise that conceptually: personal sites in general, predated personal sites with reverse-chronologically-ordered dated entries. Good concepts, even if forgotten, tend to be rediscovered & reinvented over time. When I first used the phrase "indie web" (two words) in 2010^5, I used it descriptively, an informal shorthand for the "independent web". I didn’t find out about the 1997^1 use of the phrase until many years later. I saw & was a fan of the 2001 launch of the "Independents Day" site & its manifesto^6 (at independentsday(.)org, since offline) that asked “if you create^7 your own site”, to join them. That encouragement stuck with me, and was a source of inspiration nine years later. In my presentation^8 at the 2010 Federated Social Web Summit^9, I referenced the "indie web" again, and afterwards I proposed to @aaronparecki.com that we start something focused on explicit principles & practices.^10 After subsequent chats & discussions, we settled on the term “IndieWeb” (one word). We started with three essential principles/practices, in today’s terms: “create”, “use what you make”, and “own your data”, which the community eventually expanded into 11 principles^11. This brings us back to the original question, is the #IndieWeb just blogs/blogging? In short no. Seemingly paradoxically, blogging is neither required nor sufficient to “be” IndieWeb as we use the term today. Are IndieWeb sites blogs? Some (perhaps even most) of them are. However, there are plenty of personal sites that are just a homepage^12, or a handful of static pages like a portfolio^13. Are blogs IndieWeb sites? Some of them are, if they are personal blogs, or other forms of independent sites, like small organizations with their own blogs, on their own domains. However the concept of the IndieWeb goes far beyond blogging, or any jargon like decentralization or federation.^4 The aforementioned principles^11 provide a good foundation for the IndieWeb, and a good contrast from the prevailing project-centric attitudes of the day. The practices described inside each principle, such as owning your data meaning owning your notes^14 as well, start to hint at what it means to do & be IndieWeb today. If you have a blog on your own domain, and yet you post notes as tweets or toots on someone else’s domain, are you “doing” IndieWeb? Such a split practice could be considered a mid-to-late 2000s approach to the “indie web”, but certainly not the 2023 IndieWeb. Since 2010, the IndieWeb evolved & extended far beyond blogs, into many kinds of posts^15 typical in social media (but lacking in blogs), and site-to-site social web interactions^16, like replies that looked like actual comments, rather than awkwardly displayed blog trackbacks/pingbacks. Either way, if you have your own site (whether a blog or not) and create with it, like the 2001 Independents Day encouragement, come join us^17, and we’ll help you get setup to do so much more. This is day 25 of #100DaysOfIndieWeb #100Days ← Day 24: https://tantek.com/2023/027/t5/contrast-domain-chat-name → Day 26: https://tantek.com/2023/032/t1/years-relmeauth-replace-openid ^1 1997-02-01 https://web.archive.org/web/20010805195949/http://www.uzine.net/article63.html ^2 https://en.wikipedia.org/wiki/Blog#History ^3 https://indieweb.org/#Beyond_Blogging_and_Decentralization ^4 https://indieweb.org/different ^5 http://tantek.com/2010/123/t2/blogger-turned-off-ftp-what-indie-web-diso (https://twitter.com/t/status/13329370781) ^6 https://indieweb.org/Independents_Day ^7 https://indieweb.org/creator ^8 https://web.archive.org/web/20100723133231/http://federatedsocialweb.net/wiki/2010-199-tantek-fsws-talk ^9 https://indieweb.org/Federated_Social_Web_Summit#Portland_2010 ^10 https://indieweb.org/founders#IndieWeb_movement_and_terminology ^11 https://indieweb.org/principles ^12 https://indieweb.org/homepage ^13 https://indieweb.org/portfolio ^14 https://tantek.com/2023/001/t1/own-your-notes ^15 https://indieweb.org/posts#Types_of_Posts ^16 https://indieweb.org/responses ^17 https://chat.indieweb.org/

Another interesting contrast^1 in the #IndieWeb community is that most of us have both: * a domain name^2 — for posting our content, replies, likes etc. * a chat-name^3 — for chatting in our discussion channels^4 Ideally, we would have a discussion system that “just” used our domain names as identities (IndieAuth^5 for Web sign-in^6) to chat with each other, but no such system exists (yet). No we’re not going to all setup XMPP servers on our domains and attempt to hook them all up. Nearly no one wants to pay that admintax^7. Nor would XMPP let us “just” use our domain names. Like email, XMPP requires a separate “username”. Sure we could fake it like Bridgy Fed does for us with 'domain @ domain', but why would we work harder for a worse UX? So instead of making things more complex than domains, we took the opposite approach, and based our chat on IRC, and our chat-names on plain nicknames. Using a chat system like IRC lowered the barrier to participation in the IndieWeb community, so you could for example, ask about how to pick a domain name^2 instead of being stuck in an actual catch-22^1 of needing a domain name just to ask about a domain name. By putting our chat archives on the web^8, we were able to reduce our chat system requirements, provide a simple minimal web app for brief chats, and bridge our IRC channels with multiple other chat systems, like Slack, Matrix, and even Discord^9. This has the significant advantage of much greater chat client choice for community members. However, we did realize that our statements in the chat archives^8 could be more closely tied to our domain identities, including our personal icons^10. Rather than a complex system or new protocol, we just put our flat list of nicknames in templates with images & domains on the wiki^11. Thus our chat archives, despite being based on IRC, show icons for people, and link their chat nicknames to their personal domain names, again striking a pragmatic balance.^1 The flexibility of using a wiki template allowed us to add personal time zones as well, to enable things like asking in chat, “what time is it for tantek”. This works well enough, except does not account for cross-time-zone travel, though you could update your chat-name entry if you wanted to while traveling. Having all our chat-names in a single list^11 on a page like that revealed another interesting aspect: we have folks across all the timezones in the US & Europe, some in the Middle East, Australia, and most of Asia as well. As a result, the IndieWeb chat channels have people awake and often discussing various topics 24 hours a day. Drop by^8 and say hi, and be sure to have a look at our Code of Conduct.^12 This is day 24 of #100DaysOfIndieWeb #100Days ← Day 23: https://tantek.com/2023/027/t4/five-years-websub → Day 25: https://tantek.com/2023/029/t1/indieweb-beyond-blogging ^1 https://tantek.com/2023/026/t1/indieweb-priorities-balance ^2 https://tantek.com/2023/004/t1/choosing-domain-name-indieweb ^3 https://indieweb.org/chat-names ^4 https://indieweb.org/discuss ^5 https://indieweb.org/IndieAuth ^6 https://indieweb.org/Web_sign-in ^7 https://indieweb.org/admintax ^8 https://chat.indieweb.org/ ^9 https://indieweb.org/discuss#Join_Discussions ^10 https://indieweb.org/icon ^11 https://indieweb.org/chat-names#Nicknames ^12 https://indieweb.org/code-of-conduct

Five years ago (Monday the 23rd) the @W3C Social Web Working Group published the WebSub Recommendation^1 The test suites https://websub.rocks/ for Publishers, Subscribers, and Hubs are still up & running, as are the vast majority of implementations documented in the implementation report. My site supports the publishing side of WebSub via the Superfeedr Hub^2 and there are many more supporting sites^3. Beyond publishing blog posts and realtime updates in social readers^4, there are additional WebSub use-cases such as real time #IndieWeb search^5 results, like Technorati except opt-in via WebSub subscriptions, and without any polling. Such diverse use-cases are one of the benefits of building-block^6 standards^7 like WebSub. If you create a new WebSub implementation, be sure to test it with the test suite^8 and add your results to the WebSub Implementation Reports repo^9. Got questions about WebSub? Ask in https://chat.indieweb.org/dev This is day 23 of #100DaysOfIndieWeb #100Days ← Day 22: https://tantek.com/2023/026/t1/indieweb-priorities-balance → Day 24: https://tantek.com/2023/027/t5/contrast-domain-chat-name ^1 https://www.w3.org/TR/2018/REC-websub-20180123/ ^2 https://pubsubhubbub.superfeedr.com/ ^3 https://indieweb.org/WebSub#IndieWeb_Examples ^4 https://indieweb.org/social_reader ^5 https://indieweb.org/IndieWeb_Search ^6 https://indieweb.org/building-blocks ^7 https://spec.indieweb.org/ ^8 https://websub.rocks/ ^9 https://websub.net/implementation-reports

https://bw3.dev/ (@0x3b0b) your reply mostly worked as intended! I checked my webmention.io: * 2 replies via Bridgy Fed and Bridgy (backfeed from Twitter), and * 1 mention directly from your original post permalink. Your #IndieWeb reply does have a u-in-reply-to link to a fed-brid-gy/r/ prefixed URL of my permalink, however the u-in-reply-to link directly to my site is linked to my previous post (look for "2023/018/t1" in your reply content’s markup) instead of the intended post! Try updating that direct link to use the correct URL (my original post at top of thread), add some link text to it, and resend a webmention. It’s ok to have multiple visible reply links (e.g. this reply has them, to your post & POSSE tweet reply, at the top.). Lastly, when you link directly from IndieWeb site to IndieWeb site with your reply, there’s no need to also link via Bridgy Fed. The direct Webmention is sufficient.

@elizabethtai.com (@liztai@hachyderm.io) there are a bunch of current #webrings examples listed here: https://indieweb.org/webring#Examples I’m on the #IndieWebRing: https://indieweb.org/indiewebring Links to previous/next sites in the #webring are in the footer of my tantek.com home page.

@kodfabrik.se (@voxpelli@mastodon.social) thanks for the kind words! It’s not without its trade-offs. Long term it seems correct to prioritize a simpler, consistent, continuous identity & permalinks, while incrementally adding interaction features as needed. For now, browsing & Bridgy Fed notifications instead of following feels freeing.

There are many opposing forces in the #IndieWeb that can seem like catch-22s, yet help clarify priorities, and balance present pragmatism & future optimism. * Indie, yet often on corporate infrastructure * Independent, yet dependent on community * Own your content^1, yet share publicly, perhaps CC0^2 * Control of your design^3, yet lack of control elsewhere^4 * UX freedom & creativity, yet guidance toward common patterns for usability * Decentralized, yet DNS * Make what you need^5, yet open source^6 for others * Plurality^7 of projects, yet conforming to standards^8 * Build it yourself, yet use services, software, & libraries built by others These are a few off the top of my head and implied by the IndieWeb wiki home page^9 and principles^10. Rather than contradictions, these tensions are a source of inquiry, questions, and conversations. Each could be expanded into their own discussion or exploration. Each of them is an axis of sorts, with different “right” answers for different people, depending on what they want, and how much time or other resources they have. Each makes the most sense when explored in the context of a focus on solving real user needs to participate directly on today’s web. Each is also a trap for abstract logic, theoretical purity, or dogmatic absolutism, especially when detached from real world goals, constraints, and efforts. This is day 22 of #100DaysOfIndieWeb #100Days, written after a break. Many double days ahead. ← Day 21: https://tantek.com/2023/022/t2/own-your-notes-domain-migration → Day 23: https://tantek.com/2023/027/t4/five-years-websub ^1 https://tantek.com/2023/001/t1/own-your-notes ^2 https://indieweb.org/IndieWeb:Copyrights ^3 https://indieweb.org/design ^4 https://indieweb.org/display-guidelines ^5 https://indieweb.org/make_what_you_need ^6 https://indieweb.org/open_source ^7 https://indieweb.org/plurality ^8 https://spec.indieweb.org/ ^9 https://indieweb.org/ ^10 https://indieweb.org/principles

@AnokheeTara@ohai.social indeed “drinking our own champagne” / “drinking your own champagne” was one of the proposed alternatives when the community was renaming “selfdogfooding”, though it had some downsides: https://indieweb.org/selfdogfood#drinking_our_own_champagne I like your points about emphasizing where something is amazing, and encouraging more fun and celebration. More positive metaphors! “taste your own cooking” is an excellent encouragement and variant of “eat what you cook” — I added it to the wiki (and quoted you if you don’t mind!) https://indieweb.org/eat_what_you_cook#Variants

@elizabethtai.com (@liztai@hachyderm.io) either is an excellent and challenging #100Days project. Join us in the #IndieWeb chat https://chat.indieweb.org/ for tips and help with figuring out the domain thing!

@elizabethtai.com (@liztai@hachyderm.io @liztai) Welcome and good luck with shifting to your domain name! By “post 1 post a day in the #Indieweb way” it sounds like you’ve started a 100 days of blogging project (which is great!) rather than posting about IndieWeb topics in particular. Also great if you do plan to specifically write about your #IndieWeb adventures (that’s more the intent of #100DaysOfIndieWeb), like choosing/setting up your domain, your personal publishing flow, how you are publishing on your own site and distributing your posts on Mastodon etc. Whichever you choose, use your primary domain @elizabethtai.com to sign-in to the IndieWeb wiki and add yourself to the respective subsection here: https://indieweb.org/100_days#2023

3 weeks since the 1st, since asking you to own your notes^1 Still tweeting in Big Chad’s garage or tooting in little Chad’s garage next door?^2 What’s the delay? Choosing a domain name?^3 Or a service or other path?^4 Or #TwitterMigration to #Mastodon? Two #IndieWeb alternatives to owning your notes (https://micro.blog/ or https://fed.brid.gy/, either with your own domain) both support migrating your followers from Mastodon. For example, I migrated my experimental @t@xoxo.zone Mastodon account to my own site^5, @tantek.com, thanks to the migration support in Bridgy Fed. If you’re not sure where you’d like to migrate, you can try https://micro.blog/ for 30 days to see if it works for you. If you’re a #webDev or otherwise like to tinker, it’s well worth the time to setup your own website with an SSG or CMS^6 or your own code, and grow it incrementally as you post and have time to do so. Either way, drop by https://chat.indieweb.org/ and ask any questions you have. There’s a whole community that wants you to succeed, that wants to help you own your notes. This is day 21 of #100DaysOfIndieWeb #100Days, written the night after. ← Day 20: https://tantek.com/2023/022/t1/indieweb-eat-what-you-cook → Day 22: https://tantek.com/2023/026/t1/indieweb-priorities-balance ^1 https://tantek.com/2023/001/t1/own-your-notes ^2 https://xkcd.com/1150/ ^3 https://tantek.com/2023/004/t1/choosing-domain-name-indieweb ^4 https://tantek.com/2023/003/t1/indieweb-path-chosen-why ^5 https://tantek.com/2022/358/t3/ ^6 https://indieweb.org/CMS

One of our #IndieWeb principles is Use What You Make^1. https://indieweb.org/images/8/8e/slow-social.png (Photo of basil, tomatoes, uncooked spaghetti on a rustic table with white text on top: Slow Social. Try eating what you cook on your own website. Rely less on the unhealthy fast food of corporate social media.) https://indieweb.org/eat_what_you_cook We use the metaphor Eat What You Cook^2 to more broadly relate to creators^3 of all kinds, the chefs & cooks of the IndieWeb. Cooks often taste their dishes while cooking, and modify them accordingly. Some even prepare entire dishes or meals to try themselves first, before preparing them for others. On the IndieWeb, some of us do the same by first testing our own code changes in production^4 on our personal sites, before publishing them more widely. Sometimes we let our changes simmer on our own sites for a while, before serving our code for others to consume. I myself have been most recently testing in production my at-mention auto-linking updates^5 on my site for over a week now. They seem to be working well, and I haven’t noticed any errors or regressions, so I’ll likely roll at least some of those changes into the CASSIS GitHub repo soon. While testing in production may be a reasonable & good practice for personal sites, it’s often a bad idea for corporate or critical web sites or services, and there’s no shortage of such examples. I have been wanting to write about our IndieWeb “test in production” practices for a while, and finally created a separate page on the IndieWeb wiki accordingly^4, organizing content from other pages, and adding examples beyond the IndieWeb as well. Do you write code for your website that you test there in production before sharing it more broadly on GitHub etc.? Add yourself to the examples section^6 Thanks to Chris Aldrich (https://boffosocko.com/) for the eating what you cook banner image. This is day 20 of #100DaysOfIndieWeb #100Days, written two days after. I have some double days ahead of me. ← Day 19: https://tantek.com/2023/020/t2/bridgy-fed-follow-form → Day 21: https://tantek.com/2023/022/t2/own-your-notes-domain-migration ^1 https://indieweb.org/use_what_you_make ^2 https://indieweb.org/eat_what_you_cook, much more palatable than prior "selfdogfood" or "dogfood" metaphors from other open source related communities. ^3 https://indieweb.org/creator ^4 https://indieweb.org/test_in_production ^5 https://tantek.com/2023/011/t1/indieweb-evolving-at-mention ^6 https://indieweb.org/test_in_production#IndieWeb_Examples

When you setup your site with Bridgy Fed^1, it creates a dashboard with a form for others to follow you site. E.g. mine: https://fed.brid.gy/user/tantek.com Copying that Follow form to your site sets up cross-instance following directly from your #IndieWeb site! Starting with the Follow form markup on the dashboard, copy it and make any necessary changes for its HTML & CSS to fit in with your own, e.g. <form method="post" action="https://fed.brid.gy/remote-follow"> <label for="follow-address">🐘 Follow <kbd>@tantek.com@tantek.com</kbd>:<br /> enter your @-@ fediverse address:</label> <input id="follow-address" name="address" type="text" required="required" placeholder="@you@instance.social" title="Type your @-@ address" value="" /> <input name="domain" type="hidden" value="tantek.com" /> <input name="protocol" type="hidden" value="web" /> <button type="submit">Follow</button> </form> After adding the Follow form to my site, I added more instructions and screenshots to the IndieWeb wiki to hopefuly enable more developers to setup Follow buttons: * https://indieweb.org/Bridgy_Fed#How_to_add_a_follow_form See that section for a sample rendering of the form, and what happens when someone else clicks the Follow button on your site while they’re logged into a Mastodon instance. They get prompted to FOLLOW you, and when they click that button, they get a follow confirmation. A functioning cross-instance “Follow” button is one step closer to a universal cross-site “Follow button”. This is day 19 of #100DaysOfIndieWeb #100Days, written the night after. ← Day 18: https://tantek.com/2023/019/t5/reply-domain-above-address-and-silo → Day 20: https://tantek.com/2023/022/t1/indieweb-eat-what-you-cook ^1 https://tantek.com/2023/008/t7/bridgy-indieweb-posse-backfeed

@elizabethtai.com (@liztai@hachyderm.io) Thanks! It took us a while to come up with #POSSE too! Both the concept and name. Roughly conceptually described in a 2010-05-26 interview^1: 1. Publish on your own site, own your URLs, your permalinks, and 2. Syndicate out to other sites. Your text updates to Twitter, your checkins to Foursquare, your photos to Flickr etc. A few months later in a whiteboard architecture diagram^2. Then *two years* after that @willnorris.com (@will@willnorris.com) and I finally came up with the name/acronym POSSE!^3 ^1 https://web.archive.org/web/20130312135439/http://www.monkinetic.com/2010/05/26/tantek-celik-diso-20-brass-tacks ^2 https://www.flickr.com/photos/tantek/5301870765/ ^3 http://tantek.com/2012/173/t1/posse-core-indieweb-approach

Instead of posting on a personal #IndieWeb site (& POSSE copies), some post primarily to a #fediverse instance and syndicate to Twitter, or vice-versa. How to reply^1 to such posts, e.g.: Reply to a toot (& POSSE tweet): https://tantek.com/2023/019/t4 * @-@ (Twitter @-name) This is a variant of case (2) in https://tantek.com/2023/018/t1/elevate-indieweb-above-silo. We can update the directive and two questions & answers in that prior post accordingly: * Elevate #IndieWeb domains above @-@ addresses, and those above any silo identities 1. Do they have an #IndieWeb domain? Then @-domain mention them^2, like you are speaking to them at their domain identity. This will notify them there, or at least reinforce their domain’s importance. 2. Was their post only published on a #fediverse instance (and/or silo), or was it POSSEd to a fediverse instance (and/or silo) and do you plan to federate (and/or POSSE) your reply^3? Then use their @-@ address or silo @-name, or @-@ (silo @-name) for both, or (@-@, silo @-name) parenthetically following their @-domain if (1). This will notify them on that instance (or silo), and may help thread your POSSE reply. When posting a reply, you (or your CMS automatically) should explicitly link with u-in-reply-to markup^4 to the post your are replying to, and any of its syndicated copy permalinks on destinations you plan to POSSE your reply (see also multi-reply^5). This is day 18 of #100DaysOfIndieWeb #100Days, written the day after. ← Day 17: https://tantek.com/2023/018/t1/elevate-indieweb-above-silo → Day 19: https://tantek.com/2023/020/t2/bridgy-fed-follow-form ^1 https://tantek.com/2023/017/t1/socialweb-blogs-reply-comment-post ^2 https://tantek.com/2023/011/t1/indieweb-evolving-at-mention ^3 https://tantek.com/2023/015/t1/publish-indieweb-decide-distribute ^4 https://indieweb.org/in-reply-to ^5 https://indieweb.org/multiple-reply

Thanks @w3cdevs@w3c.social (@w3cdevs) & @w3c@w3c.social, good to be back on the @W3CAB. As W3C Developers noted, we have a lot Priority Projects work to do. I have rejoined the Vision project: https://www.w3.org/wiki/AB/2023_Priorities#Vision.2FPrinciples, with gratitude to @cwilso.com (@cdub@mastodon.social) for his editing & stewardship, and am looking forward to helping support his leadership & initiative on that project.

rolandtanglao.com (@roland@devdilettante.com) thanks for the kind words and yes I was at W3C TPAC in Vancouver, would have been nice to chat! You’re right, neither ActivityPub, Webmention, nor h-entry for that matter have any explicit length limits. You can run “an experimental 10,000 character limit AP implementation” on your existing site rolandtanglao.com with a few webdev steps: Setup Bridgy Fed support on your site: * https://fed.brid.gy/docs#setup (SSL, /.well-known/ server redirects, homepage h-card) Add h-entry + h-card markup to your post template: * https://fed.brid.gy/docs#how-post Then send Bridgy Fed a Webmention when you publish a post. Presto, you’re running an AP implementation without a character limit! Happy to help with any of those steps. Drop by https://chat.indieweb.org/dev!

@swart@mastodon.cloud my #IndieWeb site https://tantek.com/, which runs its own software, doesn’t have any explicit length limit, nor does https://fed.brid.gy/, the service I use to federate to ActivityPub followers such as Mastodon instances. Both client & server as it were. I haven’t seen it cause any problems with other instances yet. For more about how an #IndieWeb setup works, and why, you might be interested in: * https://tantek.com/2023/005/t3/indieweb-simpler-approach

Bridgy Publish feature request: Support posting to GitLab sites

@novakeith.net (@knova@dartboard.social) welcome to #100DaysOfIndieWeb! There’s a few of us doing this: * https://indieweb.org/100_days#2023 Feel free to add yourself to the ”100 Days of IndieWeb” section if you like, or to a new subhead for #AtLeast100!

The answer to “How should you @-mention someone you are replying to?”^1 can depend on many factors or a few. Context matters somewhat, sometimes. We can simplify it to 2 questions, based on 1 directive: * Elevate #IndieWeb domains, above any silo or @-@ identities Two questions and answers: 1. Do they have an #IndieWeb domain? Then @-domain mention them^2, like you are speaking to them at their domain identity. This will notify them there, or at least reinforce their domain’s importance. 2. Was their post only published on a silo (or #fediverse instance), or was it POSSEd to a silo (or fediverse instance) and you plan to POSSE (or federate) your reply^3? Then use their silo @-name (or @-@ address), in parentheses if (1). This will notify them on that silo (or instance), and may help thread your POSSE reply. Examples: If the author has their own domain: Reply to an IndieWeb post (& POSSE toot): https://tantek.com/2023/008/t1/ * @-domain (@-@) Reply to an IndieWeb post (& POSSE tweet): https://tantek.com/2023/016/t1/ * @-domain [that matches their Twitter @-name] Reply to a toot: https://tantek.com/2023/008/t4/ * @-domain (@-@) Reply to a tweet: https://tantek.com/2023/002/t2/ * @-domain (Twitter @-name) If the author does not have their own domain: Reply to a toot: https://tantek.com/2023/002/t4/ * @-@ Reply to a tweet: none since this series, though it would be of the form: * Twitter @-name This is day 17 of #100DaysOfIndieWeb #100Days, again finished the next day. ← Day 16: https://tantek.com/2023/017/t1/socialweb-blogs-reply-comment-post → Day 18: https://tantek.com/2023/019/t5/reply-domain-above-address-and-silo ^1 https://tantek.com/2023/017/t1/socialweb-blogs-reply-comment-post ^2 https://tantek.com/2023/011/t1/indieweb-evolving-at-mention ^3 https://tantek.com/2023/015/t1/publish-indieweb-decide-distribute

Replying to people on the social web used to be “simple” before #socialMedia, when we used blogs. You would either write: 1. a short reply — directly on someone’s blog post comment form, OR 2. a longer reply — on your own blog, in-reply-to & linking to the other post and send a Pingback, expecting at least the other post’s author to see your reply, or you would also write a short comment in their blog post comment form with a brief summary & link to your longer reply post Aside: web forums^1 at the time were proto-silos^2, and replies/threads were generally self-contained therein. Then social media exploded and eventually everybody was replying everywhere all at once. This was so burdensome that some even hired social media managers to perform the labor of how (and if) to reply on each silo, and attempt to keep up with every new silo that popped up. After a few years of this mid-to-late-2000s social web chaos, in the early 2010s many of us went back to option 2. above from the pre-social-media era, and as part of owning our data^3, started posting our replies in general on our own #IndieWeb sites: 1. Regardless of brevity or length, we resumed posting peer-to-peer replies on our personal sites (now sent site-to-site with Webmentions^4), watched destinations retrieve & display our comments, and were pleased that our peer-to-peer comments looked like any other comments (except with permalinks back to our originals). 2. We also started posting replies to tweets, GitHub issues^5, etc. on our own sites, and automatically POSSE-threading them into their sites of origin. 3. When we wrote site-to-site replies where the original post had itself been syndicated to social media^6, we did both 1 & 2. This let readers follow the conversation in either place, providing an #IndieWeb record for if/when the social media thread was taken down, or disappeared along with another silo shutdown^7. Following this 1,2,3 approach helped conceptually simplify replying on the social web, and worked well except for a couple of interesting ongoing challenges: * What is the most efficient user interface path from viewing someone else’s post to writing a reply from your own site? * How should you @-mention someone you are replying to? (and how can our tools write or pre-fill that for us?) Regarding the latter, on day 14 I wrote a bit about how should we @-mention in general https://tantek.com/2023/014/t4/domain-first-federated-atmention though that was more of a general @-mention exploration. As a follow-up to day 14, it’s worth looking into @-reply mentions in particular, specifically for each of the above 1,2,3 contexts, analyzing examples of each, and looking for patterns of @-reply mentions best practices that we can document & recommend. This is day 16 of #100DaysOfIndieWeb #100Days, except I didn’t finish writing it (mostly) til the morning after, and editing later that afternoon. ← Day 15: https://tantek.com/2023/015/t1/publish-indieweb-decide-distribute → Day 17: https://tantek.com/2023/018/t1/elevate-indieweb-above-silo ^1 https://en.wikipedia.org/wiki/Internet_forum ^2 https://indieweb.org/silo ^3 https://indieweb.org/own_your_data ^4 https://tantek.com/2023/012/t1/six-years-webmention-w3c ^5 https://indieweb.org/GitHub#POSSE_to_GitHub ^6 https://tantek.com/2023/015/t1/publish-indieweb-decide-distribute ^7 https://indieweb.org/site-deaths

@dariusdunlap.com thanks for the kind words! Agreed that https://micro.blog/ is currently the best option for getting started with #IndieWeb / #fediverse, and for #TwitterMigration: https://indieweb.org/How_to_transition_from_Twitter

When you publish on your #IndieWeb site, you can decide afterwards where to distribute your content, and when. Figure out how you want to fit into the network of sites & instances. https://indieweb.org/images/6/6a/fit-into-the-network.png https://indieweb.org/POSSE We call this POSSE — for Publish on your Own Site, then Syndicate Elsewhere.^1 By prioritizing your own site, you decide whether (and when) you want to syndicate your posts (or a particular post) to a feed, to a fediverse, to a social media silo or silos, and/or to email like a newsletter. You can make it as simple or as detailed as you want. It’s up to you. Choose deliberately. Change your mind when things change. You can opt out of any destination, either by not opting-in, i.e. explicitly not sending your posts to them, or blocking them if necessary. Here are a few of the destination decisions I’ve made, and reasons why. You can delay sending a post to an RSS or Atom feed, say 10 minutes after the time of publication, to give yourself a chance to edit your post, fix typos or links, before a classic feed reader retrieves and perhaps caches your post. You can further delay sending to known uneditable destinations, like Twitter or email, to give yourself even longer to make further edits, corrections, updates, or improvements based on feedback to your original post. Some destination decisions may depend on the type of post. When you post a reply to someone else’s post, in addition to sending a webmention to that other post, it makes sense to also distribute it to where that other post was originally distributed, or a subset thereof, threading your POSSE reply with their original post POSSE copy. https://indieweb.org/reply#POSSE_a_reply For example, if you reply to someone’s IndieWeb note, and they’ve POSSEd that note to Twitter, you should POSSE your reply to Twitter as well, threading it with their POSSE copy, if you’re still using Twitter that is. If they did not POSSE their original note to Twitter, there may be reasons to POSSE your reply to Twitter anyway, if your reply makes sense there on its own. https://indieweb.org/Twitter#POSSE_Replies_to_Twitter Some destinations have content limitations^2, and you may want to take that into consideration when authoring your content, or not. For example, you may want to more carefully copy-edit the first 256 (for now) characters of a note if you plan to POSSE to Twitter, so that the content that makes it through makes sense as an introduction, or a summary, or a hook, and perhaps has discovery features like hashtags. https://indieweb.org/Twitter#POSSE_Notes_to_Twitter You can use that POSSE tweet text length limitation strategically, placing content after that 256 character cut-off that you may want to edit or expand in an update, or content Twitter may mess-up, like @-domain mentions I described yesterday (day 14). When you publish a multiphoto^3 post, if you’re POSSEing to Twitter, you may want to re-order your photos to choose which four photos show up in your POSSE tweet, e.g. if you happen to be using Bridgy Publish to cross-post your photos to Twitter. You can always re-order your original multiphoto post after POSSEing it. If you’re POSSEing photos to Instagram, since you can only do that manually, there’s no need to edit your original to fit Instagram’s 10-photo limitation, or 2200 characters caption limit, or 30 hashtags limit, or 20 person-tags limit. https://indieweb.org/multi-photo#How_to_POSSE Or you can reconsider what if anything you get from syndicating to Twitter or Instagram. Are people still seeing and interacting with your posts there? Are your friends? If & when social media algorithms deprioritize your original posts in favor of showing more ads, you can deprioritize posting to social media. If & when your friends quit social media silos^4, you can quit posting copies of your posts to those social media silos. You decide what content goes where, when, why, and can change your decisions any time you want. POSSEing to social media was always a stopgap. As social media silos self-destruct, you can stop syndicating to them. Thanks to Chris Aldrich (https://boffosocko.com/) for the banner image. This is day 15 of #100DaysOfIndieWeb #100Days. ← Day 14: https://tantek.com/2023/014/t4/domain-first-federated-atmention → Day 16: https://tantek.com/2023/017/t1/socialweb-blogs-reply-comment-post ^1 https://indieweb.org/POSSE ^2 Day 5: https://tantek.com/2023/005/t3/indieweb-simpler-approach ^3 https://indieweb.org/multi-photo ^4 https://indieweb.org/silo-quits

Previously^1 I asked “How should we @ someone [on the #IndieWeb]?” & suggested we use @-domain. With some web spelunking, the earliest such use I found was 2013-03-26 (~10y ago!) by @eschnou.com, maybe^2 the first #siteToSite #federated #atMention! “And my first ever #indieweb pingback goes to @tantek.com, @aaronparecki.com and @waterpigs.co.uk ! Yes, I can now federate... well.. if I can manage to get it to interop :-)” Though the original post disappeared in a site update (and was unarchived), you can see it on the Internet Archive of @eschnou.com’s #IndieWeb tag page: https://web.archive.org/web/20130609045145/http://eschnou.com/tag/indieweb#2013Mar26 At the time, Barnaby (@waterpigs.co.uk) did confirm receiving that @-mention on his site via Pingback (this was before Webmention was a thing^3): https://waterpigs.co.uk/notes/1199/ (https://twitter.com/BarnabyWalters/status/316664943820812289) @eschnou.com also asked in the IndieWeb chat if @aaronparecki.com had gotten his @-domain mention: https://chat.indieweb.org/2013-03-26#t1364333721000000 You can see at the bottom of that chat log that he did. I myself started using @-domain in my posts ~4 years later in a 2017 reply: https://tantek.com/2017/345/t1/aaronpk-paid-thanks (https://twitter.com/t/status/940382393097228288) though only when the same person controlled the domain and the Twitter @-name of the first part of the domain name before the "." (which was/is not many people. Workaround: use other @-domain mentions in posts after the POSSE tweet cut-off). I think that was my earliest use because two days after that post I added @-domain auto-linking to the https://tantek.com/github/cassis (@cassisjs) "auto_link" function https://github.com/tantek/cassis/commit/0e8e6270c0a3b600423c283f59b5d22c3648d59a (https://twitter.com/cassisjs/status/941107922318381057), likely having already tested it in production on my own site with that post. I’m still #testingInProduction the updates noted in ^3, notably "https:" for all @-mentions (@-name @-domain @-@) and hope to merge them into the repo soon. Aside: both that and the #testInProduction hashtag have hilarious Twitter results^4. Does anyone know of any other auto-linkers that support linking @-domain in plain text to an https URL of that domain? Extra internet points if they also support @-@ auto-linking. This is day 14 of #100DaysOfIndieWeb #100Days. ← Day 13: https://tantek.com/2023/013/t1/indieweb-home-internet → Day 15: https://tantek.com/2023/015/t1/publish-indieweb-decide-distribute ^1 Day 11: https://tantek.com/2023/011/t1/indieweb-evolving-at-mention ^2 I’m curious if StatusNet, OStatus, or OpenMicroBlogging had an explicit syntax for site-to-site @-mentions, whether any of them resembled @-domain, and is there evidence of their earliest @-mention usage (if any) still visible on the web (or Internet Archive) cc: @evanp.me (@evan@prodromou.pub) ^3 Day 12: https://tantek.com/2023/012/t1/six-years-webmention-w3c ^4 Navigating to Twitter hashtag results left as an exercise to the reader, to provide a deliberate soft barrier to a potential doomscrolling trap.

👍

👍

@daviddelven@pkm.social self-hosting^1 is plumbing^2, does not impact key user functionality, and thus not required for an #IndieWeb site. You can switch your site from self-hosted to service-hosted & back and it won’t affect your domain, permalinks, content, readers, peer-to-peer comments, or any other IndieWeb user features. Lastly, “self-hosting” means different things to different people. Some insist it means you have personal physical control of hardware, like a server in your home or garage, some are ok with a physical server in a personal colo cage under lock & key, or a shared colo cage, or a virtual “cloud” server without a physical location. Per the IndieWeb plurality^3 principle, people can use a self-hosted (under any of those definitions) site or a service-hosted site to publish & interact with each other. ^1 https://indieweb.org/self_hosting ^2 https://indieweb.org/plumbing ^3 https://indieweb.org/plurality

Your #IndieWeb site can be the home you’ve always wanted on the internet. https://indieweb.org/images/e/ee/the-home-youve-always-wanted.png https://indieweb.org/homepage While posting on a personal site has many^1 advantages^2 over only posting to #socialMedia, maybe you already quit social media silos^3. There are lots of reasons to get a domain name^4 and setup your own homepage on the web. If you’re a web professional, a personal site with your name on it (perhaps also in its domain) can make it easier for potential employers to find you and read your description in your own words. If you’re a web developer, a personal home page is also an opportunity to demonstrate your craft.^5 If you’re a writer, you can organize your words, essays, and longer form articles in a form that’s easier for readers to browse, and style them to both be easier to read, and express your style better than any silo. Similarly if you’re an artist, photographer, or any other kind of content creator. See https://indieweb.org/homepage for more reasons why, and what other kinds of things you can put on your home page. Thanks to Chris Aldrich (https://boffosocko.com/) for the banner image. This is day 13 of #100DaysOfIndieWeb #100Days. ← Day 12: https://tantek.com/2023/012/t1/six-years-webmention-w3c → Day 14: https://tantek.com/2023/014/t4/domain-first-federated-atmention ^1 https://tantek.com/2023/001/t1/own-your-notes ^2 https://tantek.com/2023/005/t3/indieweb-simpler-approach ^3 https://indieweb.org/silo-quits ^4 https://tantek.com/2023/004/t1/choosing-domain-name-indieweb ^5 https://indieweb.org/creator

🎉 Six years ago today, the #IndieWeb Webmention protocol was published as a W3C REC https://www.w3.org/TR/webmention/ A key social web building block, Webmention enabled peer-to-peer comments, likes, and other responses to be created, updated, and deleted across the web, by both dynamic & static websites. It was accompanied by a report of over a dozen implementations that demonstrated interoperability: https://webmention.net/implementation-reports/summary/ using an open test suite: https://webmention.rocks/ that is still up and running and used by developers today. Many many more implementations have been developed, open sourced, shipped, launched since. The specification itself has a webmention endpoint and accepts webmentions. Exactly a year before that, Webmention was published as a First Public Working Draft by the W3C Social Web Working Group: https://www.w3.org/TR/2016/WD-webmention-20160112/ It took the best parts of the prior Pingback protocol, simplified it (ditched XML-RPC), made it more secure, separated presentation from plumbing, and added update & delete semantics. It was in many ways a model for how open web standards should be developed. See the wiki page for an overview and numerous screenshots of implementations: https://indieweb.org/Webmention If you want to implement Webmention yourself, there are now numerous developer resources to do so. Start here: https://indieweb.org/Webmention-developer and come say hi at the IndieWeb development chat channel: https://chat.indieweb.org/dev Previously, previously, previously: * https://tantek.com/2020/012/t1/happy-birthday-webmention * https://tantek.com/2018/012/t1/anniversary-million-webmentions * https://tantek.com/2017/012/t1/webmntion-first-w3c-recommendation-high-bar This is day 12 of #100DaysOfIndieWeb #100Days. ← Day 11: https://tantek.com/2023/011/t1/indieweb-evolving-at-mention → Day 13: https://tantek.com/2023/013/t1/indieweb-home-internet

One of the fun things about #IndieWeb notes & replies is that how we post is actively evolving! Like how should we @ someone? #socialMedia aliases (e.g. @Twitter) were obvious, with prior @-name usage on Flickr etc. Now, some have a domain, or an @-@ (pronounced at-at, yes, just like the abbreviation for Imperial All Terrain Armored Transport^1), or some have both. We can ask questions like why do we @-someone? What are the use-cases? * In a reply to a public post, clearly express that you’re speaking to that person * In a reply to a reply, that you’re speaking to everyone upthread (AKA a https://indieweb.org/canoe) * When attributing something to someone (photo/post/cool thing by so-and-so), giving credit * Distinguish a person (or something that can be followed) from “just” a site * For all the above, notifying someone accordingly Some ideas: 1. Ideally, if/when everyone has their own domain (where they receive Webmention notifications, and a feed you can follow), we can @-name their domain, which your auto-linker^2 should hyperlink accordingly, e.g. * @aaronparecki.com @anomalily.net @Martymcgui.re‎ @david.shanske.com @voxpelli.com @adactio.com @marcthiele.com @mxb.dev These all look close enough to social media aliases/names that they’re immediately recognizable as readable @-names, a good consideration when choosing a domain name.^3 2. As a fallback (e.g. for non-@-domain-auto-linking destinations) we can use someone’s plain domain (explicitly with https:), especially if their home page still has a stream or feed you can follow, or maybe if they don’t receive homepage Webmentions (yet), e.g.: * https://jacky.wtf/ https://tmichellemoore.com/ https://crowdersoup.com/ 3. Some folks with personal sites have (for now) created separate Mastodon accounts (or installed an instance on a subdomain), and for them, we can reference their @-@ parenthetically after their domain, like: * https://kevinmarks.com/ (@kevinmarks@xoxo.zone), https://dangillmor.com/ (@dangillmor@mastodon.social), https://simonwillison.net/ (@simon@simonwillison.net) Rather than using social media silo @-names (except when explicitly replying to a silo), I’m now experimenting with all three of these (1-3) instead, both to elevate people’s IndieWeb identities, and for Mastodon viewers, provide a convenient way to follow @-@ addresses. If someone’s homepage receives Webmentions, they will get notified when I @-mention them by domain. I recently implemented syntactic auto-linking of @-@ addresses like this: * @user@example.com --> https://example.com/@user with a special case for @-domain@-domain to just link to the domain, e.g.: * @tantek.com@tantek.com --> https://tantek.com/ I also made a recent policy decision to auto-link all @-@ (and @-domain) mentions to https:, the reasoning being that identities on the web should be using https. * Testing in production here: https://tantek.com/cassis.js, search for "auto_link(" Some questions: * Does/do Mastodon (or other ActivityPub servers) notify people when you @-@ mention them in a post? How? Who’s responsible for that? * Will Bridgy Fed notify the servers (deliver to AP inboxes) of folks I merely @-@ mention (rather than explicit replies, reposts)? Should it? So many people are switching to using their personal domains to post (or at least a Mastodon account) that I no longer feel compelled to @-mention people’s Twitter handles in posts, which feels refreshing. Now the fun part is experimenting and figuring out what combination of @-domain, plain domain, or @-@ mentions looks good, makes sense to people, and sends notifications to people the way they want to receive them. This is day 11 of #100DaysOfIndieWeb #100Days. ← Day 10: https://tantek.com/2023/010/t2/build-use-services → Day 12: https://tantek.com/2023/012/t1/six-years-webmention-w3c ^1 https://en.wikipedia.org/wiki/AT-AT ^2 My https://tantek.com/github/cassis/blob/master/cassis.js auto_link() function supports @example.com auto-linking, yours should too. ^3 https://tantek.com/2023/004/t1/choosing-domain-name-indieweb

Once you have a domain^1, and connect it to an #IndieWeb service like https://micro.blog, or a https://indieweb.org/CMS on https://indieweb.org/web_hosting, you can focus^2 on your writing. Or if you enjoy #webDevelopment and want to build (option three^3), use developer services to more rapidly add IndieWeb building blocks^4 to your site so you too can focus on creating & owning your content^5. Here are some of the most common and popular developer services: 1. Webmention sending: https://webmention.app/ by https://remysharp.com/ (@rem@front-end.social), or https://mention.tech/ by https://kevinmarks.com/ (@kevinmarks@xoxo.zone) 2. Webmention receiving: https://webmention.io/ (I use this) by https://aaronparecki.com/ or https://webmention.herokuapp.com/ by https://voxpelli.com/ (@voxpelli@mastodon.social) 3. POSSE & backfeed: https://brid.gy/ by Ryan of https://snarfed.org/ (@schnarfed) 4. ActivityPub federating: https://fed.brid.gy/ also by Ryan. More on Bridgy & Bridgy Fed^6. Using a developer service to support IndieWeb protocols saves you time. You can also contribute to the community by filing suggestions for improvements, or participating on their GitHub repositories. If you prefer that your site not depend on any external services, you can do that too. Most of the above services are also open source that you can install and fully manage yourself. For example: * Webmention installable services: https://indieweb.org/Webmention#Publisher_Services Another option is to use one of many open source libraries to more rapidly implement support for IndieWeb standards^7. The wiki pages for each standard list libraries in a variety of programming languages, e.g.: * https://indieweb.org/Webmention-developer#Libraries If you choose the path of installing or building something new with libraries or by directly implementing an IndieWeb standard, be sure to test your implementation with its test suite, e.g.: * https://webmention.rocks/ As a web developer, you can choose how much of your #IndieWeb support you want to implement yourself (and time to invest) vs build on the services, libraries, and other open source that the community has produced and is actively supporting. This is day 10 of #100DaysOfIndieWeb #100Days. ← Day 9: https://tantek.com/2023/009/t2/edit-reply-comment-update → Day 11: https://tantek.com/2023/011/t1/indieweb-evolving-at-mention ^1 https://tantek.com/2023/004/t1/choosing-domain-name-indieweb ^2 https://tantek.com/2023/005/t3/indieweb-simpler-approach ^3 https://tantek.com/2023/003/t1/indieweb-path-chosen-why ^4 https://indieweb.org/building_blocks ^5 https://tantek.com/2023/001/t1/own-your-notes ^6 https://tantek.com/2023/008/t7/bridgy-indieweb-posse-backfeed ^7 https://spec.indieweb.org/

https://kevinmarks.com/ good catch and thanks. Fixed the typos and resent a Webmention to #BridgyFed using https://mention.tech/ — we’ll see if the cache of my post on your instance is updated.

Sometimes it’s the little things, like editing a post. Edit a reply, see a comment update on another post. From day 5 (https://tantek.com/2023/005/t3/indieweb-simpler-approach) * Can I edit my post after publishing? Whether a tweet or Instagram photo, the answer is no.^1 Blogs and websites have had editing capabilities since the start. However, no site is an island, it’s a *web* site. Interlinked. We expect edits on one site to show up when embedded or syndicated on other sites. #Webmention provides the ability for cross-site comments, and unlike the "one-off" prior protocols of Trackbacks & Pingbacks^2, when you update a cross-site comment, by resending a Webmention, the other post updates its copy of your reply: https://www.w3.org/TR/webmention/#sending-webmentions-for-updated-posts If you delete a reply, by resending a Webmention, the other post can delete its copy (or mark it as deleted) https://www.w3.org/TR/webmention/#sending-webmentions-for-deleted-posts Similarly, the #ActivityPub protocol specifies update & delete capabilities, as implemented by #Mastodon and others. #BridgyFed (https://fed.brid.gy) bridges (as the name says) these two protocols, which enables the following interactions. #IndieWeb post -(Webmention)-> BridgyFed -(ActivityPub)-> Mastodon displays post and then this: IndieWeb updated post -(Webmention)-> BridgyFed -(ActivityPub)-> Mastodon displays updated post This works for replies to toots as well: IndieWeb reply to toot -(Webmention)-> BridgyFed -(ActivityPub)-> toot displays reply and subsequently: IndieWeb updated reply -(Webmention)-> BridgyFed -(ActivityPub)-> toot updates display of reply Thanks to these update protocols in Webmention & ActivityPub, and BridgyFed connecting them, after adding “forward-in-time” links (https://tantek.com/2023/006/t1/forward-in-time-links) I was able to resend webmentions for my previous #100DaysOfIndieWeb posts, and have those forward links show up wherever my posts were already displayed on Mastodon. Posts interlinked with replies interlinked with protocols interlinked. This is day 9 of #100DaysOfIndieWeb #100Days. ← Day 8: https://tantek.com/2023/008/t7/bridgy-indieweb-posse-backfeed → Day 10: https://tantek.com/2023/010/t2/build-use-services ^1 The ability to edit tweets has literally been the most requested feature on Twitter since perhaps its launch. Last year, paid Twitter “Blue” accounts finally got the ability to edit tweets, sort of: five times within 30 minutes of posting. Too little, too late. * https://techcrunch.com/2022/10/03/twitters-edit-button-is-rolling-out-to-blue-subscribers-in-canada-australia-and-new-zealand/ * https://blog.hootsuite.com/can-you-edit-a-tweet/ * https://www.pcmag.com/news/twitters-edit-button-is-coming-soon-for-paid-users * https://www.macrumors.com/2022/10/06/twitter-edit-tweet-option-united-states/ * https://9to5mac.com/2022/10/06/twitter-rolling-out-edit-button/ ^2 Pingbacks were originally (and for many years) only implemented as one-off cross-blog interactions. One-time, uneditable. Pingbacks (and Trackbacks before them) were notoriously ugly when they showed up on blogs, listed & displayed as a separate thing (never tie presentation to the name of a protocol) with cryptically elided summaries: https://indieweb.org/pingback#Poor_display. Over 10 years after Pingback was specified (2002), the then nascent (founded 2011) IndieWeb community re-used pingbacks for actual comments across sites in 2013: https://tantek.com/2013/113/b1/first-federated-indieweb-comment-thread separating presentation & UI from the protocol. This separation of concerns approach evolved into the Webmention specification, separating the protocol from the display of comments, likes, reposts, and other social web https://indieweb.org/responses.

https://jhey.dev/ (@jhey@front-end.social) hey! thanks for the kind words. Two sides to supporting #webmentions: 1. Sending: https://webmention.app/ is excellent, by https://remysharp.com/ (@rem@front-end.social), or you can write your own Webmention sending loop using endpoint discovery libraries, and in that loop you can do other things, like also send each link to the Internet Archive (https://indieweb.org/Internet_Archive#Trigger_an_Archive, what I do on my site) to archive each link as of the time you linked to it. 2. Receiving: https://webmention.io/ (which is what I use) by https://aaronparecki.com/ as recommended by https://mxb.dev/ (@mxbck@front-end.social), or https://webmention.herokuapp.com/ by https://voxpelli.com/ (@voxpelli@mastodon.social) as recommended by https://kryogenix.org/ (@sil@mastodon.social). Similarly to sending, you could also write your own Webmention receiving code. Then the fun part, once you’re receiving webmentions, is figuring out how you want to display them as comments, likes, reposts etc. on your post permalinks. Do you display people’s icons/avatars, at what resolution? Do you display the entirety of comments or do you elide them at 255 characters (or some other limit)? Etc. If(when) you start storing received webmentions in your own site/server’s storage, there’s a bunch more interesting considerations. More resources: * https://indieweb.org/Webmention-developer That’s a good start. Drop by https://chat.indieweb.org/dev for deep dives into any of the above, and welcome to the Webmentionverse

11 years ago today, Ryan Barrett (https://snarfed.org/ @schnarfed) launched Bridgy (https://brid.gy/) to copy #socialmedia replies as comments on original blog posts. This meant those of us building #IndieWeb sites could use a service for that functionality, instead of having to write code ourselves, for each proprietary API. When a few of us originally started syndicating to silos (https://indieweb.org/POSSE), and sometimes reverse-syndicating replies (https://indieweb.org/backfeed), we had to write custom code to do so, calling each social media API (like Twitter) both ways. Bridgy alleviated some of that burden, and over time added support for more silos, sometimes dropping support when they were shutdown (Google+, Buzz) or scuttled their APIs (Facebook). While Bridgy started only with backfeed as a service, it eventually added publishing support, POSSE as a service. Even though I already had code working to POSSE text notes to Twitter, when I added photo posting support to my site, rather than write more code to call Twitter’s API, I started conditionally using Bridgy Publish to POSSE my photo (and video) posts. In 2017, Ryan launched Bridgy Fed (https://fed.brid.gy) which he has substantially improved in the past few months. I and many others now use Bridgy Fed to broadcast to & interact with Mastodon (and other ActivityPub) servers, without having to write any ActivityPub, Webfinger etc. code ourselves. https://tantek.com/2022/301/t1/twittermigration-bridgyfed-mastodon-indieweb Every user of Bridgy Fed gets a nice dashboard for notifications and activity. Here’s mine: https://fed.brid.gy/user/tantek.com Bridgy is a great example of a project that was started to fulfill a personal need (https://indieweb.org/make_what_you_need), growing to support broader community needs. Read more about Bridgy & Bridgy Fed: * https://indieweb.org/Bridgy (including Publish) * https://indieweb.org/Bridgy_Fed * Launch post: https://snarfed.org/2012-01-08_bridgy_launched It’s this hybrid of encouraging personally relevant work and community contributions that makes the #IndieWeb community special. Yes there is a focus on greater independence with your personal website. However we can all do more by working together. We achieve more independence, more quickly, by collaborating in community. This is day 8 of #100DaysOfIndieWeb #100Days. ← Day 7: https://tantek.com/2023/007/t2/more-100daysofindieweb-projects → Day 9: https://tantek.com/2023/009/t2/edit-reply-comment-update

@aaronpk @denicmarko It’s worse than that static snapshot (curious how you found it). See: https://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces#ud And there’s ~12 years of research & updates pending since.

@jlgatewood@mastodon.cloud my notepad++ equivalent is BBEdit http://www.barebones.com/products/bbedit/index.html (@bbedit@mastodon.social), which as they say “doesn’t suck”, on the contrary, it’s been a fast, solid, & reliable text editor for decades. It’s even faster & more dependable than Apple’s built-in “Notes” app which has become quirkier and *worse* in recent OS updates (e.g. weirdly linking #hashtags when I wish it would leave them alone, without a preference for turning that off). However yes, when I post a new #100DaysofIndieWeb post, I’m “copypasta”-ing as you say the new permalink into the previous day’s post, and vice versa, using BBEdit of course.

https://nataliekraneiss.com/ (@natalie@hcommons.social) I agree with your concerns about not being “able to edit or delete the syndicated posts afterwards”. In short, my personal site tantek.com is its own “instance” but without running Mastodon. I use https://fed.brid.gy/ to connect my site directly to #fediverse sites like Mastodon servers, without any need for syndication, cross-posting, or publishing copies of my posts. More details here: https://tantek.com/2022/301/t1/twittermigration-bridgyfed-mastodon-indieweb Because I use my site directly, I can edit/update/delete posts, and send a Webmention to #BridgyFed to propagate those changes to any #fediverse servers caching my post, all of which update themselves accordingly. I’m not that familiar with the WordPress ActivityPub plugin, however, there’s a great community of folks who can help with any questions about it here: https://chat.indieweb.org/wordpress Hope that helps and good luck!

@daviddelven@pkm.social that post is day 4 of my #100DaysOfIndieWeb project which I started on January 1st: Day 1: https://tantek.com/2023/001/t1/own-your-notes That and subsequent days should help provide context. For example, I noticed you have your own personal domain daviddelgado.cat, yet it seems to redirect to a Linktree. One way to make your web presence more #IndieWeb would be to use a static page served directly on your domain for that, instead of redirecting to a 3rd party service. If you feel comfortable with HTML+CSS, you could follow the instructions at https://indieweb.org/GitHub_Pages to setup a free static GitHub page to serve at your domain, and add all the same links you have on your Linktree.

@nomdeb@mstdn.social that’s good to know. Yes, I’ve seen these “follower collectors” as well. Hard to believe that such a high percentage of Twitter followers are dormant, or perhaps just bots or brands. I think you’re right that Twitter algorithms are pushing down our real person/connection posts, “in favor of engagement types of tweets”. Since a month ago, the differences have grown on my recent posts: Now ~6.3x (up from 2x) more #fediverse responses per post than Twitter, ~900:1 (up from ~500:1) difference per follower (having ~142x more Twitter followers).

https://crowdersoup.com/ (@CrowderSoup@hachyderm.io) glad to hear it and congrats on starting your #100DaysOfIndieWeb project! I added you to the list on the #IndieWeb wiki: * https://indieweb.org/100_days#2023 Keep up the good work!

There are more 2023 #100DaysOfIndieWeb projects, you should check them out: * https://tmichellemoore.com/blog/tag/100daysofindieweb/ (@tmichellemoore@mastodon.social) * https://crowdersoup.com/tags/100days (@CrowderSoup@hachyderm.io) Got one? Reply and I’ll add it. You can (re)start a #100Days project any day. While continuity is nice, you can take breaks. As https://kevinmarks.com/ (@kevinmarks) said in #IndieWeb chat: * https://indieweb.org/life_happens and should take priority over artificial deadlines. It all started back in 2017 when https://aaronparecki.com/ did the first #100DaysOfIndieWeb project: * https://aaronparecki.com/tag/100daysofindieweb * @100daysindieweb Want to start one of your own? See past & present IndieWeb related 100 days projects for ideas & inspiration: * https://indieweb.org/100_days This is day 7 of #100DaysOfIndieWeb. ← Day 6: https://tantek.com/2023/006/t1/forward-in-time-links → Day 8: https://tantek.com/2023/008/t7/bridgy-indieweb-posse-backfeed

https://dangillmor.com/ I found a way: https://tantek.com/2023/006/t1/forward-in-time-links

https://dangillmor.com/ wishes for “forward-in-time links so we could read … his 2023 #100Days project, #100DaysOfIndieWeb … more easily from the beginning” https://mastodon.social/@dangillmor/109646621709452885 Great suggestion Dan. Wish granted. On my #IndieWeb site, I control the user experience. Since 2010^1, I’ve had previous/next ( ← → ) temporal^2 navigation links on the top right of my post permalinks, across all posts (something I always wanted on my notes, and Twitter lacked) In 2018^3, I added similar ( ← → ) links on day archive pages, for previous/next days. Ideally I’d build similar automatic ( ← → ) links for each hashtag in a post, for the previous/next post with that same hashtag. OR for now I could manually add forward-in-time links to the bottom of my five previous #100DaysOfIndieWeb posts, and with each subsequent post, remember to update the previous one. So that’s what I did, am doing, per https://indieweb.org/manual_until_it_hurts. Previous #100DaysOfIndieWeb posts updated. This is day 6 of #100DaysOfIndieWeb #100Days, which is now a https://en.wikipedia.org/wiki/Doubly_linked_list ← Day 5: https://tantek.com/2023/005/t3/indieweb-simpler-approach → Day 7: https://tantek.com/2023/007/t2/more-100daysofindieweb-projects Previously, previously, previously: ^1 https://tantek.com/2010/032/t7/inventions-to-tweet-from-site ^2 https://tantek.com/2011/102/t2/navigation-arrows-back-past-forward-future-ui-pattern ^3 https://tantek.com/2018/308/t2/indiewebcamp-archive-navigation-day-archives

The #IndieWeb approach *is* the simpler day-to-day approach. Once you setup your domain & provider (or host/CMS), you always know where to post. Your own site. Write first, defer “destination decisions”. Create first, edit for audience(s) second. It’s refreshing & liberating. Whether text, photos, videos, podcasts, brief thoughts, thinking out loud, a considered essay or “thought piece”, or replies to any of the above, start with your own site. Why burden yourself with having to decide what to post based on: * Will this fit in 140^H^H^H 280 characters? * Or 500? * Does it need a title? * Will my photos/videos fit their aspect ratio limits? * Which four photos for this album? Or 10? What one aspect ratio to crop them all into? * Will my video fit in 15, 30, 90, or 140 seconds? * Will I upset Big Chad or be subject to selective enforcement of ever-changing policies? * Can I edit my post after publishing? By decoupling creating from “distribution”, or “audience”, or “reach”, or the size of someone else’s storage boxes, you are free to express your thoughts first, then optionally decide if you want to share them elsewhere and edit as necessary. If you do want to syndicate (POSSE) your post, then you can decide: * Where else to send your post * Is it worth your time to edit your post for any particular destination * … their content limits (number of characters/photos, or video length) * … their audience expectations or terms of service sensitivities Creating and editing are different mental tasks. Decoupling them makes posting easier and you can do a better job at both. You can defer destination decisions & editing to some point in the future entirely, when you feel it’s worth your time. You decide how and when to spend time creating vs editing. You are in control. This is day 5 of #100DaysOfIndieWeb #100Days ← Day 4: https://tantek.com/2023/004/t1/choosing-domain-name-indieweb → Day 6: https://tantek.com/2023/006/t1/forward-in-time-links

https://pauljacobson.me/, I setup my https://micro.blog/t to syndicate in posts from my site via its Atom feed. It’s standards-based POSSE from my site to micro.blog to make it easier for folks there to follow me / my posts.

“I need a quad over ice.” 📺 #Wednesday E1 34:17 Ah, my 2008-era coffee order, just darker (no surprise) https://twitter.com/t/status/920915648 Feeling seen. (Aside: 💁🏻‍♂️🦋 Is this a quote tweet?)

Choosing a domain name is a key step toward getting your own #IndieWeb site. Like choosing an account name (chat, email, Mastodon) but global, feels more personal, and like more of a commitment. Six tips: 1. Use some form of your name (given & family), so you have a chance of having your site and posts show up when people search for you 2. Or a made-up nickname that fits you now and into the future 3. Something easily memorable, speakable, & spellable to better tell people in-person or on the phone (i.e. avoid "cute" or "weird" spellings like dropping vowels) 4. Use https://domai.nr/ to quickly try variants 5. Try to get a .com .net or .org, which are still seen as more legitimate. A .me is ok, as is your country/region (e.g. .us .uk .eu etc. see https://indieweb.org/ccTLD for more examples) 6. Shorter is better for many reasons: https://indieweb.org/short-domains Once you find an available name, choose a domain registrar, which is like choosing a phone company, except there are more of them. Some recommendations: https://indieweb.org/personal-domain#Domain_Registrars Got questions, or want more tips & opinions? Ask in https://chat.indieweb.org/ — you’ll get a lot of sympathy & support as nearly everyone there has gone through this process, and many are eager to share their experiences to make it easier for new folks. https://indieweb.org/naming is hard, it’s ok to ask for help. This is day 4 of #100DaysOfIndieWeb #100Days ← Day 3: https://tantek.com/2023/003/t1/indieweb-path-chosen-why → Day 5: https://tantek.com/2023/005/t3/indieweb-simpler-approach

Is it hard to setup & use your own #IndieWeb site? Depends on the path chosen, and why. 1 turnkey: get a https://micro.blog/ - easier than #Mastodon, works with 2 #webdev: install a https://indieweb.org/CMS - needs tech knowhow 3 builder: assemble https://indieweb.org/building_blocks as desired, experiment, iterate, and explore how deep the rabbit hole goes All paths share perhaps the hardest part: Picking a domain name. Next, tips for choosing one. This is day 3 of #100DaysOfIndieWeb #100Days ← Day 2: https://tantek.com/2023/002/t6/key-owning-notes-domain-name → Day 4: https://tantek.com/2023/004/t1/choosing-domain-name-indieweb

The key to owning your notes is posting them with permalinks using a domain name you control. That’s it. https://indieweb.org/permalink There are many providers, like https://micro.blog/, that happily enable using your own domain name for everything you post. This gives you the ability to change your provider, while preserving your post permalinks. From the web’s perspective, your posts work just as they did before. You are in control. This is day 2 of #100DaysOfIndieWeb #100Days #IndieWeb. ← Day 1: https://tantek.com/2023/001/t1/own-your-notes → Day 3: https://tantek.com/2023/003/t1/indieweb-path-chosen-why

@zeina@mstdn.ca “incredibly dev-centered” is a valid criticism, and yes we need to make POSSE work in a simple & predictable way for everyone. The key way to use micro.blog to make things “truly yours” is to do so with your own domain. Then you own all the permalinks, and can migrate to another provider or CMS while preserving your permalinks.

@zeina@mstdn.ca, good questions to ask when considering a “provider” (of any sort). https://micro.blog/ is a paid service (~$5/mo last I checked), while Tumblr is not. micro.blog is more like a professional storage service, with a similar relationship and incentives, rather than a neighborhood garage which depends more on the whims and available time & interest of the admin. I personally agree with “spinning up your own CMS” for a variety of semi-obvious reasons, however, that requires a web development skillset (and perhaps time & patience) that few have or have cultivated. Hence a turn-key for-pay service (with tons of export options at sign-up time) may help many more to join and interact peer-to-peer with other #IndieWeb sites.

https://craveytrain.com/, thanks for the kind words! Big believer in walking the talk, and the persuasive power of live examples. That’s a fine 2023 commitment! If you’d like, drop by https://chat.indieweb.org/dev/ and feel free to share your thoughts-in-progress on how to own and publish your content (on your own domain).

https://brunopedro.com/ (@bpedro), thanks for the boost! Which tool or service are you using to cross-post from Mastodon to Twitter (as a tweetstorm for longer posts no less)? I’d like to find a way for a POSSE of a Mastodon boost to discover the corresponding POSSE tweet, and retweet that rather than re-posting the original post as a tweetstorm. Also curious how your system came up with “@tantek.com@fed.brid.gy” as I’ve never used that @-@, and my site is setup to show “@tantek.com@tantek.com” as its @-@ address.

https://jwz.org, thanks for the RT/boost. Am curious how you happened upon the POSSE tweet copy presumably first, rather than the original https://tantek.com/2023/001/t1/own-your-notes which should be natively visible on the “fediverse” (like this reply), perhaps by copy/pasting that URL into a Mastodon search box. Hoping to find ways to improve original post discovery, so tools can (semi-)automatically convert such POSSE links to original post permalinks when sharing/replying/reposting etc.

I am once again asking you to own your notes, rather than tweeting them into Big Chad’s garage. Maybe you left the big garage and now toot in your neighborhood Chad’s garage. It’s still someone else’s garage. https://xkcd.com/1150 #IndieWeb Maybe it was an easier first step to take. Time to take the next step, with your own domain, and a turnkey service like https://micro.blog/, or an https://indieweb.org/CMS if you prefer, or go full stack and make it yourself, using building blocks like https://indieweb.org/Indiekit. Just https://indieweb.org/start. This is day 1 of my 2023 #100Days project, #100DaysOfIndieWeb, posting an #IndieWeb encouragement, tool, or tip at least once a day for 100 days, to setup and use your own personal site instead of someone else’s garage. In the theme of: https://indieweb.org/100_days#100_Days_of_IndieWeb Previously: https://tantek.com/2022/001/t1/12-years-notes-my-site ← ✨ → Day 2: https://tantek.com/2023/002/t6/key-owning-notes-domain-name