Oddbean new post about login | logout Let's see if people are ready for this discussion https://github.com/nostr-protocol/nips/pull/1330
I certainly am 👍😇
Very ready for it. Maybe not the best solution, but directionally correct (and maybe a good enough solution!) nostr:nevent1qqsvddehdhq6g7r2rg3jkme9muyyqhuwk4w4m00rmc3zglagrkg4p7gpz9mhxue69uhkummnw3ezuamfdejj7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqzrpk3g4
Absolutely. Let's hash it out.
I am holding this off for almost a year now... Let's hope the latest xyz shenanigans have woken people up.
Any thoughts on adding some sort of easily readable/memorable unique names?
I am sure somebody will make them, but I am not sure there are all that interesting/needed
Sure, all it takes is some proof of work. Can Rana mine naddr1 addresses?
Nostr Name System? 👀 nostr:nevent1qqsvddehdhq6g7r2rg3jkme9muyyqhuwk4w4m00rmc3zglagrkg4p7gpzemhxue69uhhqatjwpkx2un9d3shjtnrdakj7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqza9ywlx
This may come off as a dumb question but in theory is this supposed to operate like Etherum's Name Service where it shortens the address name but for Bitcoin instead
This has nothing to do with blockchains. They operate entirely over nostr protocol.
It would be truly revolutionary. Do it if you can.
There's a lot of reverse proxy infrastructure that won't like this. Would be wonderful if we could at least put the original naddr in a header or something
I would love to have a solution for that.
Should those events have an expiration/ttL so clients can cache them?
We can add, for sure. Do we need to do it by `A` record or can we do it for the whole thing with `expiration`. Either way, Clients should cache it.
We should write a low level DNS server that accepts requests for naddr domains and returns proper DNS records. It should return all IPs and tag them with the pubkey so clients can leverage their WoT to pick the best.
I applaud this effort. I am curious if you will also do something with certificate issuance, nostr will need to become a 'certificate authority' as well. Or use ws:// and http:// instead of wss:// and https:// It is theoretically possible to have certificates for an IP address signed by a certificate authority but let's encrypt doesn't support it. The other option I suppose is have clients able to accept and store the certificate for that IP one time only. The problem with ws:// is that it's easy to man-in-the-middle, so even though nostr uses sigs it still needs encryption on the connection. Eg. on TOR or vpn you gonna get manipulated pretty hard without encryption.
MITM isn’t the issue… it’s the inability to resolve without the NNS note. If you want to connect to a new relay and you only have the NNS name of the new relay, you literally can’t connect if your current set of relays don’t know its IP. You literally have to ask your relays for permission to join new relays… because if they withhold the IP, you can’t resolve the NNS and you’re fucked.
Well that and I'm curious how can it have the names 'owned' by anyone, what is it gonna just be a free for all? I guess just web of trust fixes it handwaves etc? Like anyone can own any name, multiple owners of a name? 🤔😁 So you could take over a name by being more popular. Very interesting world it will be eh? #web5000
There will be a million name conflicts too, yes. Good point. This is a pile of garbage. It’s a fork of nostr that I won’t follow.
So we can’t try stuff out is what your are saying?
You should try stuff in your head and decide not to code it. These problems are easy to sniff out beforehand. But I guess that’s what these discussions are for too.
Honestly, there’s no way nostr will expand without a few changes… but this NIP creates more problems than it solves.
Propose a better solution, have some stake in the game at the very least so we can entertain it.
The spec of the better solution will be released before the next @thenostrworld After @HORNETS launches on the 4th of July 🚀 Buckle-up. 🎢
We aren’t coding anything, it’s a proposed NIP and we are having a discussion about it? Calling it a pile of garbage because obviously you know better and saying you won’t use it because apparently you think so highly of yourself isn’t helping this discussion. But fine, it’s a pile of garbage, whats your solution? I bet it’s perfect.
We do have a solution… Development is already underway. You’ll see soon enough. It scales outbox. I outlined exactly why NNS breaks — but you only focused on the mean part of my comment. Focus on the meat of what I said before that. When the spec is ready, I’ll make sure to share it here first. I’m drowning in work atm preparing for launching @HORNETS on the 4th of July, but after that it and Nestr are my main focus. Be patient and I promise not to disappoint. 🙏 I’ve been trying to scale the CAP Theorem parameters of Nostr for 2 years straight now, so I get disgruntled when I see half-baked solutions that make relay discovery even more difficult.
Great. Don’t get mad at other people trying out their ideas too just because you have yours. Let the best idea win out in the game.
Mate, that’s not it at all… if you can’t take criticism, pack-up shop now. I’m just pointing out why NNS doesn’t scale. It’s nothing personal.
You can only own names under your own pubkey. There will be no collision. We can’t have any certificate authority because that is centralized by nature. Not sure how we will solve the SSL/TLS part of the equation but that’s a another problem.
So the naddr contains both the owners pubkey and the relays IP address? That could work. It didn't mention that in the spec..
Sure, public keys work as domains. Did you see the main issue I outlined though? This NIP literally siloes you into the relays you’re connected to & the relays they’re in-sync with. If you try to resolve an NNS outside of that corner of the network, you won’t be able to resolve the IP. This literally centralizes the Nostr network.
If I can’t find your 30053 NNS note on one of my relays, then I can’t resolve your “Nostr DNS” — which means I can’t find the new IPs of new relays I want to connect to, forcing me to remain in a silo of whoever my relays are currently in-sync with. Therefore, this spec’ is so naive — like your premature file storage NIP. This NNS system only worsens the scaling problem of Nostr’s difficult-to-find relays. Throwing buzzwords at things isn’t scaling. I agree we should move away from Web2 URLs entirely, including relay URLs… but this isn’t the answer. There’s a better way.
> If I can’t find your 30053 NNS note on one of my relays, then I can’t resolve your “Nostr DNS”. We already have solutions for this because this is the same problem of finding ANY event that is not on the person's relay. What you are claiming is that Nostr doesn't work because you can't find events, yet we are all here and its working. Yep, we still need better solutions for indexing an event's host, but this can be solved at a broader level and directly benefit NNS's resolution. You think this proposal is naive. I think you are just overcomplicating things without any gain.
You’re missing the big picture. This siloes Nostr and breaks the outbox model. It makes connecting to new relays even harder than it already is by putting all the power into the relays you’re currently connected to. I don’t care to argue with you… you said we’d need 25M to build @HORNETS and we’re almost done. 🤡 Let the best ideas win. I’ll see you in Lativa and we’ll check-in then.
I am curious why you think this breaks the outbox model since it's based on it. Clients check the WRITE relays of the NNS pubkey to find it.
Let’s saying I’m connected to 7 relays and I want to connect to an 8th relay. If the 8th relay is using NNS, I now have to resolve this NNS to get its real IP. If the 7 relays I am connected to do not have the NNS note containing the IPs, then I cannot connect to the 8th relay. The 7 relays can also withhold the NNS note if they want to silo me. This allows the 7 relays to prevent data portability and free agency. Nodes should be thought of as untrustworthy — especially if it’s only a handful, like 7-15 relays. That’s too much power to give to a few server operators. I have a much better solution that doesn’t rely on trusting the small set of relays you’re connected to. It’ll be released before @thenostrworld
Your 8th has an address right? Let's say you want to connect with `naddr1abc`. As part of the `naddr` whoever sent you that link had to insert the `wss://ip4` as the `relay` field inside the naddr. This means that even if you have never seen this relay before, you have a base IP to connect and start the work. But keep in mind that NNS are designed to be broadcasted just like NIP-65 events are. They should be everywhere. But if they are not, you can always have a base IP from the latest relay hints in the events you already have.
Relay hints are a horrible foundation to rely on. Once again, we are just headed in seriously different directions. Good luck to you and your mutable world. nostr:note1jkwys58jphw3jggh2s4l86gqk3nku5s0mzvjaezux5jptkwpae9qglzq2h
I don't disagree they are a horrible foundation. But you can't say they are NOT working. They work really well. There are lots of things on Nostr that don't make any sense. And yet they work.
Sure, you can ride a bike with a flat tire for however long you want. Eventually I’m going to get off the bike from being annoyed of the bumpy experience. I’m not claiming that this imperfect mess doesn’t work sometimes. I’m saying that we must scale it without these fragile foundations. I’m happy #nostr got started the way it did. But I hope you’re all ready to let go of these fragile foundations and scale to the stars. Looking forward to hearing your responses when we finally release. 🚀
BTW, I trully look forward to your proposal. I just hope it's not something that takes too long to code or that just re-centralizes them into another trusted infrastructure.
🙏 We’re doing the best we can to make it as simple and modular as possible. It’ll be ready to read before the next nostr conference in Lativa @thenostrworld Hope you have time to check out the @HORNETS launch on the 4th of July in the meantime! We released the Scionic Merkle Trees last year on the 4th of July too. Freedom. 🦅
You need to check the experience of distributed networks like I2P or GNUnet. Maybe something like the GNU Name System? Any decentralization of DNS leads to the use of DHT. But any implementation of DHT requires an initial download of data about the network nodes. This is always the bottleneck in such networks.
Nostr IS already a DHT.
The "H" in DHT stands for "hash". Pub keys aren't hashes.
event ids are
This is not really a bottleneck. You initially download only a small number of node informations for bootstrapping.
The bottleneck is not in terms of the volume of data being loaded, but in terms of "centralization". Node data need to be kept up to date all the time. There is also a vulnerability in the substitution of loading nodes. Not that these are insurmountable problems, they just need to be kept in mind.
> The naddr1's relay field SHOULD have the IP-based URI to the relay (e.g.: wss://<ip4>/) hosting the NNS record at the time of creating the naddr1. Replacing long-lived identifiers (DNS names) with short-lived ones (IP addresses). What a great proposal. Distributed systems are hard, apparently you didn't get the memo.