Five years ago last Monday, the @W3C Social Web Working Group officially closed¹.

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², the basis of Tim Berners–Lee’s startup Inrupt.

However, in the post Elon-acquisition of Twitter and subsequent Twexodus, as Anil Dash noted³, “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⁴, 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⁵ 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⁶.

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⁷ 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⁸.

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
→ 🔮


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:
¹ https://www.w3.org/wiki/Socialwg
² https://www.w3.org/wiki/Socialwg/2015-03-18-minutes#solid
³ https://mastodon.cloud/@anildash/109299991009836007
⁴ https://websub.rocks/
⁵ https://indieweb.org/Social_Web_Working_Group#History
⁶ https://tantek.com/2023/008/t7/bridgy-indieweb-posse-backfeed
⁷ https://indieweb.org/plurality
⁸ https://indieweb.org/use_what_you_make

Nineteen years ago last Saturday, @KevinMarks.com & I introduced¹ #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², 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³, now the standard for decentralized social media verification on Mastodon⁴, GitHub⁵, elsewhere, and the basis of RelMeAuth⁶
* XMDP — XHTML MetaData Profiles, notably using an HTML class⁷ 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⁸, 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:
¹ https://tantek.com/presentations/2004etech/realworldsemanticspres.html
² https://tantek.com/log/2004/02.html#d04t1311
³ https://gmpg.org/xfn/11#me
⁴ https://docs.joinmastodon.org/user/profile/#verification
⁵ https://hachyderm.io/@nova/109790530971147702
⁶ https://tantek.com/2023/032/t1/years-relmeauth-replace-openid
⁷ https://tantek.com/2012/353/b1/why-html-classes-css-class-selectors
⁸ http://microformats.org/wiki/events/2007-12-11-open-media-web

11 days ago I suggested¹ 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² 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³.

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
 

¹ https://chat.indieweb.org/2023-02-02#t1675370124338700
² https://en.wikipedia.org/wiki/Apple_Open_Collaboration_Environment
³ https://indieweb.org/own_your_data

I got auto-Unicode & linking footnotes¹ 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², all previous posts with such "^n" style footnotes have also been updated, like my day 6 post³ 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⁴. 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⁵.


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


¹ https://tantek.com/2023/036/t1/footnotes-unicode-hyperlink
² https://tantek.com/cassis.js
³ https://tantek.com/2023/006/t1/forward-in-time-links
⁴ https://tantek.com/
⁵ https://indieweb.org/footnote

Taking a closer look at both my syntax and use-cases of footnotes in posts¹ 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¹ 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² 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
 

¹ https://tantek.com/2023/036/t1/footnotes-unicode-hyperlink
² 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¹ of the Twitter API likely also means the end of free Log in with Twitter² delegated signin service³.

If you use [Sign in with Twitter]⁴, consider replacing it with Web sign-in⁵, implementing #RelMeAuth⁶ & #IndieAuth⁷ (OAuth for the #openWeb⁸) ASAP!

If you already have your own domain (go get one⁹), add a link from your home page to your GitHub profile with rel=me¹⁰, 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


¹ https://www.theverge.com/2023/2/2/23582615/twitter-removing-free-api-developer-apps-price-announcement
² https://indieweb.org/Log_in_with_Twitter
³ https://indieweb.org/silo_sign-in
⁴ https://indieweb.org/Log_in_with_Twitter#Button
⁵ https://indieweb.org/Web_sign-in
⁶ https://tantek.com/2023/032/t1/years-relmeauth-replace-openid
⁷ https://indieauth.spec.indieweb.org/
⁸ https://indieauth.net/
⁹ https://tantek.com/2023/004/t1/choosing-domain-name-indieweb
¹⁰ 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¹
* @progrium.com suggested RelMeAuth name²
* I agreed, and wrote up a draft algorithm³

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⁴).


And today, @Github.com rolled out support for multiple rel=me profile links!⁵

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⁶). 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


¹ https://tantek.com/2010/032/t5/modest-proposal-authentication-oauth-twitter-rel-me
² https://twitter.com/progrium/status/8521001762
³ https://tantek.com/2010/032/t6/relmeauth-oauth-rel-me-auto-fallback-authentication
⁴ 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.
⁵ https://hachyderm.io/@nova/109790530971147702
⁶ https://tantek.com/2022/144/t1/redirected-github-ownyourlinks

Is the #IndieWeb just blogs/blogging?

What if I told you the phrase indie web¹ is older than the word blog or weblog²?

