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?
Discussion
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.