The “API” this feature uses isn’t (wasn’t?) documented anywhere. After you enter your username@domain, it tries to resolve it using webfinger. Then, it looks for the object containing "rel": "http://ostatus.org/schema/1.0/subscribe" in the links array in the webfinger response. This object must also contain a URI template in template field, with {uri} substring to be replaced with the object URI to be interacted with. After all this is done, the user is redirected to that URI, where their home instance shows its own UI to interact with the object.
How does the home instance know what kind of interaction the user has requested? Sure I can get that from the referrer, but this feels like an unreliable dirty hack. Is there a better way? Mastodon simply opens the remote post, right in that popup, regardless of what you clicked previously. You click a large button that says “proceed to favorite” and are shown the post again and you have to click the star again — this kind of UX is below the bar I’ve set for myself.
(is it okay that I keep posting my dumb questions about weird edge cases on this forum?)
While I can’t help you with the answer, I think this is more than okay: finding these, and maybe improving on legacy hacks that crept in (if that’s the case here), will make it ever easier for the next AP implementer that comes afterwards.
Mastodon initially reused server-to-server protocol from GNU Social. Unfortunately, from a technical point of view…
In particular, “Remote follow” feature in Mastodon still looks (and I suspect is implemented) the same way as in GNU Social 10 years ago. And this exactly Remote follow feature doesn’t work reliably between Mastodon and Pleroma now, as I experienced a couple of weeks ago, trying to follow an actor of Pleroma instance from a Mastodon instance.
On the other hand, Pump.io ( https://github.com/pump-io/pump.io/blob/9dc4d06276cd628556427bf03d3d79d062824a7f/API.md ), created as a GNU Social successor by the developer of GNU Social in 2013 (and which is very close to ActivityPub…), allows e.g. “remote follow” transparently for a client app and its user. It doesn’t work there 100% smoothly also, as I noticed, but at least it doesn’t require manual steps like you described.
And another, more general note on Pump.io role in ActivityPub development. @andstatus app that I’m developing supports Pump.io since 2013. ActivityPub support is being added since last year only. And you know, almost every feature that I add to ActivityPub in the client app, I add (or improve) and at least check and compare with pump.io. Simply because this is live social network, based on ActivityStreams, that has working instances and that actually works.
The scope of this is the web and only the web. Server-side-rendered pages, not web apps even. There’s no “client app” involved, this interaction is between instance servers.
I’ve tested the way other popular implementations handle this.
Mastodon allows both following and interacting with posts, as discussed above.
Pleroma only allows remote following. Action icons in posts are displayed but don’t do anything unless you’re logged in on that instance.
Misskey doesn’t support any such interactions at all.
Friendica is weird. There is a form for you to put your username@domain in to follow someone remotely, but it doesn’t work for me. It does work for Mastodon. There are no reply/like/share buttons on posts unless you log in.
Since Mastodon is the only implementation to support this for post interactions, I suggest to do the following:
Use the referrer to detect the kind of interaction the user requested when it’s originated from a Mastodon instance.
Invent a better and 100% reliable way of communicating that across instances going forward.
Add an additional parameter to the existing URI template?
Also add a new rel to links to maintain perfect backwards compatibility?
Does this need to be extensible? For example, do we want to be able to perform arbitrary activities remotely, passing them in as JSON objects? The user would of course see the activity on their home instance and confirm sending it.
I understood you, I think
I only told you the “interaction” story from a Client app’s User point of view. But when I sent “follow that Actor” command to my account’s server, the server interacted with a server of that “remote actor”. - And this was done without any need in opening web UI!
“Web” notion is orthogonal to “Client” notion in terms of ActivityPub.
So “Server-side-rendered pages” may be a part of a Client or a Server in terms of ActivityPub.
I’m telling that Client activity, e.g. “Follow”, should NOT require additional User’s involvement (neither via “Web” nor via other UI) no matter which Server hosts another Actor’s data.
Confusion in this thread comes from an approach, when Web UI of a Social network (conceptually - a kind of a Client) is being developed as a part of a Server and interacts with its Server in a undocumented way, so developers may even forget that this IS a Client…
Well. We have real-world problems for which we need real-world concrete solutions. Theoretical concepts are nice but they won’t do anything to displace corporate-controlled social media, neither would they improve the UX of real fediverse projects.
Whether or not theoretical concepts can help Open Source / Free software development? - Good topic. Seriously.
Maybe we should start one at this site?!
If I understand correctly – and I really doubt I do – the question is whether peer Federating servers using S2S ActivityPub could also leverage a C2S ActivityPub relationship in order to do something like:
User finds a user they want to follow on the Fediverse residing on a federating peer’s server, via a C2S-enabled browser, app, etc
User clicks “follow” on that page.
Federating peer’s server tells the user’s AP Client enough information to construct a “Follow”
User’s AP Client sends their server the C2S “Follow”
User’s server does the “S” in C2S and S2S ActivityPub protocol to send the “Follow” to the federating peer’s server
User gets notified of the result
That would be a 1-click, 1 new follow. Repeat for “like” and other federating actions.
This would definitely require a community convention and modification of browsers / apps to be the “C” in AP C2S, and convince existing AP S2S software implementations to support AP C2S, and then adopt this specific use case.
