đź‘‹ Everyone: see what you think:
-
@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.
-
@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.
@trwnh Think we are going in a bit of circles here. Every time you say that custom links are dead to users who don't have compatable browsers or choose not to agree to the prompt to do the protocol handler... and I agree, but say that Javascrpt backup handles that use case, I'm not sure where we disagree after that?
-
@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 if you message me web+soup:chicken-noodle right now, my messaging client will have no idea what to do with that link, and neither will i.
you have to consider this UX from the perspective of someone who has never used fedi, not just the set of people who already have fedi accounts.
-
@trwnh Think we are going in a bit of circles here. Every time you say that custom links are dead to users who don't have compatable browsers or choose not to agree to the prompt to do the protocol handler... and I agree, but say that Javascrpt backup handles that use case, I'm not sure where we disagree after that?
@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 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.
@trwnh Read my article and the links from it for details.
-
@trwnh Read my article and the links from it for details.
@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 i read those. the problematic bit is “rewrite all links”. please consider what this entails for non-fedi-users, who vastly outnumber fedi users.
@trwnh So that answered your question as to how I suggest to do this, and why would this exclude anyone on the web?
They would see all pubic content fine. And as they aren't fediverse uses, they couldn't socially engage, follow or boost social content in either case, as they aren't fedi users.
-
@trwnh So that answered your question as to how I suggest to do this, and why would this exclude anyone on the web?
They would see all pubic content fine. And as they aren't fediverse uses, they couldn't socially engage, follow or boost social content in either case, as they aren't fedi users.
@tchambers think about what happens when they copy a rewritten link and send it to someone else.
-
@tchambers think about what happens when they copy a rewritten link and send it to someone else.
@trwnh It's as viewable as any remote fediverse link is now. You only rewrite things to eenable social engagment.
