PrivacyDevel/nitter

with_replies also fetching people who replied to tweets

Closed this issue · 6 comments

Not sure if this is specific to this fork, or Nitter in general, but it only occurs when on the privacydev.net instance.

When using the /with_replies page, sometimes people who replied to the user in question get presented alongside that user's own replies, retweets, and normal tweets. This also shows up in the RSS feeds of said page, leading to an RSS feed full of random people. This is not desirable.

This may have been introduced in graphql-missing-threads-bug-fix / 1634ffd.
ping zedeus#885

zedeus commented

Found an example here:
image

image

image

image

It's probably caused by the automatic threading Nitter performs, not sure how it should work here.

@zedeus would it be possible to disable threading for RSS feeds?

@zedeus would it be possible to disable threading for RSS feeds?

This is the solution.

I noticed that these two instances are not affected by the bug described by roryyamm:
https://nitter.caioalonso.com/MarkHamill/with_replies/rss
https://nitter.privacytools.io/MarkHamill/with_replies/rss

What do these two instances have in common? They do not show threading in with_replies, except when the user replies to themselves.

I made a small list of instances that are affected by the bug in this post. (The instance nitter.privacydev.net is one of several affected.) What do all of those instances have in common? They all show threading in with_replies.

So, disabling threading appears to be the correct solution.

In that same post, I also made a small list of instances that are not affected by the bug but whose with_replies/rss feed is completely broken by not showing any replies at all. At first, I thought it was related to the bug, but after reading this thread and learning that the problem is caused by threading, maybe it is not related after all.

zedeus commented

It's broken because they don't use the new-ish GraphQL API that remotely up-to-date Nitter instances use. Disabling threading is not a solution, it's just a temporary workaround. A fix would be to adjust the threading to handle this new Twitter behavior.

This issue seems to have been solved: zedeus#893 (comment)