@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.

@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.

@trwnh @timbray

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 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.

@trwnh @timbray Why wouldn’t my JavaScript backup for non-compliant browesrs address that consern? I might be missing something….

@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?

@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?)

@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.

@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

@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 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 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.

@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.