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.
-
Can you expand on this idea? I know toots are short, but this is interesting and I want to better understand what you’re proposing here.




@benpate what mastodon and piefed and browser.pub do, basically.
open a link like https://browser.pub/https://mastodon.social/@benpate/116025296487246556 and then click any of the other links. you should remain in browser.pub.
-
@benpate what mastodon and piefed and browser.pub do, basically.
open a link like https://browser.pub/https://mastodon.social/@benpate/116025296487246556 and then click any of the other links. you should remain in browser.pub.
@trwnh Thank you. I understand what you’re saying. They’re rewriting links in the post to keep you on that site. I’ll need to keep this idea in my toolbox.. it will be useful.
-
In the end, we need real “share” and “like” buttons for the Fediverse - with as few clicks as possible - wrapped up as easily installable widgets that go next to Twitter and Facebook on every site online.
(That’s step 1)
Once we do this, step 2 is to lobby sites to JUST use Fediverse buttons, and drop the ones for hateful platforms.
-
@ricferrer to repeat: you don't need the extensions. they are just one option to making things simpler. i described at least 2 other options that are all complementary:
- rewrite links to keep you in-app
- content-type handlers to get you in the right app
- extensions to also get you in the right app
- share targets to get you in the right app (on mobile)you can use one, some, all, or none of these. the first one is the most important; the others should also be easy to do right now.
-
This is AMAZING, Dan, and it would be a huge win. #ThankYouThankYouThankYou!!!
-
@trwnh @benpate @evan @julian @rimu
I am focused on what can we do pragmatically and realistically as a community to fix the broken experience to help get more people into the fediverse.A mix of
1) JavaScript for websites that want to link to the fediverse that trigger ap: and offer http fallback (just like fb: before 2015)
2) adding support for ap: on fedi clients
It’s something we can do now. It works and we don’t have to wait for big tech
-
@ricferrer to repeat: you don't need the extensions. they are just one option to making things simpler. i described at least 2 other options that are all complementary:
- rewrite links to keep you in-app
- content-type handlers to get you in the right app
- extensions to also get you in the right app
- share targets to get you in the right app (on mobile)you can use one, some, all, or none of these. the first one is the most important; the others should also be easy to do right now.
@ricferrer browser support would be the icing on the cake, but i think that extensions are actually not as unrealistic as you are saying. many people end up with extensions installed almost by accident. at the end of the day, if you open an app like mastodon, you have to be prompted to do certain things like enabling notifications and registering stuff like that.
-
@trwnh @benpate @evan @julian @rimu
I am focused on what can we do pragmatically and realistically as a community to fix the broken experience to help get more people into the fediverse.A mix of
1) JavaScript for websites that want to link to the fediverse that trigger ap: and offer http fallback (just like fb: before 2015)
2) adding support for ap: on fedi clients
It’s something we can do now. It works and we don’t have to wait for big tech
@ricferrer @benpate @evan @julian @rimu doing ap: will fail for anyone who doesn't understand ap: which by default is everyone
-
@ricferrer to repeat: you don't need the extensions. they are just one option to making things simpler. i described at least 2 other options that are all complementary:
- rewrite links to keep you in-app
- content-type handlers to get you in the right app
- extensions to also get you in the right app
- share targets to get you in the right app (on mobile)you can use one, some, all, or none of these. the first one is the most important; the others should also be easy to do right now.
@trwnh staying in app is the simplest solution. But the challenge is getting me from the browser to the app without me having to install anything or use the share intent workaround, which doesn’t work because it opens a “new post” as expected by the user when they select “share”
-
@trwnh staying in app is the simplest solution. But the challenge is getting me from the browser to the app without me having to install anything or use the share intent workaround, which doesn’t work because it opens a “new post” as expected by the user when they select “share”
@ricferrer you have to at minimum register a handler, no? how is that any different than "installing"?
-
@trwnh @benpate @evan @julian @rimu
I am focused on what can we do pragmatically and realistically as a community to fix the broken experience to help get more people into the fediverse.A mix of
1) JavaScript for websites that want to link to the fediverse that trigger ap: and offer http fallback (just like fb: before 2015)
2) adding support for ap: on fedi clients
It’s something we can do now. It works and we don’t have to wait for big tech
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!
-
@ricferrer @benpate @evan @julian @rimu doing ap: will fail for anyone who doesn't understand ap: which by default is everyone
-
@trwnh Thank you. I understand what you’re saying. They’re rewriting links in the post to keep you on that site. I’ll need to keep this idea in my toolbox.. it will be useful.
-
In the end, we need real “share” and “like” buttons for the Fediverse - with as few clicks as possible - wrapped up as easily installable widgets that go next to Twitter and Facebook on every site online.
(That’s step 1)
Once we do this, step 2 is to lobby sites to JUST use Fediverse buttons, and drop the ones for hateful platforms.
-
@ricferrer @benpate @evan @julian @rimu in any case the thing all fedi apps can do "right now" (without any ecosystem changes otherwise) is to try to load all https: links locally before kicking users out. this is at least half of the problem solved right away.
-
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