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.
-
@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.
I agree with this 100% and I think this is what I’m pushing for
-
@julian @benpate @rimu @ricferrer most people don't have fedi
@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.
-
@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.
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 …
-
@julian @benpate @rimu @ricferrer most people don't have fedi
This is unfortunately true. But I believe good content (plus those little like and share buttons) would give people a reason to join.
I yammered about this for 30 minutes at FOSDEM. I can link the presentation video once it’s posted.
-
@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.
@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 somethingImagine 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
-
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.
@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@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.
@julian yup
you could in theory do web+activity to mean "http get with accept header for activity+json" but what mastodon does is i think just intercept the click with js
-
@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
-
@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 how do we get people to use fedi without an account?
-
@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
The issue with PWA targets afaik is that they are like universal/app links -> bound to a domainApps 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 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 somethingImagine 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
@ricferrer @benpate right now, if you link me x accounts and i find n interesting, i copy-paste n links (n <= x) into my fedi address bar (search bar) to access them in my "layer 2" browser-in-a-browser
i am not entirely convinced it would be better for every page to have to publish 2x links as opposed to publishing x links and you copying n links. 2x > x + n
what could be improved is opening n links in a different app (pwa included) but you can't avoid that unless you make your browser auth'd
-
@benpate how do we get people to use fedi without an account?
@trwnh sorry. What I mean is: the “share” and “like” workflows are gateways to the signup process.
If someone already has an account, use that.
Otherwise, give them a big orange button that goes directly to a signup page — no awful “instance chooser”, but that’s another conversation.
With Activity Intents, all the real work happens on your home server so we don’t need you to “sign in” on the remote server; just declare where you’re going to go when you want to interact.
-
@trwnh @benpate
The issue with PWA targets afaik is that they are like universal/app links -> bound to a domainApps 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 @benpate the app is a browser too but i mainly use either firefox or subway tooter
-
@trwnh @benpate
The issue with PWA targets afaik is that they are like universal/app links -> bound to a domainApps 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 @benpate the "end goal" for me is to have them discriminate by content type so i can open pdfs in my pdf viewer and activities in my activity viewer
-
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 …
@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?
-
@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?
@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
-
@trwnh @benpate
The issue with PWA targets afaik is that they are like universal/app links -> bound to a domainApps 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
“For 3b to work you would need to tell the page with the content which one is your home server every time”
Not quite. FedCM solves this. And in the interim, we can put this in localStorage so you only need to enter your handle once per domain. And even that can be reduced if all the JS widgets are served by a shared location.
-
@trwnh @benpate
The issue with PWA targets afaik is that they are like universal/app links -> bound to a domainApps 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
I’m 70/30 app/browser. I used the browser, for instance, when traveling internationally so I don’t have an app signed in to my identity.
But I’m not the target audience. I’m already sold. The main reason to put open web first is to give an on-ramp to newbies who would join us if we made it easy enough
-
@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
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.
