Nostr Web Client

https://github.com/nostr-protocol/nips/blob/master/05.md

It’s not hard to know what relays somebody’s using AFTER you’ve started downloading their messages. But what about when first want to connect to #[2] and I don’t know which relays you’re using.

Cosanostra 2y ago

I think https://nips.be/5 aka NIP-05 allows you add you preferred relay on your verification. This should help in this quiz.

p2x 2y ago

No bad idea at this point! I think it’d be nice to start seeing new important ideas like this being debated live between a few people on #[2] for example.

daniele 2y ago

NIP-05 already include a relays section, seems a good option, isn't?

Then we also have nprofile that embed the relays info, little used but useful for profile sharing:

https://github.com/nostr-protocol/nips/blob/master/19.md#shareable-identifiers-with-extra-metadata

cloud fodder 2y ago

nip05 relay section seems to be designed with just one person in mind, instead of a list of people at that domain that might want diff relays..

daniele 2y ago

Sorry I don't understand the point.

#[0] pointed out:

> often I don’t know what relays a person is using

NIP-05 seems solve this easily, and of course can work for multiple persons on the same domain pointing to different relays.

Cosanostra 2y ago

I found this utility for nips https://nips.be also you can check https://nips.be/5 for example. Hope it is useful your you guys!

daniele 2y ago

I was just trying to remeber this domain to use it here! :D Thanks!

cloud fodder 2y ago

my bad, i read the nip05 wrong, you *can specify a relay per person.. nice!

In nostr.json, each pubkey has their own relay list. Take a look at mine: https://mikedilger.com/.well-known/nostr.json

In saying this though, I'm not suggesting that NIP-05 ought to be how we find people's relays if we already know them by pubkey. If we know them by pubkey, we should get a pubkey-signed document, which NIP-05 is not.

wow i cant believe it is not signed, thats a real oversight, nostr needs to resist centralization

Well, it is a statement by the domain, not by the nostr keys. The domain is saying "Yes, this person at this domain goes by that nostr key". The relays are just in there as hints,.

yes it is a statement by the domain and so are all the events statements by relays, signing is fundemental to nostr, it allows trust inspite of any distribution methods

But domains don't have nostr keys to sign with. The relays part could be signed,yes, but the prevailing opinion was that we don't want to rely on DNS and would rather have such information elsewhere.

um the user would sign the thing stored at the domain? aka just another event

Yes, that’s what #[5] did with his NIP-65 spec for a signed message with relays, but there’s nothing yet about putting that signed message on the nip-05 verification / identity server or in a DHT where you could look it up without knowing at least one relay for that npub.

#[8] 's standard i think now is you implement then nip

so we need dht on relays and maybe clients?

i start to think we could host more on the nip5 providers, maybe relays should start doing both, then hash chains and repos and nostr is feeling more like bluesky

the nostr way seems to be explore many possibilities and come to what works, i cant disagree with the progress this way

I’m personally fine with DNS, I mean relays rely on dns for example. But I don’t like the idea that something as important as what relays you’re using isn’t signed by you.

We could host the 10002 message signed as part of the webfinger file that nip-05 uses, or put them in a DHT.

It feels like DHT’s are less fragile and dependent on a service provider.

dns works fine for now, but someone making something better would always be great

i agree it should be signed

i like the dht idea, if we can find a relay for a pubkey it will go a long way to improving content discovery

Thank you, Sir. 2y ago

Hey #[1] , relays are visible when logged in with another users pubkey. Not elegant, but it’s there.

I'm not sure if it is a good idea or not. Let me probe it a bit. NIP-65 offers a way for people to spread information about which relays they use... to other nostr relays, and suggests spreading it far and wide since it is just one small replaceable event without any content that would be subject to moderation. I think that might be good enough, unless a DHT offers something that relays don't. So... what would a DHT offer that is better than many relays serving an author-signed relay list over nostr?

Your nip-65 is good. Simple, straight forward. And solves one of the problems. How do you reliably, in a signed way, state what relays you’re using. But it only works once I already know one of those relays in order to see the message.

