The UX of links on the Fediverse

A proposal for loading ActivityPub status links internally by default

User-centric thinking about links.

TLDR; A proposal for loading AP status links internally by default

Not to pick on Mastodon, but I’ll use it as an example because some Mobile apps have started to implement the experience I want to discuss.

Default situation
When using Mastodon the Web app, it is not uncommon to reference another post by pasting a link, whether to our own, or to another users post perhaps on another instance, or even from a different software.

Users on the Web app wishing to consult the link will usually click the link opening a new window or tab (where interaction on a remote instance is limited). A motivated user can copy the link, paste it into the search bar and load the status internally.

Wouldn’t it be simpler if the default interaction would load the link internally? And if users want to consult a remote status in context they can open the link in a new window or tab as they would elsewhere on the web.

Existing fragmented alternatives
Some apps (Toot!, Metatext) have implemented this behaviour by default for links to Mastodon status.

Standardizing for interoperability
We’re talking about the fediverse though, so interoperability is by necessity a given.

So how could we craft a link and signal to any other ActivityPub client that the link can be loaded as application/activity+json?

Data attributes. What if clients, when crafting a link would provide a hint using data attributes.
An example:

<a href="" data-activitypub-link="activity+json">A poll about interacting with remote status</a>

A number of server implementations are already fetching links for oEmbed, this addition seems somewhat trivial, but with a big improvement for end users!

Thought, comments?

Crossposted to Socialhub

Leave a Reply

Your email address will not be published. Required fields are marked *