đź‘‹ Everyone: see what you think:
-
So for the Protocol hander discussion, I was particularly influenced by @timbray in articles such as this one: https://www.tbray.org/ongoing/When/202x/2025/04/16/Decentralized-Schemes
Curious both if TIm thinks I took the right lessons from his writing....
And very much interested in @evan and his thoughts on the idea as describe in the post. And @jenniferplusplus
As well as what browser tech folks like @jon and @jensimmons would think of my rendition of the state of play and how to move forward on web protocol handler support.
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.
-
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.
@tchambers @timbray also, schemes do nothing for migration woes because the problem there is DNS failure -- the scheme doesn't have any bearing on it at all
-
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.
@trwnh @tchambers I really really don't think Fedi constructs are HTTP resources at all.
-
@trwnh @tchambers I really really don't think Fedi constructs are HTTP resources at all.
@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?
-
@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?
@trwnh @tchambers I suggest reading my blog post that Chambers linked to. The reliance on HTTP URLs is causing bad user experiences.
-
@trwnh @tchambers I suggest reading my blog post that Chambers linked to. The reliance on HTTP URLs is causing bad user experiences.
@timbray @tchambers i read it and i was responding to it. i'm saying that a new scheme wouldn't address the pains you raised; it would worsen the UX in different ways for the vast majority of people, and it would do nothing for migration. other comments allude to this.
the cause of the bad experiences isn't HTTP, it's the attempt to build web browsers inside of web browsers, forcing everything inside the bounding box like silos. perhaps not surprising, given that a lot of fedi is cloning silos.
-
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.
Wouldn’t this plus a JavaScript backup greatly reduce the remote engagement current UX issue?
I’m not sure the nature of your objections here are is: I think you may be saying if implemented that this new UX with basically only one prompt and then everything works, isn’t as much an improvement as I’m selling it to be?
-
Wouldn’t this plus a JavaScript backup greatly reduce the remote engagement current UX issue?
I’m not sure the nature of your objections here are is: I think you may be saying if implemented that this new UX with basically only one prompt and then everything works, isn’t as much an improvement as I’m selling it to be?
@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 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 put another way: the “copy-paste dance” as you call it is directly analogous to loading any link in an existing web browser, except fedi web browsers only work with an extremely limited subset of the web and don’t register themselves as handlers for https: links. the ideal ux is that your web browser should be able to act as a social web browser, not that you should fork the web and fedi.
-
@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 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 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.
@trwnh I get that: but couldn’t we reasonably assume that every browser will have JavaScript support? Why doesn’t that back up alleviate that issue?
-
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.
@trwnh @tchambers @timbray So, for a decent while I had a misunderstanding about "web+something" schema handlers: I thought part of their point was to use the registered handler if the person has one set up, and fall back to opening them in the browser if they don't.
I guess that isn't how they work in reality. But wouldn't it be useful if they did?
-
@trwnh @tchambers @timbray So, for a decent while I had a misunderstanding about "web+something" schema handlers: I thought part of their point was to use the registered handler if the person has one set up, and fall back to opening them in the browser if they don't.
I guess that isn't how they work in reality. But wouldn't it be useful if they did?
@julian @tchambers @timbray indeed, web+ is just a conventional prefix, and unregistered schemes will not be handled at all. there is no fallback.
text someone a web+ap: link and their messaging client won’t linkify it. even if it did, clicking the link would do nothing for most people. you need to go out of your way to register a protocol handler.
web+ schemes also don’t need to follow the format of https: either! web+soup:chicken-noodle is valid. (what would the fallback for that even be?)
-
@trwnh I get that: but couldn’t we reasonably assume that every browser will have JavaScript support? Why doesn’t that back up alleviate that issue?
@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 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.)
@trwnh Why? It would work with all of them too, as long as they had javascrpt enabled and ansered only one prompt. And then set forever for that server.
And the JavaScript requirement isn't part of the protocol scheme. it's a back up for those not yet on compliant browers.
-
@trwnh Why? It would work with all of them too, as long as they had javascrpt enabled and ansered only one prompt. And then set forever for that server.
And the JavaScript requirement isn't part of the protocol scheme. it's a back up for those not yet on compliant browers.
@tchambers failure modes:
- you don’t have a protocol handler registered
- you have javascript disabled or unimplemented
- you have multiple accounts or multiple serversyou 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 websiteat no point does a custom protocol scheme help with either of these. the problem is more like login or session management
-
@tchambers failure modes:
- you don’t have a protocol handler registered
- you have javascript disabled or unimplemented
- you have multiple accounts or multiple serversyou 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 websiteat no point does a custom protocol scheme help with either of these. the problem is more like login or session management
@trwnh Issue one has about 80 percent market share in deskop and for most fediverse offerings, about 50 percent market share including mobile. So we can make all those lives better today. With a Javascript fall back for rest.
Two feels like a very small edge case. Three could be code for in javascript, right?
-
@trwnh Issue one has about 80 percent market share in deskop and for most fediverse offerings, about 50 percent market share including mobile. So we can make all those lives better today. With a Javascript fall back for rest.
Two feels like a very small edge case. Three could be code for in javascript, right?
@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 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 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.
