It’s really surprising to me that the #fediverse hasn’t agreed on a standardized way to open cross-instance #activitypub objects and instead relies on links that open in the browser.

@ricferrer@mastodon.social @benpate@mastodon.social yes, that's correct and what the current state of affairs is.

You can write links pointing to an interstitial page that says something like "opening in app", and use js to fire off the web+ap protocol handler.

If the user is still on the page after some time has passed, the handler failed and you redirect to the https version.

@julian @benpate @rimu @ricferrer most people don't have fedi

@benpate @ricferrer @evan @julian @rimu if i'm already in my browser i don't want another browser. the "open web" IS the platform. that's where the interactions SHOULD be happening... and could be with a bit of work.

Yes, that would suck. But it’s not what I’m suggesting. More like:

1. On a web page with cool content
2. Click “like” or “share” button
3a. Already identified? Jump to your home server, confirm the action, return to page
3b. Else, click “join now” to sign up on a recommended server for this content. Bonus pts for keeping the intent context around and completing the “like” once you have your new account.

This would help more people explore the Fediverse.

@trwnh @ricferrer @evan @julian @rimu

@trwnh@mastodon.social exactly, that's why when you open the interstitial page, it tries the protocol handler, and if there's no response, sends the user to the https target as fallback.

@benpate i think 3b is where my issue is -- the solution for me looks a lot more like

1. on a web page
2. click share (in js or in browser)
3. your browser or os sends some stuff to an app of your choice you already have (including registered pwa targets)

bonus: filter share targets by content-type

@trwnh That would be ideal, once you have the app. But if you don’t already have an app installed for this, how do we onboard new users? That’s the most important part, for me.

I’m starting to think there’s some hybrid approach that will just do everything. Hopefully it can all be “containerized” in a JS widget that lets website designers KitKat drop a widget in their page and then it’ll just magically work

@benpate i think 3b is where my issue is -- the solution for me looks a lot more like

1. on a web page
2. click share (in js or in browser)
3. your browser or os sends some stuff to an app of your choice you already have (including registered pwa targets)

bonus: filter share targets by content-type

@trwnh @benpate I agree. It should always be web first. But for those that made the leap, choose from the 100,000 servers and have an app, we shouldn’t make them relive the trauma by asking them to log in on every instance where they just want to either follow someone or like something

Imagine i send you the link below through signal. It opens in the browser or webview. If i want to follow them all, i have to log in x times https://joinfediverse.wiki/Notable_Fediverse_accounts

@benpate how do we get people to use fedi without an account?

@trwnh @benpate
The issue with PWA targets afaik is that they are like universal/app links -> bound to a domain

Apps from different vendors can pick it up (it’s only a problem if you have more than one on iOS, Android lets you choose)

For 3b to work you would need to tell the page with the content which one is your home server every time for every content

Do you use a browser for the fediverse mostly or an app? I am 100% app

@trwnh @benpate
The issue with PWA targets afaik is that they are like universal/app links -> bound to a domain

Apps from different vendors can pick it up (it’s only a problem if you have more than one on iOS, Android lets you choose)

For 3b to work you would need to tell the page with the content which one is your home server every time for every content

Do you use a browser for the fediverse mostly or an app? I am 100% app

@julian

just some historical context,

since at least 2010 (16 years ago) registerProtocolHandler is specified and worked for mailto: then for tel: (cause nice for gooles android)

back in 2015 (11 years ago) we (w3c SocialCG) had talked to all the browser makers about making ActivityPub and webmention trusted protocols.

In 2016 (T-10 years) I demoed the existing practical problems at Jeremy Keiths indiewebcamp in Brighton see the demo https://www.youtube.com/live/W70wd56i0Bg?si=DJgm9WsGpwzaLdGJ&t=2030 (indiewebcamp demos are written in incredible short time …)

Anyway - nothing changed at the browser makers except the browser makers switched their positions from company to company. @jaffathecake

[edit; well: Mozilla did BrowserId, renamed it to Persona and directly trashed it cause then gaming and AI [where the parts of the teams went to] was more important …

@ricferrer @benpate

@sl007 @julian @jaffathecake @benpate but you don’t need approval or the blessing from the browsers to implement a uri scheme right? iTunes used it with itms: , zoom does it.

It works of people have the app. You would only need their support if you want the browser to do something with the uri out of the box when there is no app other than showing an error. Right?

@trwnh @benpate
The issue with PWA targets afaik is that they are like universal/app links -> bound to a domain

Apps from different vendors can pick it up (it’s only a problem if you have more than one on iOS, Android lets you choose)

For 3b to work you would need to tell the page with the content which one is your home server every time for every content

Do you use a browser for the fediverse mostly or an app? I am 100% app

@trwnh @benpate
The issue with PWA targets afaik is that they are like universal/app links -> bound to a domain

Apps from different vendors can pick it up (it’s only a problem if you have more than one on iOS, Android lets you choose)

For 3b to work you would need to tell the page with the content which one is your home server every time for every content

Do you use a browser for the fediverse mostly or an app? I am 100% app

@ricferrer@mastodon.social yes and no. I think standalone apps can listen for their own protocol handlers (like julian:// what a great protocol)

But PWAs must use the web+ prefix. The OS (or maybe just the browser) won't allow registration otherwise

@trwnh@mastodon.social @benpate@mastodon.social @sl007@digitalcourage.social

@ricferrer@mastodon.social yes and no. I think standalone apps can listen for their own protocol handlers (like julian:// what a great protocol)

But PWAs must use the web+ prefix. The OS (or maybe just the browser) won't allow registration otherwise

@trwnh@mastodon.social @benpate@mastodon.social @sl007@digitalcourage.social

@ricferrer@mastodon.social yes and no. I think standalone apps can listen for their own protocol handlers (like julian:// what a great protocol)

But PWAs must use the web+ prefix. The OS (or maybe just the browser) won't allow registration otherwise

@trwnh@mastodon.social @benpate@mastodon.social @sl007@digitalcourage.social

@julian

That’s really helpful. Thanks, Julian://

One follow up question? Is it possible for regular apps to use the web+ prefix, too? Otherwise we’d have to pick one over the other, which might be problematic.

@ricferrer @trwnh @sl007