Replies (52)
I wanted to create this view on Amethyst for so long now.. I just never found a good way to integrate into our current flow...
Check out the mobile version, it's not bad:

Is it like showing latest position( notes) of a group (of people) on diverse threads ?
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.
Mmh.. yes.
Try it :)
Feed filters that are set & saved in the main menu & a long press on "new threads" to collapse & filter might be nice? It might be cool if it which view was chosen was remembered between sessions, too.
I like this. It's intuitive & less distracting.
this is nice. good one!
This is amazing, it's all I always wanted.
Some issues:
- the settings are not persisted over sessions.
- the time limits could be more flexible, for example when fetching some relay feeds like wss://relays.land/spatianostra I get too few notes because of the hard limits on timestamps even though the relay has a very small note frequency.
- I don't know if this a Jumble bug that went unnoticed before because there was so little information on screen and now there is much more, but lots of profile metadata are failing to load:

Oh, it also excludes the "replies" feed? Doesn't show any replies at all? Would be nice to capture replies in the groupings too, optionally.
cool
This is 10/10
Persisted settings are in the roadmap, I need to study how Jumble save them for Filters and replicate it.
What kind of flexibility do you need? An open field to specify the number of days? I was also thinking about an "Infinite" option, where you can simply scroll down and load more content; in this case the total count should be predefined, for example to 24h.
I also noticed some problems on loading related to profiles' loading, I need to check.
Yes, the replies tab currently is deliberately hidden.
I can test an option that include the replies; since users are less inhibited when responding, I can't imagine what the final result might be.
Happy to see that you are as amazed as I was.
Nice
Great idea, I really liked it. Some suggestions:
1- Add an option on users profile menu to prioritize showing some users on top of the feed. These profiles could have some signal on feed indicating that they are "important".
2- If I choose 24 hous and the user have posted like 8 notes, when I click on 8, should show only the 8 notes or show the 8 notes as unread. Would be great to have an option to mark all as read, so this user on feed will be hidden until the user write a new note.
cc
@Cody
Ha ha, damn. You included reposts. Brutal. 😂
Let no good deed go unpunished. 😂
Great ideas.
And I think it's time to have custom feeds instead of this grouped thing that works like a filter. So we could create a new feed for grouped one with custom options and that doesn't disappear when we refresh the page, something like what Iris client does.

* doesn't reset when we refresh the page,
We first need to address the performance issue, right now this mode becomes very laggy when browsing relays with lots of content or when a longer time limit is set. Since it loads all notes within the time window, it can even trigger the relay’s rate limiting. I think we may need to remove the time limit and instead load a few hundred notes at a time and group them.
You should add trimmed content as a single line in compact mode — that would make the UX perfect. Congrats.
I mean a single line like this:
You can manage content types using the filter.
1. Favorite/sticky users is an interesting idea; Jumble already has public/encrypted mute lists, so it should be pretty easy to implement.
2. I was already thinking about a read status, but the implementation is a little trickier, you should save a timestamp for every follows.
This is a completely different topic. I also want lists (kind 30000).
Nice idea, thanks!
Time is the essential factor, tho. It's a time-span group, rather than a continuous timeline.
Just query them all in parallel and populate the map, as the results come in, with a 30-second timeout.
And have most kinds deselected, by default. Limit it to kind 1, with a "see all results" toggle.
Most people who post infrequently, use kind 1.
Would blow up the map. 😂
But, yeah, some people only reply, so you won't see them, otherwise.
Might want to make that an either/or fetch.
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.
I also thought this initially, but actually the time-span group is browsed in sequential chunks, so we can lazy loading them.
The only cons of this i approach seems that you cannot have the real total count for every user of all the published events.
Or something like that.
@Vitor Pamplona 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.
Wait, I'm confused. I thought you were fetching all follows from last X hours into a map in cache and displaying that, with lazy-loading in the rendering step, when someone clicks on an entry.
How does this work?
It's like that, but for long ranges, e.g. 5-30 days, I actually can load only the events necessary to fill the viewport and permit some scrolling. So I have to query all follows, but for a limited time-span, and then load more in chunks.
An AUTH aggregator like aggr.nostr.land really shines with this view
@semisol as you can deliver big data fast without triggering rate-limiting.
This actually helps frequent posters, too, as you can filter them out, temporarily, instead of muting them. Even if you only used this view, they'd reappear during times when they were quieter.
You can probably use this type in blogs, wikis, git that don't have replies
Ah, okay. I see.
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.
According to nostr.band’s stats, there were 20,670,324 kind 1 events in the past 24 hours.
But what are the chances that they all came from someone's followers?
This feature isn’t limited to the following feed.
Ah, I oversaw that. Thought it was for following. 🤔
It would work well on TheForest 🌲, but if you did it on band, it'd be a bunch of garbage.
Yeah, for now TheForest should be fine. But once it grows bigger, problems might show up.
Great idea! Trying it now
Thanks for getting back to me! I’m based in Miami, Florida. Where are you located?