Folks, a question mainly for client devs and integrators: If you receive an nevent without relay metadata and want to fall back to a hardcoded list of relays to try and find the event on a best effort basis, which relays would you include? Or is there a better approach to try and find a note by id?
#askNostr #relay #popularity #nip19 #nip21
If it can’t be found on local cache, use the current user’s read relays and author’s write relays.
I should have given more info above. This is in the context of an external web app working with a NIP-21 URI in the format `nostr:nevent1xxxx`. Relay and author metadata are optional so we can't always do the Outbox model bootstrapping sequence magic as we may not even have the author pubkey (although I'll tag nostr:nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgpypmhxue69uhkx6r0wf6hxtndd94k2erfd3nk2u3wvdhk6w35xs6z7qgwwaehxw309ahx7uewd3hkctcpypmhxue69uhkummnw3ezuetfde6kuer6wasku7nfvuh8xurpvdjj7a0nq40 here just in case as he often has magical solutions to everything nostr :))
I wonder what software like njump.me do to retrieve a note by nevent.
nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhkcmmrdd3x77pwve5kzar2v9nzucm0d5hsh2c3z4, sorry to bother you. Is the central njump.me using this list of relays to retrieve nevents without relay metadata? If not, can you send me the most up-to-date list or point us to whatever magic you are doing there?
https://github.com/fiatjaf/njump/blob/master/relay-config.json.sample
I think the actual answer is to fix the clients that are producing those nevent IDs without encoding the author or relay metadata of where it was published or found. I feel like it’s ok to say we don’t have enough information to find this event on this decentralized network because you didn’t provide it. That’s just my opinion though.
Agreed, although "fix" may be a strong word given that NIP-21 language makes it optional. https://github.com/nostr-protocol/nips/blob/master/19.md . Still, you are right, clients should include relay metadata when generating nevents
If you only have the Id (since nevent makes the rest optional) there is no slick magic. Now that this is clear, when you create an nevent include the author so other people don't have this problem. I'd even suggest changing the NIP to make the author required for an nevent.
Maybe check an aggregator like relay.nostr.band? That's a temporary band-aid for the issue, though... What client is generating nevent URIs without any relay hints?
Thanks. Yes nostr.band should definitely be in the list.
I've seen a few of those nevents without relays in the wild. Not sure which clients are producing it, but the events without relay hints do exist unfortunately.
nostr:nprofile1qqsyr80gx8trp6e4putucnhzsrwwu504xrzneg2tfsdvq3urrekmjfcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcppemhxue69uhkummn9ekx7mp0qyt8wumn8ghj7un9d3shjtnddaehgu3wwp6kytcmn278n is building Nostr pubkey claim support on Keyoxide.
The claim is in the format of nostr:neventXXXX pointing to a note with the proof back to your PGP Key or Ariadne Profile (Think NIP-39 but the other way around, where you prove ownership of a npub with your PGP key). Just wondering what is the best thing to do here. IMO, failing the claim and telling the user to provide a proper nevent is an option, but we can try some default fallback relays as well.
I don't know if there are other aggregators out there, other than maybe Primal. But aggregating all notes is only going to be realistic for so long, and nostr.band has been known to go down from time to time. 😂
Most users still post to one or more of the big, public relays, too. That would be relay.damus.io, relay.primal.net, and nos.lol. Having them on the fallback list would always be a good idea, but this is also just a stop-gap rather than a solution.
If nostr:npub1gxw7svwkxr4n2rche38w9qxuaegl2vx98js5knq6cprcx8ndhyns5uk8jl's client is going to be generating the nevents pointing to these notes, though, he should be able to include relay hints in them based on the author's outbox relays. Then there is only an issue finding those notes if the author changes their outbox relays, or there is another client that starts using the same note kind and doesn't include relay hints.
The outbox model is great, if you know the note author, since you can just look up their relay list... Maybe note aggregators like nostr.band will one day be unrealistic and they will just aggregate the note ID and author's pubkey, then the client can look up the author's outbox relays based on that.
I'm in full agreement. Also, even if aggregators could theoretically scale, I don't think Nostr wants to replicate the Bluesky/AT architecture, as in practice these components end up being very expensive to run and likely end up in the hands of a few companies with deep enough pockets. Nothing against aggregator relays, directories, "global" firehoses/caches, etc., in the context of specific Nostr experiences. But the less we rely on all of this, the better.
I think that using the relays from the njump.me list below (which includes all of the relays mentioned above), or whatever relays njump.me is using as fallback nowadays is a safe way to go. Somehow njump.me never fails me.
Keyoxide will be merely a consumer of nevents for validating claims. And worst of all, it will be an indirect consumer. I.e., the users will input the nevent as a claim, for instance, using PGP notation and uploading their public key to a PGP keyserver. From there, Keyoxide fetches the PGP key, extracts the nevent from the PGP key notation, and uses nostr-tools to connect to the underlying relays, download the note and validate the "proof" (I.e., specific text in the note).
This means the options here are either telling the user to use a better client to generate a nevent with proper metadata, or hunting for the event blindly. I almost feel like, long term, telling the user to generate a proper nevent is a better strategy. Even if it means slightly worse UX for now.
Exactly. I feel like note aggregators are a centralizing force. Why do the hard method of looking for notes from a user's outbox relays if it is almost certainly also saved to a note aggregator? Heck, that's Primal's entire architecture, right?
Indexes, by contrast, can be helpful for encouraging decentralized relay usage, since the indexer doesn't store the content itself, only points to where it can be found, and there can be multiple indexes, since it takes up a comparatively small amount of space.
I know that an index of all kind 10002s is currently around 50MB, which means Nostr could 20x before the index even grew to 1GB. I'd be interested in finding out how big an index of all note's hex IDs, paired with the author's hex pubkey would be. A lot bigger, I imagine, but likely still more than realistic for a standard PC to store several times over.
