Big Bad John's avatar
Big Bad John 5 months ago
Why don't people ask "which google.com?" when you tell them to go visit it? There are theoretically unlimited alternate versions of any given .com, right? Such dominance of reputation (ICANN allowing you to say ".com" with confidence, and know which website that really is) requires both great trust and actual physical enforcement (gov violence in this case). But, the truth is, in the background we do ask "which google.com?" when we send that URL into the browser. We ask through DNS, but we offer total trust and dominance to ICANN. Such naming solutions are not exclusive from any given network model anyway, thus arguably off-topic. Pubky users could put their key in ICANN DNS, or point to the same server from both the key and their .com, right? And finally, this of all begs the question of which situation you were really in where you had no other choice but to ask someone to memorize your domain name? It's barely an edge case imo, and I think if we scrutinize any examples, they would be weak... Here's the dynamic distilled: 1. Names are subjective, thus cannot be owned. 2. Names can be declared, but are unenforceable without real-world physical restriction. - Typically this requires violent enforcement my government - But could also include other physical limits, like distance, connectivity, and... encryption! What? How? We can map these concepts to PKDNS easily. But here we have the physical limits enforced by encryption instead of violence. It is too much work to brute-force an ed21559 key, so it allows enforcement of the "names" (signed dns records) you declare in your PKARR! This should all fit together as a consistent mental model for anyone interested in these ideas!

Replies (17)

