Hello there !
I'm working on a new kind of interface. I'm very fond of how Zulip works: discussions are all part of a specific Topic (which in piefed would be a Post and its Comments, not a piefed's Topic). A topic has a beginning and usually has an end. Topics are all part of Channels (piefed equivalent: community). It's a pretty standard way of modeling data, but the innovation is in the interface: everything can be merged in a combined view with every comment and every post in a single "timeline", giving you affordances of a chat. Using chat affordances makes discussion and contribution easier, and using a combined view allows you to very quickly follow each topic you are interested in and filter out the topics or even channels you're not that interested with. Of course with the possibility to see all of them specifically.
It's hard to describe in words (they have their own explanation for more details), much easier to try it out if possible. Here are two screenshots showing how it can look like: the first shows a combined view of posts and comments in this community, and the second one shows a post and its comments


The current API pushes towards a certain type of interfaces: the hierarchical "view communities" -> "view posts in a community" -> "view post and comments". Not a bad thing in itself, but it's not the most straightforward for my use case:
- to me, posts and comments are really the same but they're in two different endpoints. I need to do some logic to "merge" them
- I would like to have the new posts/comments as they arrive, so some kind of realtime-ish stuff. Maybe polling could be enough if the API could return 304. Maybe long-polling could work (the server doesn't respond yet, but waits for actually new content to arrive to return the response)
- But for long-polling to work there needs to be some kind of "since" or "after" parameter. As a more general point, "after"/"before" is much much better than offset-based pagination: pagination isn't really useful (no one wants to go to page 7, we really want to go to the next or previous page, or around a specific point in time) and is bad for the database (with pagination, all items need to be fetched from disk and sorted before dropping them; with a "before"/"after" the index directly says which items will be fetched. More details in this nice page )
I'm not expecting you to change the API just for me, this is just to inform about what might help me, but I think a realtime-ish api and a before/after param can also help others.
And thank you for the very nice work !