Show Navigation
Notices tagged with 100postsofindieweb, page 2
-
✏️ 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
→ 🔮
-
Nice #IndieWebCamp discussion session with Kevin Marks (@kevinmarks@indieweb.social @kevinmarks@xoxo.zone @kevinmarks) on the topic of auto-linking¹.
I’ve implemented an auto_link function² that handles quite a few use-cases of URLs (with or without http: or https:), @-name @-domain @-domain/path @-@-handles, hashtags(#), and footnotes(^).
Much of it is based on what I’ve seen work (or implemented) on sites and software, and some of it is based on logically extending how people are using text punctuation across various services.
It may be time for me to write-up an auto-link specification based on the algorithms I’ve come up with, implemented, and am using live on my site. All the algorithms work fully offline (none of them require querying a site for more info, whether well-known or otherwise), so they can be used in offline-first authoring/writing clients.
I have identified three logical chunks of auto-linking functionality, each of which has different constraints and potential needs for local to the linking context information (like hashtags need a default tagspace). Each would be a good section for a new specification. Each is used by this very post.
* URLs, @-s, and @-@-s
* # hashtags
* ^ footnotes
#IndieWeb #autoLink #hashtag #hashtags #footnote #footnotes
Previously, previously, previously:
* https://tantek.com/2024/070/t1/updated-auto-linking-mention-use-cases
* https://tantek.com/2023/100/t1/auto-linked-hashtags-federated
* https://tantek.com/2023/043/t1/footnotes-unicode-links
* https://tantek.com/2023/019/t5/reply-domain-above-address-and-silo
References:
¹ https://indieweb.org/autolink
² https://github.com/tantek/cassis/blob/main/cassis.js
This is post 18 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/238/t1/indiewebcamp-portland
→ https://tantek.com/2024/242/t1/indiewebcamp-portland
-
Nice #IndieWebCamp discussion session with @KevinMarks.com (@kevinmarks@xoxo.com @kevinmarks) on the topic of auto-linking¹.
I’ve implemented an auto_link function² that handles quite a few use-cases of URLs (with or without http: or https:), @-name @-domain @-domain/path @-@-handles, hashtags(#), and footnotes(^).
Much of it is based on what I’ve seen work (or implemented) on sites and software, and some of it is based on logically extending how people are using text punctuation across various services.
It may be time for me to write-up an auto-link specification based on the algorithms I’ve come up with, implemented, and am using live on my site. All the algorithms work fully offline (none of them require querying a site for more info, whether well-known or otherwise), so they can be used in offline-first authoring/writing clients.
I have identified three logical chunks of auto-linking functionality, each of which has different constraints and potential needs for local to the linking context information (like hashtags need a default tagspace). Each would be a good section for a new specification. Each is used by this very post.
* URLs, @-s, and @-@-s
* # hashtags
* ^ footnotes
#IndieWeb #autoLink #hashtag #hashtags #footnote #footnotes
Previously, previously, previously:
* https://tantek.com/2024/070/t1/updated-auto-linking-mention-use-cases
* https://tantek.com/2023/100/t1/auto-linked-hashtags-federated
* https://tantek.com/2023/043/t1/footnotes-unicode-links
* https://tantek.com/2023/019/t5/reply-domain-above-address-and-silo
References:
¹ https://indieweb.org/autolink
² https://github.com/tantek/cassis/blob/main/cassis.js
This is post 18 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/238/t1/indiewebcamp-portland
→ 🔮
-
All setup here at IndieWebCamp Portland!
https://events.indieweb.org/2024/08/indiewebcamp-portland-2024-8bucXDlLqR0k
Good crowd of participants from #XOXO #XOXOConf (@xoxofest.com @xoxo@xoxo.zone @xoxo) here to work on their personal website(s), domains, or other independent social media setups!
As encouraged by Andy Baio (@waxy.org @andybaio@xoxo.zone @waxpancake)
“Every one of you should have a home on the web not controlled by a billionaire.”
If you’re in #Portland and want help, encouragement, or camaraderie in getting setup or doing more with your personal site, come on by! We’ll be having a mix of discussion sessions and create/hack sessions.
Personal site and hack demos at 16:00 PDT!
#indieweb #fediverse #ActivityPub #decentralized #socialMedia
This is post 17 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/237/t1/people-over-protocols-platforms
→ 🔮
-
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
-
What I created while remotely participating at #IndieWebCamp Brighton 2024: wiki-gardened day 1’s BarCamp sessions notes pages, and documented my @-mention @-@-mention autolinking coding improvements I built the Sunday before.
Day 2 of IndieWebCamps is Create Day, where everyone is encouraged to create, make, or build something for their personal website, or the IndieWeb community, or both.
At the start of day 2, everyone is encourage to pick things to make¹. What to make at an IndieWebCamp² can be anything from setting up your personal website, to writing a blog post, redesigning your styling, building new features, helping other participants, or contributing to shared IndieWeb community resources, whether code or content.
Everyone is encouraged to at least pick something they consider easy, that they can do in less than an hour, then a more bold goal, and then perhaps a stretch goal, something challenging that may require collaboration, asking for help, or breaking into smaller steps.
For my "easy" task, I built on what another remote participant, @gregorlove.com completed the night before. gRegor had archived all the IndieWebCamp Brighton Sessions Etherpads onto the wiki, linked from the Schedule page³. gRegor had noted that he didn’t have time to clean-up the pages, e.g. convert and fix Markdown links.
I went through the 13 Session Notes archives and did the following:
* converted Markdown links to MediaWiki links
* converted indieweb.org (and some services) links to local wiki page links
* fixed (some) typos
With some help from @alexsirac.com (@alexture@todo.eu), I figured out how to create a MediaWiki Contributions summary link of my edits:
* https://indieweb.org/wiki/index.php?title=Special:Contributions&target=Tantek.com&namespace=all&start=2024-03-10&end=2024-03-10&offset=20240310143900&limit=25
I point this out to provide an example of an IndieWeb Create Day project that is:
* incremental on top of someone else’s work
* community contribution rather a personal-focused project
* editing and wiki-gardening as valid contributions, not just creating new content
I point this out to illustrate some of the IndieWeb community's recognitions & values in contrast to typical corporate cultures and incentive systems which often only reward:
* new innovations (not incremental improvements)
* solo (or maybe jointly in a small team) inventions, designs, specs, or implementations
* something large, a new service or a big feature, not numerous small edits & fixes
In this regard, the IndieWeb community shares more in common with Wikipedia and similar collaborative communities (despite the #Indie in #IndieWeb), than any corporation.
For my "more bold" goal, I wrote a medium-sized post about the auto-linking improvements I made the Sunday before the IndieWebCamp to my personal website with examples and brief descriptions of the coding changes & improvements.
* https://tantek.com/2024/070/t1/updated-auto-linking-mention-use-cases
My stretch goal was to write up a more complete auto-linking specification, based on the research I have done into @-mention @-@-mention user practices (on #Mastodon, other #ActivityPub or #fediverse implementations, and even across #socialMedia silos), as well as how implementations link URLs, domains, and paths.
That stretch goal remains a goal, however I did collect a handful of prior posts on @-mentions which I plan to source for specifying auto-linking and @-mentioning:
* https://tantek.com/2023/011/t1/indieweb-evolving-at-mention
* https://tantek.com/2023/014/t4/domain-first-federated-atmention
* https://tantek.com/2023/018/t1/elevate-indieweb-above-silo
* https://tantek.com/2023/019/t5/reply-domain-above-address-and-silo
* https://tantek.com/2023/109/t2/years-ago-first-federated-indieweb-thread
#autoLink #atDomain #atPath #atMention #atMentions #atat #atAtMention
I was one of a few remote participants in addition to ~18 in-person participants, the overwhelming majority of overall attendees, who demonstrated something at the end of IndieWebCamp Brighton 2024 day 2. See what everyone else made & demonstrated on Create Day:
* https://indieweb.org/2024/Brighton/Demos
This is post 13 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/070/t1/updated-auto-linking-mention-use-cases
→ 🔮
Glossary:
Create Day
https://indieweb.org/Create_Day
IndieWebCamp Brighton 2024
https://indieweb.org/2024/Brighton
References:
¹ https://indieweb.org/IndieWebCamps/Attending#Day_Two
² https://indieweb.org/what_to_make_at_IndieWebCamp
³ https://indieweb.org/2024/Brighton/Schedule#Saturday
-
Updated the auto-linking code¹ on my website last Sunday to handle a few more @-mention use-cases.
In particular:
* @-domains with dashes/hyphens like @sonja-weckenmann.de
* @-@ with (some) Unicode alphabetic characters like @briansuda@loðfíll.is
* @-domain-and-path for indicating @-mentions of silo profiles that don’t support @-@ syntax, like @flickr.com/people/tantek or @instagram.com/tantek
I also dropped auto-linking of URLs with user:password "userinfo", since they’ve been long abandoned and effectively deprecated because there’s fairly wide agreement that such "basic HTTP auth"^2 was poorly designed and should not be used (and thus should not be linked).
If you’re curious you can take a look at https://tantek.com/cassis.js, which has updated functions:
* auto_link_re() — regular expression to recognize URLs, @-mentions, @-@, and footnotes to link
* auto_link() — specifically the code to recognize different kinds of @-@ and @-mentions and link them properly to profiles, domains, and paths.
This code is only live on my website (testing in production³ as it were) for now, and you’re welcome to copy/paste to experiment with it. I plan to test it more over the coming weeks (or so) and when I feel it is sufficiently well tested, will update it on GitHub⁴ as well.
With this additional auto-linking functionality, I feel I have a fairly complete implementation of how to auto-link various URLs and @-mentions, and plan to write that up at least as a minimal “list of use-cases and how they should work” auto-linking specification.
This (blog post) is my contribution to today’s #IndieWebCamp Brighton⁵ #hackday!
This was originally a project I wanted to complete during IndieWebCamp Nuremberg last October, however I was pre-occupied at the time with fixing other things.⁶
#autolink #atmention #atmentions #atat #atatmention
This is post 12 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/047/t1/indieweb-major-update-design
→ 🔮
¹ https://tantek.com/cassis.js
² https://en.wikipedia.org/wiki/Basic_access_authentication
³ https://indieweb.org/test_in_production
⁴ https://tantek.com/github/cassis
³ https://indieweb.org/2024/Brighton
⁴ https://tantek.com/2023/302/t1/indiewebcamp-completed-projects
-
New this week: the #IndieWeb community deployed a major modern update to the design, usability, and cross-device support of the https://indieweb.org/ home page and wiki in general! In brief:
* Updated MediaWiki install, updated themes, better mobile device support
* New default theme: Vector (2022), the same as English Wikipedia
* Lots of CSS fixes for content, sidebars, etc.
* Home page content simplification and more pleasing design update
Lots more details on the 2024 homepage and design update project page:
* https://indieweb.org/2024/homepage
This was a community effort, with many people pitching in with major & minor contributions, spending weeks, days, hours, or a few minutes here and there helping out. From server work, to PHP coding, to HTML+CSS (re)coding, to testing variants of MediaWiki themes, browsers, and devices.
Huge thanks in particular to @PaulRobertLloyd.com for both driving this design update (e.g. said project page) and doing the heavy lifting of debugging, patching, and testing the latest MediaWiki Vector theme, documenting before & after screenshots, and @AaronParecki.com for all the server-side software updates, PHP/IndieAuth wrangling, and critical devops too.
Go try the new https://indieweb.org/ on any browser, on any device, and share your experience!
#IndieNews
This is post 11 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/046/t1/the-ephemeral-web
→ 🔮
-
A couple of days ago in an informal discussion in the #indieweb chat channel about how different people view #Mastodon, the #fediverse, or #Bluesky, and services like #Bridgy & #BridgyFed quite differently, I noted¹ that one big unspoken difference was how things on the web last over time, from the traditional persistent web, vs the newer and growing ephemeral web.
There is the publicly viewable #OpenWeb that many of us take for granted, meaning the web that is persistent, that lasts over time, and thanks to being #curlable, that the Internet Archive archives, and that a plurality of search engines see and index (robots.txt allowing). The HTML + CSS + media files declarative web.
Then there are the https APIs that return JSON "web", the thing that I’ve started calling the ephemeral web, the set of things that are here today, briefly, gone tomorrow. I’ve previously used the more provocative phrase js;dr (JavaScript required, Didn’t Read) for this #ephemeralWeb, yet like many things, it turns out there is a spectrum from ephemeral to persistent.
One popular example on that spectrum that’s closer to the ephemeral edge is anything on a Mastodon server running v4 (or later as of this writing) of the software. (I’m not bothering to discuss the examples of walled garden social media silos because I expect we will continue to see their demise² over time.)
For example, the Internet Archive version of the shutdown notice for the queer(.)af Mastodon server, is visibly blank:
https://web.archive.org/web/20240112165635/https://queer.af/@postmaster/111733741786950083
Note: only a single Internet Archive snapshot was made of that post.
However if you View Source, you can find the entirety of that #queerAF post duplicated across a couple of invisible-to-the-user meta tags inside the raw HTML:
"**TL;DR: Queer[.]AF will close on 2024-04-12** …"
[.] added to avoid linking to a dead domain.
Note: such meta tags in js;dr pages were part of the motivation to specify metaformats.
To be clear, the shutdown of queer(.)af was a tragedy and not the fault of the creators, administrators etc., but rather one of the unfortunate outcomes of using some ccTLDs, country-code top level domains, that risk sudden draconian rules, domain renewal price hikes, or other unpredictable risks due to the politics, turmoil, regime changes etc. of the countries that administrate such domains.
Nearly the entirety of every Mastodon server, every post, every reply, is ephemeral.
When a Mastodon server shuts down, all its posts disappear from the surface of the web, forever.
Perhaps internet archeologists of the future will discover such dead permalinks, check the Internet Archive, find apparent desolation, and a few of them will be curious enough to use View Source tools to unearth parts of those posts, unintentionally preserved inside ceremonial meta tags next to dead scripts disconnected from databases and an empty shell of a body.
All reply-contexts of and replies to such posts and conversations lost, like threads unraveled from an ancient tapestry, scattered to the winds.
If you’re reading this post in your Mastodon reader, on either the website of your Mastodon account, or in a proprietary native client application, you should be able to click through, perhaps on the date-time stamp displayed to you, to view the original post on my website, where it is served in relatively simple declarative HTML + CSS with a bit of progressive enhancement script.
Because I serve declarative content, my posts are both findable across a variety of services & search engines, and archived by the Internet Archive. Even if my site goes down, snapshots or archives will be viewable elsewhere, with nearly the same fidelity of viewing them directly on my site.
This design for longevity is both deliberate, and the default for which the web was designed. It’s also one of the explicit principles in the IndieWeb community.
If that resonates with you, if creating, writing, & building things that last matter to you, choose web tools, services, and software that support the persistence & longevity of your work.
#persistentWeb #longWeb #LongNow
This is post 10 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/035/t2/indiewebcamp-brighton-tickets-available
→ 🔮
Post glossary:
API (Application Programming Interface)
https://indieweb.org/API
Bluesky
https://indieweb.org/Bluesky
Bridgy
https://brid.gy/
Bridgy Fed
https://fed.brid.gy/
ccTLD (country-code top level domain)
https://indieweb.org/ccTLD
curlable
https://indieweb.org/curlable
declarative web
https://www.mozilla.org/en-US/about/webvision/full/#thedeclarativeweb
Internet Archive
https://archive.org/
js;dr (JavaScript required; Didn’t Read)
https://tantek.com/2015/069/t1/js-dr-javascript-required-dead
JSON
https://indieweb.org/JSON
longevity
https://indieweb.org/longevity
Mastodon
https://indieweb.org/Mastodon
metaformats
https://microformats.org/wiki/metaformats
permalink
https://indieweb.org/permalink
principles in the IndieWeb community
https://indieweb.org/principles
progressive enhancement
https://indieweb.org/progressive_enhancement
reply
https://indieweb.org/reply
reply-context
https://indieweb.org/reply-context
robots.txt
https://indieweb.org/robots_txt
social media
https://indieweb.org/social_media
silo
https://indieweb.org/silo
View Source
https://firefox-source-docs.mozilla.org/devtools-user/view_source/index.html
¹ https://chat.indieweb.org/2024-02-13#t1707845454695700
² https://indieweb.org/site-deaths
-
#Brighton #London and other #England & #Europe friends:
🎪 #IndieWebCamp Brighton tickets are available!
🎟 https://ti.to/indiewebcamp/brighton-2024
🗓 2024-03-09…10
🏢 The Skiff, Brighton, England
🌐 https://indieweb.org/2024/Brighton
Grab an in-person ticket (limited capacity) then optionally add yourself to the list of participants: https://indieweb.org/2024/Brighton#In_person
For more information, see organizer @paulrobertlloyd.com (@paulrobertlloyd@mastodon.social)’s post: https://paulrobertlloyd.com/2024/032/a1/indiewebcamp_brighton/
Also check out @ClearLeft.com (@clearleft@mastodon.social @clearleft)’s “Patterns Day” (https://patternsday.com/) in Brighton the Thursday (2024-03-07) beforehand!
Previously: https://tantek.com/2024/022/t1/indiewebcamp-brighton-planned
This is post 9 of #100PostsOfIndieWeb. #100Posts #IndieWeb
← https://tantek.com/2024/035/t1/greshams-law-developers-users-jargon
→ 🔮
-
Similar to @paulgraham.com (@paulg@mas.to @paulg)’s 2008 observation about trolls¹, there’s a sort of Gresham's Law of developers (vs users): developers are willing to use a forum with a lot of users in it, but users aren’t willing to use a forum with a lot of developer-speak.
Whether such forums are email lists, chat (IRC, #Matrix, #Slack, #Discord), or, well, online forums (#Reddit, #HackerNews), when discussions either start or shift into technical details, jargon, or acronyms, users (in a very broad sense) tend to stop participating, and sometimes leave, never to return.
Users in this context are anyone with a desire (or a preference) not to chat or even be bothered spending time reading about technical plumbing & #jargon, and see such discussions as a distraction at best, and more like noise to be avoided.
Paraphrasing Paul Graham again: once technical details, jargon, acronyms “take hold, it tends to become the dominant culture” and discourages users from showing up, discussing user-centric topics, or even staying in said forum.
The #IndieWeb community started in 2011 as a single #indiewebcamp IRC channel (no email list²) because it was tightly coupled to IndieWebCamp events, which were both highly technical and yet focused on actually making things work on your personal site that you need³, that you will use⁴ yourself. Conversations bridged real world use-cases and technical details.
It only took us five years after the first IndieWebCamp in Portland to recognize that the community had grown beyond the events, and had a clear need for a separate place for deep discussions of developer topics.
As part of renaming the community from IndieWebCamp to IndieWeb⁵, we created the #indieweb-dev (dev) channel for such technical topics like protocols, formats, tools, coding libraries, APIs, and any other acronyms or jargon.
The community did a good job of keeping technical topics in the dev channel, and encouraging new folks in the main #indieweb channel who started technical conversations to continue them in the dev channel.
Still, it was too easy for user-centric topics to veer into technical territory. It often felt more natural to continue a thread in the channel it started rather than break to another channel. There was also a need for regular community labor to nudge developer conversations to the developer chat channel.
We had already started documenting IndieWeb related jargon⁶ on the wiki and turned it into a MediaWiki Category so we could tag individual pages as jargon and have them automatically show-up in a list. Soon after, @aaronparecki.com (@aaronpk@aaronparecki.com) added a heuristic to the friendly channel bot Loqi to recognize when people started using jargon in the main IndieWeb chat channel and nudge⁷ them to the development channel.
Having Loqi do some of the gentle nudging has helped, though it‘s still quite easy for even the experienced folks in the community to get drawn into a developer conversation on main as it were.
We’ve documented both a summary and lengthier descriptions of channel purposes⁸ which help us remind each other, as well as provide a guide to newcomers.
Both experienced community members and newcomers share much of the user-centric focus of the IndieWeb, the IndieWeb being for everyone⁹, whether developer, hobbyist, or someone who wants an independent presence on the web without bothering with technical details. Whether some of us want to code or not, we all want to use our IndieWeb sites to express ourselves on the web, to use our sites instead of depending on social media silos. That shared purpose keeps us focused.
It takes a village: eternal community vigilance is the price of staying user-centric and welcoming to newcomers.
The ideas behind this post were originally shared in the IndieWeb meta chat channel.¹⁰
This is post 8 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/033/t1/earthquake-sanfrancisco-shifted
→ 🔮
Post glossary:
development channel (indieweb-dev)
https://indieweb.org/discuss#dev
Discord
https://indieweb.org/Discord
format
https://indieweb.org/format
Hacker News (HN)
https://indieweb.org/Hacker_News
IndieWeb
https://indieweb.org/IndieWeb
IndieWebCamp
https://indieweb.org/IndieWebCamp
IRC
https://indieweb.org/IRC
jargon
https://indieweb.org/jargon
Loqi
https://indieweb.org/Loqi
main IndieWeb chat channel (on main)
https://indieweb.org/discuss#indieweb
Matrix
https://indieweb.org/Matrix
meta chat channel
https://indieweb.org/discuss#meta
MediaWiki Category
https://www.mediawiki.org/wiki/Project:Categories
plumbing
https://indieweb.org/plumbing
protocol
https://indieweb.org/protocol
Reddit
https://indieweb.org/Reddit
tools
https://indieweb.org/tools
Slack
https://indieweb.org/Slack
social media silos
https://indieweb.org/silos
¹ https://www.paulgraham.com/trolls.html (2008 essay, HN still succumbed to trolling)
² https://indieweb.org/discuss#Email
³ https://indieweb.org/make_what_you_need
⁴ https://indieweb.org/use_what_you_make
⁵ https://indieweb.org/rename_to_IndieWeb
⁶ https://indieweb.org/jargon
⁷ https://indieweb.org/Category:jargon#Loqi_Nudge
⁸ https://indieweb.org/discuss#Chat_Channels_Purposes
⁹ https://tantek.com/2024/026/t3/indieweb-for-everyone-internet-of-people
¹⁰ https://chat.indieweb.org/meta/2024-01-22#t1705883690759800
-
Similar to @paulgraham.com (@paulg@mas.to @paulg)’s observation about trolls¹, there’s a sort of Gresham's Law of developers (vs users): developers are willing to use a forum with a lot of users in it, but users aren’t willing to use a forum with a lot of developer-speak.
Whether such forums are email lists, chat (IRC, #Matrix, #Slack, #Discord), or, well, online forums (#Reddit, #HackerNews), when discussions either start or shift into technical details, jargon, or acronyms, users (in a very broad sense) tend to stop participating, and sometimes leave, never to return.
Users in this context are anyone with a desire (or a preference) not to chat or even be bothered spending time reading about technical plumbing & #jargon, and see such discussions as a distraction at best, and more like noise to be avoided.
Paraphrasing Paul Graham again: once technical details, jargon, acronyms “take hold, it tends to become the dominant culture” and discourages users from showing up, discussing user-centric topics, or even staying in said forum.
The #IndieWeb community started in 2011 as a single IRC channel #indiewebcamp (no email list²) because it was tightly coupled to IndieWebCamp events, which were both highly technical and yet focused on actually making things work on your personal site that you need³, that you will use⁴ yourself. Conversations bridged real world use-cases and technical details.
It only took us five years after the first IndieWebCamp in Portland to recognize that the community had grown beyond the events, and had a clear need for a separate place for deep discussions of developer topics.
As part of renaming the community from IndieWebCamp to IndieWeb⁵, we created the #indieweb-dev (dev) channel for such technical topics like protocols, formats, tools, coding libraries, APIs, and any other acronyms or jargon.
The community did a good job of keeping technical topics in the dev channel, and encouraging new folks in the main #indieweb channel who started technical conversations to continue them in the dev channel.
Still, it was too easy for user-centric topics to veer into technical territory. It often felt more natural to continue such threads in the channel it started rather than break to another channel. It was also a constant bit of community labor to nudge developer conversations to the developer chat channel.
We had already started documenting IndieWeb related jargon⁶ on the wiki and turned it into a MediaWiki Category so we could tag individual pages as jargon and have them automatically show-up in a list. Soon after, @aaronparecki.com (@aaronpk@aaronparecki.com) added a heuristic to the friendly channel bot Loqi to recognize when people started using jargon in the main IndieWeb chat channel and nudge⁷ them to the development channel.
Having Loqi do some of the gentle nudging has helped, though it‘s still quite easy for even the experienced folks in the community to get drawn into a developer conversation on main as it were.
We’ve documented both a summary and lengthier descriptions of channel purposes⁸ which help us remind each other, as well as provide a guide to newcomers.
Both experienced community members and newcomers share much of the user-centric focus of the IndieWeb, the IndieWeb being for everyone⁹, whether developer, hobbyist, or someone who wants an independent presence on the web without bothering with technical details. Whether some of us want to code or not, we all want to use our IndieWeb sites to express ourselves on the web, to use our sites instead of depending on social media silos. That shared purpose keeps us focused.
It takes a community to keep a community healthy and welcoming to newcomers. Eternal community vigilance is the price of being user-centric and welcoming to newcomers.
The ideas behind this post were originally shared in the IndieWeb meta chat channel.¹⁰
This is post 8 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/033/t1/earthquake-sanfrancisco-shifted
→ 🔮
Post glossary:
development channel (indieweb-dev)
https://indieweb.org/discuss#dev
format
https://indieweb.org/format
IndieWeb
https://indieweb.org/IndieWeb
IndieWebCamp
https://indieweb.org/IndieWebCamp
jargon
https://indieweb.org/jargon
Loqi
https://indieweb.org/Loqi
main IndieWeb chat channel (on main)
https://indieweb.org/discuss#indieweb
meta chat channel
https://indieweb.org/discuss#meta
MediaWiki Category
https://www.mediawiki.org/wiki/Project:Categories
plumbing
https://indieweb.org/plumbing
protocol
https://indieweb.org/protocol
tools
https://indieweb.org/tools
social media silos
https://indieweb.org/silos
¹ https://www.paulgraham.com/trolls.html
² https://indieweb.org/discuss#Email
³ https://indieweb.org/make_what_you_need
⁴ https://indieweb.org/use_what_you_make
⁵ https://indieweb.org/rename_to_IndieWeb
⁶ https://indieweb.org/jargon
⁷ https://indieweb.org/Category:jargon#Loqi_Nudge
⁸ https://indieweb.org/discuss#Chat_Channels_Purposes
⁹ https://tantek.com/2024/026/t3/indieweb-for-everyone-internet-of-people
¹⁰ https://chat.indieweb.org/meta/2024-01-22#t1705883690759800
-
I felt the #earthquake here in #SanFrancisco. A single quick sharp jolt with rapid decay, duration less than 2s, meaning it was relatively nearby and small in magnitude
I was about to say, perhaps #earthquakes are the last use-case for #Twitter because yes I reflexively checked it and did see posts about it from folks, including a few friends.
Then I checked https://indieweb.social/tags/earthquake and it has plenty of recent #fediverse posts about the earthquake, several @sfba.social.
Feels like something big has shifted.
The #federated #IndieWeb has replaced another #socialMedia silo use-case.
This is post 7 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/027/t1/indieweb-ideals-systems-swappable
→ 🔮
Post glossary:
silo
https://indieweb.org/silo
social media
https://indieweb.org/social_media
use-case
https://indieweb.org/use_case
-
For the #IndieWeb ideals of independence from intermediaries, not requiring corporate platforms or other organizational intermediaries¹, the best systems we have still depend on organizations. However they are all swappable, at will, by the individual:
1. domain names, depend on registrars, which you can switch
2. web hosts, depend on hosting providers, which you can switch
3. internet access, depends on internet service providers, which you can switch
4. web browsing, depends on browsers, which you can switch
5. personal devices, that have choice of web browser and internet access, which you can switch, upgrade, and use multiples of simultaneously
When you can migrate from one provider to another, one device to another, without disruption, without breaking your people-to-people connections, the providers and devices serve you, instead of gatekeeping you.
This freedom to swap, freedom to choose, depends on practical #interoperability across multiple implementations, multiple services. Open standards are the means to encouraging, testing, and verifying this user-feature interoperability across implementations and services.
This is post 6 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/026/t3/indieweb-for-everyone-internet-of-people
→ 🔮
Post glossary:
domain name
https://indieweb.org/personal-domain
interoperability
https://www.w3.org/wiki/Interoperable
web host
https://indieweb.org/web_host
¹ https://tantek.com/2024/026/t3/indieweb-for-everyone-internet-of-people
-
The #IndieWeb is for everyone, everyone who wants to be part of the world-wide-web of interconnected people. The social internet of people, a network of networks of people, connected peer-to-peer in human-scale groups, communities of locality and affinity.
These peer-to-peer links should not require corporate platforms or other organizational intermediaries, nor should they require depending on developer intermediaries, nor server administrator intermediaries.
This is the "indie" in IndieWeb, independence from intermediaries, not independence from people. Because the "web" in IndieWeb, is yes the Web of the World Wide Web, and it is also the Web of people.
The "indie" in IndieWeb is also the independent agency to opt-into human-scale groups, opt-into peer-to-peer connections, opt-into communities, opt-into publics. As the POSSE page says: “Figure out how you want to fit into the network”.
The "web" in IndieWeb is also an open acknowledgment and acceptance that regardless of what groups, connections, communities, and publics you opt-into, that they are all interconnected in a larger web, that even without connecting, you can accept and respect from a distance.
The IndieWeb is for everyone, everyone who wants independence from organizations, independence of agency to associate, and who embraces the web of humans that want to interconnect, to communicate, to value and respect each other, whether one degree apart or thirty.¹
This is post 5 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/023/t1/should-public-posts-flow-across-sites
→ 🔮
Post glossary:
IndieWeb
https://indieweb.org/
POSSE
https://indieweb.org/POSSE
publics
https://indieweb.org/publics
¹: https://www.theguardian.com/technology/2008/aug/03/internet.email
-
@snarfed.org posted a great overview of thoughtful (and sometimes heated) discussions across blogs and the #fediverse about how freely should “public” posts & comments on the web flow across sites:
“Moderate people, not code” (https://snarfed.org/2024-01-21_moderate-people-not-code)
If you are designing or creating any kind of publishing or social features on the web, this post is for you.
It touches on topics ranging from #contextCollapse to #federation to #moderation and everything in between.
Does your choice of publishing tool set expectations about where your content might propagate, or whether it will be indexed by search engines? Should it?
Do the limitations of your server (e.g. js;dr) imply limitations of where your posts go, or whether they can be searched or archived? Should they?
When you post something publicly, are you truly posting it for a global audience for all time, or only for one or a few more limited #publics for an ephemerality?
When you reply to a post, do you expect your reply to only be visible in the context you posted it, or do you expect it to travel alongside that post to anywhere it might propagate to?
On the #IndieWeb, especially for public posts, some of these questions have easier and more obvious answers, because the intent of nearly all public IndieWeb posts is to interact across the web with other posts and sites, typically via the #Webmention protocol. However there are still questions.
Are the expectations for a blog and blogging different from a social media site, whether a silo or an instance on a network?
Is a personal website with posts still just a blog, or does it become something new when you start posting responses from your site, or receiving (e.g. via Webmention) and displaying responses from across the web to your posts on your site? Or is it now a “social website”?
If you have a social website, what is your responsibility for keeping it, well, social? Do you moderate Webmentions by default? Do you use the Vouch extension for some automatic moderation?
Are #POSSE & #backfeed different from federation or are they the same thing from a user-perspective, with merely different names hinting at different implementations?
Do you allow anyone from any site to respond or react to your posts? Or do you treat your social website like your home, and follow what I like to call a "house party protocol", only letting in those you know, and perhaps allowing them to bring a +1 or 2?
I have many more questions. Each of these deserves thoughtful discussions, documentation of what different tools & services do today that we can try out, learn from, and use to make considered decisions when creating new things to post on and across websites.
This is post 4 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/022/t1/indiewebcamp-brighton-planned
→ 🔮
Post glossary:
backfeed
https://indieweb.org/backfeed
blog
https://indieweb.org/blog
blogging
https://indieweb.org/blogging
comments
https://indieweb.org/comments
context collapse
https://indieweb.org/context_collapse
ephemerality
https://indieweb.org/ephemerality
js;dr
https://indieweb.org/js;dr
moderation
https://indieweb.org/moderation
POSSE
https://indieweb.org/POSSE
posts
https://indieweb.org/posts
publics
https://indieweb.org/publics
reply
https://indieweb.org/reply
Vouch
https://indieweb.org/Vouch
Webmention
https://indieweb.org/Webmention
Tantek
All stadeus content and data are available under the