Show Navigation
Notices tagged with indieweb, page 4
-
I am running for election in this month’s #W3C (@w3.org @w3c@w3c.social @w3c) Advisory Board (AB) election¹ and blogged my personal statement: https://tantek.com/2023/128/b1/running-for-w3c-advisory-board-ab-election
@fantasai.inkedblade.net (@fantasai@w3c.social @fantasai) is also running for the #W3CAB, and admirably blogged her imminent affiliation change *before* the election started: https://fantasai.inkedblade.net/weblog/2023/affiliation-change/ — Congrats Elika! Your new affiliation is lucky to have you.
In addition to the two of us, @cwilso.com (@cdub@mastodon.social @cwilso) also posts on his own blog and is running for the AB.
Those are the three candidates I know have their own personal #website, and was able to verify by searching for candidates on the web, #socialMedia, etc.
Three out of the nine candidates² running for election to the World Wide Web Consortium’s Advisory Board.
As I wrote in my statement:
> “I believe governance of W3C, and advising thereof, is most effectively done by those … who directly use & create on the web using W3C standards. This direct connection to the actual work of the web and W3C is essential to prioritizing the purpose & scope of governance thereof.”
I firmly believe that direct hands-on experience with using the web, beyond reading the web or using someone else’s apps, actually writing to the web, posting on the web, creating for the web, provides better insight into the technologies & standards necessary to evolve the web, how to improve them and represent the communities working on them.
I ask for your support for the Advisory Board, and support for those who create on the web.
If any other candidates have their own #IndieWeb site (or set one up!), and especially if they blog their personal statements, I will gladly link to them as well.
Thanks for your consideration.
¹ https://www.w3.org/blog/news/archives/9903
² https://www.w3.org/2023/04/ab-nominations.html
-
🌱 I have long been a fan of @Foursquare.com and @Swarmapp.com, having created many venues, posted many tips, and (checks profile) over 45,000 checkins. I recently joined @happycow.net and before I start posting new vegan (friendly) venues or reviews there, I really need to figure out my own personal site venue pages (including URL design) and review posts design and authoring workflow.
I’m pretty sure I can and should post h-review posts as a variant of articles (with usual h-entry markup) with an explicit article name, since most review destinations request a title (name) for the review (e.g. HappyCow, TripAdvisor), and for others with only review text (e.g. Google Maps), I can include the name at the start.
Different review destinations have different text requirements (minimum and/or maximum lengths), and I’ll take time to document those first.
The first destination I’ll likely try automatically syndicating to is a site created by #IndieWeb community member @jamesg.blog (@capjamesg@indieweb.social): @breakfastand.coffee
It’s still quite new, but the thing that makes Breakfast & Coffee innovative and unique is that it encourages you to post your venue (e.g. cafe) description or review on your own site with a meaningful slug, link to https://breakfastand.coffee/ and then send a Webmention to indicate that you’d like to syndicate your venue or review into Breakfast & Coffee, like into an aggregator.
Before I get to that point however, I feel there’s quite a few challenges in publishing a “decent” restaurant / cafe venue page, because there really is a dearth of good examples of doing so with simple semantic HTML + CSS. You really don’t need JS to post info about a restaurant.
Setting aside the economic / intermediation challenges of "delivery apps" for now, people really want a few simple things from a restaurant site / page that could all be marked up with simple semantic HTML (thus resulting in good web search rankings) and styled in a quickly readable and mobile-friendly way.
* hours open (perhaps kitchen hours if different)
* location (address that links to a map UI or map embed w/o cookies/tracking)
* nearest bus/tram/rail stop
* payment restrictions (e.g. if only cash, or only credit) or options if you prefer
* contact info (including a note about catering if that’s an option)
* links to social media profiles
* links to restaurant review sites/aggregator pages (e.g. venue permalink on Google Maps, TripAdvisor, Foursquare, Swarm, HappyCow)
* menu with item name, description, price, optional-thumbnail, and dietary/allergy notations
No you really don’t need the full mess of made-up things at schema-org.
The community at OpenStreetMap has done A LOT (most? nearly all?) of the work figuring out the ways to express the above types of information, e.g.:
https://wiki.openstreetmap.org/wiki/Key:opening_hours
Yet has anyone actually seen a simple semantic HTML page that publishes this kind of information?
I’ve web searched many search terms and phrases and found nothing good.
Stylistically dated templates for sale. Examples with numerous unnecessary scripts (no your typical user does not care about your clever animated 3D-carousel of pretty photos, certainly not waiting for a megabyte of framework scripts for it). Something built on Bootstrap, unnecessary for today’s mobile-friendly HTML+CSS.
I did find one (ONE) blog post from 2007 (those were the days) for semantic markup for a restaurant menu: https://jonchristopher.us/blog/a-semantic-breakdown-of-restaurant-menus/
Unless I find an existing solution soon, I’m going to create something from scratch with h-card (since a restaurant is an organization / venue) and add semantic HTML & class names for various fields, re-using from OpenStreetMap Keys whenever possible.
That leaves the URL design, where to publish my restaurant pages on my own site, and rather than rethink it, I will likely go with what I decided in my Whistle short URL design¹ many years ago, which is /v/ at the top level of my site, followed by a slug of my short name for the venue. This way I can play with static HTML pages there, with a shared style sheet in that same directory, without impacting anything else on my site.
I have some other thoughts around iconography for various diet preferences / allergen warnings for menu items that I’ve tried (or considered), though perhaps I’ll leave those for another post.
Or maybe I’ll braindump them now, however incomplete, to see if they resonate or anyone has better suggestions (restaurants and menus really have no standard for these)
🌱 vegan & gluten-free
🌱🌾 vegan + gluten
🌱🥜 vegan + nuts
🌱🍫 vegan + chocolate
🌱🍯 vegetarian (has honey)
🌱🧈 vegetarian (has butter)
🌱🥛 vegetarian (has milk, cream, or yogurt)
🌱🧀 vegetarian (has cheese)
🌱🥚 vegetarian (has egg)
with combinations as necessary.
For example, a breakfast sandwich at Devil’s Teeth Bakery²:
* Regular Breakfast Sandwich (no bacon!) $10.00 🌱🌾🧈🧀🥚
Or a chocolate croissant at Arsicault³:
* Chocolate Croissant $5.75 🌱🌾🧈🍫
Non-vegetarian items would omit the plant 🌱 icon/emoji, but could still include allergen icons.
If you are posting restaurants (or any other venues) to your personal site, please add a few of their permalinks to the IndieWeb Examples here: https://indieweb.org/venue#Indieweb_Examples
This is day 40 of #100DaysOfIndieWeb. #100Days
← Day 39: https://tantek.com/2023/112/t2/account-migration-post-blog-archive-format
→ 🔮
Glossary
article
https://indieweb.org/article
checkin
https://indieweb.org/checkin
h-card
https://microformats.org/wiki/h-card
h-entry
https://microformats.org/wiki/h-entry
h-review
https://microformats.org/wiki/h-review
POSSE
https://indieweb.org/POSSE
review
https://indieweb.org/review
URL design
https://indieweb.org/URL_design
venue
https://indieweb.org/venue
References
¹ https://tantek.com/w/Whistle#design
² https://www.devilsteethbakingcompany.com/menu
³ https://arsicault-bakery.com/menus
-
One of the pretty neat innovations from #Mastodon has been actual, functional, and fairly reliable (from all accounts I’ve seen) distributed system account migration, with the notable exception of post migration, which has additional challenges worth exploring.
To be clear, as far as I know, no other blogging (or chat) software, system, or even protocol comes close to achieving the level of functionality described in Mastodon’s documentation:
https://docs.joinmastodon.org/user/moving/#migration
In short, moving:
* all your profile information
* moving all your followers & followings, transparently
* redirecting your old account to your new one
More at that link. From the docs, it’s clear that quite a bit of thought & consideration went into the design & implementation.
Once I had setup #BridgyFed to #federate posts from my own site¹, I myself made use of the this Mastodon feature to migrate from my try-it-out @t@xoxo.zone account to my #IndieWeb @tantek.com (move destination handled by BridgyFed).
For me the migration experience was 100%, because I had not posted anything @t@xoxo.zone.
The challenge of post migration is not unique to Mastodon, though I believe it goes beyond “simple” export & import support, which is still a good place to start.
Mastodon has two forms of posts “export” currently:
* RSS feeds, which will get you some number of recent posts, by adding ".rss" to the end of any Mastodon profile URL, e.g. https://indieweb.social/@tchambers.rss
* Activity Streams 2.0 JSON, per https://docs.joinmastodon.org/user/moving/#export (note: it currently says “ActivityPub JSON format”, but there is no such thing, #ActivityPub uses the #ActivityStreams 2.0 JSON format and I’ve filed a PR² to fix this in the docs)
Lots of software & services import RSS, e.g. #WordPress.
As far as I know, nothing (not even Mastodon itself) actually supports importing Activity Streams 2.0.
There is a more complete format (with specification!) for exporting & importing blog content:
Blog Archive Format (.bar), first specified here with example file:
* https://www.manton.org/2017/11/24/blog-archive-format.html
More details and another example file:
* https://www.manton.org/2021/12/27/importing-blog-archive.html
Blog Archive Format has the very nice features of:
* portable HTML feed (h-feed) and JSON Feed
* photos and other media
* locally browsable post archive
Naturally, https://micro.blog/ supports both exporting & importing Blog Archive Format.
There’s an interesting opportunity here for an open source converter
* from Activity Streams 2.0
* to Blog Archive Format
Such a library would make an excellent drop-in addition to any #ActivityPub implementation, allowing both export of posts, and also a browsable archive format, so you could visually double check when importing to another service that these were the old posts you were looking for.
This would be a good first step, using an open standard, towards Mastodon itself supporting post migration³.
Ideally, similar to account migration, the old posts server should also at least:
* redirect old permalinks to the new permalinks
* redirect any replies being delivered by ActivityPub to the new location
* provide #Webmention discovery forwarding from the old URLs to the new URLs (e.g. using HTTP LINK headers)
for some amount of time.
Want to add support for Blog Archive Format or got questions or feedback?
Join in the development conversations: https://chat.indieweb.org/dev
This is day 39 of #100DaysOfIndieWeb. #100Days
← Day 38: https://tantek.com/2023/110/t2/beyond-mastodon-indieweb-own-domain
→ 🔮
Glossary
account migration
https://indieweb.org/account_migration
blog archive format
https://indieweb.org/blog_archive_format
h-feed
https://microformats.org/wiki/h-feed
JSON Feed
https://www.jsonfeed.org/
post migration
https://indieweb.org/post_migration
Webmention
https://indieweb.org/Webmention
References
¹ https://tantek.com/2022/301/t1/twittermigration-bridgyfed-mastodon-indieweb
² https://github.com/mastodon/documentation/pull/1202
³ https://github.com/mastodon/mastodon/issues/12423
-
In https://www.theverge.com/2023/4/20/23689570/activitypub-protocol-standard-social-network, author @pierce@mas.to does an excellent job covering a broad range of #ActivityPub related updates, and goes beyond the usual #Mastodon focus to describe numerous implementations.
I was very happy to see that he also clearly communicated several #IndieWeb principles¹, practices, goals, and reasons why². Like this quote:
“But the advice you’ll hear from most people in this space is this: own your own domain. Don’t be john@/mastodon.social or anna@/facebook.com. Have a space that is yours, that belongs to you, a username and identity that can’t disappear just because a company goes out of business or sells to a megalomaniac.”
and this:
“It’s [your own domain is] your YouTube channel name and your TikTok username and your Instagram handle and your phone number and your Twitter @, all in one name.”
Great interviews with @stevetex@mozilla.social, @mike@flipboard.social, @dustycloud.org (@cwebber@octodon.social), @evanp.me (@evan@cosocial.ca), @anildash.com (@anildash@me.dm), @coachtony@me.dm, and @manton.org.
As Manton said in the article:
“If you solve identity with domain names, it makes things easier because it fits the way the web has been for 20 years,”
Pierce also noted:
“you might soon be able to turn your personal website into your entire social identity online”
Already can.
I replied to Pierce’s post³ about his article noting this⁴, from #federating directly from my website for the past ~6 months⁵, to over a decade of using it as my social identity with the POSSE method⁶ with various #socialMedia silos.
It’s important enough that I’ll repeat part of Pierce’s quote at the top:
“own your own domain. Don’t be john@/mastodon.social or anna@/facebook.com. Have a space that is yours”
He gets it. Don’t be someone at someone else’s server.
Big Chad or Little Chad’s garages⁷ are social media stepping stones towards owning your own domain and IndieWeb presence.
We’re here when you’re ready to take that next step: https://chat.indieweb.org/
This is day 38 of #100DaysOfIndieWeb. #100Days
← Day 37: https://tantek.com/2023/109/t2/years-ago-first-federated-indieweb-thread
→ 🔮
¹ https://indieweb.org/principles
² https://indieweb.org/why
³ https://mas.to/@pierce/110231624819547202
⁴ https://tantek.com/2023/110/t1/
⁵ https://tantek.com/2022/301/t1/twittermigration-bridgyfed-mastodon-indieweb
⁶ https://indieweb.org/POSSE
⁷ https://tantek.com/2023/001/t1/own-your-notes
-
10 years ago today the first #federated #IndieWeb comment thread was published and collected peer-to-peer IndieWeb replies across websites without any intermediary, silo or otherwise¹.
2013-04-19 @eschnou.com posted a brief note on his personal site with #atMentions of a few domains (putting an '@' sign immediately before a domain name to indicate an explicit cross-web @-mention), which itself was also a first²
"Testing #indieweb federation with @waterpigs.co.uk, @aaronparecki.com and @indiewebcamp.com !"
When @aaronpk.com was notified and replied from his site within minutes³, it became the first peer-to-peer federated IndieWeb comment thread, at the time using h-entry and Pingback. I blogged about it a few days later⁴.
Earlier this year I blogged more observations of all the user interactions that happened on that day and shortly thereafter to make this all work: https://tantek.com/2023/014/t4/domain-first-federated-atmention
Unfortunately Laurent Eschnou’s original post is no longer up, and we only have the Internet Archive copy. However most of the IndieWeb reply posts are still up including Barnaby’s: https://waterpigs.co.uk/notes/1334/
The oldest still working federated post and comment thread was second overall, unsurprisingly from @aaronparecki.com⁵, a whole 40 days after Laurent’s first.
This is day 37 of #100DaysOfIndieWeb. #100Days #OpenWeb #federation #fediverse
← Day 36: https://tantek.com/2023/100/t1/auto-linked-hashtags-federated
→ 🔮
Glossary
federation
https://indieweb.org/federation
h-entry
https://microformats.org/wiki/h-entry
Pingback
https://indieweb.org/Pingback
reply post
https://indieweb.org/reply
References
¹ https://web.archive.org/web/20130427010301/http://eschnou.com/entry/testing-indieweb-federation-with-waterpigscouk-aaronpareckicom-and--62-24908.html
² https://tantek.com/2023/014/t4/domain-first-federated-atmention
³ https://aaronparecki.com/2013/04/19/3/indieweb
⁴ https://tantek.com/2013/113/b1/first-federated-indieweb-comment-thread
⁵ https://aaronparecki.com/2013/05/21/4/xkcd
-
@fredrocha.net (@john_fisherman@mastodon.social) saw your post (https://mastodon.social/@john_fisherman/110224246899618915) from the #IndieWeb stream. Beautiful photos on your site! #btconf was great wasn’t it?
My personal URL is https://tantek.com/ and my #fediverse @ is @tantek.com. My Atom feed file is auto-discoverable by feed readers from my home page.
Feeding (so to speak) two discovery birds with one stonefruit¹.
Your personal website can be your fediverse address², each providing seamless discovery for the other.
As web developers we should be building & developing our personal sites to exemplify the latest & greatest of such practices, including using Mastodon/ActivityPub as yet another distribution mechanism (ala POSSE) for your existing personal websites rather than a separate profile/stream.
Discussed this with @nebu@mastodon.social and @kadirtopal@mastodon.social just after the last talk @beyondtellerrand.com (@btconf@mastodon.social @btconf) yesterday, fitting conference closing thoughts complementing the heartfelt opening talk by @localghost.dev (https://sophie.omg.lol/ @sophie@social.lol)³.
Glossary
ActivityPub
https://indieweb.org/ActivityPub
feed file
https://indieweb.org/feed_file
POSSE
https://indieweb.org/POSSE
References
¹ https://tantek.com/2020/147/t2/replace-violent-metaphors
² https://tantek.com/2022/301/t1/twittermigration-bridgyfed-mastodon-indieweb
³ https://tantek.com/2023/107/t1/beyond-tellerand-talk-love-personal-website
-
@fredrocha.net (@john_fisherman@mastodon.social) saw your post (https://mastodon.social/@john_fisherman/110224246899618915) from the #IndieWeb stream. Beautiful photos on your site! #btconf was great wasn’t it?
My personal URL is https://tantek.com/ and my #fediverse @ is @tantek.com. My Atom feed file is auto-discoverable by feed readers from my home page.
Feeding (so to speak) two discovery birds with one stonefruit¹.
Your personal website can be your fediverse address², each providing seamless discovery for the other.
As web developers we should be building & developing our personal sites to exemplify the latest & greatest of such practices, including using Mastodon/ActivityPub as yet another distribution mechanism (ala POSSE) for your existing personal websites rather than a separate profile/stream.
Discussed this with @nebu@mastodon.social and @kadirtopal@mastodon.social just after the last talk @beyondtellerrand.com (@btconf@mastodon.social @btconf) yesterday, fitting conference closing thoughts complementing the heartfelt opening talk by @localghost.dev (https://sophie.omg.lol/ @sophie@social.lol)³.
Glossary
ActivityPub
https://indieweb.org/ActivityPub
feed file
https://indieweb.org/feed_file
POSSE
https://indieweb.org/POSSE
References
¹ https://tantek.com/2020/147/t2/replace-violent-metaphors
² https://tantek.com/2022/301/t1/twittermigration-bridgyfed-mastodon-indieweb
³ https://tantek.com/2023/107/t1/beyond-tellerand-talk-love-personal-website
-
About three weeks ago I got auto-linked hashtags working on my posts.
The biggest challenge was picking a tag space to link my hashtags.
The second biggest challenge was figuring out how to get my linked hashtags to work when my posts were federated into Mastodon instances, and have them rewrite those links into instance-local tag page links. We need a term for such locally rewritten linked hashtags, perhaps “federated hashtags”.
While typical personal sites link a hashtag to a tag page that only displays personal posts, I wanted to link to something more like a tag aggregation page that also displayed similar posts from others.
The tag pages on Mastodon instances do a good job of this, showing tagged posts from any user on that instance, and tagged posts from any user followed by any user on that instance.
I reviewed my hashtags since the start of 2023, checked their pages on indieweb.social and found that the posts displayed were all on topic, and surprisingly free of tag spam (perhaps for now).
I chose https://indieweb.social/tags/ for my tag space (which is a 404 if you click it, where it really should display a tags page listing popular or recent tags or a tag cloud).
Combining a hashtag like #100DaysOfIndieWeb with a tag space produces a link to a tag page like: https://indieweb.social/tags/100DaysOfIndieWeb.
The other interesting thing about hashtag links is how they’re rewritten when a post is displayed on another Mastodon instance, to link to the tag page local to that instance.
This linked-hashtag-portability is underspecified unfortunately (it could probably use its own portable markup specification, or at least a best practice for h-entry publishing).
How it works in Mastodon is non-obvious enough that there’s a 4+ year old Bridgy Fed issue on the subject!
* https://github.com/snarfed/bridgy-fed/issues/45
With a bunch of research and experiment contributions from several folks in the issue, @snarfed.org (@schnarfed) did eventually figure out how to get Bridgy Fed to federate hashtags in posts into Mastodon instances so they would rewrite hashtag links into instance-local hashtag pages:
* https://github.com/snarfed/bridgy-fed/issues/45#issuecomment-1468962400
Thus even though I’m using the indieweb.social tag space on the hashtag links in my original post, if you are reading this post on Mastodon, you should see a hashtag like #IndieWeb link to your local instance’s tag page for IndieWeb, and my post should show up on that page.
From testing a few other instances tag pages, this is now working, e.g. these tag pages:
* https://indieweb.social/tags/100DaysofIndieWeb (as expected)
* https://xoxo.zone/tags/100DaysOfIndieWeb
* https://mozilla.social/tags/100DaysofIndieWeb
display the #MozFest post¹ I published right after implementing linked hashtags (and any subsequent 100DaysofIndieWeb posts).
I did go back and send Webmentions to BridgyFed to send ActivityPub updates for all my past #100DaysofIndieWeb posts, however only a few of them showed up in those tag pages. It’s unclear why a few did and most didn’t, or why there are inconsistencies across instances. More to explore and debug.
Federated hashtags definitely need their own specification, because currently they barely interoperate when published, and even then require Mastodon-implementation-specific knowledge to function.
The good news is that several of us now have linked hashtags on our personal sites display and link as expected when our posts are federated across Mastodon instances, using a variety of different pieces of software to make it all work.
This is day 36 of #100DaysOfIndieWeb #100Days
← Day 35: https://tantek.com/2023/081/t1/mozfest-making-fediverse-socialweb
→ 🔮
Glossary
h-entry
https://microformats.org/wiki/h-entry
hashtag
https://indieweb.org/hashtags
tag aggregation
https://indieweb.org/tag_aggregation
tag page
https://indieweb.org/tag_page
tags page
https://indieweb.org/tags_page
References
¹ https://tantek.com/2023/081/t1/mozfest-making-fediverse-socialweb
-
Watching #MozFest session Dialogues & Debates: Making the Fediverse¹ and panelist @stevetex@mozilla.social (@stevetex) just announced that we (#Mozilla) are standing up a #Mastodon instance², starting with limited sign-ups.
I’m excited that Mozilla is experimenting with #socialWeb alternatives to centralized #socialMedia silos.
There are many #Mozillians with #fediverse addresses you can follow:
* https://wiki.mozilla.org/Mastodon
Several of these folks also have their own #IndieWeb sites.
It’s interesting seeing how people are individually choosing to use a fediverse address on someone else’s server, vs their own server like with a subdomain, vs just using their existing site.
One trend I have seen is people using someone else’s Mastodon server as a stepping stone, a learning experience, before migrating to either self-hosting Mastodon (or an easier to run alternative like microblog.pub³, not to be confused with micro.blog⁴), or ideally directly using their own site, blog etc. to connect to the fediverse⁵.
Do you have an @-@ address and want to use your own site instead?
If you’re a #webdev, you can totally do this by connecting your existing personal site with https://fed.brid.gy/ and own your presence on the web, social web, fediverse all at one place.
Got questions? Drop by the IndieWeb chat! https://chat.indieweb.org/dev
This is day 35 of #100DaysOfIndieWeb #100Days
← Day 34: https://tantek.com/2023/072/t1/blog-as-if-ai-trained-posts
→ 🔮
¹ https://schedule.mozillafestival.org/session/UEEGYL-1
² https://mozilla.social/
³ https://indieweb.org/microblog.pub
⁴ https://indieweb.org/micro.blog
⁵ https://tantek.com/2022/301/t1/twittermigration-bridgyfed-mastodon-indieweb
-
Watching #MozFest session Dialogues & Debates: Making the Fediverse¹ and panelist @stevetex@mozilla.social (@stevetex) just announced that we (#Mozilla) are standing up a #Mastodon instance², starting with limited sign-ups.
I’m excited that Mozilla is experimenting with #socialWeb alternatives to centralized #socialMedia silos.
There are many #Mozillians with #fediverse addresses you can follow:
* https://wiki.mozilla.org/Mastodon
Several of these folks also have their own #IndieWeb sites.
It’s interesting seeing how people are individually choosing to use a fediverse address on someone else’s server, vs their own server like with a subdomain, vs just using their existing site.
One trend I have seen is people using someone else’s Mastodon server as a stepping stone, a learning experience, before moving to either self-hosting Mastodon (or an easier to run alternative like microblog.pub³, not to be confused with micro.blog⁴), or ideally, directly using their existing site, blog etc. to connect to the fediverse⁵.
Do you have an @-@ address and want to use your own site instead?
If you’re a #webdev, you can totally do this by connecting your existing personal site with https://fed.brid.gy/ and own your presence on the web, social web, fediverse all at one place.
Got questions? Drop by the IndieWeb chat! https://chat.indieweb.org/dev
¹ https://schedule.mozillafestival.org/session/UEEGYL-1
² https://mozilla.social/
³ https://indieweb.org/microblog.pub
⁴ https://indieweb.org/micro.blog
⁵ https://tantek.com/2022/301/t1/twittermigration-bridgyfed-mastodon-indieweb
-
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 a W3C Recommendations (which you can find from the Implementation Report 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
→ 🔮
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
→ 🔮
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
→ 🔮
¹ 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^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
→ 🔮
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
→ 🔮
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 (got 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
→ 🔮
^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
-
Is the #IndieWeb just blogs/blogging?
What if I told you the "indie web"^1 is older than "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
→ 🔮
^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
→ 🔮
^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
→ 🔮
^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
Tantek
All stadeus content and data are available under the