Too soo-…wait what fucking year is it

rimu@piefed.social interesting idea… I know Evan has some thoughts about this as part of his ActivityPub HTML discovery project

ActivityPub Discovery

(swicg.github.io)

I am not sure why they did not settle on protocol handlers but I’ve tagged him for comment

evan@activitypub.space evan@cosocial.ca

The concept sounds excellent, although there is fairly limited mobile support.

Since NodeBB is an installable PWA it would be definitely nice to have it supported there as well.

@julian I write about this here: near zero mobile browser support but strong desktop browser support- and I suggest a JavaScript fallback for the others …. https://www.timothychambers.net/2025/06/24/the-seven-deadly-fediverse-ux.html

@rimu web+acct

It’s a good idea, but fedi is maybe too broad to be useful? I wouldn’t want a Lemmy post to open in Mastodon, and pretty sure opening a Mastodon post in Lemmy is impossible unless the post was directed to a community.

web+threadiverse could solve that issue but that’s kinda hacky. Maybe the real solution is to improve Lemmy and Mastodon so that they are capable of doing these things decently.

I was actually thinking of making a browser extension that handles this instead. Each Fediverse software could write something to window.fediverse or something like that, with tags for group support or micro blogging. The extension could have methods to infer these values for existing platforms. But the extension could give a dialog box to redirect, based on your preferred instances for certain tags.

What does acct stand for?

@Die4Ever

RFC 7565: The 'acct' URI Scheme

The 'acct' URI Scheme (RFC 7565, )

IETF Datatracker (datatracker.ietf.org)

@rimu

web+ap, which was proposed by Fedilink authors. To my knowledge, it is the most widely adopted proposal

Fedi Links

(web.archive.org)

(the main site seems to be offline now)

cc @SoniEx2

Are there implementors of web+ap? I’d be interested in adopting.

I assume the fallback behaviour is to just assume https?

@julian Fedilinks website lists 3 MastoAPI clients, but the list is incomplete. I saw Fedilinks being mentioned in changelogs of other clients too.

There was also an Akkoma PR, it was closed by the author: https://akkoma.dev/AkkomaGang/akkoma/pulls/589. I don't quite understand the reasoning, perhaps @smitten could clarify.

The PR comments suggest that making the various changes to the backend were too large to justify, and a front-end only approach would be preferred? smitten@key.portend.place

It raises a good point though, where if you serve web+ap://, it’s not understood by clients that are not aware of this scheme. If there were a way a client could communicate whether there is a protocol handler registered, then the server could tailor its response.

Glad to see more people having this idea! The problems we ran into were in helping the browser understand the address and know where to forward. Each server implements lookup routes differently, so there's not necessarily a generic path that you can trust is available on https on the person's home server, even if you know their home server origin. So in some ways the feature should be offered by your home server software, maybe offering a website that does the handler registration to its known lookup/redirect address.

But that is limiting in a few ways. It's a lot of extra steps for each person to do (browsers' default UI for registering protocols is not obvious or easy). It doesn't carry over to different devices, and if you have more than one home server in some way, you are back dealing with that not-great browser UI to pick which handler you want.

In general people are more accustomed to registering protocols to apps they have installed, especially phone apps. It's much easier to register them there and you don't have to have approval flow UI, but taking that approach moves this whole served handler route out of the backend again, so we have to start thinking more along the lines of web+ap-compatible servers that handler clients know how to call or bounce to.

@julian@community.nodebb.org @silverpill@mitra.social @SoniEx2@chaos.social @rimu@piefed.social

Also I want to highlight this excellent comment by Yumechi about fingerprinting and de-anonymization risks.

https://socialhub.activitypub.rocks/t/fep-07d7-a-custom-url-scheme-and-web-based-protocol-handlers-for-linking-to-activitypub-resources/3588/53

@SoniEx2@chaos.social @silverpill@mitra.social @julian@community.nodebb.org @rimu@piefed.social

@smitten_ Do you know what is the status of Fedlilinks? Has it been abandoned?
FEP-07d7 was withdrawn, and other proposals have even less support than these two.

@SoniEx2 @julian @rimu @activitypub

@tchambers @julian @silverpill I put together a prototype, using web+ap.

Here’s a video demo - https://peertube.wtf/w/r8M4KpS6yLd9H2r2oPAs9M

The workflow is a wee bit clunky, with the browser popping up things more than I'd like, but it works.

@rimu @tchambers @julian

Neat.

@smitten_ Check it out

rimu@mastodon.nzoss.nz what happens if a browser that doesn’t understand protocol handlers encounters this scheme?

@tchambers@indieweb.social @julian@community.nodebb.org You're absolutely right about the mobile browsers sadly, but support on mobile apps is good. The UX there is better than it is on desktop browsers too, because it can be registered in the app manifest and doesn't require complicated approval and handler selection flows. People are also more familiar with links that look a certain way opening in their related app, it's just that they expect the behavior at the host level instead of the protocol level.