Welcome to 2025!

15 years ago today I began posting notes on my own #indieweb site first, and only later on #socialMedia: https://tantek.com/2010/001/t1/declaring-independence-building-it

You can too.

I am once again encouraging you start the year with:
1. Getting a personal domain name
2. Posting on your own site first, then syndicating elsewhere: #POSSE

In 2025 there are even more neighborhoods with other people’s garages¹ to post into. Companies, servers, services, disappear all the time, taking all their posts and permalinks with them to graveyard 404².

This is your annual reminder to embrace #independent ownership of your online self, your creations, and their #longevity:
* Own your domain -> own your online identity
* Own your permalinks -> own your posts

Want help? Just ask: https://chat.indieweb.org/

#ownYourContent #ownYourData

Once again I am restarting a #100PostsOfIndieWeb #100Posts project for the year.

This is post 1.

Previously, previously, previously:
* https://tantek.com/2024/001/t1/restarting-100days-indieweb-gift-calendar
* https://tantek.com/2023/001/t1/own-your-notes
* https://tantek.com/2022/001/t1/12-years-notes-my-site
* https://tantek.com/2020/001/t1/10-years-notes-my-site
* https://tantek.com/2015/002/t1/notes-replies-faves-before-twitter-ownyourdata

←
→ https://tantek.com/2025/001/t2/first-new-year-review-prior


Glossary:

IndieWeb
  https://indieweb.org/
longevity
  https://indieweb.org/longevity
post
  https://indieweb.org/post
permalink
  https://indieweb.org/permalink
personal domain name
  https://indieweb.org/personal-domain
POSSE
  https://indieweb.org/POSSE
syndicate
  https://indieweb.org/syndicate

¹ https://tantek.com/2023/022/t2/own-your-notes-domain-migration
² https://indieweb.org/site-deaths

This is a summary curation of prior posts of mine on why post, what to post, and how to post, as well as some bits I wrote on the #IndieWeb wiki. This post assumes you already have a blog — if you don’t have one and wonder why you should, that’s a different blog post.

If you have a blog and ever feel stuck about why you should post, what to post next, or how to write your post, hopefully this post will help get you unstuck.

These reasons, topics, and techniques help me create, expand, edit, publish, and update more posts, sooner. Choose the ones that resonate for you, ignore the rest, and publish what else works for you on your personal site!


Why Post

There is a whole wiki page on the topic:
* https://indieweb.org/why_post — which could use some gardening

Here are a few specific reasons why you should post:

* Wean yourself off social media. Post to your own site instead of social media. If you already post on social media, into someone else’s garage¹, then you already have reason enough to post. So post on your own site first, and optionally syndicate² to that silo, only if you have friends who still use it to read posts.
* Search everything you write. Do you post long comments or issues on GitHub? Do you post on public mailing lists? Post such things to your own site, so you can more easily search everything you’ve written on a topic. Then post a copy to those external destinations.
* All the reasons to own your data: https://indieweb.org/own_your_data


What to Post

There are so many things to post about! This is obviously highly personal. Here are a few that I use myself:

* Post positive things promptly: https://tantek.com/2018/357/t3
  * … from that day first: https://tantek.com/2018/364/t1
  * … in time order: https://tantek.com/2018/364/t5
* Make and share lists. People like lists
* Post to learn in public, and pass on what you learn


How to Post

I have spent a lot of time thinking about, trying, and iterating on different methods and techniques for starting, expanding, completing, publishing, and updating posts. These are a few of the techniques I use:

* Use a local text editor
* Capture first, edit & publish later: https://tantek.com/2023/365/t1/
* Do something positive (in-person), then post about it: https://tantek.com/2018/002/t1
* Single topic post
* Short and to the point. Edit and remove anything distracting from the main point.
* Quotable post title
* Summary opening paragraph
* Put tangents aside
* Quotable sentences and multi-sentence paragraphs
* Subheadings help cluster related paragraphs
* Use a footer for updates, terminology, previous posts, additional reading, and citations.
  * Move definitions, citations, etc. to the footer unless including them inline either provides little risk of distraction or significantly helps reading flow
  * Use footer sections: Previously, Post Glossary, References, Additional Reading
