Show Navigation
Notices tagged with 100daysofindieweb
-
Time to begin again: restarting my #100Days of #IndieWeb project for 2024, as a #100Posts of IndieWeb project, and congrats to the IndieWeb community on a fully completed 2023 IndieWeb Gift Calendar!
Last year I completed 48 out of a planned 100 posts in my #100DaysOfIndieWeb project, for nearly 48 days (some days had multiple posts). Instead of resetting my goals accordingly, say down to 50, I’m going for 100 again, however, this time for 100 posts rather than 100 days, having learned that some days I find the time for multiple posts, and other days none at all.
Looking back to the start of last year’s 100 Days project, it’s been one year since I encouraged everyone to own their own notes¹. Since then many have started, restarted, or expanded their personal sites to do so. Some have switched from a #Twitter account to a #Mastodon (or other #fediverse) account as a stopgap for short-form status posts. A step in the right direction, yet also an opportunity to take the leap this year to fully own their identity and posts on the web.
In 2023 Twitter also broke all existing API clients (including my website). I did not feel it was worth my time to re-apply for an API key and rebuild/retest any necessary code for my semi-automatic #POSSE publishing, not knowing when they might break things again (since there was no rational reason for them to have broken things in the first place).
I manually POSSEd a few posts after that, yet from the lack of interactions, either Twitter’s feed algorithm² isn’t showing my posts, or people have largely left or stopped using Twitter.
Either way, when your friends stop seeing your posts on a silo, there’s no need to spend any time POSSEing to it.
On the positive side, the IndieWeb community really came together in 2023, shining brightly even through the darker days of December.
We, the IndieWeb community (and some beyond!) provided a gift (or often multiple) to the rest of community for every single day of December 2023³, the first time we successfully filled out the whole month since the 2018 IndieWeb Challenge⁴, and only the second time ever in the seven years of the IndieWeb Challenge-turned-Gift-Calendar.
By going through the various gifts (more than 2 per day on average!), there are many interesting numbers and patterns we could surface. That deserves its own post however, as does a summary of the 48 posts⁵ of my 2023 100 Days of IndieWeb attempt, so I’ll end this post here.
Happy New Year to all, with an especially well deserved congratulations to the IndieWeb community and everyone who contributed to the 2023 Gift Calendar. Well done!
Let’s see what else we can create & share on our personal sites in 2024 and continue setting a higher bar for the independent web by showing instead of telling. #ShowDontTell
This is post 1 of #100PostsOfIndieWeb. #100Posts
← ✨
→ 🔮
Post glossary:
API
https://indieweb.org/API
POSSE
https://indieweb.org/POSSE
silo
https://indieweb.org/silo
¹ https://tantek.com/2023/001/t1/own-your-notes
² https://indieweb.org/algorithmic_feed
³ https://indieweb.org/2023-12-indieweb-gift-calendar
⁴ https://indieweb.org/2018-12-indieweb-challenge
⁵ https://tantek.com/2023/365/t2/no-large-language-model-llm-used
-
No large language models (LLM) were used in the production of this post.
Inspired by a subtle but clear sign-of-the-times one-line disclaimer at the end of RFC9518’s Acknowledgments (https://www.rfc-editor.org/rfc/rfc9518.html#appendix-A-4)
“No large language models were used in the production of this document.”
I have added a similar disclaimer to the footer of my homepage:
“No large language models were used in the production of this site.”
2023 was certainly a year that LLMs took off and stole the hypecycle from #metaverse and #blockchain before that.
Yet unlike those previous two, #LLMs are already having real impacts on the way people create (from emails to art), communicate (LLM chat apps), and work (2023 Writer’s Strike), fueling growing concerns about the authenticity of content, especially content from human authors.
I expect we will see more such disclaimers in the future.
For now, if you blog on your own site with words written by you not #ChatGPT or a similar tool, I encourage you to add a similar disclaimer, and then add your site as an example to the #IndieWeb wiki:
* https://indieweb.org/LLM#IndieWeb_Examples
#largeLanguageModel #LLM #generativeAI #AI
There is the related problem of, when you discover what seems to be an independent site written by a human, how do you know that human actually exists?
For now I’ll mention that XFN rel=met links, published (e.g. metrolls / met-rolls), aggregated, indexed, and queried, can solve that problem. This will be similar to how XFN rel=me links solved #distributed verification on the web (see https://tantek.com/2023/234/t1/threads-supports-indieweb-rel-me and posts it links to).
This is day 48 of #100DaysOfIndieWeb. #100Days
← Day 47: https://tantek.com/2023/365/t1/capture-first-edit-publish-later
→ 🔮
Post glossary:
blockchain
https://indieweb.org/blockchain
large language model / LLM
https://indieweb.org/large_language_model
metaverse
https://indieweb.org/metaverse
rel=me
https://indieweb.org/rel-me
rel=met
http://gmpg.org/xfn/11#met
XFN
https://gmpg.org/xfn/
-
Writing about writing: capture first, edit & publish later.
Braindump timely thoughts & experiences into as many draft notes as it takes, while ideas & memories are fresh.
Collecting higher fidelity memories seems more important than editing past writings or finishing/polishing a post for publishing, which can be done at a later time.
Sometimes the passage of time helps provide insights and broader understandings that can help with writing more effective posts, from better summaries to narratives that help sense-making.
Bits of even this minor post sat for weeks, and only today did I add a summary and related thoughts.
Similarly, it makes sense to edit and publish small notes on a subject, without feeling compelled to turn them into a larger blog post, or a longer list of points.
This is a key advantage to publishing on your own #indieweb site, you decide on the granularity of your posts, small, medium or large, instead of being constrained, burdened, or pressured by any particular #socialMedia user interface, character count limitation, or audience expectation.
Like Twitter before it, even the default #Mastodon user interface has limitations, and the #fediverse itself as a whole has audience/cultural expectations (certainly quite a few articles have been written about that).
On your own site you decide if you want to publish a post to make one point, or mention a related point or two, or collect things into a list or longer article, or eventually all of the above.
On your own site you feel more free to prioritize and share what is on your mind, instead of feeling compelled to first respond to whatever topics are trending, or to whatever you happen to read in your algorithmic feed.
#writingAboutWriting
This is day 47 of #100DaysOfIndieWeb. #100Days
← Day 46: https://tantek.com/2023/289/t1/bridgyfed-webmention-like-fediverse
→ Day 48: https://tantek.com/2023/365/t2/no-large-language-model-llm-used
Related:
* “More Thoughtful Reading & Writing on the Web” (https://tantek.com/2023/277/b1/thoughtful-reading-writing-web)
Post glossary:
algorithmic feed
https://indieweb.org/algorithmic_feed
article
https://indieweb.org/article
note
https://indieweb.org/note
post
https://indieweb.org/post
sense-making
https://en.wikipedia.org/wiki/Sensemaking_(information_science)
social media
https://indieweb.org/social_media
-
Great article on #POSSE by David Pierce (@davidpierce@mastodon.social @pierce) @Verge:
https://www.theverge.com/2023/10/23/23928550/posse-posting-activitypub-standard-twitter-tumblr-mastodon
Several key points of POSSE explained in the article:
First, post on your own site:
“In a POSSE world, everybody owns a domain name, and everybody has a blog. (… a place on the internet where you post your stuff and others consume it.)”
Second, syndicate elsewhere, appropriately for each destination:
“Then, your long blog post might be broken into chunks and posted as a thread on X and Mastodon and Threads. The whole thing might go to your Medium page and your Tumblr and your LinkedIn profile, too. If you post a photo, it might go straight to Instagram, and a vertical video would whoosh straight to TikTok, Reels, and Shorts. Your post appears natively on all of those platforms,”
You can use Bridgy Publish (https://brid.gy/) to POSSE to many destinations, and Bridgy Fed (https://fed.brid.gy/) to #federate to #Mastodon and other #fediverse destinations, directly from your site instead of posting a copy on yet another account on yet another server.
Third, and this is a key piece that distinguishes proper POSSE setups, with original post perma(short)links back to your posts on your domain:
“typically with some kind of link back to your blog.”
All copies link to (your) home.
"And your blog becomes the hub for everything, your main home on the internet."
You have power over your domain (name), not outside silos.
David embedded a screenshot of one of my posts, a reply post:
in which I posted a reply *on my own site*¹ to @Zeldman.com’s tweet (itself a reply to a POSSE copy of one of my posts), and POSSEd my reply to Twitter so it would thread with his reply.
This illustrates another important detail of a proper POSSE setup:
Fourth, post *replies* and other responses from your own site, whether to other #IndieWeb sites, or to others’s silo posts (tweets etc.).
Own your data means owning your replies as well.
David also noted several challenges and good questions about POSSE. Some of these have answers & established practices, others are areas of exploration. E.g.
"The first is the social side of social media: what do you do with all the likes, replies, comments, and everything else that comes with your posts?"
The short answer is #backfeed: https://indieweb.org/backfeed
Backfeed is a concept I first wrote about as “reverse syndication”².
As you syndicate your posts out to #socialMedia silos, you reverse syndicate any responses there back to your original post.
Your site can do this with a service like #Bridgy, which uses the #Webmention standard to forward such silo responses back to your site, and #BridgyFed which does same for responses from Mastodon to your #federated posts.
David asked many other questions, which are deserving of their own posts to help answer, so I’ll leave you with just one more:
"The most immediate question, though, is simply how to build a POSSE system that works."
The short answer is: just start³.
Even if you have to do it manually (until it hurts), even if you have to edit your posts on a static GitHub site (behind your domain name of course), and then copy & paste to your silo(s) of choice, just start.
By practicing POSSE, even manually, you will learn what aspects of POSSE & backfeed matter the most to you, what aspects actually involve reaching & responding to friends and others you care about.
By doing so you will naturally focus on setting up & making what you need, and you too can join the future of web publishing, today.
Questions? Join us in the chat: https://chat.indieweb.org/ (also on Discord, IRC, and Slack⁴)
This is day 46 of #100DaysOfIndieWeb. #100Days
← Day 45: https://tantek.com/2023/289/t1/bridgyfed-webmention-like-fediverse
→ 🔮
Post glossary:
backfeed / reverse syndication
https://indieweb.org/backfeed
Bridgy
https://brid.gy/
make what you need
https://indieweb.org/make_what_you_need
manual (until it hurts)
https://indieweb.org/manual_until_it_hurts
original post link
https://indieweb.org/original_post_link
own your data
https://indieweb.org/own_your_data
own your replies
https://indieweb.org/own_your_replies
permalink
https://indieweb.org/permalink
permashortlink
https://indieweb.org/permashortlink
POSSE
https://indieweb.org/POSSE
silo
https://indieweb.org/silo
social media
https://indieweb.org/social_media
static site
https://indieweb.org/static_site
start
https://indieweb.org/start
Webmention
https://indieweb.org/Webmention
¹ https://tantek.com/2023/253/t2/
² https://tantek.com/2010/034/t2/diso-2-personal-domains-shortener-hatom-push-relmeauth
³ https://tantek.com/2023/001/t1/own-your-notes
⁴ https://indieweb.org/discuss
-
Implemented liking/favoriting of #Mastodon posts via Bridgy Fed on my site! (Actually of any post on any site that #BridgyFed can discover an #ActivityPub endpoint to send likes to.)
Tested it by liking @evanp.me (@evan@cosocial.ca @evanpro)’s reply¹ confirming that he received a notification from my prior post². I sent a #Webmention from my like post³ to Bridgy Fed, and it #federated the like to Evan’s server, which subsequently showed up in the "favourites" list of Evan’s post:
https://cosocial.ca/@evan/111237962392745000/favourites
Every step that connects heterogenous #socialWeb systems & protocols feels like progress.
This is day 45 of #100DaysOfIndieWeb. #100Days #IndieWeb #like #likes #fediverse #favorite #favourite #favourites
← Day 44: https://tantek.com/2023/234/t1/threads-supports-indieweb-rel-me
→ 🔮
¹ https://cosocial.ca/@evan/111237962392745000
² https://tantek.com/2023/287/t1/federating-mentions
³ https://tantek.com/2023/289/f1
-
Threads.net now supports the #indieWeb #microformats #openStandard rel-me for distributed ✅ verification!¹ (supported since 2023-08-09)
My Threads profile already had my domain since it was created from my Instagram profile.
View source on https://www.threads.net/@tantek and you can see the #relMe on a link tag:
<link rel="me" href="https://tantek.com/" />
Instructions to add yours:
* Add your domain to your Threads profile "Link" field. That’s it.
Longer explicit steps: https://indieweb.org/rel-me#Threads
Thanks especially to @timothychambers.net (@tchambers@indieweb.social, @timothyjchambers@threads.net) for requesting rel-me support² which one Threads engineer “decided to hack it together” one night!³
You can view Tim’s profile @tchambers@indieweb.social for a real world example of a Mastodon profile showing a green text ✅ verified link to a Threads profile.
Tim made several good points in his request:
“… a small, but disproportionately helpful addition would be to support this "rel=me" feature in your profiles. That could launch well before full ActivityPub, & show the first real integration to open social web standards”
Microformats (and IndieWeb) standards in general are deliberately designed as small, incremental building blocks which are disproportionately helpful as Tim says.
These small building blocks which directly enable user features are usually something a web developer can code at least some (often complete!) support for in one day/night which makes them particularly appealing as a way to rapidly support open #socialWeb standards used by the #fediverse and beyond.
Incrementally implementing microformats & IndieWeb standards⁴ also demonstrates good will and good intentions for supporting the #openWeb.
This is day 44 of #100DaysOfIndieWeb. #100Days
← Day 43: https://tantek.com/2023/171/t1/anniversaries-microformats-posse
→ 🔮
Previously:
* 2023-02-01 Wikipedia.org supports multiple rel=me links: https://tantek.com/2023/139/t1/wikipedia-supports-indieweb-rel-me
¹ https://www.threads.net/@mosseri/post/Cvu2eXurRbB
² https://www.threads.net/@timothyjchambers/post/CupCvChAxI8
³ https://www.threads.net/@0xjessel/post/Cvu7-A4viZu
⁴ https://spec.indieweb.org/
-
Two anniversaries today: microformats (18y) and POSSE (11y).
Happy 18 years of https://microformats.org/ #microformats!
Most prominent this past year (again) has been the littlest #microformat that could:
rel=me — AKA #relme, now effectively the standard for #distributed #verification on the web:
* https://microformats.org/wiki/rel-me (originally introduced in 2004¹)
with support added in the past year for:
* #GitHub multiple rel-me links²
* #Wikipedia User page rel-me link³
, which is surprising since when it was conceived, the #IndieWeb community was in a period of very rapid innovation & iteration.
POSSE itself replaced a previous term, "POSE", short for “Publish Once Syndicate Everywhere”, which had only been around a year or two at most (I’m still looking for the first use of the "POSE" abbreviation for that meaning).
Since “publish once” was vague enough to include practices of publishing once on a social media silo, or in someone else’s garage⁵, we needed to clearly express the requirement to use your own site instead, first, as the source of your truth. Cross-posting to other sites & channels, is a second, optional step, ideally with a permalink linking back to your original post so viewers can easily discover and use your site.
That distinction was enough for POSSE to express a strong creator-owned-first publishing model that resonated and grew. Every time a silo shutdown⁶ at the end of its incredible journey⁷, removing posts & permalinks from the web, POSSE was there for people who were tired of losing their data, permalinks, & profiles, and wanted an alternative.
This is day 43 of #100DaysOfIndieWeb. #100Days
← Day 42: https://tantek.com/2023/160/t1/mastodon-activitypub-follow-form-bridgy-fed
→ 🔮
Glossary
permalink
https://indieweb.org/permalink
POSE
https://indieweb.org/POSE
POSSE
https://indieweb.org/POSSE
silo
https://indieweb.org/silo
References
¹ https://gmpg.org/xfn/11#me
² https://tantek.com/2023/032/t1/years-relmeauth-replace-openid
³ https://tantek.com/2023/139/t1/wikipedia-supports-indieweb-rel-me
⁴ https://tantek.com/2012/173/t1/posse-core-indieweb-approach
⁵ https://tantek.com/2023/001/t1/own-your-notes
⁶ https://indieweb.org/site-deaths
⁷ https://ourincrediblejourney.tumblr.com/
-
If you added a #Mastodon / #ActivityPub follow form to your #IndieWeb site based on Bridgy Fed (e.g. using code/instructions I previously posted¹), you need to update it to add another invisible input element for the "protocol", e.g.:
<input name="protocol" type="hidden" value="web" />
Otherwise people trying to use your form to follow you may see an error from #BridgyFed like:
> Bad Request
> Missing required parameter protocol
Here is the complete example that I posted previously with the new invisible input:
<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" />
<input name="protocol" type="hidden" value="web" />
<button type="submit">Follow</button>
</form>
I also updated that previous post¹ with the new input in case people find that instead.
This is day 42 of #100DaysOfIndieWeb. #100Days
← Day 41: https://tantek.com/2023/139/t1/wikipedia-supports-indieweb-rel-me
→ 🔮
¹ https://tantek.com/2023/020/t2/bridgy-fed-follow-form
-
Wikipedia.org (@wikipedia@wikis.world @wikipedia) now supports #IndieWeb rel-me!¹
Thanks to @taavi.wtf (@taavi@wikis.world) for the #MediaWiki RealMe extension²
Added it to my #Wikipedia User: page https://en.wikipedia.org/wiki/User:Tantek
View source and you can see the #relMe on a link tag:
<link href="https://tantek.com/" rel="me">
Instructions to add yours here:
* https://indieweb.org/rel-me#Wikipedia
This is day 41 of #100DaysOfIndieWeb. #100Days
← Day 40: https://tantek.com/2023/114/t1/venues-reviews-personal-pages
→ 🔮
Previously:
* 2023-02-01 GitHub supports multiple rel=me links: https://tantek.com/2023/032/t1/years-relmeauth-replace-openid
¹ https://wikis.world/@wikipedia/110396865170645710
² https://www.mediawiki.org/wiki/Extension:RealMe
-
🌱 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
-
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
-
Blog as if there’s an #AI being trained¹ to be you based on your blog posts.
And what if it was trained on your Universal Outbox²?
#IndieWeb #OpenAI #ChatGPT
This is day 34 of #100DaysOfIndieWeb #100Days
← Day 33: https://tantek.com/2023/051/t1/five-years-ago-w3c-social-web
→ 🔮
¹ https://indieweb.org/OpenAI#IndieWeb_Examples
² https://tantek.com/2023/044/t1/unified-sent-box-universal-outbox
-
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
Tantek
All stadeus content and data are available under the