Let's see if people are ready for this discussion
Discussion
Re-writing the internet one nip at a time.
Progress
thank you
I certainly am šš
Very ready for it.
Maybe not the best solution, but directionally correct (and maybe a good enough solution!)
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
Nostr Name System? š
It would be truly revolutionary. Do it if you can.
Nice! With this the image can become movable!
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.
If the tags are individual records then each should have their own TTL
The expiration tag is for relays to know when to delete the event which is NOT what we want here. Otherwise a new event needs to be published.
The TTL is for clients to know when they should invalidate their cached version
Figured we donāt need any hierarchical format for names since that leads to centralization.
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.
MITM is a secondary issue compared to the inability to connect to new relays.
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 nostr:npub1nstrcu63lzpjkz94djajuz2evrgu2psd66cwgc0gz0c0qazezx0q9urg5l
After nostr:npub1h0rnetjp2qka44ayzyjcdh90gs3gzrtq4f94033heng6w34s0pzq2yfv0g 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 nostr:npub1h0rnetjp2qka44ayzyjcdh90gs3gzrtq4f94033heng6w34s0pzq2yfv0g 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.
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.
Sounds like a great way to totally break the outbox model. What happens when I want to connect to an outbox relay and none of my current relays have its NNS? It literally breaks.
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 nostr:npub1h0rnetjp2qka44ayzyjcdh90gs3gzrtq4f94033heng6w34s0pzq2yfv0g 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 nostr:npub1nstrcu63lzpjkz94djajuz2evrgu2psd66cwgc0gz0c0qazezx0q9urg5l
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 nostr:npub1nstrcu63lzpjkz94djajuz2evrgu2psd66cwgc0gz0c0qazezx0q9urg5l
Hope you have time to check out the nostr:npub1h0rnetjp2qka44ayzyjcdh90gs3gzrtq4f94033heng6w34s0pzq2yfv0g launch on the 4th of July in the meantime!
We released the Scionic Merkle Trees last year on the 4th of July too. Freedom. š¦
> broadcasted
broadcast
I am
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.
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://
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.