Mastodon: Missing interface to interact with toots on other instances

[alerque]

When viewing a _profile_ on an instance other than your own, there is a follow back system that asks for your own instance and sends you off to take the follow action from the right host.

This sort of mechanism is missing from all other elements, most notably toots. There is no way to reply, boost, or favorite a toot you found on an instance other than your own. In my case I even arrived there browsing from my own instance.

1. One of my toots got favorited by somebody I didn''t know on another instance.
2. From my own instance's notifications I clicked on their name.
3. It loaded their profile in the sidebar, but incomplete because the instance had only observed a few very recent items.
4. I clicked through from the profile picture to the profile page on the remote instance.
5. With the complete user's timeline visible now I see toots I couldn't see from my instance.
6. I opened one of them.
7. _‹crickets›_ ... I couldn't do anything.

Consider what's visible at that point:

Because I'm not signed in on this instance, nothing is active. I can't reply, boost, favorite, or anything. Worse yet, there is no way to view this toot in my own instance. Nothing here gets me a place where this becomes interactive.

Something akin to the remote follow interface needs to be implemented for other actions when viewing anything on a remote instance such as reply, boost, mention, and favorite.

---

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[Shnoulle]

I have another linked idea :

1. Add a 'specified by url' toot/notice
2. Add a 'specified by url' favorite/like toot/notice

Then : you have always a solution, even if the other system are not mastodon or are an older installation of mastodon.

[wxcafe]

To be completely fair, there is a way to view this toot on your instance : if you paste the URL of the toot in the search bar of your instance, you'll see it there and will be able to interact with it

[alerque]

@wxcafe To be completely fair? That's completely unfair! As far as end user UX is concerned you might as well only make the buttons active if the user mumbles _abracadabra_ three times in the microphone while holding down the AnyKey. Not that the search technique shouldn't exist, but that does absolutely nothing to resolve the issue for an end user.

[Gargron]

There is a constraint: other instances do not know who you are. Remote follow UX solves this by making you enter your full ID to send you back to the right place. Given this constraint, what kind of UX do you see for this feature?

[wxcafe]

Personally I see that exact same UX. You click "Remote Boost", it asks you for your full ID, and you click boost on your instance.

[alerque]

@Gargron Ditto to what @wxcafe said. All remote actions will need to prompt the user for their ID. When browsing a site that isn't logged in this modal could ask for either login info to that instance or a remote ID. Once it knows who you want to be it passes the action along to your instance for verification. It can probably keep your full ID in a cookie for future remote actions as well.

I foresee the opportunity for phishing as a potential Achilles heel of this kind of federated action. 2FA should be pushed very strongly, even enforced by instance admins. Otherwise the chance of users falling pray to providing credentials to instances other than their own is going to be huge. There isn't much the remote-action interface here can do to stop that either, but a permanent warning in the modal prompting a user for their remote ID should probably be standard in the official Mastodon release. Obviously a malicious instance would suppress that, but if everybody else helps raise awareness...

[wxcafe]

Individual admins could change the theme of the "login for remote action" page, but apart from that yeah it would be pretty hard for users to detect phishing, good point. The cookie thing would be nice too, it's a bit frustrating having to type your username each time. I have no idea if that could work on remote instances, though.

[alerque]

@wxcafe The cookie would be able to track your preferred remote instance on any given remote instance, but would have to be bound to the domain so it wouldn't be a global thing. It would only help for sequential actions on the same remote instance.

[Gargron]

Duplicate of #916