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.
-
I think the biggest difference with pdfs, mp4 in your example and an activity is that I most likely want to interact with an activitypub object: either follow, repost/announce, etc for this to work I need to be logged in. So is the solution to include an activitypub client in the browser? Use an external viewer that intercepts through browser extensions?
Now even the experience inside mastodon sometimes opens a webview
️I think the right solution is to use a combination of FedCM (making progress in the W3C) plus Activity Intents (FEP-3b86) to link you back to the web page for your home server.
FedCM will let you “sign in” to your browser, and make that information available (with consent) to the pages you visit online.
Activity Intents publish the operations your home server supports, then give links to complete the intent.
We already have the tools we need.
-
@trwnh @evan @julian @rimu imho this is unrealistic and wishful thinking. I don’t think all major browsers will agree to do it this way anytime soon. Specially on mobile where most people get their content.
if that doesn’t happen the fediverse will continue to be difficult for ppl accustomed to one app that offers a unified social experience
Before 2015 universal/app links didn’t exist, a URI scheme was the best solution FB, Twitter, Instagram found
@ricferrer @evan @julian @rimu fb twitter instagram etc are also centralized single entities, so there's no contention on who gets to open the link.
-
I think the right solution is to use a combination of FedCM (making progress in the W3C) plus Activity Intents (FEP-3b86) to link you back to the web page for your home server.
FedCM will let you “sign in” to your browser, and make that information available (with consent) to the pages you visit online.
Activity Intents publish the operations your home server supports, then give links to complete the intent.
We already have the tools we need.
@benpate @ricferrer @evan @julian @rimu should be possible even without necessarily those specific tools -- although fedcm can make it "friendlier" ux-wise
- authenticate your id ("i am this person")
- get the linked claims from the id ("this is my proxy url")
- submit the request ("fetch me this thing")i mean, you could write a web extension right now that does it in a very minimal way, i'm pretty sure? "POST the current URL to this proxyUrl" is not exactly a difficult thing to do...
-
@benpate @ricferrer @evan @julian @rimu should be possible even without necessarily those specific tools -- although fedcm can make it "friendlier" ux-wise
- authenticate your id ("i am this person")
- get the linked claims from the id ("this is my proxy url")
- submit the request ("fetch me this thing")i mean, you could write a web extension right now that does it in a very minimal way, i'm pretty sure? "POST the current URL to this proxyUrl" is not exactly a difficult thing to do...
@benpate @ricferrer @evan @julian @rimu there's a shortcoming where mobile browsers don't let you install web extensions as easily but that can also be overcome i think.
-
@benpate @ricferrer @evan @julian @rimu there's a shortcoming where mobile browsers don't let you install web extensions as easily but that can also be overcome i think.
@benpate @ricferrer @evan @julian @rimu native apps can also expose share targets so you can "share" the current web URL to those apps and it opens in those apps.
-
@benpate @ricferrer @evan @julian @rimu should be possible even without necessarily those specific tools -- although fedcm can make it "friendlier" ux-wise
- authenticate your id ("i am this person")
- get the linked claims from the id ("this is my proxy url")
- submit the request ("fetch me this thing")i mean, you could write a web extension right now that does it in a very minimal way, i'm pretty sure? "POST the current URL to this proxyUrl" is not exactly a difficult thing to do...
You’re correct.
FedCM is a bonus, but not required.
And Activity Intents just normalize the mess of “remote follows” and “share intents” that many apps already support. I currently “polyfill” intents for servers (like Mastodon) that don’t publish explicitly.
It should, however, start with a GET to my home server (not a POST) so I can see what I’m about to do. There’s so much variation between servers; we’re asking for bugs if we skip this step.
-
You’re correct.
FedCM is a bonus, but not required.
And Activity Intents just normalize the mess of “remote follows” and “share intents” that many apps already support. I currently “polyfill” intents for servers (like Mastodon) that don’t publish explicitly.
It should, however, start with a GET to my home server (not a POST) so I can see what I’m about to do. There’s so much variation between servers; we’re asking for bugs if we skip this step.
@benpate @ricferrer @evan @julian @rimu i'm not entirely sure why it's POST proxyUrl instead of GET proxyUrl but i think it has to do with leaking metadata iirc
-
@benpate @ricferrer @evan @julian @rimu should be possible even without necessarily those specific tools -- although fedcm can make it "friendlier" ux-wise
- authenticate your id ("i am this person")
- get the linked claims from the id ("this is my proxy url")
- submit the request ("fetch me this thing")i mean, you could write a web extension right now that does it in a very minimal way, i'm pretty sure? "POST the current URL to this proxyUrl" is not exactly a difficult thing to do...
@trwnh @benpate @evan @julian @rimu of course. There are several nerdy and probably cleaner ways of doing it. But requiring the user to install an extension is the first mistake on the path to wide adoption. I think sometimes a more pragmatic approach can bring the best results, if the goal is to get most people to the fediverse and not have the most elegant solution from the the start or nothing
-
@trwnh @benpate @evan @julian @rimu of course. There are several nerdy and probably cleaner ways of doing it. But requiring the user to install an extension is the first mistake on the path to wide adoption. I think sometimes a more pragmatic approach can bring the best results, if the goal is to get most people to the fediverse and not have the most elegant solution from the the start or nothing
@ricferrer @benpate @evan @julian @rimu you don't have to install an extension though -- that's just one way to make things easier.
consider the example of sharing something via a messaging app though. do you trust people to copy the "right" link? or do people have to load an https: then load a fedi: link twice in a row? how is that supposed to work vs just having your existing https resolver handle it for you, *like it already does* to some extent with other content-types?
-
@benpate @ricferrer @evan @julian @rimu i'm not entirely sure why it's POST proxyUrl instead of GET proxyUrl but i think it has to do with leaking metadata iirc
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 you don't have to install an extension though -- that's just one way to make things easier.
consider the example of sharing something via a messaging app though. do you trust people to copy the "right" link? or do people have to load an https: then load a fedi: link twice in a row? how is that supposed to work vs just having your existing https resolver handle it for you, *like it already does* to some extent with other content-types?
@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.
-
@trwnh @benpate @evan @julian @rimu of course. There are several nerdy and probably cleaner ways of doing it. But requiring the user to install an extension is the first mistake on the path to wide adoption. I think sometimes a more pragmatic approach can bring the best results, if the goal is to get most people to the fediverse and not have the most elegant solution from the the start or nothing
Agreed. Nobody’s going to install an extension. It HAS to work with native web pages and vanilla browsers to be viable.
-
@ricferrer @evan @julian @rimu fb twitter instagram etc are also centralized single entities, so there's no contention on who gets to open the link.
@trwnh @evan @julian @rimu it already works well for mailto: the average user doesn’t have 10 mail clients. For the advanced and technical savvy users that want a bunch of fedi clients they can find other solutions on how deal with it.
Btw Android lets you choose your the app.
Before 2015 you would uninstall twitter and install tweetbot which responded to twitter:
Fallbacks to http/html for people without apps was handled through JavaScript
-
@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.
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 @ricferrer @evan @julian @rimu native apps can also expose share targets so you can "share" the current web URL to those apps and it opens in those apps.
-
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!!!
