The problem
One of the problems of the Fediverse is the user experience of cross instance interactions on the web (e.g. you watched a video on PeerTube and would like to comment on it with one of your Mastodon accounts). This is already detailed on the post a custom URL scheme handler as a streamlined UX for cross-instance interactions on the web.
The main scenarios I’m aiming to address here are:
- Follow/subscribe an account on a different instance
- Reply to a post on a different instance
- favorite/like (Like) or boost/repost (Announce) a post on a different instance
This is specially an issue for new users, not yet used with this hurdle. I’ll quote an anonymous peer:
I am flabbergasted that I have to copy/paste the URL over to the mastodon instance that I am on to “boost”/retweet it. That doesn’t seem to scale well.
The solution proposal
Inspired by WebLN, I imagined we could have a Web Standard to transform the browser in an ActivityPub client, and expose this to the web applications through a Javascript API.
The browser would abstract the authentication and also handle permissions (e.g. when a webapp wants to behave as a client using this Javascript API, the browser has to prompt the user for consent).
This could enable a seamless experience once the use has configured its account(s) in the browser.
A simplified happy path would look like this:
- The user goes to the browser configuration and sets up their ActivityPub accounts
- The user visits a website where ActivityPub Objects are shown (e.g. Statuses on a Mastodon instance, a Video on a PeerTube instance) - this is not an instance where the use has an account
- The user interacts with the object (e.g. Likes the Mastodon status) directly from the website they are visiting.
Under the hood the frontend application of the website visited by the user is consuming a Web API to post an Activity to the user’s outbox on the instance where the user has an account.
Here is a sketch of how the code on the front end app could look like:
// This code runs when the user clicks on a Like button of a Note on a website where they don't have an acount
// WebAP is a global object exposed by the browser
// each client is a configured account
const activityPubClients = await WebAP.getClients();
// ideally you would have some logic prompt the user to select the proper client (account) when there is more then one, or inform the user to configure it if there are none
const client = activityPubClients[0];
client.postToOutbox({
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Like",
"object": objectId, // id of the note to be liked
"to": "https://www.w3.org/ns/activitystreams#Public"
});
How could this get started?
Assuming this is a good idea, we would need some level of browser support to get this started. I cannot imagine big name browsers introducting something like this any time soon, so we would need an alternative.
Again I draw inspiration from WebNL. There is a Browser extension called Joule that somehow exposes the API to front end web applications. I don’t know exactly how it is done, but in theory this could be used to get started and mitigate the browser adoption problem.
From there, we would need some early adopters (imagine for instance if Pleroma and Mastodon would consider consuming this API from their front end to enable seamless cross instance integractions).
Since Mastodon has a big user base and it does not support C2S, I wouldn’t discard a provisional translation layer from AP C2S into Mastodon API on the Extension, to maximize adoption.
Closing remarks
This is just a rough idea, with many rough edges to be polished. Executing it in a future proof way would be challenging. It should also be said, it inherits all the already existing challenges of implementing an AP client.
I’m eager to hear the opinions of the community about this crazy idea.
If I have enough time and energy, I might do some prototyping.
.
, but here is the second ever message sent with it: