Home | Notifications | New Note | Local | Federated | Search | Logout
Note Detail
Reply to @harblinger@wizard.casa
silverpill@silverpill@mitra.social (2026-07-15 04:28:16)
@harblinger So you need an API endpoint for getting latest replies for a bunch of threads at once?
Let's add it.
I am not against real time API but that would require much more work.
---Reply---
Harblinger@harblinger@wizard.casa (2026-07-26 18:52:59)
Got around to it, here's the "slop" proposal (actually pretty good until item 6 "not part of this proposal" which snuck in, can be ignored)
https://git.wizard.casa/nak/chan-fe/src/branch/main/docs/mitra-catalog-endpoint-proposal.md
Reply
---Replies---
silverpill@silverpill@mitra.social (2026-07-26 19:55:36)
@harblinger
It's not bad! Creating a sibling to get_direct_conversations is a good idea.
>2. What Mitra already has
>The missing piece is only that nothing orders conversations by activity, and nothing exposes them at public visibility.
This is correct. However, I think the results of get_direct_conversations can be ordered by activity (post.created_at). I made a quick test, the estimated cost of the query is exactly the same.
>3.1 A bump column on conversation
...So this shouldn't be necessary.
>Three details worth deciding deliberately:
>Reposts have no conversation_id
I've never seen an imageboard with reposts. I think only comments should bump threads.
>Only public activity should bump a public thread.
If the cost is not too high, we can bump threads on private comments too. get_direct_conversations already does that.
>3.2 The endpoint
I think /api/v1/conversations is a better prefix for the endpoint.
>root_status — the OP; this is the catalog card. The query already joins post AS root, it just doesn't return it today.
>last_status — newest activity, already produced by the lateral. Its id doubles as the max_id for the next page.
Returning whole Status is expensive. Unless you need to know everything about both root_status and last_status, I recommend returning a partial entity (e.g. only a title of the root).
>3.3 Optional: the same for group timelines
>Strictly a follow-up.
👍
This should be delayed until private groups are implemented.