Notices by infinite love ⴳ (trwnh@mastodon.social)

@tchambers if you mean the google doc, i still fail to see how it's "far better ux":

- what you call "option a" would not work without pre-registration, and would be terrible ux outside of browsers
- what you call "option b" is basically what mastodon already does, as best as i can tell... although it has issues outside of mastodon [1] [2]
- what you call "option c" would not work at all, because localStorage is not shared cross-origin

[1]: https://github.com/mastodon/mastodon/issues/26995

[2]: https://github.com/mastodon/mastodon/issues/34908

@tchambers wait, if you rewrite links to https: on the home website, then why would you need a protocol handler?

also, how is this different from what mastodon currently does?

@tchambers you don’t need to rewrite anything, and the rewrite is harmful when copied. you could at best write two links to the same resource, one https: (for copying and sharing as normal) and one web+mastodon: (for loading the mastodon-specific “authorize interaction” endpoint when clicked, provided you registered it ahead-of-time at a browser and/or os level)

the problem is that you need to explain to users why there are two links, and the web+mastodon: link shouldn’t be copied/shared.

@tchambers think about what happens when they copy a rewritten link and send it to someone else.

@tchambers i read those. the problematic bit is “rewrite all links”. please consider what this entails for non-fedi-users, who vastly outnumber fedi users.

@tchambers how would js handle it? either the links are rewritten (in which case they become useless when copied), or they’re not rewritten (in which case why do you need a protocol handler?)

i have to ask this because i’m not sure: have you tried the current interaction modal in fairly recent mastodon versions? it does something similar to what you describe, but it doesn’t require custom schemes at all. i think it uses webfinger and it has some bugs, but it generally works as you might expect.

@tchambers just because someone *can* register a protocol handler, does not mean that they *will* or *have* already done so. the vast majority of the population will never register a protocol handler. your custom links will be useless to them.

@tchambers no, it’s a significant case and we should not normalize a requirement for javascript. https://indieweb.org/js;dr

even with javascript, you can’t just store an identity “forever”. this is part of what i’ve been trying to describe over and over, which is that the double-browser pattern creates this issue due to your seesion only being established within the inner browser. a proper “social web” would operate on the web without having to be virtualized.

@tchambers failure modes:
- you don’t have a protocol handler registered
- you have javascript disabled or unimplemented
- you have multiple accounts or multiple servers

you have two separate components to deal with:
1) authentication: the current website knows who you are, in some limited fashion
2) authorization: the current website triggers an action on your home website

at no point does a custom protocol scheme help with either of these. the problem is more like login or session management

@tchambers if the javascript performs a rewrite, then the resulting link is useless to anyone who hasn’t registered a protocol handler.

(also, no, we can’t and shouldn’t assume javascript as a requirement for a protocol scheme. even if we did, there are still issues with the proposed “back up” as above.)

@tchambers the rewriting is the issue, because there is a very real and very likely chance that there is no way to handle web+ap: links. they might work for you as a visitor to a mastodon-powered website, but the minute you send them to someone else you are necessarily expecting them to have a protocol handler set up, which they almost certainly will not. we want to preserve https: links in almost every single case. inside the fedi web browser, you can intercept clicks instead.

@tchambers @timbray i’m saying that for anyone who doesn’t support the new scheme, which by default is literally everyone, you will be sending them broken links when you copy or share the rewritten web+ap: instead of https: links. you’d be fragmenting “fedi” from “the web”, since your links would only work with the former and not with the latter. you’re also not accounting for multi-account or multi-server cases.

the root cause of the ux issue is the double-browser pattern, inspired by silos.

@tchambers @timbray

i'm starting to get a little incredulous at the sheer number of times people suggest new protocol schemes and handlers for what is still fundamentally an HTTP resource

if we switched to serving web+activity: or fedi: or whatever, that'd be a horrific regression in UX because clicking/copying links would *break* for most people

the problem is most "fedi" apps are building a web browser inside a web browser. that's the fundamental ux sin. all else stems from that.

@timbray @tchambers "at all"? we fetch them using HTTP GET, we communicate using HTTP POST... what makes you so strongly object to classifying them as HTTP resources?

@silverpill

Iceshrimp has hacky workarounds for interop reasons with plain JSON consumers who fail to understand the currently canonical fully conformant normal form of "as:Public" and only understand the non-canonical full URI. Hacky workarounds shouldn't be the norm. If one were to build an AS2 validator right now, the validator would produce documents that cause interop issues. That's the problem we're trying to solve. Issues like this prevent validation from being feasible.

@steve @raucao

@silverpill @steve @raucao <Note> is <as:Note> is <https://www.w3.org/ns/activitystreams#Note>, but only "Note" is consistent with compacted JSON-LD.

Fundamentally, identifiers are expressed in different ways depending on context. The prefix mechanism produces compact URIs, which are still intrinsically URIs despite their lexical form not being a valid URI. If you care about referents, you need to expand them.

"as:Public" is canonical for object properties (type:id). Disliking this fact doesn't make it untrue.

@silverpill @steve @raucao The only thing I can really suggest is dropping the use of the prefix mechanism by undefining the `as` term, then rewriting all other term definitions to not use the `as:` prefix. This might make sense since the media type nominally guarantees the meaning of certain terms, and you really shouldn't define your own custom terms in the `as:` namespace, so maybe it's okay to say that no one should ever use `as:`. Is that the resolution you'd prefer?

@silverpill @raucao no requirements are being changed here. "the identifier is foo" does not mean "the identifier MUST always be expressed using the literal sequence of characters f, o, o".

speaking of requirements, please read the first sentence of https://www.w3.org/TR/activitystreams-core/#jsonld and note the MUST.

"as:Public should be banned" is completely uncalled for.

and you currently need to special-case the full URI too! this is because it is not a real object. the real mistake is addressing Public at all.

@pfefferle @julian @bengo @csarven @raucao @oblomov

i think the context is this github issue: https://github.com/w3c/activitypub/issues/320

was put to the swicg mailing list as a cfc by evan: https://lists.w3.org/Archives/Public/public-swicg/2025Jun/0038.html

bengo requested a clear "error description" and "candidate correction": https://lists.w3.org/Archives/Public/public-swicg/2025Jun/0039.html

to clarify, no requirements are being removed: https://lists.w3.org/Archives/Public/public-swicg/2025Jun/0043.html

i agree that cfc emails should include an "error description" and "candidate correction". perhaps https://github.com/w3c/activitypub/issues/320#issuecomment-2971191447 suffices?

@silverpill @mkljczk @reiver there still isn't any support for granting quote authorization stamps, so the only valid quotes are the ones that meet the default policy:

- quoted post is by you
- quoted post mentions you

and then in 4.5:

- quote post has a valid authorization stamp by the author of the quoted post (not possible yet since authorization stamps aren't issued yet)