The IndieWeb, as it says on the homepage³, also goes beyond blogging⁴.

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⁵, I used it descriptively, an informal shorthand for the "independent web". I didn’t find out about the 1997¹ use of the phrase until many years later.

I saw & was a fan of the 2001 launch of the "Independents Day" site & its manifesto⁶ (at independentsday(.)org, since offline) that asked “if you create⁷ your own site”, to join them. That encouragement stuck with me, and was a source of inspiration nine years later.

In my presentation⁸ at the 2010 Federated Social Web Summit⁹, I referenced the "indie web" again, and afterwards I proposed to @aaronparecki.com that we start something focused on explicit principles & practices.¹⁰

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¹¹.

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¹², or a handful of static pages like a portfolio¹³.

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.⁴

The aforementioned principles¹¹ 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¹⁴ 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¹⁵ typical in social media (but lacking in blogs), and site-to-site social web interactions¹⁶, 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¹⁷, 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


¹ 1997-02-01 https://web.archive.org/web/20010805195949/http://www.uzine.net/article63.html
² https://en.wikipedia.org/wiki/Blog#History
³ https://indieweb.org/#Beyond_Blogging_and_Decentralization
⁴ https://indieweb.org/different
⁵ http://tantek.com/2010/123/t2/blogger-turned-off-ftp-what-indie-web-diso (https://twitter.com/t/status/13329370781)
⁶ https://indieweb.org/Independents_Day
⁷ https://indieweb.org/creator
⁸ https://web.archive.org/web/20100723133231/http://federatedsocialweb.net/wiki/2010-199-tantek-fsws-talk
⁹ https://indieweb.org/Federated_Social_Web_Summit#Portland_2010
¹⁰ https://indieweb.org/founders#IndieWeb_movement_and_terminology
¹¹ https://indieweb.org/principles
¹² https://indieweb.org/homepage
¹³ https://indieweb.org/portfolio
¹⁴ https://tantek.com/2023/001/t1/own-your-notes
¹⁵ https://indieweb.org/posts#Types_of_Posts
¹⁶ https://indieweb.org/responses
¹⁷ https://chat.indieweb.org/

Another interesting contrast¹ in the #IndieWeb community is that most of us have both:
* a domain name² — for posting our content, replies, likes etc.
* a chat-name³ — for chatting in our discussion channels⁴

Ideally, we would have a discussion system that “just” used our domain names as identities (IndieAuth⁵ for Web sign-in⁶) 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⁷. 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² instead of being stuck in an actual catch-22¹ of needing a domain name just to ask about a domain name.

By putting our chat archives on the web⁸, 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⁹. 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⁸ could be more closely tied to our domain identities, including our personal icons¹⁰. Rather than a complex system or new protocol, we just put our flat list of nicknames in templates with images & domains on the wiki¹¹.

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.¹

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¹¹ 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⁸ and say hi, and be sure to have a look at our Code of Conduct.¹²


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


¹ https://tantek.com/2023/026/t1/indieweb-priorities-balance
² https://tantek.com/2023/004/t1/choosing-domain-name-indieweb
³ https://indieweb.org/chat-names
⁴ https://indieweb.org/discuss
⁵ https://indieweb.org/IndieAuth
⁶ https://indieweb.org/Web_sign-in
⁷ https://indieweb.org/admintax
⁸ https://chat.indieweb.org/
⁹ https://indieweb.org/discuss#Join_Discussions
¹⁰ https://indieweb.org/icon
¹¹ https://indieweb.org/chat-names#Nicknames
¹² https://indieweb.org/code-of-conduct

Five years ago (Monday the 23rd) the @W3C Social Web Working Group published the WebSub Recommendation¹

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² and there are many more supporting sites³.

Beyond publishing blog posts and realtime updates in social readers⁴, there are additional WebSub use-cases such as real time #IndieWeb search⁵ 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⁶ standards⁷ like WebSub.

If you create a new WebSub implementation, be sure to test it with the test suite⁸ and add your results to the WebSub Implementation Reports repo⁹.

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


¹ https://www.w3.org/TR/2018/REC-websub-20180123/
² https://pubsubhubbub.superfeedr.com/
³ https://indieweb.org/WebSub#IndieWeb_Examples
⁴ https://indieweb.org/social_reader
⁵ https://indieweb.org/IndieWeb_Search
⁶ https://indieweb.org/building-blocks
⁷ https://spec.indieweb.org/
⁸ https://websub.rocks/
⁹ https://websub.net/implementation-reports

