Show Navigation
Notices tagged with indieweb
-
I have written several posts with tips for various aspects of blogging. This post curates those posts and bits from the #IndieWeb wiki into a linear progression, from why, to what, and how to post. 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.
Why Post
There is a whole wiki page on the topic:
* https://indieweb.org/why_post — which could use some gardening
Here is a summary of reasons why to post:
1. 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.
2.
What to Post
* 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
How to Post
* 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 writings, 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 subsections: Previously, Post Glossary, References, Additional Reading
* Check your references
Each of these points could be its own blog post.
Glossary
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 #indieweb 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
→ 🔮
-
Last week at a #HomebrewWebsiteClub session¹ I pointed out that I was working on implementing a “simple” way to support embeds of my notes, that is, make my short notes embeddable, like how people embed tweets or toots.
I noted that to keep it as simple as possible while being flexible to implementation changes, I planned to implement three things:
1. A separate “embed” version of my post permalinks, with just the entry information (no header, nav, search, sidebar, footer etc.), embeddable via copy/paste or an iframe.
2. A way to “Follow Your Nose” discover that separate embed version
3. A way to discover the original post from the embedded version
For (1) a minimal h-entry, with perhaps a little bit of inline CSS would suffice.
For (2) I proposed using “rel=embed” which I’ve subsequently written up briefly².
For (3) The obvious existing answer is rel=canonical link from the embed version to the canonical post permalink.
Soon thereafter, several folks in the #IndieWeb community went ahead and implemented such embeds for their own sites, and even the https://libre.fm/ open scrobbling service!
https://indieweb.org/embed#IndieWeb_Examples
I have yet to implement it myself, and that’s fine. This is one of the things I appreciate about the community, we can share our plans and ideas for improving things on our own sites, and if someone else does it first, that's great! We celebrate it and explore the solution space together.
Got other ideas for simple embeds? Want to implement them on your own site?
Join us in the #indiewebdev chat: https://chat.indieweb.org/dev
UPDATE: What about oEmbed? tl;dr: oEmbed requires JS and backend code, more work and unsuitable for embeds from static site hosting (like GitHub pages).
A simple HTML method is accessible to many more independent publishers and easier to implement. More: https://tantek.com/2024/306/t2
Glossary
embed
https://indieweb.org/embed
Follow Your Nose
https://indieweb.org/follow_your_nose
h-entry
https://microformats.org/wiki/h-entry
oEmbed
https://indieweb.org/oEmbed
rel-canonical
https://indieweb.org/rel-canonical
static site hosting
https://indieweb.org/static_web_hosting
References
¹ https://indieweb.org/events/2024-10-23-hwc-europe#embedding
² https://indieweb.org/rel-embed
This is post 27 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/287/t1/fediverse-unfollow-bridgyfed-bug
→ 🔮
-
European friends!
🗓 I am going to Beyond Tellerand (@btconf@mastodon.social) Berlin next week 7-8 November and you should too!
BTconf is the best independent web design, development, and inspiration conference in Europe.
Everything from the speakers to the talks to the side events are a labor of love by @MarcThiele.com (@marcthiele@mastodon.social) and his crew, and it shows in the #btconf community he has gathered over the years.
If you’re in #Berlin, or can hop on a train and join us, you should.
🎟 Grab a ticket: https://btco.nf/t
And while you’re there, consider joining us at #IndieWebCamp Berlin right afterwards on 9-10 November (complimentary camp tickets at the same link), for #barcamp style discussions sessions and an #indieweb Create Day, writing, styling, designing, coding, hacking on our personal sites for a better web for ourselves and everyone else.
-
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
→ 🔮
-
Happy October!
For some reason this month has a plethora of daily blogging or other creativity prompts. Here’s a list of the ones I found so far:
* #Blogtober (consider this post my first for this, retroactively day 1)
* Inktober — https://inktober.com/
* LOLtober - https://weblog.anniegreens.lol/2024/10/loltober-2024
* Looptober — https://looptober.com/
* Mathober - https://mathober.com/
* Viztober — https://www.instagram.com/evalottchen/p/DAiNm3ZtuTj/
Having found so many for the month I created an “October” page on the #IndieWeb wiki to document them all (and in case folks find others to add):
* https://indieweb.org/October
October is also a very popular month for seasonal blog styling:
* https://indieweb.org/Halloween
Do you have a custom Halloween theme for your personal site? Add it to the wiki!
This is post 23 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/247/t4/w3c-link-checker-before-federating
→ 🔮
-
20 years and two weeks ago, I came up with undohtml.css and unknowingly invented the mechanism of CSS Resets (AKA reboot or reset style sheets¹) which spawned numerous variants, many still in broad use on the web today.
https://tantek.com/log/2004/09.html#d06t2354
A one sentence problem description, and a short paragraph describing my problem-solving, actions, license, link to less than 300 bytes of code (not counting comments), and a few future thoughts.
The rest of that blog post was about “debug scaffolding”, the part I thought was more interesting at the time.
Eric Meyer (@meyerweb.com @meyerweb@mastodon.social) followed up ~10 days afterwards with his thinking and improvements:
* https://meyerweb.com/eric/thoughts/2004/09/15/emreallyem-undoing-htmlcss/
where he mentioned “resetting” in passing, but not actually calling it a "reset".
~2.5 years later Eric published “Reset Styles” with further reasoning and improvements:
* http://meyerweb.com/eric/thoughts/2007/04/12/reset-styles/
describing them as: “reset” or “baseline” set of styles.
Subsequently he iterated in several more blog posts:
* http://meyerweb.com/eric/thoughts/2007/04/14/reworked-reset/
* http://meyerweb.com/eric/thoughts/2007/04/18/reset-reasoning/ — this is Eric’s first post where he explicitly calls them “reset styles”, which I believe is the origin of the eventual phrase “CSS Reset” and “reset style sheets”
* http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/ (yes a Matrix: Reloaded reference)
~6 months later Eric published his evergreen resource “CSS Tools: Reset CSS”
* https://meyerweb.com/eric/tools/css/reset/
which, as you see within the URL: “css/reset”, is perhaps where the phrase “CSS Reset” comes from, and it’s also the label (link text) he gives that page in his UI about-page² and the first content link in his 404 page³.
My technology invention takeaways from all this:
1. if you find yourself repeatedly solving the same (especially annoying) problem, create a re-usable solution that works for you
2. write up your problem statement / use-case in only one sentence
3. publish your solution (on your personal site⁴), name it something short, with only a short paragraph description, and re-use/remix friendly license (like Creative Commons)
And things not to worry about (that may get in your way to publishing):
1. perfecting or making your solution “big enough” or “the right size”. does it solve your problem? then it’s already the right size.
2. coming up with the perfect name. instead, name it what it does. someone might come up with a better name weeks, months, or years later. let them run with it!
3. waiting to blog multiple things. I could have blogged undohtml.css by itself, probably should have, and instead lumped it into a blog post with another CSS thing I came up with.
Further reading and resources for CSS Resets:
* More history: https://css-tricks.com/reboot-resets-reasoning/
* Large collection: https://perishablepress.com/a-killer-collection-of-global-css-reset-styles/
References:
¹ https://en.wikipedia.org/wiki/Reset_style_sheet
² https://meyerweb.com/ui/about.html
³ https://meyerweb.com/404
⁴ https://indieweb.org/
#undoHTML #undoHTMLCSS #reset #CSSreset #resetstyles #webdesign #technology #invention #indieweb
-
Twenty years ago this past February, Kevin Marks and I introduced #microformats in a conference presentation.
Full post: https://tantek.com/2024/044/t1/twenty-years-microformats
Aside: This is an even shorter summary of that post from ~200 days ago, which #Mastodon readers never got due to a Mastodon #federation bug (details in https://tantek.com/t5Yo1).
Since early 2023, here are the top three updates & interesting developments in microformats:
1. Growing rel=me adoption for distributed verification (✅ in Mastodon etc.)
* Wikipedia, Threads, omg.lol
2. Proposal to merge #microformats2 h-review into h-entry, since in practice (e.g. on #indieweb) reviews are just entries with a bit more.
3. #metaformats adoptions, implementations, iteration
-
Twenty years ago this past February, @KevinMarks.com (@KevinMarks@xoxo.zone) and I introduced #microformats in a conference presentation.
Full post: https://tantek.com/2024/044/t1/twenty-years-microformats
Aside: This is a summary of a longer post from ~200 days ago¹, which #Mastodon readers never got due to a Mastodon #federation bug (instances returned 202 for post inbox delivery, but did not show post to followers or on local profiles, details in https://tantek.com/t5Yo1).
I wrote a retrospective last year: https://tantek.com/2023/047/t1/nineteen-years-microformats
Since then, here are the top three updates & interesting developments in microformats:
1. Growing rel=me adoption for distributed verification (✅ in Mastodon etc.)
* Wikipedia, Threads, omg.lol support
2. A proposal to merge #microformats2 h-review into h-entry, since reviews are in practice (e.g. on the #indieweb) always entries with a bit more information.
3. #metaformats adoptions, implementations, and iteration
More details:
¹ https://tantek.com/2024/044/t1/twenty-years-microformats
-
✏️ 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
-
✏️ 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 @KevinMarks.com (@kevinmarks@indieweb.social @kevinmarks@xoxo.zone @kevinmarks) 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, 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
→ 🔮
-
Had a great time at IndieWebCamp Portland 2024 this past Sunday — our 10th IndieWebCamp in Portland!
https://events.indieweb.org/2024/08/indiewebcamp-portland-2024-8bucXDlLqR0k
Being a one day #IndieWebCamp, we focused more on making, hacking, and creating, than on formal discussion sessions.
Nearly everyone gave a brief personal site intro with a summary of how they use their #IndieWeb site and what they would like to add, remove, or improve.
* https://indieweb.org/2024/Portland/Intros
There were lots of informal discussions, some in the main room, on the walk to and from lunch, over lunch in the nearby outdoor patio, or at tables inside the lobby of the Hotel Grand Stark.
We wrapped up with our usual Create Day¹ Demos session, live streamed for remote attendees to see as well. Lots of great demos of things people built, designed, removed, cleaned-up, documented, and blogged! Everyone still at the camp showed something on their personal site!
* https://indieweb.org/2024/Portland/Demos
Group photo and lots more about IndieWebCamp Portland 2024 at the event’s wiki page:
* https://indieweb.org/2024/Portland
Thanks to everyone who pitched in to help organize IndieWebCamp Portland 2024! Thanks especially to Marty McGuire (@martymcgui.re) for taking live notes during both the personal site intros and create day demos, to Kevin Marks (@kevinmarks@indieweb.social @kevinmarks@xoxo.zone @kevinmarks) for the IndieWebCamp live-tooting, and Ryan Barrett (@snarfed.org) for amazing breakfast pastries from Dos Hermanos.
The experience definitely raised our hopes and confidence for returning to Portland in 2025.²
References:
¹ https://indieweb.org/Create_Day
² https://indieweb.org/Planning#Portland
This is post 19 of #100PostsOfIndieWeb. #100Posts #2024_238
← https://tantek.com/2024/238/t3/indiewebcamp-auto-linking
→ https://tantek.com/2024/245/t1/read-write-suggest-edit-web
-
Had a great time at IndieWebCamp Portland 2024 this past Sunday — our 10th IndieWebCamp in Portland!
https://events.indieweb.org/2024/08/indiewebcamp-portland-2024-8bucXDlLqR0k
Being a one day #IndieWebCamp, we focused more on making, hacking, and creating, than on formal discussion sessions.
Nearly everyone gave a brief personal site intro with a summary of how they use their #IndieWeb site and what they would like to add, remove, or improve.
* https://indieweb.org/2024/Portland/Intros
There were lots of informal discussions, some in the main room, on the walk to and from lunch, over lunch in the nearby outdoor patio, or at tables inside the lobby of the Hotel Grand Stark.
We wrapped up with our usual Create Day¹ Demos session, live streamed for remote attendees to see as well. Lots of great demos of things people built, designed, removed, cleaned-up, documented, and blogged! Everyone still at the camp showed something on their personal site!
* https://indieweb.org/2024/Portland/Demos
Group photo and lots more about IndieWebCamp Portland 2024 at the event’s wiki page:
* https://indieweb.org/2024/Portland
Thanks to everyone who pitched in to help organize IndieWebCamp Portland 2024! Thanks especially to Marty McGuire (@martymcgui.re) for taking live notes during both the personal site intros and create day demos, to @KevinMarks.com (@kevinmarks@xoxo.zone @kevinmarks @kevinmarks@indieweb.social) for the IndieWebCamp live-tooting, and Ryan Barrett (@snarfed.org) for amazing breakfast pastries from Dos Hermanos.
The experience definitely raised our hopes and confidence for returning to Portland in 2025.²
References:
¹ https://indieweb.org/Create_Day
² https://indieweb.org/Planning#Portland
This is post 19 of #100PostsOfIndieWeb. #100Posts #2024_238
← https://tantek.com/2024/238/t3/indiewebcamp-auto-linking
→ 🔮
-
People over protocols over platforms.
inspired by today’s #indieweb #fediverse #ActivityPub #decentralized #socialMedia lunch meetup at #XOXO #XOXOConf (@xoxo@xoxo.zone)
This is post 16 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/173/t1/years-posse-microformats-adoption
→ 🔮
-
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) 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 (@pluralisticmamot.fr) 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
→ 🔮
Post glossary:
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
-
The Library of Infinite Loan is a physical world practice I conceived of many many years ago¹, implemented in minimal prototype form 5+ years ago², shared a summary with the #IndieWeb community at least four years ago at the #IndieWebCamp Austin in 2020³ and last year in IndieWeb chat⁴, so it’s about time⁵ I wrote it down.
Summary: lend a #book from your personal library⁶ to a friend, on the conditions that they do not donate sell or dispose of it, and instead when they are done with it they return it or lend it to someone else who agrees to these conditions.
My goal was to create a book lending system that:
* preserves books — effectively in a giant #distributed communal #library
* makes lending easier fiscally, psychologically, emotionally for both parties
* encourages direct person-to-person lending without intermediaries
* grows a culture of non-zero-sum sharing, preservation, and longterm thinking
The basic steps to create a Library of Infinite Loan:
1. Create a separate space (like a particular bookshelf) for #books to infinite lend. A small shelf in a guest room or common space like a hallway works well.
2. Move books there that you are ok lending out and never seeing again
3. Label that space your “Library of Infinite Loan”, or invite guests to borrow from your “Library of Infinite Loan”
4. When visitors ask what that means, explain the Rules
Rules for borrowing from a Library of Infinite Loan (“the Rules”)
1. Keep it as long as you like
2. Do not sell donate or otherwise dispose of it
3. You may give it
a. back to the person you borrowed from
b. or back to its original purchaser if they wrote their name and web address inside
c. or (lend it) to someone else who agrees to the Rules
There are several ways to extend / expand the Library of Infinite Loan:
* custom book plate: design a custom book plate for yourself with room for your name (and web address) on it e.g. “From Tantek’s (@tantek.com) Library” (with space), print it on longterm adhesive paper, and place it inside new books you purchase. When you move a book to your Library of Infinite Loan, amend the book plate to say ”… Library of Infinite Loan” and attach a copy of the Rules.
* add a “borrowers log” with blank lines for anyone you lend it to or they lend it to, transitively, to optionally add their name, web address, and a date of borrowing. Then amend the rules to allow returning a book to who you borrowed from or anyone in the borrower log or original purchaser.
* more media: CDs, vinyl records, DVDs, LaserDiscs, VHS, cassette tapes, video game cartridges etc.
* other things
* large tools — which usually come in a box with instruction manual, so there’s a logical place to put an “owners plate”, “borrowers log”, and copy of the rules.
* artwork — a great way to rotate art among a community
This is what I remember off the top of my head and with a little web searching. I know I have a bunch more notes in various places of my thoughts (and conversations) over the years about a Library of Infinite Loan. As I find those notes, I’ll post them as well.
#infiniteLoan #libraryOfInfiniteLoan
References:
¹ I’m looking through old personal logs for earliest mentions of “infinite loan”
² In my 2019 personal log I found a note that I “moved some books as library of infinite loan to guest room” where I had previously setup a small bookshelf for such books.
³ https://indieweb.org/2020/Austin/reading
⁴ https://chat.indieweb.org/2023-10-01#t1696202307311300
⁵ I was also inspired by sharing the idea again to a couple of friends in an espresso-making livestream this morning
⁶ https://indieweb.org/personal_library
-
Last week I participated @W3.org (@w3c@w3c.social) #W3CAC (W3C Advisory Committee¹), #W3CAB (W3C Advisory Board² @ab@w3c.social), and #W3CBoard³ meetings in Hiroshima, Japan.
The W3C Process⁴ describes the twice a year AC (Advisory Committee) Meetings⁵. In addition to members of the AC (one primary and one alternate per W3C Member Organization), the meetings are open to the AB (Advisory Board), the Board of the W3C Corporation, the #w3cTAG (W3C Technical Architecture Group⁶ @tag@w3c.social), Working Group⁷ chairs, Chapter⁸ staff, and this time also a W3C Invited Expert designated observer⁹.
The AC currently meets in the Spring on its own and a shorter meeting in the Fall as part of the annual #W3CTPAC (W3C Technical Plenary and Advisory Committee¹⁰ meetings). The existence, dates, and location of the event are public¹¹, however the agenda, minutes, and registrants are generally Member-confidential. Since those individual links have their own access controls, I collected them on a publicly-viewable wiki page for easier discovery & navigation (if you work for a W3C Member Organization¹²):
* https://www.w3.org/wiki/AC/Meetings#2024_Spring
Most of the W3C meeting materials and discussions were also W3C Member-confidential, however a several of the presentations are publicly viewable, and a few more may be shared publicly after the fact.
Myself and others at #W3C who believe in pushing for more openness and transparency in standards work, even (or especially) governance of said work, will be doing our best to work with others at W3C to continue shifting our work accordingly.
Aside: I started the #OpenAB project when I was first elected to the AB (Advisory Board) in 2013, documenting it on the publicly viewable W3C Wiki, and updated it with the help of others since: https://www.w3.org/wiki/AB#Open_AB
Like most conferences, I got as much out of side conversations at breaks (AKA hallway track¹³) and meals as I did from scheduled talks and panels.
For now, here are the events, slides, and videos which are publicly viewable that provide an interesting glimpse into some of the topics discussed:
* 📄 report: https://www.w3.org/reports/ai-web-impact/
* 🖼 slides: https://www.w3.org/2024/Talks/ac-slides/engaging-the-members/
* 🖼 slides: https://www.w3.org/2024/Talks/ac-slides/exploration/
* 🖼 slides: https://www.w3.org/2024/Talks/ac-slides/OHCHR.pdf
* ▶️ video 5m42s: https://customer-0kix77mxh2zzzae0.cloudflarestream.com/9ad1e01b20d9b15d413f02c0ada3fe34/watch
* ▶️ video 4m16s: https://customer-0kix77mxh2zzzae0.cloudflarestream.com/1bfde2bf614d7535b8a775217a949974/watch
* 🗓 event: https://www.w3.org/events/meetings/13213a52-8159-4af8-b939-38c7880ba266/
* 🖼 slides: https://www.w3.org/2024/Talks/ac-slides/lt-deepfake/
* 🖼 slides: https://www.w3.org/2024/Talks/ac-slides/lt-accessing-llms-data/
* 🖼 slides: https://www.w3.org/2024/Talks/ac-slides/pac-data-sovereignty/ (nice #IndieWeb mention)
* 🖼 slides: https://www.w3.org/2024/Talks/ac-slides/intro-content-credentials.pdf
* 🖼 slides: https://w3c.github.io/adapt/presentations/ac2024/ Warning: the proposed use of .well-known therein is IMO a bad mistake. Unnecessary reinvention (most handled by existing rel values¹⁴), more complex to author (requires sidefiles¹⁵), harder to publish (requires site admin root access), likely to become inaccurate (Ruby’s postulate¹⁶), and fragile (site admins frequently break .well-known for individual pages). A full critique likely requires its own blog post.
* 🗓 event: https://www.w3.org/events/meetings/df0b9dd8-2356-47ec-839d-eadc06da1ca1/
I’ll update this list with additional resources as they are made publicly viewable.
If you work for a W3C Member Organization you can view the full list of resources linked from the Member-confidential agenda: https://www.w3.org/2024/04/AC/ac-agenda.html#monday
References:
¹ https://w3.org/wiki/AC
² https://w3.org/wiki/AB
³ https://w3.org/wiki/Board
⁴ https://www.w3.org/Consortium/Process/
⁵ https://www.w3.org/2023/Process-20231103/#ACMeetings
⁶ https://w3.org/tag
⁷ https://www.w3.org/groups/wg/
⁸ https://chapters.w3.org/
⁹ https://www.w3.org/invited-experts/#ac-observer
¹⁰ https://www.w3.org/wiki/TPAC
¹¹ https://www.w3.org/events/ac/2024/ac-2024/
¹² https://www.w3.org/membership/list/
¹³ https://en.wiktionary.org/wiki/hallway_track
¹⁴ https://microformats.org/wiki/existing-rel-values
¹⁵ https://indieweb.org/sidefile-antipattern
¹⁶ https://intertwingly.net/slides/2004/devcon/68.html
-
@indieweb.org/POSSE in effect!
Well done @joanwestenberg@threads.net 🙌🏻
#POSSE threads
https://www.threads.net/@joanwestenberg/post/C43gPbVSzPI:
“Me: You should publish on your own website first, then other platforms.
Me: Publishes on my own website first, then other platforms.
Galaxy brains: HOW IRONIC YOU PUBLISH ON OTHER PLATFORMS”
#IndieWeb
-
While an HTML style element for inline CSS needs nothing but simple start and end tags (as of HTML5 and later)
<style>
p { margin:0 }
</style>
a more robust style element requires a precise series of overlapping code comments.
Here is the answer if you want a code snippet to copy & paste
<style><!--/*--><![CDATA[*/
p { margin:0 } /* you may delete this sample style rule */
/*]]><!--*/--></style>
Here is why:
1. Not all HTML processors are CSS processors. While all modern browsers know how to parse CSS in style elements inside HTML, it is still quite reasonable for people to build HTML processors that do not, and many exist. There are plenty of ways that errant or deliberately misplaced markup inside a style element, like in a CSS comment, that such processors will not see, that can break them and cause unexpected and different results in different processors.
Thus it makes your HTML more parseable, by more processors, if you can hide the entirety of the style sheet inside the style elmenet from such processing. A CDATA section does exactly that:
<style><![CDATA[
p { margin:0 } /* CDATA allows a </style> here to not close the element */
body > p { margin:1em } /* CDATA allows an unescaped > child combinator */
]]></style>
2. However CSS syntax does not recognize a CDATA directive (even as of the latest published CSS Syntax Module Level 3¹ or editor's draft² as of this writing). CSS parsers may very well treat a CDATA directive as a syntax error that invalidates the subsequent style rule.
Thus we must hide the CDATA directive, its opening and closing markup, from CSS parsers. CSS code comments /* ... */ can do exactly that:
<style>/* <![CDATA[*/
p { margin:0 } /* CDATA allows a </style> here to not close the element */
body > p { margin:1em } /* CDATA allows an unescaped > child combinator */
/*]]>*/</style>
3. This is close but still exposes HTML processors that do not process CSS to a minimal bit of content, the CSS comment opener and closer that are outside the CDATA section:
/* */
This recently showed up in a draft of the This Week in The #IndieWeb newsletter³, because portions of it are automatically constructed by parsing the HTML of MediaWiki pages for content, and one of those used a MediaWiki template that included a minimal style element to style the marked up content inserted by the template. A draft of the newsletter was showing raw CSS, extracted as text from the style element by the CSS-unaware parser extracting content. I was able to hide nearly all of it using CSS comments around the CDATA section opener and closer. Except for that little bit of CSS comment noise outside the CDATA section: /* */
Fortunately there is one more tool in our toolbox that we can use. Simple HTML/SGML comments <!-- --> are ignored at the start and end of style sheets⁴ (noted there as CDO-token⁵ and CDC-token⁶), and thus we can use those to hide the last two remaining CSS comment pieces that were leaking out, like this: <!-- /* --> and <!-- */ -->. Note that the portion of the HTML comment directives that are inside CSS comments are ignored by CSS processors, which is why this works for both processors that parse CSS and those that do not.
This last addition produces our answer, with no fewer than three different comment mechanisms (CDATA, CSS, HTML/SGML), overlapping to hide each other from different processors:
<style><!--/*--><![CDATA[*/
p { margin:0 } /* CDATA allows a </style> here to not close the element */
body > p { margin:1em } /* CDATA allows an unescaped > child combinator */
/*]]><!--*/--></style>
By replacing those informative style rules with a style rule to be deleted, we have recreated the code snippet to copy & paste from the top of the post:
<style><!--/*--><![CDATA[*/
p { margin:0 } /* you may delete this sample style rule */
/*]]><!--*/--></style>
Q.E.D.
Afterword:
If you View Source on this original permalink or my home page you can see the more robust style element in a real world example, following the IndieWeb Use What You Make⁷ principle.
#CSS #style #styleElement #styleSheet #HTML #HTML5 #CSSsyntax #codecomments
Glossary:
CDATA
https://en.wikipedia.org/wiki/CDATA
CSS — Cascading Style Sheets
https://en.wikipedia.org/wiki/CSS
HTML — HyperText Markup Language
https://en.wikipedia.org/wiki/HTML
HTML5
https://en.wikipedia.org/wiki/HTML5
IndieWeb Principles
https://indieweb.org/principles
MediaWiki
https://en.wikipedia.org/wiki/MediaWiki
original permalink
https://indieweb.org/original_permalink
Q.E.D.
https://en.wikipedia.org/wiki/Q.E.D.
References:
¹ https://www.w3.org/TR/css-syntax-3/
² https://drafts.csswg.org/css-syntax/
³ https://indieweb.org/this-week-in-the-indieweb
⁴ https://www.w3.org/TR/css-syntax-3/#stylesheet-diagram
⁵ https://www.w3.org/TR/css-syntax-3/#CDO-token-diagram
⁶ https://www.w3.org/TR/css-syntax-3/#CDC-token-diagram
⁷ https://indieweb.org/use_what_you_make
Tantek
All stadeus content and data are available under the