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

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

@trwnh Reread my article - and the bigger article it links to that explains how it’s far better Ux.

@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