* Check your references


Each of these points could be its own blog post. There are many more whys, whats, and hows. See more on these pages on the IndieWeb community site:

* https://indieweb.org/why_post
* https://indieweb.org/what_to_post
* https://indieweb.org/how_to_post

Add your own to each, and/or help organize them!


Glossary

mailing list
  https://indieweb.org/mailing_list
own your data
  https://indieweb.org/own_your_data
post footer
  https://indieweb.org/posts#Footer_sections
silo
  https://indieweb.org/silo
social media
  https://indieweb.org/social_media


References

¹ https://tantek.com/2023/001/t1/own-your-notes
² https://indieweb.org/POSSE


This is post 29 of #100PostsOfIndieWeb. #100Posts

← https://tantek.com/2024/306/t1/simple-embeds
→

Day 1 of #IndieWebCamp #Berlin 2024¹ was very well attended!
* 20 participants, more than 3x the previous one in 2022, and second highest (2019 had 22).
* 18 introduced themselves² and their personal sites or aspirations for one

Collectively we proposed and facilitated 11 breakout sessions³ on many timely topics covering #syndication, #inclusion, #longevity, #federation / #fediverse, how to best use #Mastodon with your personal site, #privacy and #security concerns of being online, #writing, how can we design better user interfaces for text authoring, and personalized reading #algorithms for staying connected with friends.

Session titles (and hashtags)
* How to #POSSE
* How to make the web queerer / stranger. #queer
* Online presence after our #death
* Threat modeling #threatmodeling
* Non-technical collaboration on the internet. #collab
* Locations and #places check-in
* Writing with images. #imagewriting
* Text authoring UX. #textUX
* #SSR, organizing CSS/JS
* Website design without being a designer. #designfordummies
* Timeline algorithms. #timelines

Etherpad notes from sessions have been archived to the wiki, with session recordings to follow!

Day 2 also had 20 in-person participants, the highest IndieWebCamp Berlin day 2 attendance ever! Most everyone from day 1 came back to hack, and three new people showed up. We also had several remote participants.


References
 
¹ https://indieweb.org/2024
² https://indieweb.org/2024/Berlin/Intros
³ https://indieweb.org/2024/Berlin/Schedule#Saturday


This is post 28 of #100PostsOfIndieWeb. #100Posts

← https://tantek.com/2024/306/t1/simple-embeds
→

No I did not block you on the #fediverse / #Mastodon / #Misskey etc.

If you were following me @tantek.com on your client/server/instance of choice but noticed you were no longer doing so, that was due to a recent software bug in my fediverse provider which accidentally caused everyone’s #ActivityPub servers to unfollow me (bug details below).

No it’s absolutely not your fault, you did nothing wrong.

We need a variant of Hanlon’s Razor¹ like:

“Never attribute to malice that which is adequately explained by a software bug.”

Take another look at my posts if you want (directly on @tantek.com or try searching for that on your instance) and if you like what you see or find them otherwise informative and useful, feel free to refollow. If not, no worries!

Also no worries if you ever unfollow/refollow for any reason. I mean that.

I always assume people know best how to manage their online reader/reading experiences, everyone’s priorities and likes/dislikes change over time, and encourage everyone to make choices that are best for their mental health and overall joy online.

Bug details:

This was due to a #BridgyFed bug² that deleted my profile (“ActivityPub actor”) from (nearly?) all instances, making everyone’s accounts automatically unfollow me, as well as remove any of my posts from your likes and reposts (boosts) collections. It also removed my posts from any of your replies to my posts, leaving your replies dangling without reply-contexts. Apologies!

