Represent endpoint for remote interaction

ActivityPub
1

Problematic

Users discover content publicly accessible (such as a public message or video…) on remote instances and wish to interact with on their own instance.

Solutions

The “paste URL way”

Easiest (and probably earliest) solution is to copy the URL of the content and paste it in the search bar.
AFAIK, Mastodon, Pleroma and PeerTube support this, but very probably many more.

The ostatus way

  • Mastodon also supports asking your federated ID profile@instance.tld when you try to interact with the content and redirecting to your own instance depending on your input. It uses the same endpoint as for following users, taken from ostatus http://ostatus.org/schema/1.0/subscribe and available through WebFinger. The path is /authorize_interaction?acct={uri}.
  • PeerTube does the same for comments under videos on other instances, but doesn’t support the redirection for interacting itself.
  • Pleroma supports the redirection to the same endpoint for interaction, but doesn’t suggest interacting with it’s own public content. The path is /ostatus_subscribe?acct={uri}.

Note : This solution can be improved with a browser addon such as https://github.com/rugk/mastodon-simplified-federation

The protocol handlers way

Even though it seems a good fit, there’s not much support for it, so…

Remarks

The “paste URL in search field” solution seems commonly used but users usually don’t know about and AFAIK no software makes any effort in this direction to let users know that you can put URLs in their search fields, so it’s more a hack than anything else.

As of now, the second solution seems more appropriate (even though quite laborious). What bothers me though, is having to use the same endpoint to remote follow someone and interact with some content.
I think it would be appropriate to have the equivalent of http://ostatus.org/schema/1.0/subscribe for interactions (not sure whether it should use the ostatus namespace) and have it as well exposed through Webfinger.

Please tell me what you think about this and what I’ve probably missed on the subject.

Additional Links

Issues at Pleroma: https://git.pleroma.social/pleroma/pleroma-meta/issues/1 https://git.pleroma.social/pleroma/pleroma/issues/978
Issue at Pixelfed https://github.com/pixelfed/pixelfed/issues/1276

P.S: about sharing external content

It’s not really the same thing, but let’s note that Diaspora* uses the centralized service https://share.diasporafoundation.org to provide share buttons that ask for your federated ID (and store it locally afterwards) to redirect you to the content on your instance. But that’s for external content, not for internal one.
There’s https://aly-ve.github.io/Mastodon-share-button/ that kinda does the same for Mastodon.

2

Friendica does 1 and 2 as well. And I think the OStatus endpoint in webfinger is a good solution.

3

What I wanted to discuss is the fact that this OStatus endpoint was indended for account subscription, not for providing a way to interact with content, as Mastodon and other have started to do.

The user’s XRD document MAY have an additional link template with Rel equal to http://ostatus.org/schema/1.0/subscribe to indicate the endpoint to use for initiating a subscription on the user’s subscription server. The template should take a single argument, uri, for the account to subscribe to.

4

I have a clear view on this since in the early stages of @redaktor.me I did demos on protocol handlers e.g. in 2016 : https://indieweb.org/2016/Brighton/Demos

It would be THE solution !
There is a single reason WHY they are not much supported :
Chrome and Edge treat them like shit.
I raised many issues there but I was unheard.

Chrome shows a nearly invisible icon for the user consent in the right of the url bar and does not allow to deregister handlers.
Edge is, well Edge …

5

Follow-up here:

1 Like