Tusky

Tusky copied to clipboard

A well-known limitation of the way Mastodon does federation is that opening a (local caching of a) remote post will not show the full thread, but only the messages that got sent to the local server via federation (or because posted by local users).

On the PWA, this can be worked around by opening the original post (in a separate page) to view (at least the public part of) the full thread. However, this is extremely clumsy, and if any kind of interaction is desired with any of the remote thread posts, the user has to copy the links to one's own instance and interact there. This is extremely user-unfriendly and is the subject of mastodon/mastodon#22674 and obviously related to mastodon/mastodon#34 and mastodon/mastodon#21571 among others.

I have gone through the (closed) Tusky issues #3182 and especially #2539 and I understand the objection to a more general “load data from remote servers”, but I would propose here something more restricted, aimed specifically at individual threads, and only done “under user supervision”. A similar issue is also being discussed for IceApp and is apparently also featured in other clients.

The idea would be to allow in-app a workflow similar to the one possible with the PWA, without having to go through the (Android) web browser. At the user request, the (publicly visible part of) the remote thread is loaded, allowing the user to see all (publicly visible) comments. If the user interacts with any of the (remote) posts (open/fav/boost/comment), then the specific comment is first pulled to the local server (as it would be if the link was pasted in the search bar) and interaction is done locally as usual. In this “remote thread” view it may even be requested that the user first opens a specific toot (which imports it) before being able to like or boost or comment on it.

---

• Tusky Version: 21.0

• Android Version: no applicable

• Android Device: not applicable

• Mastodon instance (if applicable): not applicable

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

This isn't significantly different from #2539 in my view. (Yes, I read the description.)

It does fall within the same general context, yes, but it's much more focused in scope, and I do believe that it can be implemented in a way that isolates the possible threats, providing a separate browsing context (remote thread), requiring manual intervention to be opened, and isolating interaction by restricting it to imported content only. But of course if the developers see this as a way for the more general “load remote content” idea to worm itself in, I can understand why they'd rather close the issue 8-)

it seems like a good idea as long we implement something we can fine tune it later. I really want to share mastodon with my non technical friends but we really need to find practical solutions to these problems and try to emulate as much as possible systems that do currently work

This, all along with the ability to entirely load public posts directly from a remote profile (vs "just" displaying the posts by some user that our instance has seen) still is a feature direly missing in Tusky compared to Fedilab...