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.
-
Here’s a question: do browsers let JavaScript introspect what custom protocol handlers are available/installed?
I’m planning a Franken-widget that works with whatever tools are available.
Activity Intents? Sure
Custom protocol? Okay, we’ll use that too.
None of the above? Sniff the server and polyfill.
We could certainly try an “AND” approach, if JavaScript will let us.
-
Yes. I agree with just moving forward with the tech we have.
What would the JavaScript do, exactly?
What parts of this would require a new ap:// protocol, or could we accomplish this with regular https:// links?
Also: thanks for starting this conversation. I think it’s very helpful and timely!
@benpate @trwnh @evan @julian @rimu
Maybe I did not explain it well. Fb, twitter, instagram used JavaScript to try to open their uri. If it failed, they opened the http equivalentThe user did not notice much. If they had the app, it jumped. Sometimes if you returned to the browser the http was opened anyways. But that’s wasn’t very annoying
-
Also, you can see this running right now on bandwagon.fm.
You can remote follow right from a band page, or even from a page of search results.
This works with just about any Fedi server by polyfilling the oStatus remote follow logic
If you’re in an #Emissary server you can also do remote likes, too
Could you try out the workflow I have in place right now? My goal is to expand this, make it all JS (no server-side required) then package it for everyone
-
And I thing this “other way around” — going from a remote server to your home server — is the most important use case.
Let’s lock this down and get “share” buttons everywhere.
-
Here’s a question: do browsers let JavaScript introspect what custom protocol handlers are available/installed?
I’m planning a Franken-widget that works with whatever tools are available.
Activity Intents? Sure
Custom protocol? Okay, we’ll use that too.
None of the above? Sniff the server and polyfill.
We could certainly try an “AND” approach, if JavaScript will let us.
@benpate @trwnh @evan @julian @rimu I know I implemented it at some point by analyzing what Facebook and co were doing. I think it was kind of a hack, but it worked. It didn’t let you know what was available. It just assumed it worked if you left the page and if you were still there it opened http. Like I said sometimes you had the page open when you came back to the browser (so it effectively opened both) but it wasn’t that annoying
-
@benpate @trwnh @evan @julian @rimu
Maybe I did not explain it well. Fb, twitter, instagram used JavaScript to try to open their uri. If it failed, they opened the http equivalentThe user did not notice much. If they had the app, it jumped. Sometimes if you returned to the browser the http was opened anyways. But that’s wasn’t very annoying
I think I follow. Instead of “look before you leap” it’s more like “just jump anyway, then recover errors gracefully.”
On my iPhone, websites themselves can declare a preferred app to use instead of the site. That’s another way around this problem, yes? But I don’t know if that’s available in desktops or not.
I care mostly that we don’t break things for regular people who haven’t installed an app, and haven’t installed a browser plugin.
-
And I thing this “other way around” — going from a remote server to your home server — is the most important use case.
Let’s lock this down and get “share” buttons everywhere.
@benpate @ricferrer @evan @julian @rimu if you never leave the app then the "other way around" basically never presents itself at all
but really, how hard is sharing a link? doesn't seem hard!
content handler is best in the long term but in immediate term there are still many ways to do this...
-
@benpate @trwnh @evan @julian @rimu
Maybe I did not explain it well. Fb, twitter, instagram used JavaScript to try to open their uri. If it failed, they opened the http equivalentThe user did not notice much. If they had the app, it jumped. Sometimes if you returned to the browser the http was opened anyways. But that’s wasn’t very annoying
@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.
-
@benpate @ricferrer @evan @julian @rimu if you never leave the app then the "other way around" basically never presents itself at all
but really, how hard is sharing a link? doesn't seem hard!
content handler is best in the long term but in immediate term there are still many ways to do this...
You’re right.. ONCE YOURE IN the ecosystem, it would be easy to just stay there. But how do you get into it in the first place?
Most interactions will START out there in the open web. We need to make a smooth on-ramp for newbies to find us first.
That’s why web -> fedi matters so much.
-
I think I follow. Instead of “look before you leap” it’s more like “just jump anyway, then recover errors gracefully.”
On my iPhone, websites themselves can declare a preferred app to use instead of the site. That’s another way around this problem, yes? But I don’t know if that’s available in desktops or not.
I care mostly that we don’t break things for regular people who haven’t installed an app, and haven’t installed a browser plugin.
@benpate @ricferrer @evan @julian @rimu you can already do this with http and as early as 2013 there was an android app for handling links before they reached your default browser. i'm trying to remember what it was called
-
@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.
@benpate@mastodon.social and yes it will work fine with users without an app or extension installed. Agreed that this is a no-go for wide adoption. It has to be done with stuff everybody already has.
cc @trwnh@mastodon.social @rimu@mastodon.nzoss.nz @ricferrer@mastodon.social
-
I think I follow. Instead of “look before you leap” it’s more like “just jump anyway, then recover errors gracefully.”
On my iPhone, websites themselves can declare a preferred app to use instead of the site. That’s another way around this problem, yes? But I don’t know if that’s available in desktops or not.
I care mostly that we don’t break things for regular people who haven’t installed an app, and haven’t installed a browser plugin.
@benpate @trwnh @evan @julian @rimu that was the beauty of the approach. At the time desktop only said “app not available” but still had the destination open below the alert. I don’t know if macOS and other desktop handles it the same way now. I tried this in 2009 the last time
but it might be worth a try On you iPhone it uses the newer approach of registering the domain for universal links (released in 2015). Which won’t work in the fediverse
-
You’re right.. ONCE YOURE IN the ecosystem, it would be easy to just stay there. But how do you get into it in the first place?
Most interactions will START out there in the open web. We need to make a smooth on-ramp for newbies to find us first.
That’s why web -> fedi matters so much.
@benpate @ricferrer @evan @julian @rimu right, so...
- here's a link that you won't know how to open
- go sign up at one of 100,000 servers before you can open it
- do all that and end up with basically just a share buttonis a really bad ux, isn't it? i mean, it annoys me so much when people share matrix.to links for this reason...
-
@benpate @ricferrer @evan @julian @rimu right, so...
- here's a link that you won't know how to open
- go sign up at one of 100,000 servers before you can open it
- do all that and end up with basically just a share buttonis a really bad ux, isn't it? i mean, it annoys me so much when people share matrix.to links for this reason...
@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.
-
@benpate@mastodon.social and yes it will work fine with users without an app or extension installed. Agreed that this is a no-go for wide adoption. It has to be done with stuff everybody already has.
cc @trwnh@mastodon.social @rimu@mastodon.nzoss.nz @ricferrer@mastodon.social
@julian @benpate @rimu @ricferrer most people don't have fedi
-
@benpate @ricferrer @evan @julian @rimu right, so...
- here's a link that you won't know how to open
- go sign up at one of 100,000 servers before you can open it
- do all that and end up with basically just a share buttonis a really bad ux, isn't it? i mean, it annoys me so much when people share matrix.to links for this reason...
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 @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.
