people are loving #jumble - nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl 's new relay-oriented client, and for me it is two reasons
- relays have the ability to filter out spam better than clients, because they can be paid, or private, or be only accessed by the list of users prescribed by some mechanism by the relay operator (like #realy and UTXO's WoT relays)
- the application is extremely simple, and hopefully it stays that way and the author(s) are not fooled into the hype-powered fundnig mechanism that has polluted most other clients with five billion features that nobody needs - nostrudel is an example of this, it is useful, but the more things you roll into one the less likely that any of it works properly
a lot of people are going to switch to #jumble because of these two reasons, and the rest of the client devs would do well to pay attention to the reasons
The two only features missing are:
- sharing relay sets among contacts
- outbox model for the following feed (arguably there should not be a following feed at all, but if you have one it must support outbox otherwise it's an attack on Nostr)
nostr:npub1vxd0dfst8ljvwva2egrpc53ve8ru78v8aaxfpravchkexmfmmu3sqnrs50 disagrees though, he thinks Jumble needs all the features in the world.
That's exactly what I'm planning next. First, I'll remove relay sets and put all saved relays into a single set to simplify relay management and allow viewing others' saved relays. After that, I'll focus on improving the following feed.
Do you have any suggestions for the following feed? Most people still use a few large relays for writing, so it seems difficult to avoid sending requests with a large number of pubkeys to some relays 🤔
maybe what would help is if you kept a census of the amount of each npub events are found as a time series, like, broken into day segments or something, then you could prioritise fetching the ones that most frequently post a lot
this is an obvious subject matter for a "DVM" - gonna pencil this one into my mental notes for possible index and search functions - a time series data of events found in the index so you can prioritise the most likely stuff to have new content is an easy solution to make smoother on the back end too
If someone doesn't post frequently, their posts might be harder for others to discover with this strategy 🤔
it's just for getting the majority of the new stuff on the feed, you could always sort it by "first seen" and put the rarer stuff at the top
I don't see a problem problem with sending requests with a large number of pubkeys to the big relays if the people are on those big relays, as long as you're fetching the other pubkeys from the other small relays they publish to.
One low hanging fruit is the ability to provide njump links to notes seen there.