The bug was introduced accidentally as part of another fix about a month ago³, and was triggered within the following week⁴.

Anyone following me before ~2024-09-22 was no longer following me. A few folks have noticed and refollowed. Any likes or reposts of my posts before that date were also undone (removed).

Ryan (@snarfed.org) has been really good about giving folks a heads-up, and apologizing, and quickly doing what he can to fix things.

Bugs happen, yes even in production code, so please do not post/send any hate.

I’d rather be one of the folks helping with improving BridgyFed, and temporary setbacks like this are part of being an early / eager #IndieWeb adopter.

This bug has also revealed some potential weaknesses in other ActivityPub implementations. E.g. deleting an “actor” should be undoable, and undoing a delete should reconnect everything, from follows to likes & reposts collections, to reply-contexts. Perhaps the ActivityPub specification could be updated with such guidance (if it hasn’t been already, I need to double-check).

To be clear, I’m still a big supporter of #BridgyFed, #ActivityPub, #Webmention, and everyone who chooses to implement these and other #IndieWeb related and adjacent protocols as best fits their products and services.

All of these are a part of our broader open #socialWeb, and making all these #openStandards work well together (including handling edge-cases and mistakes!) is essential for providing #socialMedia alternatives that put users first.

References:

¹ https://en.wikipedia.org/wiki/Hanlon%27s_razor
² https://github.com/snarfed/bridgy-fed/issues/1379
³ https://github.com/snarfed/bridgy-fed/commit/4df76d0db7b87cabbd714039546c05b3221169be
⁴ https://chat.indieweb.org/dev/2024-09-22#t1727028174623700

This is post 26 of #100PostsOfIndieWeb. #100Posts

← https://tantek.com/2024/285/t1/io-domain-suggested-steps
→

.io domain¹ likely being phased-out² — seven suggested steps

Good article in The Verge summarizing recent .io related events, see that for more context if this is news to you:
* https://www.theverge.com/2024/10/8/24265441/uk-treaty-end-io-domain-chagos-islands

It looks likely .io (and .io domains) will go away in the next few years (as .cs and .yu did³), so here are my suggested steps to take depending on your usage of .io domains:

