"Social sharing" with ActivityPub

Fediversity
1

Discourse has a “social share” component so that readers can share a post on different platforms. On the link above you will find ways to share with all kinds of social media silos, but not a single one to share with an ActivityPub instance. This, to me, is a terrible overlook from the ActivityPub community, that it does not make easy for people to perform one-click sharing of contents.

I agree that the use-case of “sharing with” decentralized instances is not the same as with sharing with a unique instance. But this does not mean it should be more difficult to do: actually it should be as easy as documenting an URI template such as: https://your.social.example/sharing?url=.

If we could agree that all ActivityPub implementations would implement such a template, then it would bring a very easy way to catch up with centralized services. Eventually, this could become standardized, but even before considering this, let’s consider the actual use-case of adding the possiblity for people to share with their favorite ActivityPub instance.

Since Diaspora already has such a template, documented at the link above (https://share.diasporafoundation.org/?title={title}&url=), we can see that: 1) there’s a convenient, but centralized, way of sharing a link to D*; 2) there should be a similar service that would detect, maybe through fediverse.space, which instance you’d like to share with – or, even better, “force” a local instance, that would then ask you to log in and forward the sharing request to your own instance (which would mean to specify more precisely this workflow in ActivityPub).

I’m just throwing wild thoughts here, but the problem to solve does not seem to be too difficult for coordinated action, while the benefit seems, in the current state of the web, an avenue to take back from centralized services.

1 Like
2

This was one of the first issues considered by the SocialCG: https://github.com/swicg/general/issues/5, and for a while mastodon implemented a custom protocol handler as detailed there to attempt to solve this problem, but we found 1) the browser and user UX around web protocol handlers was too confusing—browsers wouldn’t prompt users to add the custom protocol and didn’t provide a way for users to choose or switch between protocol handlers 2) there wasn’t a lot of interest in it from other implementors.

Right now, mastodon does implement a share template, and it uses it internally on static pages (so when you’re viewing a profile on toot.cafe, you can like it from your mastodon.social account), but our experience is that the kind of people writing social buttons don’t want to implement the 2-step flow that decentralized sharing currently requires (i.e. ask for the user’s domain, and then redirect to the share sheet for that domain).

The ticket linked above also suggested using a trusted intermediate domain as a fallback for when web protocol handlers were not available—i have to admit that i’m pretty wary of any trusted intermediate domain we choose still being available 10 years on (you can’t even find the gnu social spec anywhere on the internet these days), but maybe if we could convince the w3 to host something simple, that might work.

(side note: I don’t understand the fediversity category here. That category seems to be focused on education around the existing fediverse platform, but this seems like a spec issue—i.e., it’s about an improvement to the existing platform)

1 Like