Your relays don’t just matter based on who you follow. Here’s what else relay choice impacts
* your personal timeline (with replies)
* your event publish reach to your followers
* your inbound DMs
* your outbound DMs
* your notifications
* any global timeline
* event relay hints you reply to or view threads
And the right relays today are likely different in a week - at least for a number of reasons. The best relay to publish a specific event is different between events (a sent DM is different from a global feed note, different again a reply on a poorly replicated event).
Relay selection is a deceptively complex topic. Any overly simplistic autopilot is likely a step backwards for users experience.
Not necessarily.
Events can have optional relay hints. The sports themed relay rejects global messages and only allows certain root events (for desired channels).
Replies to a sports channel event seen by another user from another relay, should still be able to see the root event relay hint - which they can either use to query for events or use to publish their replies.
The content isn’t only on that one sports relay. Replication isn’t a problem. Other relays could white list channels themselves - like a subreddit. In my example the sports relay doesn’t allow kind1 events unless they are a reply for a whitelisted channel message.
Other relays can whitelist the same sports channels. Not a problem. However limiting what a relay stores when there is 5GB+ new Nostr events per day will become a problem for smaller relay operators. Selective relay storage will become a thing - either time to live or type of content or paid users only.
I can see how things could go wrong.
One issue is that today, relays are all generalists. There are no real specific topic/niche or relay tools/features to focus on hosting specific content.
A simple example could be a relay that hosts only a specific list of channel (maybe sports for example), all events not in one of those channels is rejected. Another example could be German or language specific only. Another example could be specific media types only.
Part of the issue is relays don’t know yet how they will be funded. The network is too small to carve out tiny niches today.
When relays are all generalist, the optimisation is event coverage, which can lead to silos and bubbles. A way to combat that is better content/people/topic discover tools.
Maybe just early Nostr maturity pains. Maybe a critical centralisation or bubble risk long term.
Sure. Could run locally.
What type of triggers and actions would you use?
If Nostr had a If-This-Then-That (ITTT) service, what would you use it for?
Watch lists, send an email, create a reminder, etc? What can’t we do today that should be easy?
👀 we may have a prototype coming that’s pretty kick ass.
Table size in Postgres with about a year of data. It likely includes indexes too, but didn’t explicitly check. Maybe 6-7Gb total - including some custom tables with extra refs for better queries.
I’m still experimenting. There are lots of ok ways to try do this, however few will consistently hit 95% plus - without adding 20+ relays (or more in future).
I’m currently streaming events from 80+ relays, so I can tag which events have been seen by which relays (without actively asking at present).
The current approach is to lookup who a pubkey follows, then get the most recent N events by them, and then process against which relays would be needed to get coverage across the following event set.
It’s got some recursion, so processing speed or pre-processing are considerations vs good enough.
My other approach is to multiplex and perhaps dynamically do this for clients. https://nostrgraph.net/relay
I’ll share updates on Nostr. It’s a little hard to publish a working algorithm since it’s data dependent.
Already 1,200+ Nostr pubkeys with banner images. 4-6k pubkeys posting each day (with a name set). Average of around 20 text events (kind 1/42) per minute throughout the day. Over 2k+ NIP-05 (my data may be missing newer). Using most data is kind 3 events for contact lists (around 900mb - however I haven’t pruned stale ones). Then text events. And then reactions.
#[0] I’ve been looking into the ‘best relays’ problem given a set of pubkeys to follow.
There will never be an exact solution as followers change, events broadcast or sync between relays indeterminately, etc - however I think we can effectively make use of the Minimal Set Cover Problem. A few different algorithms exist each with trade offs.
I’m also prototyping a custom algorithm that can work pretty well, but likely falls short with 75-90% event coverage.. but often that’s with 15 relays (for ~80 pubkeys) which isn’t ideal. Adding another 5 relays likely boosts that by another 10%. Client apps not retrying failed send posts could be impacting it too - with less replication.
Another factor I’ve ignored for now is inbound DMs, which could be on different relays again. And the relay auth NIP could make it harder to understand where DMs are being relayed to.. perhaps it’s a client space problem.
I’m waiting for more event ‘seen by relay’ data after a code update, so perhaps it will improve when my data is more complete.
I actually also want to try build a “pick your relays” UI, and then if you auth to a relay, it will only send you ones from relays you selected. Perhaps choice of broadcast too.
I’m chasing down a memory leak in rust (must be a dependency). Needs a few fixes before I’m happy.. but otherwise it was working decent before I had to break/rewrite some stuff.. so working to get it solid again.
Once it’s decent, happy to recommend it more or even add as option for client apps.
And another good example is users sharing client app mute/block filters. Kind of like ad block list for events. It likely needs a filter that supports content field regex tho.
I think this added logic can sit nicely on top of the generic relay pool concept (all relays equal) used today for most apps.
I’ll spend more time on “best relays for a pubkey” based on who they follow recommendation engine (it’s most likely recursive and may be expensive to generate). However, the client app layer on top of relay pools is the next level of maturity/intelligence needed for relay interactions.
I do to. I dislike having to select/copy/paste more - especially on phones. Tap share, then edit and send.
For news articles etc, ideally it’s just the title of the article and a url.
https://nostrum.pro and https://nostr.band are excellent search engines, but they really should add support for the nostr: link scheme instead of hardcoding web clients. The web client I use is not there, the desktop native client I use is not there and the Android client I use is not there either. The universal way forward is nostr:npub1... and nostr:nprofile1..., please!
Maybe a nostr:share?kind=1&content=Hello%20Nostr could work for universal sharing of templated or pre-filled event content/type. Not sure how most url handler registration works across apps/platforms/devices. Thoughts?
I think with more sharing functionality, it can really boost adoption.
Issue still remains of false flagging or flooding or targeting suppression attacks.
I still think some kind of open/community indicator for tagging content is universally valuable. Just not as simple as a new emoji.
