i have an npub. how am i supposed to find the relay? \ stacker news ~nostr

pull down to refresh

i have an npub. how am i supposed to find the relay?

17.6k sats \ 40 comments \ @anon 17 Feb nostr

Okay, so people give out their npub, post it on their website, print it on their business card, etc. Awesome. Your npub is basically a public key, so you own it. Nobody can take it away from you, cancel it, etc. It has none of the problems of Mastadon/Matrix where whoever owns the domain name of your homeserver can cancel you on a whim.

But... if I hand out my npub to people, how tf are they supposed to find the relay that relays my notes?

NIP19 nprofiles with a relay entry are not a solution -- they just resurrect the Mastadon/Matrix problem. If I print my nprofile on my business card and invest a ton of effort into getting that to people, the relay operator can just decide they don't like me and stop relaying my notes. You own your npub but you don't own your nprofile.relay.

So basically, nostr has not solved the cancellation problem. It just shifted it somewhere else.

I'm kinda disappointed with this. The only solution to this problem that has stood the test of time is a DHT like bittorrent uses. The MPAA throws millions and millions of dollars at trying to kill bittorrent, and their DHT just sort of laughs. Bittorrent proved that DHTs work, so long as the DHT keys are network endpoints (IP address and port number) and nothing else. That way you can't spam the DHT -- you have to prove ownership of the endpoint to get it into the DHT, so your spamming capability is bounded by the number of IP addresses you own (incidentally this is why IPv6 DHTs are unlikely to happen anytime soon).

So... when are we getting a nostr DHT to map npubs to relays?

Hint: if there isn't one yet, please follow the Bittorrent design as closely as possible. There are so many ways to fuck this up (like IPFS keeps doing). Use UDP, don't use connections (not even QUIC), be stateless like NFS is. Seriously, just copy what Bittorrent is doing, swap ed25519 with secpk256, and don't touch anything else.

view all related items

3145 sats \ 2 replies \ @TonyGiorgio 17 Feb

You're thinking about it in terms of "a relay" and that's not what nostr is. It's many, and the notes and profile information is distributed across them. If someone wants to see the notes of an npub, they ask all the relays they are connected to. Gossip model stuff pushes the search out further too. One relay taking something down should have no affect.

If you have suggestions to building nostr the way you prefer a distributed protocol to be, you may want to post those here: https://github.com/nostr-protocol/nips

2445 sats \ 1 reply \ @anon 18 Feb

they ask all the relays they are connected to

This is just dodging the question.

How do I know which relays to connect to? What if none of the relays I connected to are the one that relays notes from the npub that I want to follow?

"Gossip" is just a happytalk phrase... it doesn't scale without a distance metric, and a DHT is nothing more than gossip plus distance metric. You can't expect to connect to everybody on the internet, so as you gossip your way around, you need a way of figuring out if you're getting closer to or farther from your goal. That's what a DHT is.

If you have suggestions to building nostr the way you prefer a distributed protocol to be, you may want to post those here: https://github.com/nostr-protocol/nips

I'm seriously considering it. Posting here was a sanity check to make sure I wasn't missing some obvious existing solution.

Kind of put off that they require a github account though instead of using NIP-34.

0 sats \ 0 replies \ @ek 18 Feb freebie

Kind of put off that they require a github account though instead of using NIP-34.

NIP-34 is just a draft

518 sats \ 6 replies \ @BlueSlime 17 Feb

DHT is not really a good fit, as the clients are not meant to be reliable end points, and relays aren't that much more reliable.

Gossip works far better, and there's already a proposal and implementation.

There's also things like blastr, which can mass-update your profile to a list of relays.

1337 sats \ 3 replies \ @anon 18 Feb

DHT is a perfect fit, as the relays are the endpoints.

"Gossip" is just a happytalk way of dodging the question.

How do you know which IP addresses to gossip with? "All of them" doesn't scale. A DHT is nothing more than gossip with a distance metric so you can know when you're getting closer or farther to your goal.

I note that you posted no links. A lot of this stuff sounds great in quick replies but doesn't pan out when you have to sit down, write, and implement a detailed spec.

0 sats \ 1 reply \ @BlueSlime 18 Feb

I don't think you understand how nostr works. The relays are not meant to be endpoints, they are only meant to be dumb relays. Also the relays already operate as a hash table for the notes being stored.

There's no IP addresses with nostr gossip, just a list of relays and some overlap between clients. If our clients share a single preferred relay, I can retrieve your note and rebroadcast it to my other preferred relays. It's not a hard concept to understand, and the "links" are on the nostr github.

0 sats \ 0 replies \ @ek 18 Feb

The relays are not meant to be endpoints, they are only meant to be dumb relays.

Yes, they are not meant to be endpoints, they are only meant to be dumb relays, but is this currently the case?

If most connect to the same big relays, is it really irrelevant which relay you choose? Are relays really fungible? Can you just spin up a new relay and have the same network effects as other relays?

Serious questions, I don't know the answer.

0 sats \ 0 replies \ @premitive1 18 Feb

