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:
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 nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
- 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 https://grouped-notes.dtonon.com
And give back any feedback, thanks!
nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl should I open a PR? :)
Very interesting concept! I really like the compact mode. After trying it out briefly, I have two questions:
- When I’m browsing a specific relay and click on “X other notes from the same user”, are those notes limited to the current relay?
- How many notes are fetched at once? I noticed some lag when using it in normal mode, so I’m wondering if there’s room for optimization. The feature is super cool and useful, but it does seem to require quite a lot of resources.
I'd do it in two rounds. Open up streams for 3 seconds into a map. Aggregate by npub, count how many notes they published, filter out those over X times, refetch the rest for the remainder, with a 10-second timeout.
Or something like that. nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z this optimization needs math.
Ideas?
Or do the second fetch with a 100-event limit.
Since you've already filtered-out the frequent-posters, you can hard-limit the remainder without missing anything from anyone.
For most relays this approach works fine, but for some of the larger ones it’s a serious issue. For example, trying to aggregate all events from relay.damus.io over 24 hours. Even with smaller relays, if a user sets a 30-day time limit, you’ll run into the same performance and bandwidth problems.
