A new experimental release of "grouped notes" has been deployed at Key feature: a read status is displayed for both the last note and all notes, so you can easily keep track of what you've already seen and what's new; in addition the counter is reset when a profile has been marked as read and new notes arrive. Other additions: - A new option to include replies has been added - Only the content in the selected timeframe is shown when checking "other notes from the same user" - Group notes mode and its settings persist across reloads - Compact mode is what offers a radical new experience, so now it is the default Thanks @fiatjaf, @idsera & others for the suggestions and feedback.
daniele's avatar daniele
One year ago I proposed a "stacked users" design/UX (note mentioned at the bottom of this note). It was appreciated but I didn't see any real implementation of it, so I finally decided to build it on my own, but instead of creating yet another nostr client, I picked Jumble and added it as a new "Grouped notes" mode: image Main features: - Pick a custom timeframe (default 24 hours) - Filter out users that posted more than X notes; useful to surface users that post rarely - Switch to compact mode to have a RSS-like feeling, to the delight of @fiatjaf - See how many other notes the author published in the selected timeframe - Compatible with the built-in filters - Works also when browsing specific relays I've been using this mode in the last few days, and I really like it, especially the compact version, since it offers a clean interface without any doom scrolling temptation. It also is letting me discover interesting content and users I forgot I followed that, for a long time, remauned hidden behind the more active ones on my list. Try it yourself at And give back any feedback, thanks! @Cody should I open a PR? :) View quoted note →
View quoted note →

Replies (22)

I know that's how it is in Jumble, but I deliberately changed it because I don't find it useful at all. Why should I see the main notes under “replies”?
I will reply on github as soon I will reflect on the proposal. But I think your idea is largely unrelated with the "grouped notes" feature, where you want to explicitly track users's notes and optionally replies, so replies should be quickly and clearly accessible.
I understand you like it, but putting something that is NOT a reply under "replies" is weird :D Other clients use the label "Conversations", this make more sense.
The Replies option is required, otherwise users who only post replies never appear in the feed. On the other hand is useful to filter them if you want to see only new content.
I'm going to open a PR with what I' be done (so no performance updates). I don't see many performances issues; if we want to be conservative we can simplify limit the timeframe. @fiatjaf what is your feedback about the performances.
I don’t think aggregating by timeframe would work well. For example, when browsing large relays like relay.damus.io, even aggregating notes from just 24 hours could be very difficult and would definitely hit the relay’s rate limits. On the other hand, for smaller relays, there might be so few notes in 24 hours that aggregation wouldn’t even be necessary. I’d prefer to aggregate by count instead — for example, every 500 or 1000 notes.
I read you already advanced this proposal in the past, but it doesn't accomplish the goal of surfacing profiles that post rarely, it's a completely different view. About browsing relays, that is a secondary feature compared to browsing the following list with that goal in mind, it could be fixed adding a sufficient delay. The only different approach, that I think is the correct one, is to have a local DB caching data for the last X days.
If this feature is mainly intended for the following feed, then we should consider hiding the option in other feeds. I’m not sure if it’s just me, but when I enable grouping, I often can’t scroll through the list, and the mouse cursor turns into a loading icon. I agree that the only real solution is to use a caching database. However, I’m not sure if we should add one to Jumble, since many clients have run into various issues caused by improper cache handling.
The feature can be applied to relays to, it's a valid use case. Never had scrolling problems! Simply the full loading can be slow with long timeframes (you see the loading at the bottom). Maybe there is a problem, I would be happy if you can investigate the code. Which kind of cache issues?
The slow loading is expected, it’s also slow when group mode is off. I’m not sure what cache issues there might be. It’s just that some Nostr clients I’ve used before had problems that seemed related to caching, like failing to load new events.