A Web Standard for ActivityPub cross-instace UI interactions

[dellagustin]

The problem: "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." - https://innersourcecommons.slack.com/archives/CUWFGQJ8K/p1670605043162499?thread_ts=1670600007.178549&cid=CUWFGQJ8K

Idea: to have a Javascript API to expose ActivityPub capabilities to websites The use would configure the browser as a client in a Client-to-server (C2S) connection with one or more ActivityPub enabled instances and expose this to webapps throgh a JS API, similar to what WebLN does for lightning. Having an extension to expose this first (like Joule for WebLN) would be a way to provide a minimal viable implementation.

To Do

• [x] Create a post on https://socialhub.activitypub.rocks - DONE - https://socialhub.activitypub.rocks/t/proposal-the-browser-as-a-client-with-a-new-web-standard-cross-instance-interactions-on-the-web/2806

References

• https://github.com/podStation/podStation/issues/304
• https://webauthn.io/
• Suggestion: a custom URL scheme handler as a streamlined UX for cross-instance interactions on the web
• https://webln.dev/#/
  • https://lightningjoule.com/

[dellagustin]

For prototyping: https://github.com/webap-api

[dellagustin]

Post Draft for SocialHub

The browser as a client with a web standard- cross-instance interactions on the web

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 a Mastodon account). This is already details 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:

1. Follow/subscribe an account on a different instance
2. Reply to a post on a different instance
3. favorite/like or boost/repost 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).

A simplified happy path would look like this:

1. The user goes to the browser configuration and sets up their ActivityPub accounts
2. 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
3. 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 activtyPubClients = 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 = activtyPubClients[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"
});