GeopJr / Tuba

Browse the Fediverse
https://tuba.geopjr.dev/
GNU General Public License v3.0
506 stars 55 forks source link

[Request]: Fetch remote interactions (missing favorites, boosts, replies) #953

Open Saltane opened 1 month ago

Saltane commented 1 month ago

Describe the request

Fediplatforms, Mastodon in particular, have this issue when posts from remote instances donʼt have all the interactions fetched by instance. This includes favorites, boosts, and, importantly, replies. This issue is most prominent on small instances. This leads to situations where people answer already answered posts, or miss important discussions. In practice, it looks like this: On the image below, a post from EUREA shows 3 boosts and none favs. Image from web-client to confirm Tuba is not to blame. Tuba, post viewed from my home instance Web, post viewed from my home instance And below is the same post viewed from original server. Notice 73 boosts and 99 favs.

Web, post viewed from original instance

Since vanilla Mastodon does not yet provide native solution to this, itʼs up to each client to resolve the issue themselves. And there are couple practical examples of how it can be done.

  1. Substitoot browser extension — only works with Mastodon as a homeserver, but is able to fetch interactions from some other platforms (Akkoma, Pleroma, etc.). When opening a post, it spends some time fetching missing interactions and seemlessly injects retrieved counts and replies into post viewed. Fetched replies can be interacted with and be fetched to home instance on demand.
  2. Mammoth iOS client — fetches missing interactions out of the box, notice counts on the screenshot below. Web, post viewed from original instance

That all said, the request boils down to adding remote interactions fetcher to Tuba.

Implementation Details

GeopJr commented 1 month ago

Thanks for the suggestion!

Personally, I'm against this.

  1. It requires doing out-of-instance requests. I've been trying to avoid doing any out-of-instance requests without user consent for privacy reasons. For example, a malicious entity, me@music.hater wants to get your IP address. They could send a post just to your single-user instance, you@music.lover and Tuba (or another client/extension) would make some predictable requests to music.hater, allowing them to single you out. Obviously, this is a very surface-level example, it gets more complicated when you consider activist/whistleblower instances/accounts.
  2. It's instance spammy. There's no 'centralized' way to do this, so every Tuba user that opens a post will spam that instance with random requests. Many instances (especially single-user ones) run on very low-spec servers, getting 1-10k requests when users of specific clients open your posts, could go as far as DDoSing you.

(Not in this feature request but related, quotes. Tuba supports quotes when the instance provides them, but won't randomly manually fetch posts linked on instances that do not support quotes. It's spammy on the user's own instance.)

I'll side with preventing spam on volunteer-running instances over getting the total amount of interactions of posts.

That's just where I'm sitting, I'm open to more opinions on this though!