#dev 2026-03-05

2026-03-05 UTC
luca, ax562 and grufwub joined the channel
#
[tantek]1 FYI folks who want to participate in the W3C Social Web WG, this Friday 9am Pacific is the first meeting of the newly restarted WG: https://www.w3.org/events/meetings/ada33800-0886-424a-bb73-9bf331034cee/ — if you're W3C member you can join the WG and attend the meeting (or at least join even if you can't make the meeting), otherwise you can contact the chair and apply to be an invited expert. cc: [aaronpk] [KevinMarks] [manton] [snarfed]
#
[tantek]1 if anyone has any questions about the WG or participating at W3C in general feel free to ask!
#
[tantek]1 maintenance of several IndieWeb specs is part of the charter: https://www.w3.org/2026/01/social-web-wg-charter.html#deliverables
TwinAdam joined the channel
#
aaronpk Oh jeez I might be able to join the call a bit late
jjuran and Skaterfish joined the channel
#
ulhar4409 hmm, thinking of working on comments markup tonight
#
ulhar4409 i have a slightly cursed idea where commenters' icons are used for <li> list-style
lars_the_bear joined the channel
#
capjamesg [tantek] I should be able to make it!
#
capjamesg Ah I can't join as I'm not invited. Never mind! I just wanted to sit in and listen but it's maybe not the best room for that.
[artlung], kishy and Skaterfish joined the channel
#
capjamesg Does anyone know if service workers work without JavaScript enabled?
#
ulhar4409 hmm, i think *enabling them* is usually done from the website's js, but beyond that i don't know
#
ulhar4409 the service worker itself is also javascript, so it does seem ambiguous
#
capjamesg Yeah. I wonder what happens if someone has the SW enabled then disables JavaScript.
blacklight joined the channel
#
ulhar4409 i guess there's only one way to find out :P
#
ulhar4409 well, eventually two, after the one is definitely taken
blacklight and CRISPR joined the channel
#
capjamesg [edit] spamt0n[d] You may appreciate https://indieweb.org/self_hosting
blacklight, Skaterfish, CRISPR, kishy and kishy-lib joined the channel
#
capjamesg The Sovereign Tech Agency is running a survey to learn about developers' experiences working with or alongside standards: https://www.sovereign.tech/news/open-standards
#
capjamesg [edit] The Sovereign Tech Agency is running a survey to learn about developers' experiences working with or alongside standards: https://www.sovereign.tech/news/open-standards
lars_the_bear and TwinAdam joined the channel
#
[KevinMarks] https://bsky.app/profile/43081j.com/post/3mgaongrbi22y
#
[KevinMarks] https://43081j.com/npm-xkcd/?q=indiekit
TwinAdam, WinnerWi- and kishy joined the channel
#
[artlung] funny AND true visualization? whoa.
CRISPR, TwinAdam, WinnerWi- and [manton] joined the channel
#
[manton] [tantek] For whatever it’s worth, I submitted myself as an invited expert about a month ago. Haven’t heard anything.
#
[tantek]1 [manton] worth reaching out to Darius (email?) directly and asking if there's an ETA on approving invited expert applications
#
[manton] [tantek] Okay, thanks. I can also lurk on the calls to at least be in the loop a little. I’d like to help with the IndieWeb specs and LOLA. Don’t think my feedback on ActivityPub itself will be very useful. (“Let’s get rid of JSON-LD…” 🤪)
kchar and ax562 joined the channel
#
[tantek]1 lol
lars_the_bear, blacklight, kishy, jjuran and gRegor joined the channel
#
trwnh i believe part of the agenda of the first WG meeting is to deal with exactly that question on invited experts, "who should be in the room" (although future meetings are intended to be joint WG/CG iirc per darius?)
#
trwnh https://github.com/w3c/socialwg/issues/2
#
trwnh also not exactly related but tangential offhand comment: the alternative to jsonld is central/official registries of allowed terms. arguably getting rid of it won't matter practically though if everyone already ignores it (and continues to have problems with not understanding each other, curiously...)
#
[tantek]1 trwnh, that perspective of "alternative to" is only valid if JSON-LD extensibility was a thing that actually worked in practice, which it has not.
#
[tantek]1 and yes, "central/official registries of allowed terms" is literally what most specs are, and in my experience you get MUCH better interop by iterating on specs instead of letting thousands of extensibility flowers bloom
#
[tantek]1 100% on "if everyone already ignores it (and continues to have problems with not understanding each other, curiously...)" which is precisely why it's worth getting rid of. why pay the cost of JSON-LD if products, services, users are not reaping any benefits?
#
trwnh i mean it would work if people actually used it, which they don't -- they just assume you mean the same thing as them even when you don't. so it's a coordination problem, not a jsonld problem. you still have to know what things mean and ignoring their definition is not a viable strategy
#
trwnh we can't really say it has a "cost" if it's being ignored, can we? most of the complaints i see about jsonld in the fediverse boil down to "mastodon is being too strict in validation", which is a mastodon problem
#
trwnh or another mastodon problem, which is assuming everything else is mastodon or shares the same understanding as mastodon (which they Do Not)
#
trwnh i just think if we "got rid of it" it wouldn't really amount to anything because we basically already de facto have. but we would then need the w3c to maintain which terms are allowed and what they mean
#
trwnh outside of the ones already defined, that is -- which people already use incorrectly against their official definitions
#
trwnh so if the real problem is "people are ignoring the definitions", then we just end up in a situation where people use the exact same terms but with different meanings.
#
trwnh ironically jsonld could help fix that, but only if you inject context after-the-fact to describe what people *actually* meant instead of what they *said* they meant. which is again ironically what jsonld works best at -- an elective thing you can do on your own end to be more precise and explicit with multiple disparate data sources
#
trwnh the indieweb equivalent is if people started using h-entry in ways that don't match whatever is described on indieweb.org or microformats.org
#
trwnh and then suddenly you would have to figure out "are they using h-entry according to the microformats.org profile, or some other profile?"
#
trwnh i can understand seeing it as a tactical difference, if you have a community growing some small thing and everyone in the community agrees on it or reaches some consensus within that subnetwork. but if you don't have that community or that consensus then you don't really have a standard, you just have conventions
tmoose joined the channel
#
trwnh standards require some kind of governance or management to be able to authoritatively say "this is the correct answer". that's what's really missing. i think unfortunately what got passed through the first social WG didn't really define that or constrain it enough.
#
trwnh so in practice it ends up being one protocol per software release -- "mastodon 4.4" is not the same as "mastodon 4.5" nor the same as "akkoma 3.10.2" nor the same as "misskey 2025.12.1". they just happen to incidentally overlap in some places. and other softwares like lemmy will overlap less, and softwares like funkwhale may not overlap at all in any practical way.
#
trwnh this is all so far removed from "jsonld" that it actually makes me laugh sometimes when people complain about jsonld because it is so much more else than that. you have like 100 or more softwares that fundamentally don't agree. that's the real problem xD
#
[tantek]1 trwnh, I find your "it would work if" and "it is so much else than that" arguments unconvincing because that's the same refrain that RDF/SemWeb folks have said for years and been repeatedly proven wrong by failure after failure.
#
[tantek]1 At some you can't blame devs, and it's the underlying technology that's poorly designed
#
[tantek]1 It's basically the "you're not holding the phone properly" type of argument
#
[tantek]1 Bad technology blames the users (in this case devs) for its failures
#
trwnh i don't think it's that kind of argument; it's moreso a failure to engage with the problem at all (just "assume the problem doesn't exist")
#
[tantek]1 The "one protocol per release" problem has nothing to do with JSON-LD or failure to "adhere" to it. It has everything to do with the lack of a maintained test suite
#
[tantek]1 Not sure why LD/RDF/SemWeb still inspires such "faith based", "trust me", "if you only did it the RIGHT way" type arguments
#
[tantek]1 People show ship products know that's nonsense
#
[tantek] People who* ship
#
trwnh it wasn't intended as that type of argument fwiw
#
[tantek] But that's exactly the kind of argument it is with phrases like "it would work if"
#
trwnh the bit i was responding to there is specifically "if JSON-LD extensibility was a thing that actually worked in practice, which it has not"
#
trwnh the reason it hasn't worked is because it was never used
#
[tantek] Right, in practice it has not. Never did. This was something I warned the first WG about with depending on JSON-LD based on the faith-based statements of LD advocates
#
[tantek] "It was never used" right, so claiming it would work is an appeal to faith, not running code
#
[tantek] You've proven my point
#
trwnh what actually ended up happening was mastodon assuming its own definitions held for the rest of the network.
#
[tantek] I’m saying pre-AP it was also never demonstrated as working
#
[tantek] So it's unsurprising it didn't with AP/AS2
#
[tantek] The LD advocates wore down the AS/AP editors into including it, without any evidence LD had ever worked in any context previously. It was 100% "trust us" which is nonsense in technology
#
aaronpk It really was a "wearing down", it was exhausting
NegateThis joined the channel
#
trwnh i wasn't there for any of that so i can't speak directly to it, but it seems to me "we never tried this" is not equal to "it didn't work". is everything you never tried already a failure? i guess by some definitions maybe, because if you never try then you can never succeed.
#
trwnh similarly if you just assume the network is mastodon then it all works out fine... except there's a lot of stuff getting dropped, but you'll never see it
#
trwnh note i am not saying "hey everyone, let's try jsonld!" -- it is kind of too late for that i think, because there is too much divergence already.
#
trwnh so just ignore the @context field really. there we go, jsonld removed and none of the coordination problem was solved.
Skaterfish joined the channel
#
trwnh i guess an analogy would be, if everyone was speaking the same language then translators wouldn't be necessary. but not everyone is speaking the same language. confusingly, they are still using the same words, so the translator can't work without knowing who said it. does this make translators useless?
#
[tantek] trwnh, again, false lines of reasoning "is everything you never tried already a failure?" is inapplicable because JSON-LD long predated AP/AS and plenty of OTHER people have tried it and never got it to work in terms any form of extensibility interop etc.
#
[tantek] once again, that history of ZERO things working didn't stop from the advocates from overwhelming the AP/AS editors and frankly bullying into including it
#
[tantek] we had to pushback on it JSON-LD being *required* and only eked that out after a bunch of very painful arguments against the LD advocates
#
[tantek] the only reason JSON-LD is optional in AP/AS2 is because a bunch of us stood up and said no, the JSON-LD emperor has no clothes, so how about we make it optional so implementers/devs who are used to "just JSON" can actually have a chance of making something work (like they have with everything else "just JSON")
#
[tantek] and then because a bunch of us pushed back against LD and dared to openly question it, others who have written up a "history" of sorts (yes, scare quotes because it's mostly bs) blamed those of us who pushed back against LD for their own shortcomings/failures/burnout — instead of blaming the JSON-LD advocates/bullies
NegateThis left the channel
#
[tantek] and again, if "assume the network is mastodon then it all works out fine... except there's a lot of stuff getting dropped, but you'll never see it" is the problem you want to solve, that would have been better solved with actual spec-specific comprehensive test suites that were maintained
#
[tantek] stop asking for JSON-LD religion/faith. start demanding comprehensive test suites that are maintained, if broad interop and stuff "just working" for users and devs is your goal
NegateThis joined the channel
#
trwnh "asking for jsonld faith" is a strawman but at this point the test suite is basically mastodon. i'm really not sure at all how jsonld could ever be "required" because you already end up assuming the context from the application/activity+json content type (which is where the semantics live typically). unfortunately there is no processing model included. and unfortunately still, mastodon is the one gatekeeping based on the @context (which it shouldn't!)
#
trwnh as you point out, it's NOT required, and anyone wanting to do LD processing MUST assume it from the media type
#
trwnh to reiterate, this is a coordination problem and specifically a mastodon problem with mastodon assuming it is the spec.
#
trwnh mf2 doesn't have this problem in practice because everyone already defers to microformats.org to define what mf2 properties mean. but people don't want to defer to mastodon to define what AS2 properties mean.
#
[tantek] Perhaps I'm an optimist then? I don't think we should give up on the spec being the spec. I believe that if a good faith AP/AS2 test suite effort were developed in the new Social Web WG, that Mastodon would both contribute to it, and be open to making changes (fixes) as a result of the test suite exposing bugs (according to the spec).
#
trwnh which again, they shouldn't -- mastodon shouldn't get to redefine AS2.
#
[tantek] mf2 is not without problems to be clear, plenty of open issues. it simply has far less lofty goals and claims. fewer places for incompatibilities to develop (but not zero).
#
trwnh I would love to be optimistic but I also can't say that a "W3C vs WHATWG" situation will never develop.
#
[tantek] people should defer to the AS2 spec to define what AS2 properties etc. mean. presumably that's why we participate in the Social Web WG
#
trwnh that's exactly it, though -- are the properties AS2 terms or are they actually Mastodon terms that coincidentally have the same shorthand?
#
[tantek] re: W3C vs WHATWG — I believe there is plenty of flexibility in how the Social Web WG is run, so if the chair / editors want to run it more like WHATWG, I doubt anyone at W3C will oppose that 🤷
#
trwnh officially, they are AS2 terms, but in practice Mastodon defines what they mean at https://docs.joinmastodon.org/spec/activitypub
#
[tantek] you don't have to convince "W3C" of this. you have to convince the chair (Darius) and current AP/AS2 editor (Evan) of this.
#
[tantek] you can ask them to be as "pragmatic" as you wish to advocate for. I suspect plenty of us in the WG would support you in that
NegateThis left the channel
#
trwnh by "w3c vs whatwg" i don't mean the way the WG is run, i mean the tendency of fedi implementers to ignore the WG/CG outputs for years -- and to not participate, either. there's probably more participation in mastodon's devrel chats than there is in the social CG or WG, and even more in dozens of backchannels. i'm not convinced that fedi is the one and only interpretation of "ActivityPub" that matters (nor am i convinced it's solely one interpretation). but it is
#
trwnh a question of governance and constituency. the mastodon project governs the mastodon protocol, and its constituency is the mastodon software and anyone else wanting to talk to it. people want to talk to mastodon but don't want to be governed by mastodon. but they won't participate in the CG/WG either.
#
trwnh me personally? i am not sure what i wish to advocate for, although as you say a test suite probably can't hurt, unless it's testing for the wrong things. so having a processing model for activities is probably needed, but if people just ignore activities entirely then they'll ignore that too.
NegateThis, redshuffle and WinnerWi- joined the channel; NegateThis left the channel
#
[KevinMarks] We did in the AS community let a lot of properties accrete without interop tests, but Mastodon arbitrarily assuming they could use "summary" as "content-warning" caused a lot of interop problems.
#
trwnh mastodon also arbitrarily assumes that attachment and tag are ordered, that to is an array, that discoverable is a boolean for appearing in mastodon discovery features but NOT the public timelines, which instead use their weird to/cc heuristic, etc etc etc etc etc etc... at some point i sat down and mapped out their divergences and augmentations here https://gist.github.com/trwnh/d2f6fb1c87465baab8231427013a36a8 although even this is incomplete if you want to
#
trwnh truly disambiguate term ids. if i were attempting to describe mastodon's semantics i would probably mint new identifiers that maybe subclass or subproperty from the AS2 ones. the problem is that i don't know when a given peer is using mastodon semantics (or if they're actually using a secret third thing)
#
trwnh it would be cool to have some way of establishing a profile that people can say they are or are not following. i really don't want to sniff nodeinfo for all the reasons i would prefer not to sniff user agents in http
#
trwnh at least when an http user agent or html processor doesn't understand something, it's not like there are automated side effects attached to that (generally). also the breakage tends to be more visible than silent, since http will give you actual error responses and unknown html elements will get parsed as div by default thus still visible
Kupietz, ax562 and Skaterfish joined the channel
#
[tantek] indeed, good reason HTML formats tend to be more forgiving (of experiments, etc.)
#
ulhar4409 (TIL about divs being the "fallback element" for unknown elements)
rrix joined the channel
#
[tantek] spans but yeah
#
[tantek] unknown elements don't create display blocks
#
ulhar4409 oh fair