Nested threads

[FedericoCeratto]

Thank you @ihabunek for the wonderful application. Would you consider supporting a nested thread view e.g. in the picture in https://en.wikipedia.org/wiki/Conversation_threading ?

[ihabunek]

I'm not opposed to the idea, but don't have a lot of free time to work on toot these days. Patches welcome. :)

[edent]

I've made a client which can display threads. That's all it can do, mind you. Nothing else.

Python code is at https://codeberg.org/edent/Mastodon_Tools

Is that the sort of thing you were looking for? I'm not sure if I have to skill to add a patch - but I can give it a go if you like?

[osresearch]

I'd love to see a tree-based browser for mastodon threads, possibly based on the minimal one from classic news readers like trn. These don't take up much space and allow quick navigation through the thread, as well as single key commands to say "I'm done with this branch, mark everything under it as read'.

[danschwarz]

@edent , this is your site? Nice. You've done a lot more research than I have on this, so let me pick your brain a bit?

I have a question about how implementing a tree view would work given Mastodon's rate-limits. Per your site, you have to do 2 context queries in order to get the full context for a given status: First, to get the oldest ancestor of the status, and second, to get the full tree of descendants of that ancestor. So, at a minimum, we're looking at:

1. One* query to get 40 statuses (*actually may be > 1 due to paging?)
2. 80 queries to get the full tree for each of those statuses

That's fine... but when a person browses the next 40, and then the next 40 after that, we might be bumping up against the 300 queries per 5 minute limit from a given account or given IP address.

Perhaps we could halve the number of context queries required by doing one context query per status, just enough to know if a status is standalone or part of a thread. Then we display a [+] symbol after any status that has a thread, and defer showing the thread until the user requests it by clicking or pressing '+'

The other question I have is about screen real estate. Right now we do not display any status contents on the left side pane, just the status date, author's account and a few other symbols. Displaying a tree like you have above might require a full-width pane. Any suggestions on what a simplified tree view could look like, given the screen constraints?