by some axiom a relay shouldn't generally be treated as an end-point, hence the word "relay"

0 sats \ 1 reply \ @ibz 18 Feb

There is no "gossip" happening in nostr. Nostr is meant to have clients talk to relays and relays be independent of each other and not talk to each other.

0 sats \ 0 replies \ @BlueSlime 18 Feb

There is a gossip protocol spec in Nostr. I forget the NIP but you can easily find it.

Clients perform the gossip by republishing the notes of others, which is an intended feature of nostr.

205 sats \ 6 replies \ @ibz 18 Feb

The issue you raise is valid and I think it comes from the misunderstanding that even most nostr app developers have about the protocol which leads to them writing "nostr apps" in a way that - indeed - makes no sense, causes confusion, and ultimately does not solve anything.

In one short sentence: people mistake nostr for IPFS. They think relays are there to somehow store the events, to provide persistence. They are not! They are there to relay the data. Remember, the T in nostr stays for transmitted.

Most "nostr apps" do this: want to publish an event? Let's blast it to a list of relays and say done! Want to see other people's events - or even my events? Ask the same list of relays. Maybe have a DB locally used as a cache for better performance. This is the wrong approach in my opinion, and leads to nostr being misunderstood - at best - and will lead to data loss and pain and disappointment in the long run.

To better explain: I think relays should be thought as ephemeral entities. Every client should store the data locally first. After storing the data locally, it should blast it to a bunch of relays that happen to be active at that particular moment, and other clients will receive these events from those relays. But these relays might disappear an hour later. They are not there to stay. Having the data locally means that IF the user decides that the events are important enough (for example the events represent profile metadata or long-form blog posts), it can periodically send them to new relays. If the events are not considered important - like a short status update - it is perfectly fine to just stop caring and assume that whoever got it, got it, but other clients that come online later might not get it anymore.

100 sats \ 1 reply \ @sebastix 18 Feb

I think relays should be thought as ephemeral entities. Every client should store the data locally first. After storing the data locally, it should blast it to a bunch of relays that happen to be active at that particular moment, and other clients will receive these events from those relays.

Sounds like POSSE https://indieweb.org/POSSE

0 sats \ 0 replies \ @ibz 19 Feb

Didn't know about this term, but yes. This was the whole point of nostr: to 1) put you in control of your data and 2) make your data easily accessible and hard to censor.

How would you achieve 1) if you would not hold your data in the first place, anyway? How are you self-sovereign if you trust some random relays to hold your data forever?

100 sats \ 3 replies \ @premitive1 18 Feb

I still haven't full wrapped my mind around the "transmitted" part of NOSTR. There's a part of me that intuitively understands, but the rest of me is still unsure of how that should work.

47 sats \ 2 replies \ @ibz 19 Feb

You hold your data in a safe place - a place you have 100% control over. Not inside Twitter, not inside the cloud, not on a VPS. This might mean your data is on your node running in your closet. Which means it is not accessible from the outside world. Nostr clients cannot connect to your node, since it doesn't have a public IP. Plus you don't even want random strangers to know your node's IP address.

So what do you do?

You talk to these random dudes that sit on the street all day long and answer questions to anyone passing by.

You tell them ... "if anyone asks about me, tell them I said this and that." That's it. These dudes might come and go. Nobody needs to know who they are. The whole point is that they don't need to be trusted, because the messages are signed, so these shady dudes cannot alter the messages. Also, nobody needs to know where exactly you live, all they need to find is some random dude knowing something about you.

26 sats \ 0 replies \ @sebastix 19 Feb

Don’t trust, just verify 🤓

0 sats \ 0 replies \ @premitive1 19 Feb

What I don't like about this characterization, though I may have to live with it, is that this random dude on the side of the street doesn't just give me message to people asking for it, but he'll give it to everyone passing by unless they specifically avoid it. (ie they have global feed turned off and only see people they follow in their own client) Maybe this is an issue with the message I give him, and not with his model of telling anyone everyone else's business.

5081 sats \ 3 replies \ @franzap 17 Feb

Nostr's "DHT" is NIP-65 (kind 10002), we have purplepag.es but need more of these special purpose relays

99 sats \ 2 replies \ @anon 18 Feb

Hey thanks for pointing to this. NIP65 is definitely part of the solution -- it's the (signed) thing that you want when you have an npub and are looking for its relay.

But relays don't talk to relays, and even if they did it isn't practical for every relay on the planet to store the latest NIP65 for every npub on the entire internet. Even if this were possible, it would cause awful spam attacks.

I think the solution is coming into focus: I knew the DHT keys would be npubs, and now you've pointed out that validly-signed NIP65 kind:10002 notes should be the values.

0 sats \ 0 replies \ @028a8fbdbe 18 Feb

Not true. Relays can and do talk to each other.

0 sats \ 0 replies \ @franzap 18 Feb

Exactly, signed 10002 events. Spam can be mitigated by requiring payment or proof of work on the event. Relays are starting to talk more to each other, many are using the negentropy protocol to sync

40 sats \ 0 replies \ @anon 17 Feb