1. Avoid buying new .io domains (or making plans with existing ones; sell if you can)
2. If you currently run a .io service⁴ (for a company or community), make and publicize a transition plan (like a new domain, redirection, orderly shutdown plan for redirects)
3. If you have a personal site on a .io domain⁵ or subdomain, make your own transition plan, and perhaps post about how others should link to your posts
4. If you are using someone else’s .io domain to publish (like #GitHubPages⁶), make a transition plan to publish elsewhere and leave a forwarding note and link behind
5. If you use a .io domain as your Web sign-in login on any sites, switch them to another non-io personal domain
6. Similarly if your site accepts #WebSignIn logins (via #IndieAuth, #RelMeAuth, or even #OpenID), consider discouraging any new sign-ups from .io domains, and warning any existing users with .io domains to switch per # 5
7. If you have posts (or a whole #indieweb site) with links to .io sites or pages (like those in 2-4 above), make a plan for editing those links to point to an alternative or an archival copy (like on the Internet Archive)

And of course, post about your #dotIO plans.

Glossary

Domain
 https://indieweb.org/domain
IndieAuth
 https://indieweb.org/IndieAuth
Internet Archive
 https://web.archive.org/
OpenID
 https://indieweb.org/OpenID
Redirect
 https://indieweb.org/redirect
RelMeAuth
 https://indieweb.org/RelMeAuth
Web sign-in
 https://indieweb.org/Web_sign-in


References:

¹ https://indieweb.org/.io
² https://en.wikipedia.org/wiki/.io#Phasing_Out
³ https://en.wikipedia.org/wiki/.cs
⁴ E.g. https://indieweb.org/webmention.io or https://indieweb.org/granary.io
⁵ E.g. https://indieweb.org/werd.io
⁶ https://indieweb.org/github.io


This is post 25 of #100PostsOfIndieWeb. #100Posts

← https://tantek.com/2024/283/t1/metaphors-constructive-cooperative-joyful
→

I want the Read Write Suggest-Edit Accept-Edit Update Web.

The consumer Infinite Scroll Web leaves us feeling empty.

Too few of us participate in the Read Write Web, whether with personal sites or Wikipedia.

A week ago when we wrapped up #IndieWebCamp Portland and I was reading Kevin Marks (@kevinmarks@indieweb.social) live-tooting of the demos¹, I noticed a few errors, typos or miscaptures, and pointed them out in-person.

Kevin was able to quickly edit his toots and update them for anyone reading, thanks to #Mastodon’s post editing feature and its support of #ActivityPub Updates. But this shouldn’t require being in the same room, whether IRL or chat.

We should be able to suggest edits to each other’s posts, as easily as we can reply and add a comment.

13 years ago I wrote²:

 “The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web.”

Now I want the Read Write Suggest-Edit Accept-Edit Update Web.

The Reply button is fairly ubiquitous in modern post user interfaces (UIs).

Why not also a Suggest Edit button, to craft a fix for a typo, grammar, or other minor error, and send the author for their review, and acceptance or rejection? Perhaps viewable only by the suggester and the author, to avoid "performative" suggested edits.

If the author’s posts provide revision histories, when a suggested edit is accepted, a post’s history could show the contributor of the edit.

Instead of asking Kevin in-person, what if I could have posted special "Suggested Edit" responses in reply to his toots, for which he would receive special notifications, and could choose to one-click accept and update (or further edit) his toots?

To enable such UIs and interactions across servers and implementations, we may need a new type of response³, perhaps with a special property (or more) to convey the edits being suggested.

There is documentation of this and similar use-cases, prior art / UIs, as well as some brainstorming on the #IndieWeb wiki:
* https://indieweb.org/edit

Our interaction after IndieWebCamp has inspired me to take another look at how can we design and prototype solutions to this problem.

For now, if you host your blog and posts as static files on GitHub (or equivalent), you could add a button like this to your posts alongside Like, Reply, Repost buttons:

Suggest Edit

and link it to an edit URL for the static file for the post.

I don’t use GitHub static files myself for posts, but here’s an example of such an edit link for one of my projects:

https://tantek.com/github/cassis/edit/main/README.md

This will start the process of creating a “pull request”, GitHub’s jargon⁴ for a “suggested edit”.

After completing GitHub’s ceremony of entering multiple text fields (summary & description), and multiple clicks to create said “pull request”, it’ll be sent to the author to review. Presuming the author likes the suggested edit, they can perform the other half of GitHub’s jargon-filled ceremonies to “Merge” or “Squash & Merge”, “Delete fork”, etc. to accept the edit.

It’s an awkward interaction⁵, however useful for at least prototyping a Suggest Edit button on sites that store their posts as files in GitHub. Certainly worthy of experimenting with and gathering experience to design and build even better interactions.

We can start with the shortest path to getting something working, then learn, iterate, improve, repeat.

#readWriteWeb #editableWeb #suggestEdit #acceptEdit

References:

¹ https://indieweb.social/@kevinmarks/113025295600067213
² https://tantek.com/2011/174/t1/read-fork-write-merge-web-osb11
³ https://indieweb.org/responses
⁴ The phrase “pull request” was derived from the git command: “git request-pull” according to https://www.reddit.com/r/git/comments/nvahcp/comment/h12hzj7/
⁵ “edits” in GitHub require taking far more steps, and navigating far more jargon, then say, Wikipedia pages, which come down to “Edit” and “Save”. We should aspire to Wikipedia’s simplicity, not GitHub’s ceremonies.

This is post 20 of #100PostsOfIndieWeb. #100Posts

← https://tantek.com/2024/242/t1/indiewebcamp-portland
→ https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed

Happy 12 years of https://indieweb.org/POSSE #POSSE and
19 years of https://microformats.org/ #microformats! (as of yesterday, the 20th)

A few highlights from the past year:

POSSE (Publish on your Own Site, Syndicate Elsewhere) has grown steadily as a common practice in the #IndieWeb community, personal sites, CMSs (like Withknown, which itself reached 10 years in May!), and services (like https://micro.blog and Bridgy) for over a decade.

In its 12th year, POSSE broke through to broader technology press and adoption beyond the community. For example:

* David Pierce’s (@pierce@mas.to) excellent article @TheVerge.com (@verge@mastodon.social): “The poster’s guide to the internet of the future” (https://www.theverge.com/2023/10/23/23928550/posse-posting-activitypub-standard-twitter-tumblr-mastodon):
  “Your post appears natively on all of those platforms, typically with some kind of link back to your blog. And your blog becomes the hub for everything, your main home on the internet.
Done right, POSSE is the best of all posting worlds.”

* David also recorded a 29 minute podcast on POSSE with some great interviews: https://podcasts.apple.com/us/podcast/the-posters-guide-to-the-new-internet/id430333725?i=1000632256014

* Cory Doctorow (@craphound.com @doctorow@mamot.fr) declared in his Pluralistic blog (@pluralistic.net) post: “Vice surrenders” (https://pluralistic.net/2024/02/24/anti-posse/):
  “This is the moment for POSSE (Post Own Site, Share Everywhere [sic]), a strategy that sees social media as a strategy for bringing readers to channels that you control”

* And none other than Molly White (@mollywhite.net @molly0xfff@hachyderm.io) of @web3isgoinggreat.com (@web3isgreat@indieweb.social) built, deployed, and started actively using her own POSSE setup as described in her post titled “POSSE” (https://www.mollywhite.net/micro/entry/202403091817) to:
  "… write posts in the microblog and automatically crosspost them to Twitter/Mastodon/Bluesky, while keeping the original post on my site."
 
Congrats Molly and well done!


In its 19th year, the microformats formal #microformats2 syntax and popular vocabularies h-card, h-entry, and h-feed, kept growing across IndieWeb (micro)blogging services and software like CMSs & SSGs both for publishing, and richer peer-to-peer social web interactions via #Webmention.

Beyond the IndieWeb, the rel=me microformat, AKA #relMe, continues to be adopted by services to support #distributed #verification, such as these in the past year:

* Meta Platforms #Threads user profile "Link" field¹
* #Letterboxd user profile website field²


For both POSSE and microformats, there is always more we can do to improve their techniques, technologies, and tools to help people own their content and identities online, while staying connected to friends across the web.

Got suggestions for this coming year? Join us in chat:
* https://chat.indieweb.org/dev
* https://chat.indieweb.org/microformats
for discussions about POSSE and microformats, respectively.


Previously: https://tantek.com/2023/171/t1/anniversaries-microformats-posse


This is post 15 of #100PostsOfIndieWeb. #100Posts

← https://tantek.com/2024/151/t1/minimum-interesting-service-worker
→ https://tantek.com/2024/237/t1/people-over-protocols-platforms


Post glossary:

Bridgy
  https://brid.gy/ and https://fed.brid.gy/ for direct federation instead of POSSE
CMS
  https://indieweb.org/CMS
h-card
  https://microformats.org/wiki/h-card
h-entry
  https://microformats.org/wiki/h-entry
h-feed
  https://microformats.org/wiki/h-feed
microformats2 syntax
  https://microformats.org/wiki/microformats2-parsing
rel-me
  https://microformats.org/wiki/rel-me
SSG
  https://indieweb.org/SSG
Webmention
  https://indieweb.org/Webmention
Withknown
  https://indieweb.org/Known


References:

¹ https://tantek.com/2023/234/t1/threads-supports-indieweb-rel-me
² https://indieweb.org/rel-me#Letterboxd

Yesterday I proposed the idea of a “minimum interesting service worker” that could provide a link (or links) to archives or mirrors when your site was unavailable as one possible solution to the desire to make personal #indieweb sites more reliable by providing at least a user path to “soft repair” links to your site that may otherwise seem broken.

Minimum because it only requires two files and one line of script in site footer template, and interesting because it provides both a novel user benefit and personal site publisher benefits.

The idea occurred to me during an informal coffee chat over Zoom with a couple of other Indieweb community folks yesterday, and afterwards I braindumped a bit into the IndieWeb Developers Chat channel¹. Figured it was worth writing up rather than waiting to implement it.

Basic idea:

You have a service worker (and “offline” HTML page) on your personal site, installed from any page on your site, that all it does is cache the offline page, and on future requests to your site checks to see if the requested page is available, and if so serves it, otherwise it displays your offline page with a “site appears to be unreachable” message that a lot of service workers provide, AND provides an algorithmically constructed link to the page on an archive (e.g. Internet Archive) or static mirror of your site (typically at another domain).

This is minimal because it requires only two files: your service worker (a JS file) and your offline page (a minimal self-contained static HTML file with inline CSS). Doable in <1k bytes of code, with no additional local caching or storage requirements, thus a negligible impact on site visitors (likely less than the cookies that major sites store).

User benefit:

If someone has ever visited your personal site, then in the future whenever they click a link to your pages or posts, if your site/domain is unavailable for any reason, then the reader would see a notice (from your offline page) and a link to view an archive/mirror copy instead, thus providing a one-click ability for the reader to “soft-repair” any otherwise apparently broken links to your site.

Personal site publisher benefits:

Having such a service worker that automatically provides your readers links to where they can view your content on an archive or mirror means you can go on vacation or otherwise step away from your personal site, knowing that if it does go down, (at least prior) site visitors will still have a way to click-through and view your published content.

Additional enhancements:

Ideally any archive or mirror copies would use rel=canonical to link back to the page on your domain, so any crawlers or search engines could automatically prefer your original page, or browsers could offer the user a choice to “View original”. You can do that by including a rel=canonical link in all your original pages, so when they are archived or mirrored, those copies automatically include a rel=canonical link back to your original page or post.

The simplest implementation would be to ping the Internet Archive to save² your page or post upon publishing it. You could also add code to your site to explicitly generate a static mirror of your pages, perhaps with an SSG or crawler like Spiderpig, to a GitHub repo, which is then auto-served as GitHub static pages, perhaps on its own domain yet at the same paths as your original pages (to make it trivial to generate such mirror links automatically).

If you’re using links to the Internet Archive, you can generate them automatically by prefixing your page URL with https://web.archive.org/web/*/ e.g. this post:

https://web.archive.org/web/*/https://tantek.com/2024/151/t1/minimum-interesting-service-worker

Possible generic library:

It may be possible to write this minimum interesting service worker (e.g. misv.js) as a generic (rather than site-specific) service worker that literally anyone with a personal site could “install” as is (a JS file, an HTML file, and a one-line script tag in their site-wide footer) and it would figure everything out from the context it is running in, unchanged (zero configuration necessary).


This is post 14 of #100PostsOfIndieWeb. #100Posts

← https://tantek.com/2024/072/t1/created-at-indiewebcamp-brighton
→


Post glossary:

GitHub static pages
  https://indieweb.org/GitHub_Pages
HTML
  https://indieweb.org/HTML
JS
  https://indieweb.org/js
rel-canonical
  https://indieweb.org/rel-canonical
service worker
  https://indieweb.org/service_worker
Spiderpig
  https://indieweb.org/Spiderpig
SSG
  https://indieweb.org/SSG

 
References:

¹ https://chat.indieweb.org/dev/2024-05-29#t1717006352142600
² https://indieweb.org/Internet_Archive#Trigger_an_Archive