What I’m saying, is would it be useful to not just have you spread your 10002 message to multiple relays but also to be able to push it to a DHT, would be useful.

Especially if we get to a world where because of spam, most relays end up with gatekeepers like needing to pay satoshi to join.

Ok but isn't it true that in order to read someone's relay list off of a DHT I have to connect to one of the server serving that DHT? And if so, how is that different from all those servers being nostr relays and serving the same information?

Well with a DHT you connect to one of several known root servers. This is how you bootstrap in to tor, ipfs, or BitTorrent. Then from there that root server keeps a record of other peers and you can start querying.

In this case, the relays hosted by NIP-05 aren’t signed and often aren’t updated. Not as big an issue where folks are hosting it just for themselves like you’re doing’s but for people using the cloud nip-05 services, it is.

I’m pretty sure we could post NIP-65 events to a DHT, it’s signed, so we know somebody didn’t forge it, and then we could allow lookup based on npub.

Cosanostra 2y ago

I want to run my own relay for private purposes and dont trust in any root at all, even with certificates and verification with keypairs. I run my servers at home I can unplug them if I want or get tired. That is the philosophy.

Ok first of all, NIP-05 is out of the question. It's not signed, it's not a contender here. That was just to make it easier to find someone, back when we didn't have better ways. It was my idea to put it into nostr.json in the first place, so I am shooting down my own idea.

My newer idea is expressed in NIP-65, which is just to spread that kind-10002 event to hundreds of relays (while only using a few relays for regular events).

I've always been in favor of relays or servers that specialize in serving kind-10002 events. I was going to suggest if someone does a DHT to put the kind-10002 events in there. Sounds like that is already part of your idea.

It seems that if all the clients move over to publishing into a DHT, then a DHT would have the advantage that all the data would be in it (the hash table being synchronized, I presume), whereas if you just ask a popular relay, it might not know, and you could never know for sure if that was because the relay didn't know or because the data wasn't there. BUT that property doesn't appear unless and until everybody moves to using the DHT. And I'm not sure people will because of the chicken-and-egg problem.

But a DHT seems like (even though it is distributed) a potential single source of failure. If there are "root servers", how many are there? Can they cheat?. Can things be removed from or replaced in a DHT, and if so, cant someone censor data out of it, and then replicate that censorship widely? If not, how is that enforced? I admit to my ignorance on this point.

I think we’re in agreement. If the DHT is setup in such a way that to write to it you need to use your nsec to sign the 10002 post which lists your relays with the lookup based on the npub. DHT’s are particularly censorship resistant, there are lots of kinds of DHT’s and ways to use them. We’d want to have somebody double check and help with its design.

There might even be a good way to take 10002 messages from a relay and push it to the DHT. It has to be signed, so even if the original person who created it doesn’t post it to the DHT with their app, others or relays could. The other half is to then provide a web UI for looking up npubs from the DHT. That way it would work without a chicken and egg problem.

Are you planning to build this? I look forward to seeing how it works out.

Nuh 2y ago

I am working on it and would love all the help I can get https://pkarr.nuhvi.com/

I am already getting great results, but will need real stress testing, if you are willing to help testing, please let me know, the code for the server side is almost ready. And the demo web app will be read before Monday, but feel free to watch it as it evolves pkarr.nuhvi.com

Skekzyz 2y ago

signing to write is a must, pow would be good too

Skekzyz 2y ago

100% dht to find relays for npubs

adding p2p elements to nostr clients is highly desirable, i propose people have a home relay where they try to maintain all their notes, this will make advertising a single relay sufficient, we should probably hash chain all our events too

Well if we started signing our hash chain that potentially brings up the issues that held secure scuttlebutt back. The p2panda, moderator/atacama, and earthstar projects solve that with nifty ways of signing through Merkel trees instead of a linear chain.

i disagree we dont need to maintain the entire event collection, it just adds security if we have more of the chain and makes it easier to ask a relay for a section of the chain and know if we have everything or how much is missing