"swap ed25519 with secpk256" should read "swap sha1 hashes with secpk256 public keys". The bittorrent spec for using ed25519 keys isn't actually needed for finding nostr relays.

321 sats \ 6 replies \ @fiatjaf 18 Feb

I have a Bitcoin node, how do I find other Bitcoin nodes to fetch blocks from?

Conclusion: Bitcoin is centralized.

390 sats \ 4 replies \ @anon 18 Feb

https://x.com/peterktodd/status/1759151430336737645 cc @petertodd

https://m.stacker.news/16528

0 sats \ 3 replies \ @premitive1 18 Feb

that's a fellow arguing for tail-emissions, right?

0 sats \ 1 reply \ @ek 18 Feb

Is this all that @petertodd is to you?

0 sats \ 0 replies \ @premitive1 18 Feb

for a shit post like this, yes.

0 sats \ 0 replies \ @basantagoswami 18 Feb freebie

yes

380 sats \ 0 replies \ @ek 18 Feb freebie

I believe the difference is that it's more about fetching blocks and less which bitcoin nodes you connect to.

If I run a new bitcoin node, I can be pretty sure that my node have the same view (shared reality) as everyone else on the bitcoin network. Thanks to PoW, my node can just follow the chain with the most PoW in it as long as my node "randomly enough" connect to nodes.

On nostr, to which relays I connect to is important to have "shared realities" with others, no? I can't just randomly connect to relays and think my view is the same as everyone else on nostr, no?

So I think OP is more concerned about censorship resistance than centralization since yes, Bitcoin Core includes DNS seeds.

42 sats \ 2 replies \ @Bass 18 Feb

Step 1: login to their npub Step 2: mark down their relays Step 3: log out of their npub Step 4: login with your keys Step 5: compare and add relays

0 sats \ 1 reply \ @premitive1 18 Feb

how do you mean login to their npub?

0 sats \ 0 replies \ @ek 18 Feb freebie

You can login with any npub for read only access on some clients like Snort:

https://m.stacker.news/16585

That's also how you can see who writes who on nostr and read their notifications.

For example, here I am logged in as Jack:

https://m.stacker.news/16586

update: apparently, Snort does not show you the messages anymore but it's still possible per protocol

1 sat \ 0 replies \ @hampus 19 Feb

NIP19 nprofiles with a relay entry are not a solution -- they just resurrect the Mastadon/Matrix problem.

It doesn't resurrect the Mastodon/Matrix problem. The fact that you can have mulitple relays embedded in the nprofile is a huge win over Mastodon, where your identity (that you don't own) is stuck on one single instance that can ban you at any time. nprofile is good enough.

0 sats \ 0 replies \ @nerd2ninja 18 Feb

NIP19 nprofiles with a relay entry are not a solution -- they just resurrect the Mastadon/Matrix problem. If I print my nprofile on my business card and invest a ton of effort into getting that to people, the relay operator can just decide they don't like me and stop relaying my notes. You own your npub but you don't own your nprofile.relay.

Okay...then own your own nprofile.relay.

Use this nostr relay guide: https://usenostr.org/relay

Use this tool: https://nak.nostr.com/ Paste your npub in there. A bunch of fields will popup. One of which will be "Add relay hint" Paste your domain name (wss://domain-name/) Copy the resulting nprofile Encode into a QR code and spend a bunch of money on business cards.

Bam, you own your nprofile.relay.

In nostros I can then sync and connect to any relays you may be connected to.

I also personally update my "about me" or "description" or whatever you want to call that part of nostr profile when you visit it, with a list of relays I'm the most fond of using (I'm connected to them because I think they're good not just because the people I follow are connected to them)

0 sats \ 0 replies \ @gzuuus_ 18 Feb

There are a prNIP-302 about relay pools, that maybe can fits with what you are thinking about 🤔 https://github.com/nostr-protocol/nips/pull/1035

0 sats \ 0 replies \ @dtonon 17 Feb

NIP-5 address is the solution, although it is not perfect because it depends on the centralized structure that manage domains.

0 sats \ 0 replies \ @03479d0ee6 17 Feb

There is nip65 where when you create an account or update relays clients should spread your relay choices across many relays. Not sure but I think clients should also spread your notes to your followers relays.

0 sats \ 2 replies \ @premitive1 17 Feb

These are still very early days, so I don't think it's fair to paint with such a wide brush. Currently this problem gets avoided by most people being in the same handful of relays.

493 sats \ 1 reply \ @anon 17 Feb

This isn't a criticism of nostr, but rather of its development priorities. It seems really weird to me that the decentralized relay-finding problem isn't even acknowledged.

this problem gets avoided by most people being in the same handful of relays

Isn't that kind of centralization the exact opposite of what nostr is trying to achieve?

10 sats \ 0 replies \ @premitive1 17 Feb

maybe. a lot of people seem to complain about protocol level design choices made that make it unattractive to wider development. there are definitely people working on nostr things, but I don't know of anyone working on what you call the relay-finding problem. Seems like something worthwhile