↳ In reply to bw3.dev’s post 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.

↳ In reply to hachyderm.io user liztai’s post @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.

↳ In reply to mastodon.social user voxpelli’s post @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¹, yet share publicly, perhaps CC0²
* Control of your design³, yet lack of control elsewhere⁴
* UX freedom & creativity, yet guidance toward common patterns for usability
* Decentralized, yet DNS
* Make what you need⁵, yet open source⁶ for others
* Plurality⁷ of projects, yet conforming to standards⁸
* 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⁹ and principles¹⁰.

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


¹ https://tantek.com/2023/001/t1/own-your-notes
² https://indieweb.org/IndieWeb:Copyrights
³ https://indieweb.org/design
⁴ https://indieweb.org/display-guidelines
⁵ https://indieweb.org/make_what_you_need
⁶ https://indieweb.org/open_source
⁷ https://indieweb.org/plurality
⁸ https://spec.indieweb.org/
⁹ https://indieweb.org/
¹⁰ https://indieweb.org/principles

↳ In reply to ohai.social user AnokheeTara’s post @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

↳ In reply to hachyderm.io user liztai’s post @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!

↳ In reply to hachyderm.io user liztai’s post @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¹

Still tweeting in Big Chad’s garage or tooting in little Chad’s garage next door?² What’s the delay?

Choosing a domain name?³
Or a service or other path?⁴
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⁵, @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⁶ 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


¹ https://tantek.com/2023/001/t1/own-your-notes
² https://xkcd.com/1150/
³ https://tantek.com/2023/004/t1/choosing-domain-name-indieweb
⁴ https://tantek.com/2023/003/t1/indieweb-path-chosen-why
⁵ https://tantek.com/2022/358/t3/
⁶ https://indieweb.org/CMS

One of our #IndieWeb principles is Use What You Make¹. We use the metaphor Eat What You Cook² to more broadly relate to creators³ 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⁴ 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⁵ 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⁴, 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⁶

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


¹ https://indieweb.org/use_what_you_make
² https://indieweb.org/eat_what_you_cook, much more palatable than prior "selfdogfood" or "dogfood" metaphors from other open source related communities.
³ https://indieweb.org/creator
⁴ https://indieweb.org/test_in_production
⁵ https://tantek.com/2023/011/t1/indieweb-evolving-at-mention
⁶ https://indieweb.org/test_in_production#IndieWeb_Examples

When you setup your site with Bridgy Fed¹, 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" alt="fediverse address" value="" />
 <input name="domain" type="hidden" value="tantek.com" />
 <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


¹ https://tantek.com/2023/008/t7/bridgy-indieweb-posse-backfeed

↳ In reply to hachyderm.io user liztai’s post @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. 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².

Then *two years* after that @willnorris.com (@will@willnorris.com) and I finally came up with the name/acronym POSSE!³

¹ https://web.archive.org/web/20130312135439/http://www.monkinetic.com/2010/05/26/tantek-celik-diso-20-brass-tacks
² https://www.flickr.com/photos/tantek/5301870765/
³ 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¹ 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², 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³?
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⁴ 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⁵).
 

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


¹ https://tantek.com/2023/017/t1/socialweb-blogs-reply-comment-post
² https://tantek.com/2023/011/t1/indieweb-evolving-at-mention
³ https://tantek.com/2023/015/t1/publish-indieweb-decide-distribute
⁴ https://indieweb.org/in-reply-to
⁵ https://indieweb.org/multiple-reply

↳ In reply to w3c.social user w3cdevs’s post 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.

↳ In reply to devdilettante.com user roland’s post 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!

↳ In reply to mastodon.cloud user swart’s post @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

↳ In reply to novakeith.net’s post @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?”¹ 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², 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³? 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


¹ https://tantek.com/2023/017/t1/socialweb-blogs-reply-comment-post
² https://tantek.com/2023/011/t1/indieweb-evolving-at-mention
³ 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¹ at the time were proto-silos², 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³, 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⁴), 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⁵, 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⁶, 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⁷.


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


¹ https://en.wikipedia.org/wiki/Internet_forum
² https://indieweb.org/silo
³ https://indieweb.org/own_your_data
⁴ https://tantek.com/2023/012/t1/six-years-webmention-w3c
⁵ https://indieweb.org/GitHub#POSSE_to_GitHub
⁶ https://tantek.com/2023/015/t1/publish-indieweb-decide-distribute
⁷ https://indieweb.org/site-deaths