The UX of Links on the Fediverse

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?

Proposal
The Type attribute. What if clients, when crafting a link would provide a hint using a type attribute.
An example:
<a href="https://social.coop/@django/106999656743222202" type="application/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?

EDITED to incorporate @tcit use of the Type attribute

1 Like

You could simply use the type attribute :

<a href="https://social.coop/@django/106999656743222202" type="application/activity+json">A poll about interacting with remote status</a>
3 Likes

Additionally you could use CSS to differentiate such links:

:link[type=application/activity+json]::before {
  content: '\2B5A '; /*⭚ */
}
2 Likes

Wow, I was not even aware of the Type attribute’s existence! This is actually much more appropriate.

Thanks, I thought about this too, but was thinking it’d be best to leave it up to the implementer.

But how would the server creating the post know that it’s a link to an ActivityPub object? Am I supposed to try to follow every link/URL every user posts hoping it might point to something ActivityPub? I don’t have the notion of a client.

I already do this for mentions tho, but internally. I always try to open mentioned user’s profiles on my instance just so you could easily interact with that user should you want to.

This character doesn’t show up on my system:
image

1 Like

Wouldn’t it be simpler if the default interaction would load the link internally?

Yes, of course. For example if redaktor got a link with type="application/activity+json", it will load it in the same visual context, you opened it from. In redaktor, this can be a “column” (e.g. a stack of cards in the normal inbox view), “row” (overviews) or “full” …

We had this discussion multiple times and there are web standards about that.
For example, we discussed specyifing “link relations” at the second conference and
at a Social CG meeting.
By the time I was told that I am the only one interested in that.

The big player was not interested, which usually means, the discussion ends – as here too:
Defining alsoKnownAs - #14 by Sebastian and Defining alsoKnownAs - #12 by Sebastian

Then this was a summary of an irc conversation with rhiaro: 2020-12-04 SocialCG Meeting - #2 by Sebastian

First off, it is important, what @tcit wrote, use type
No link parser in the world would parse “data-” attributes but all are parsing type

Additionally, the rel attribute is an option, see all “Attributes” of <a> in <a>: The Anchor element - HTML: HyperText Markup Language | MDN

For example, micropub registered a link relation: Micropub rel="micropub" and we can become more specific, for example if we want to link the author (attributedTo) of an ActivityPub post, it would be
rel="activitypub author" and everyone knows, the relation is “author of ActivityPub object” …

See also
Link types - HTML: HyperText Markup Language | MDN and Link Relations (Registry)


PS, if you use CSS and an icon, there is a webfont or svgs which you can use, e.g. the logos are z_… activitypub-origami/webfont/svg at master · sebilasse/activitypub-origami · GitHub and you can use e.g. a data url of the svg with how’s example …

2 Likes

This is a fair point. Not every implementation does server-side look ups to fetch metatags like Open Graph, oEmbed (Mastodon), for some its optional (Zap), but for implementations that don’t but are capable of making internal links, it wouldn’t be too onerous to add this type attribute.

This has been true in the past, yet we are seeing movement with the Edit activity for example.

Either way, if this is defined as a #activitypub:fep , and users are interested enough in this, pull requests can be opened…

I’ve created a FEP for this: fep/fep-e232.md at main - fep - Codeberg.org. The proposed solution is to use Link tags.

Discussion thread: FEP-e232: Object Links

3 Likes

What about situations where the data is available in multiple formats? Should we tell the client app all of the available formats so it can to choose how to render it? Or what about situations where the viewer wants to go to the origin instead of viewing it within the app?

I think object links should work like mention links. Usually there’s a way to open it at the origin (for example, by opening the link in a new browser tab).

2 Likes