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

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

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

@trwnh It's as viewable as any remote fediverse link is now. You only rewrite things to eenable social engagment.

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

@trwnh Actually:

When you use Option A or B that I described in my article to engage with remote content (rewritten to your home server) and then copy/share that rewritten link:

That link points to the version of the post as seen from your own server.

My home server has successfully fetched and cached the public content. So:

For non-Fedi users (not logged in, no account):

The link will work as for all public posts. And for non-fedi users that is all they see anyway.