Cool! Nice work. Will give it a try this weekend 👀

Great news!

How will your UI display comments like a chatroom when they are deeply nested?

Simple: there is no nesting :) it's a flat chain ordered by date. It's a design choice by zulip, not necessarily better in all cases, but is driven by different design decisions: discussions are expected to be about converging to something, so everyone is expected to read everything in a thread. If the subject diverges, it is expected to move to another thread. So instead of branches there is a set of topics, and you can mute some if you want to

So we have the basic architecture already there and it wouldn't be much work to provide what you need.

Indeed there is the architecture, it should be feasible. I might join and even have a go at it at some point (so I can add the before/after haha)

Thanks for the pointers !

That is an interesting idea. How will your UI display comments like a chatroom when they are deeply nested? As in, a reply to a reply to a reply to a reply? I think you're going to have a difficult time with that.

Adding an endpoint to retrieve posts and comments is pretty straightforward, the interesting part is the realtime updates.

PieFed is using SSE in a limited way, to tell the frontend about new notifications and new private messages. The frontend makes a GET request to retrieve the content and then updates the UI. The backend code for this. The frontend code.

This would need to be extended to send events for all new content, not just notifications and PMs.

So we have the basic architecture already there and it wouldn't be much work to provide what you need. I have a lot of other priorities to deal with but if you engage with others in our matrix or zulip you might find someone wants to pick this up. Or make a codeberg issue.

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 !

Thats like sharkey or akkoma :)

That can work!

If you do another emoji it'll replace your first one.

Because I didn't pay enough attention to the other post with all the updates to really understand the details of how emojis worked (specifically where they go), I just left a rather strange emoji.... Is there a way to remove this? Future update maybe? I accept my mistake but this seems like a good option.

Also adding :catjam: might be a good idea—it seems to be the ruling emoji of the fediverse.

Edit: I might have just missed it on account of the disco theme.

Upvotes aren't really controversial though. One assumes if you give a thumbs up or a :100: that it counts as an upvote in itself, which is fine. But many other reacts may have more abstract uses.

Except that reactions count as upvotes, so I don't think it'd actually be a good way to express disapproval without downvoting.

Interesting. It shows up, but just as the shortcode:

@rimu@piefed.social - not sure what the json looks like coming from mitra, but at least in the short term it might make sense to just have piefed interpret emoji it doesn't understand as an upvote (like it had been doing up to now) so that it doesn't break the UI like this.

I would prefer it not downvote. I don’t downvote content but i’ll give someone a thumbsdown if they’re being a turd.

I think there can be only one reaction. I added one, clicked another, and the previous one disappeared. After adding it back the second one's number dropped

@rimu I sent two reactions, one unicode and one with a custom emoji. The unicode one worked as expected, but the second one with :catjam: is not rendered properly. Also it seems to have replaced the unicode reaction.

Yeah, i think it would be even more confusing if certain emojis counted as downvotes.

If you do add it to work like that, you'd need to make it abundantly clear that a thumbs-down is a downvote. Or people will accidently downvote without meaning to.

I don't think it should work like that. It'd be a good way to express disapproval without downvoting, which is desirably used for spam/off-topic/hateful content (as it is mostly used on the fediverse).

Currently, yes. I'll see how this plays out with people using it before adding special cases for some emoji. There's no technical reason why not to make it downvote...

I'm holding back on it because downvotes aren't supposed to be "I don't like this" or "this makes me feel sad" like an emoji is.

It may turn out that overloading votes like this is bad. But I hope it works because choosing an emoji is already lots of clicks so I'd like to avoid a extra click for upvoting.

So if you give an emoji reaction thumbs-down 👎, it will count as a like?

Great addition !

Great!

Oops, forgot to add an endpoint for voting on a poll. Added one now!

POST api/alpha/post/poll_vote

Great!

NB POST /api/alpha/upload/user_image is for profile photos and does not count towards their quota.