Show Navigation
Notices tagged with indieweb
-
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
-
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
-
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
-
Twenty years and two days ago, @KevinMarks.com (@KevinMarks@xoxo.zone @KevinMarks) and I introduced #microformats in a conference presentation.
I wrote a long retrospective last year: https://tantek.com/2023/047/t1/nineteen-years-microformats
Since that post nearly a year ago, here are the top three updates & interesting developments in microformats:
1. Growing rel=me adoption for distributed verification (✅ in Mastodon etc.)
* Wikipedia: https://tantek.com/2023/139/t1/wikipedia-supports-indieweb-rel-me
* Threads: https://tantek.com/2023/234/t1/threads-supports-indieweb-rel-me
* omg.lol profile links by default: https://home.omg.lol/info/profile-items
2. A proposal to merge h-review into h-entry, since reviews are in practice always entries with a bit more information:
* https://github.com/microformats/h-entry/issues/32
3. #metaformats adoptions, implementations, and iteration
* There was growing practical interest in metaformats, so I updated the spec accordingly
* A half dozen implementations shipped: https://indieweb.org/metaformats#IndieWeb_Examples
* Active discussion for evolving metaformats to support more real world use-cases: https://github.com/microformats/metaformats/issues
Hard to believe it’s been 20 years of iterating and evolving microformats, to #microformats2, growing adoption as #IndieWeb building blocks, distributed verification (those green checkmarks) in #Mastodon and across the #fediverse, and implementing metaformats parsing to standardize parsing various meta tags for link previews into equivalent microformats2.
From last year’s activity, it’s clear there’s more use-cases, implementer interest, and community activity than ever. Looking forward to seeing what we can build in 2024.
Post Glossary
h-entry
https://microformats.org/wiki/h-entry
h-review
https://microformats.org/wiki/h-review
link-preview
https://indieweb.org/link-preview
metaformats
https://microformats.org/wiki/metaformats
microformats
https://microformats.org/wiki/
microformats2
https://microformats.org/wiki/microformats2
rel-me
https://microformats.org/wiki/rel-me
-
Twenty years and two days ago, @KevinMarks.com (@KevinMarks@xoxo.zone @KevinMarks) and I introduced #microformats in a conference presentation.
I wrote a long retrospective last year: https://tantek.com/2023/047/t1/nineteen-years-microformats
Since that update nearly a year ago, here are the top three interesting developments in microformats:
1. Growing rel=me adoption for distributed verification:
* Wikipedia: https://tantek.com/2023/139/t1/wikipedia-supports-indieweb-rel-me
* Threads: https://tantek.com/2023/234/t1/threads-supports-indieweb-rel-me
* omg.lol profile links by default: https://home.omg.lol/info/profile-items
2. A proposal to merge h-review into h-entry, since reviews are in practice always entries with a bit more information:
* https://github.com/microformats/h-entry/issues/32
3. #metaformats adoptions, implementations, and iteration
* There was growing practical interest in metaformats, so I updated the spec accordingly
* A half dozen implementations shipped: https://indieweb.org/metaformats#IndieWeb_Examples
* Active discussion for evolving metaformats to support more real world use-cases: https://github.com/microformats/metaformats/issues
Hard to believe it’s been 20 years of iterating and evolving microformats, to #microformats2, growing adoption as #IndieWeb building blocks, distributed verification (those green checkmarks) in #Mastodon and across the #fediverse, and implementing metaformats parsing to standardize parsing various meta tags for link previews into equivalent microformats2.
From last year’s activity, it’s clear there’s more use-cases, implementer interest, and community activity than ever. Looking forward to seeing what we can build in 2024.
Post Glossary
h-entry
https://microformats.org/wiki/h-entry
h-review
https://microformats.org/wiki/h-review
link-preview
https://indieweb.org/link-preview
metaformats
https://microformats.org/wiki/metaformats
microformats
https://microformats.org/wiki/
microformats2
https://microformats.org/wiki/microformats2
rel-me
https://microformats.org/wiki/rel-me
-
#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
-
The first IndieWebCamp of the year has been planned!
🎪 IndieWebCamp Brighton
🗓 2024-03-09…10
🏢 The Skiff, Brighton, England
🎟 Tickets available 2024-02-01!
Event: https://events.indieweb.org/2024/03/indiewebcamp-brighton-2024-xRTP2hAZOvZd
Wiki: https://indieweb.org/2024/Brighton
Questions about #IndieWebCamp? Ask in #IndieWeb chat!
💬 https://chat.indieweb.org/
This is post 3 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/003/t1/2023-indieweb-gift-calendar-numbers
→ 🔮
-
31 days of #IndieWeb gifts: the _2023 IndieWeb Gift Calendar_ (https://indieweb.org/2023-12-indieweb-gift-calendar) wrapped up a full month of IndieWeb-related creations & updates from the community (and sometimes beyond) to everyone who wants to improve their #IndieWeb experience.
From plugins & libraries, to tools & services, to events & meetups, to web components & wiki pages, and blog posts & newsletters, there was something for everyone.
Some numbers:
🎁 67 total gifts
📄 32 new IndieWeb wiki pages
📜 7 posts on improving blogs, IndieWeb specs, and event summaries
💻 6 Homebrew Website Club online meetups
📫 5 This Week In The IndieWeb newsletters
🧱 4 library updates: new web components, #microformats2 parser update
🌉 3 Bridgy Fed updates & improvements
🧩 2 plugin updates: #Elgg IndieWeb & #WordPress #IndieAuth
🎪 1 #IndieWebCamp San Diego (2 days!)
📚 1 indiebookclub new year in review overview feature
📽 1 IndieWeb movie viewings aggregator
🧶 1 #Threads federating out #ActivityPub (followable by #BridgyFed)
Gift were shared by:
👥 20 individuals
🏢 1 company
I compiled these numbers by hand. Let me know if you see any errors. There are many more potential stats like:
* average (mean and median) number of gifts per contributor
* how many edits to the Gift Calendar wiki page
* how many different editors of the wiki page
* average (mean and median) number of edits per editor
I’ll leave those as exercises for others if they wish!
This is post 2 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/001/t1/restarting-100days-indieweb-gift-calendar
→ 🔮
-
Time to begin again: restarting my #100Days of #IndieWeb project for 2024, as a #100Posts of IndieWeb project, and congrats to the IndieWeb community on a fully completed 2023 IndieWeb Gift Calendar!
Last year I completed 48 out of a planned 100 posts in my #100DaysOfIndieWeb project, for nearly 48 days (some days had multiple posts). Instead of resetting my goals accordingly, say down to 50, I’m going for 100 again, however, this time for 100 posts rather than 100 days, having learned that some days I find the time for multiple posts, and other days none at all.
Looking back to the start of last year’s 100 Days project, it’s been one year since I encouraged everyone to own their own notes¹. Since then many have started, restarted, or expanded their personal sites to do so. Some have switched from a #Twitter account to a #Mastodon (or other #fediverse) account as a stopgap for short-form status posts. A step in the right direction, yet also an opportunity to take the leap this year to fully own their identity and posts on the web.
In 2023 Twitter also broke all existing API clients (including my website). I did not feel it was worth my time to re-apply for an API key and rebuild/retest any necessary code for my semi-automatic #POSSE publishing, not knowing when they might break things again (since there was no rational reason for them to have broken things in the first place).
I manually POSSEd a few posts after that, yet from the lack of interactions, either Twitter’s feed algorithm² isn’t showing my posts, or people have largely left or stopped using Twitter.
Either way, when your friends stop seeing your posts on a silo, there’s no need to spend any time POSSEing to it.
On the positive side, the IndieWeb community really came together in 2023, shining brightly even through the darker days of December.
We, the IndieWeb community (and some beyond!) provided a gift (or often multiple) to the rest of community for every single day of December 2023³, the first time we successfully filled out the whole month since the 2018 IndieWeb Challenge⁴, and only the second time ever in the seven years of the IndieWeb Challenge-turned-Gift-Calendar.
By going through the various gifts (more than 2 per day on average!), there are many interesting numbers and patterns we could surface. That deserves its own post however, as does a summary of the 48 posts⁵ of my 2023 100 Days of IndieWeb attempt, so I’ll end this post here.
Happy New Year to all, with an especially well deserved congratulations to the IndieWeb community and everyone who contributed to the 2023 Gift Calendar. Well done!
Let’s see what else we can create & share on our personal sites in 2024 and continue setting a higher bar for the independent web by showing instead of telling. #ShowDontTell
This is post 1 of #100PostsOfIndieWeb. #100Posts
← ✨
→ 🔮
Post glossary:
API
https://indieweb.org/API
POSSE
https://indieweb.org/POSSE
silo
https://indieweb.org/silo
¹ https://tantek.com/2023/001/t1/own-your-notes
² https://indieweb.org/algorithmic_feed
³ https://indieweb.org/2023-12-indieweb-gift-calendar
⁴ https://indieweb.org/2018-12-indieweb-challenge
⁵ https://tantek.com/2023/365/t2/no-large-language-model-llm-used
-
No large language models (LLM) were used in the production of this post.
Inspired by a subtle but clear sign-of-the-times one-line disclaimer at the end of RFC9518’s Acknowledgments (https://www.rfc-editor.org/rfc/rfc9518.html#appendix-A-4)
“No large language models were used in the production of this document.”
I have added a similar disclaimer to the footer of my homepage:
“No large language models were used in the production of this site.”
2023 was certainly a year that LLMs took off and stole the hypecycle from #metaverse and #blockchain before that.
Yet unlike those previous two, #LLMs are already having real impacts on the way people create (from emails to art), communicate (LLM chat apps), and work (2023 Writer’s Strike), fueling growing concerns about the authenticity of content, especially content from human authors.
I expect we will see more such disclaimers in the future.
For now, if you blog on your own site with words written by you not #ChatGPT or a similar tool, I encourage you to add a similar disclaimer, and then add your site as an example to the #IndieWeb wiki:
* https://indieweb.org/LLM#IndieWeb_Examples
#largeLanguageModel #LLM #generativeAI #AI
There is the related problem of, when you discover what seems to be an independent site written by a human, how do you know that human actually exists?
For now I’ll mention that XFN rel=met links, published (e.g. metrolls / met-rolls), aggregated, indexed, and queried, can solve that problem. This will be similar to how XFN rel=me links solved #distributed verification on the web (see https://tantek.com/2023/234/t1/threads-supports-indieweb-rel-me and posts it links to).
This is day 48 of #100DaysOfIndieWeb. #100Days
← Day 47: https://tantek.com/2023/365/t1/capture-first-edit-publish-later
→ 🔮
Post glossary:
blockchain
https://indieweb.org/blockchain
large language model / LLM
https://indieweb.org/large_language_model
metaverse
https://indieweb.org/metaverse
rel=me
https://indieweb.org/rel-me
rel=met
http://gmpg.org/xfn/11#met
XFN
https://gmpg.org/xfn/
-
Writing about writing: capture first, edit & publish later.
Braindump timely thoughts & experiences into as many draft notes as it takes, while ideas & memories are fresh.
Collecting higher fidelity memories seems more important than editing past writings or finishing/polishing a post for publishing, which can be done at a later time.
Sometimes the passage of time helps provide insights and broader understandings that can help with writing more effective posts, from better summaries to narratives that help sense-making.
Bits of even this minor post sat for weeks, and only today did I add a summary and related thoughts.
Similarly, it makes sense to edit and publish small notes on a subject, without feeling compelled to turn them into a larger blog post, or a longer list of points.
This is a key advantage to publishing on your own #indieweb site, you decide on the granularity of your posts, small, medium or large, instead of being constrained, burdened, or pressured by any particular #socialMedia user interface, character count limitation, or audience expectation.
Like Twitter before it, even the default #Mastodon user interface has limitations, and the #fediverse itself as a whole has audience/cultural expectations (certainly quite a few articles have been written about that).
On your own site you decide if you want to publish a post to make one point, or mention a related point or two, or collect things into a list or longer article, or eventually all of the above.
On your own site you feel more free to prioritize and share what is on your mind, instead of feeling compelled to first respond to whatever topics are trending, or to whatever you happen to read in your algorithmic feed.
#writingAboutWriting
This is day 47 of #100DaysOfIndieWeb. #100Days
← Day 46: https://tantek.com/2023/289/t1/bridgyfed-webmention-like-fediverse
→ Day 48: https://tantek.com/2023/365/t2/no-large-language-model-llm-used
Related:
* “More Thoughtful Reading & Writing on the Web” (https://tantek.com/2023/277/b1/thoughtful-reading-writing-web)
Post glossary:
algorithmic feed
https://indieweb.org/algorithmic_feed
article
https://indieweb.org/article
note
https://indieweb.org/note
post
https://indieweb.org/post
sense-making
https://en.wikipedia.org/wiki/Sensemaking_(information_science)
social media
https://indieweb.org/social_media