For the last couple of decades, the social web has been in a stagnant state, restricted to siloed social media systems. As these companies seem to implode on themselves or dry out, more open social web systems seem to be taking their space. Fediverse is one such social web concept, and as more modes become compatible with the underlying technology, ActivityPub, I wonder how we will interact with it.

The main way we currently interact with the modern social web is either through an external app which collects your feed(s) in one place, or a dedicated webpage opened in a browser for each server you interact with.

Under a centralised social media system, all that is necessary is to add a plugin or embed a button from a platform, like Facebook’s Like button, and suddenly everyone who uses that platform can instantly interact. To do the same with a Fediverse account (be it mastodon, WordPress, Pixelfed, or any of the others), you first need to identify if a page is AP-compatible, then copy the link, then open your server’s web interface or a dedicated app, paste it, and then either find the original post or create your own in order to comment on it. This is unusable for the average netizen.

I feel that in order for systems like the fediverse to really take off, then the browser will need to be that main point of interaction. This could be built-in, or could be offered by web extension technology, or via an API to a dedicated app. When you are browsing the web, it is simply far too difficult at the moment to share links and interact with social web content. As web browsers act as user agents for the world wide web, they will eventually need to act as user agents for the social web.

What could this look like?

Well, a user agent for the social web would need to:

• Indicate the fediverse accounts of pages you are currently visiting (such as with the streetpass extension, which lists followable accounts that you come across on the web)
• Indicate whether the page you are looking at right now is an activitypub-compatible item (e.g. if you copy the url of this blog entry into your main fediverse interface, it will display it as an interactable post)
• Offer direct interactions like comment, boost / share, favourite / like, follow, without the website needing 3rd party trackers or embeds (remember the facebook like button? you can’t add a unique button for every single fediverse server)
• Indicate when the user has previously interacted (a social app will show you when you’ve previously boosted, favourited and item, or followed an account)

How could this be implemented for websites and user agents?

• The user could decide which social web accounts or external apps to link to a browser. Social web services wouldn’t be able to track how the browser is used, but if the user initiates an action, like ‘follow’, then this could be sent via API to that social web service. Multiple accounts could be connected to a single browser.
• For indicating accounts and activity-pub compatible content, places like mastodon already have a system for indicating account ownership through metadata fields. This could be expanded for any content to indicate the canonical URL that a social web user agent should refer to. This way users don’t need to query the URL every single time they want to check if a page’s content is interactable.
• For interactions, generic social web controls could be created for the most common social web interactions, for example following, boosting/sharing, or liking/favouriting. Controls for these could be included within the user agent’s chrome, or websites could include them on a page with special HTML like <social type="boost">. Any AP content could be styled using special CSS selectors like :liked or :replied to customise how content is displayed based on previous interactions.

What would be the limits?

Of course, privacy would need to be maintained. The is one of the major failings of the original social media phase of the web. Websites should not be able to infer whether a user follows them, has previously interacted with them, or whether they even have a connected social web account, and nor should they be able to require this for any purpose.

On a technical level, if the browser does not implement this, then a system like email’s mailto: protocol will be an essential next step for Fediverse working groups to develop.

What do you think? Please leave a comment (or a reply on a Fediverse platform) if you’ve got any ideas.