Thread resolving for remote statuses #24
Labels
expertise wanted
Extra expertise is needed for implementation
Comments
|
If the relation of A to B can be saved and B can be resolved through the federated API, then B and C and so on could be left to the consuming interface. Although, there may others be issues with resolving a thread specifically in resolving only one branch of a potentially large conversation tree. |
Gargron
added a commit
that referenced
this issue
Sep 20, 2016
This is a big one, so let me enumerate: Accounts as well as stream entry pages now contain Link headers that reference the Atom feed and Webfinger URL for the former and Atom entry for the latter. So you only need to HEAD those resources to get that information, no need to download and parse HTML <link>s. ProcessFeedService will now queue ThreadResolveWorker for each remote status that it cannot find otherwise. Furthermore, entries are now processed in reverse order (from bottom to top) in case a newer entry references a chronologically previous one. ThreadResolveWorker uses FetchRemoteStatusService to obtain a status and attach the child status it was queued for to it. FetchRemoteStatusService looks up the URL, first with a HEAD, tests if it's an Atom feed, in which case it processes it directly. Next for Link headers to the Atom feed, in which case that is fetched and processed. Lastly if it's HTML, it is checked for <link>s to the Atom feed, and if such is found, that is fetched and processed. The account for the status is derived from author/name attribute in the XML and the hostname in the URL (domain). FollowRemoteAccountService and ProcessFeedService are used. This means that potentially threads are resolved recursively until a dead-end is encountered, however it is performed asynchronously over background jobs, so it should be ok.
MitarashiDango
referenced
this issue
in MitarashiDango/mastodon
Sep 24, 2017
GenbuHase
pushed a commit
to GenbuHase/Yzu-don
that referenced
this issue
Feb 3, 2018
Sylvhem
pushed a commit
to Sylvhem/mastodon
that referenced
this issue
Mar 18, 2018
Mise à jour du thème personnalisé
chendo
added a commit
to assemblyfour/switter
that referenced
this issue
May 28, 2018
Auto sensitive statuses
YaQ00
pushed a commit
to YaQ00/mastodon
that referenced
this issue
Jan 3, 2019
…tory-to-blue-in-new-version-rb ソースコードの URL を blue に変更しました
rinsuki
pushed a commit
to rinsuki/mastodon
that referenced
this issue
Nov 20, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In
ProcessFeedService, if a remote status we want to save (A) is a response to another status (B), then we try to look up a local copy of B. If it fails, no reply-to information is saved.It's up for debate if the method should then try to somehow fetch the B status. The potential problem with that approach would be that B is a reply to status C, etc etc indefinitely, which would force the Mastodon service to crawl the entire fediverse. That may not be wise.
The text was updated successfully, but these errors were encountered: