Show decendants in conversation api

[ibrokemypie]

Summary

The /notes/conversation api currently just returns one array of the notes before the current note in the reply chain, ignoring the ones below.
This means clients cant see any replies TO a selected note.
It would be better to return two arrays, one that contains replies down the chain and one that contains replies up the chain.

Environment

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[tamaina]

Related to #2113

[syuilo]

How about notes/replies?

[mei23]

子のtreeを一度に再帰取得したいのだと思う

notes/conversation 親を再帰取得していく

3 <= 2 <= 1 <= START

notes/replies 子を取得する (距離1のみ)

START => a
      => b
      => c

こう ★

START => a => a2
      => b => b2
      => c

[ibrokemypie]

i guess you could do it in multiple response, though that would be a LOT of unessary overhead, having to make a new request for each reply in a thread
the only way to even make it slightly manageable is to limit it client side, eg only go one level down and only get for things that are on screen, however the logic for this would be annoying and get messy, and it would 100% be detrimental to the ux

[ibrokemypie]

Either way, this would allow solving #2113 and would be a major improvement to usability as currently it is impossible to view threads fully.

[Johann150]

Current Situation

Misskey Web UI calls /api/notes/children recursively for each note. However since #7979, only a limited depth is fetched and displayed in Misskey Web UI.

• advantage: simple to implement in both server and client
• disadvantage: bad performance due to communication overhead in client/server communication that is currently mitigated by limiting the depth which is fetched.
  • server has to deserialize multiple JSON request bodies instead of one, and in turn serialize multiple responses
  • client has to make many responses which can lead to network digestion

Misskeys unique ability of quote renotes creates a special situation in this case, when showing child notes: quotes can be children of two notes at once, child of the quoted note and child in form of a reply. See for example note E in this situation:

A
|- B
|  `- E (reply to B, quote of C)
|     `- F
`- C
   |- D
   `- E (reply to B, quote of C)
      `- F

This means that just using nested objects may duplicate data; as you can see in the example above this would not only duplicate E but also any quotes or responses to it like F. Depending on the depth chosen this could also be quite a lot of data.
Deeply nested JSON objects could also cause issues with some JSON implementations.

Proposed solution

The API endpoint in question returns a list of replies and the client has to sort them into a thread using the replyId field.

• Advantage: simple & non-recursive data structure in the API, probably easy to implement on the server.
• Disadvantage: Client code requires more complexity to sort the notes into threads.

The server load should not be made too high through this by still limiting the number of notes which may be fetched in one call. However I think this limit could be higher than the current one. This is necessary so this request does not become an easy target for DoS. (see also ActivityPub specification § B.3)