Return threads in a linear list

[mikuhl-dev]

I feel it is a bit hacky the way post threads are returned in a deeply nested object, which is causing problems with huge threads that are being made. Perhaps return threads in a linear list, and allowing for a certain few posts of context, then the actual requested post, and then replies and replies of replies (to a certain extent.) Each object could have a boolean set/unset if it is the tail of a thread, to draw the line underneath avatars you usually see. An algorithm field could be added to to the procedure to allow different ways for the PDS to choose which threads to show, but perhaps by default prioritizing threads that contain the OP, and otherwise the most likes.

For example, without context, it is nearly impossible to determine which post is replying to which if it does not contain the direct line to the next, and often the actual post it is replying to is multiple posts above it. This is why only one thread for each reply should be shown.

[DavidBuchanan314]

Nesting depth is now mitigated by #1062, although I would also prefer a flat list layout, or a map indexed by CID. Each entry can still reference replies and parent by CID, allowing a client to reconstruct the tree hierarchy if needed.