@onlinepersona@programming.dev Following groups on other sites works well. The current default theme doesn't do visual threading, but reply relationships are maintained and linked. QuickReply kind of quietly discourages direct replies to comments, though, so I imagine many users - especially those new to the bulletin board experience - may end up replying to OPs, especially without a threaded UI.

I'm sure there's nothing stopping someone from making a threaded theme, though.

@onlinepersona@programming.dev there is some active discussion around how to better represent federated communities. The current iteration of NodeBB will bring them in as regular user accounts that can be followed, and this is tested and working with Lemmy and PieFed, primarily.

@Kichae, two things:

1. You're right, and I've brought that up internally. It's difficult to justify the change in UX, but there may be a way to support both UX flows with the addition of a checkbox that adjusts toPid/inReplyTo. The downside of that is the whole point of the quick-reply box is to actively limit the number of visible controls

2. A threaded view is difficult because it is not scalable, at least with the way our current backend is built out. We load topics page by page, which means every page is loading in O(x*n) time¹, where x is the number of posts. If we wanted to load a threaded view, we'd have to query every single post and build the threaded relationship on-the-fly, since we don't maintain that in the backend, and that's... O(a lot more)²

There is a way we can approximate the threaded UI, but @baris and I haven't played around with it for a couple years...

¹ I am not well-versed in computer science so I may be wildly wrong about this
² very scientific, yes.

@julian Personally, I find the reply list -- and especially the new auto-quote back-references a more than sufficient solution, but then I don't think threaded discussions are a value-add to the bulletin board experience.

It's just not part of the expected UX, and kind of breaks the BB UX, which has always been built on the expectation of reverse-chronological posting. Not that I don't understand the utility, or someone having the preference. Threading is now ubiquitous on other social modals. It's become part of the design language of Web 2.0.

Some platforms that use threading now only load the first couple of levels of replies. I wonder if that's something that's currently possible via theme work, or if a plugin would be required, or even if work on core would be necessary. Or if some sort of popup modal that loads threads might be viable? Solutions that wouldn't require the threads to be pre-loaded.

@Kichae the workaround that @baris and I played around with (very) briefly involved the "x replies" expando button.

I think there were some rather simple adjustments made to load only one level at a time, and that was essentially the "threaded" view.

I don't remember the details any more, perhaps he does.

Yeah there is a config property config.showNestedReplies https://github.com/NodeBB/NodeBB/blob/master/public/src/client/topic/replies.js#L40, it is not exposed anywhere but a plugin can set this to true in filter:config.get and that would cause more than one level of replies to show up. However the posts all show up at the top level in chronological order, since core adds everything at the top level(tid:posts) and then adds it topid::replies if it is a reply to a specific post.

@baris could we theoretically load only top-level replies by:

• filtering tid::posts (expensive), or
• maintaining a separate zset (lighter)?

Filtering goes when you have a topic with 50k posts, and adding a new zset means adding 2 actually because there is sort by timestamp and sort by votes for topics.

I made a post about this a couple of days ago with an example, where I tried to post into a Lemmy community and it didn't arrive