Good topic for Nostr, the DNS-itch is real here. Pretty much agree here. But this all does hinge a fair amount on: >which situation you were really in where you had no other choice but to ask someone to memorize your domain name? It's barely an edge case imo. I wonder if such situations are indeed barely edge cases? I think its worth stress testing this question, chase out situations where you really don't have another choice, or you do but that other choice is so awkward that in your mind you may as well not have it, and see what emerges. Is it folly to sweep all these under the edge-case rug or is it fair? I suspect though that even for situations that do emerge there are ways of dismissing them by introducing new norms, habits and so on; meaning the feeling that you didn't have a choice was a real feeling, and has to be taken seriously, but it was as a result of cultural conditioning and not some law of physics. Useful exercise though.
Big Bad John's avatar
Big Bad John 5 months ago
No need to imagine such a stress test, we are building it every day, right? :) We have no nicknaming on the Pubky roadmap (despite having some interesting ideas around it). As a system, you have to use the keys. Will people strap on ICANN? Probably! Then how do we even test?!
I looked at it. Things I understood: it's just a few bytes on chain and this ZK proof stuff seems en vogue for good reason. When you obtain a sub-domain then, as long as the transfer to you is committed to chain, it's yours forever. The auction system is also better than most. Things I didn't understand: It's partly positioned at Nostr but unless I'm confused then it seems not to actually work with Nostr's core architecture, and Nostr changes its core architecture for no man, woman or beast. It also has a bespoke DHT, which, I dunno. Mainline or full-on client-side validation like RGB both make sense, but stuff in the middle seems kinda danger-zone.
The argument you're actually up against is that such architectures make "names" themselves superfluous, be they ICANN names, SpacesProtocol names, ENS names, Handshake names, or any other human-readable names for which there can only be a single one of each within the borders of its system.
It's not about there being no human-readable names. It's about removing the enforced uniqueness for them. So removing the uniqueness police officer, whether that police officer is officer ICANN or officer Spaces or officer ENS... Like in the real world. Bob is Bob and Alice is Alice, but Bob doesn't have the right to be the only Bob, nor Alice Alice. But we still figure it out. You're Curious here. Which is human-readable. Your pubkey is your uniqueness, There is no police officer needed. Or rather physics is the police officer and that's a police officer we can accept. Also all of these non-physics police officers do a bad job anyway. Let's say I’m fire77@bitcoin. But there are many other @bitcoins, on many other protocols (Handshake, Unstoppable, etc.). Unstoppable is by far more popular than Spaces right now. So you have to say “I’m fire77@bitcoin on the Spaces Protocol, not Unstoppable or any of the other ones.". Then you have to say "by the way don’t go typing it in your browser or try to send an email it won't work...” If trying to enforce uniqueness becomes an impossible farce, why try to enforce? It's the annoyance of being policed with none of the benefits. Why not just say “I’m fire77, search for me on Nostr” or "find me on Pubky". Or here's my QR, whatever. Because that is what in truth is the most human way. Trying to say no two people can have the same name as each other, if you think about it, is kinda un-human. That's the argument anyway. I mostly agree.
You're missing the point on uniqueness. You can have a practical resolution for hard to read public keys that is not unique. We all have such a thing on Nostr. It's fine. Your uniqueness in the real world is your DNA and your history. It's not your name. Your name is a non-unique practical resolution for your DNA. We don't enforce some 1 to 1 name to DNA ratio. If we did that would be policing. Why should online be any different? SpaceProtocol is about such control and policing. All are. And it's silly anyway because curious@bitcoin is not practical at all. I could go register curious@bitcoin somewhere else right now. That's how you can tell that it's not uniqueness enforced by physics. It's humans playing with bubbles. If it were enforced by physics there could only be one in the world. Physics isn't sloppy.
Yup good debate. >NOSTR is NOT doing naming just fine. It relies on DNS and ICANN. That’s centralized and fragile. Spaces Protocol solves this by creating decentralized unique names without gatekeepers. Nostr does not rely on ICANN for my public key, nor does it rely on ICANN for @Garbage nsec my handle, or my description, or my web of trust, on and on. That all taken together is enough to represent me on Nostr. Nostr of course does rely on ICANN for my NIP05, but that's pretty useless to me, so I made it a joke NIP05. (If Primal takes it away tomorrow I could care less.) Nostr also relies on ICANN for relays, which are things and not people. If SpacesProtocol could resolve relay IPs that'd be welcome, but to do so would require communicating with a trusted node, TLS fingerprints, and all sorts of other things SpacesProtocol doesn't do. >Humans value naming, we’ve built systems to enforce uniqueness (first, last names, SSN’s, drivers licenses, passports, etc.). First and last name combos are not unique. SSNs are not human-readable. You only get both if you have an enforcer. >You yourself have a name, a picture, and a centralized zap address. Why aren’t you using your npub? Spaces Protocol mirrors this reality as a tiny permissionless layer on bitcoin. The only reason I have a zap address showing on my profile is because I can't hide it. I don't need it shown at all. People can zap my posts and I'll get the sats no problem. Whether my zap address shows in my profile or not is irrelevant to zapping. People can also zap my profile without caring about my zap address. If my zap address were a long string of numbers it'd all still work fine. >Spaces Protocol isn’t about control, it’s about providing the coherence users desire without central authorities. Protocols scale in layers, Bitcoin will scale in layers, Spaces Protocol is the Bitcoin identity layer. It is about establishing a court of law. Let's say I go and inscribe curious@bitcoin on a Satoshi (very easy, I could do it today). Now curious@bitcoin exists on the bitcoin chain, forever, in two places. You'll tell me your curious@bitcoin is the "right one". But you can't argue it's the "right one" because it's "on bitcoin". My curious@bitcoin is on bitcoin too. Mine is also newer. All you can do is point people to the judge, in this case SpacesProtocol, and ask the judge to affirm your case and dismiss mine.
It's not permissionless, though. It's simply automated permissioning. I need SpacesProtocol's permission to register @bitcoin on SpacesProtocol. At the moment SpacesProtocol's automated permission system denies me. I don't need anyone's permission to create an npub on Nostr and assign the handle @Garbage nsec to it. That is actual permissionless naming for social.
Yes but duplicates for what? For names of people. Bitcoins are not people. This would be the equivalent of the maternity ward nurse saying to a new father and mother, sorry, you cant use the name Jane Smith, that one's taken.
Making a Bitcoin public key discoverable is what's valuable. But you do not have to slap on a third-party-protocol-policed name for that. First, there are other ways. Second there is no good answer to the question "which third party"? This is what all the Bitcoin and Bitcoin-adjacent naming services look like to neutral people, each service claiming to be the single source of truth for @whatever. Spaces is just one of the hands in the air. How is that a good user experience? image