Gitea
next.orly.dev/docs/names.md at main
next.orly.dev - Total rewrite of ORLY to simplify and make it more robust
this is a novel consensus protocol that uses nostr relays for storage and rendezvous connections, to process name registrations (as in DNS names) and registration updates (mainly assigning them to new npubs).
just for the fuck of it i threw in a TLS replacement that uses nostr cryptography and the noise protocol instead of AES256 CBC/CFB types of encryption used in SSL, it's going to be using sha256, probably chacha20poly1305 as the cipher stream (although, to be fair, AES-NI is faster on most hardware if the compiler supports using it) CSPRNG, because hey, we can integrate ACME challenges into the protocol, so relays can verify bindings between a name and an IP address.
the consensus is based on one designed by lesterpig, the inventor of the "sporeDB" database replication protocol, which more recently he refined and upgraded to become "PnyxDB" named after the forum in Athens where democracy first happened.
it works by relay operators specifying their trust ranking of other relays that they do, or do not, particularly, want to replicate their version of the database, and based on the user assigned trust scores, and the trust scores assigned by those users towards other candidate new trtansactions, and it accepts them if they pass 50% trust and ignore them if they don't.
this creates what i'm going to refer to as a "lumpy consensus" that is fairly consistent between nodes but different enough that because it's fully peer-driven, subjective evaluations, the only attack on this consensus is a social one, so, there is no central lever in the consensus, it's less than 100% consistent, maybe it varies from 75-99% agreement on the consist of the database, but because to coordinate an attack on the consensus one has to recruit more than 50% of the relay operator population in order to beat the un-manipulated choices of the remainder, creates a lot of friction for attempts to compromise it.
this proposal completely covers every aspect, even ones you hadn't considered, such as the integration of acme challenges for verifying the server is controlled by someone who also controls the nsec of the registration. because it's a p2p network, the reason for integrating the connection encryption with it is that you can basically turn the network into letsencrypt, without the single point of failure. so there can't be a monopoly market in third party attestations, either, because the cost for robust attestations is trivial.
putting this at the OS level is just augmenting the DNS client in most OSs with a nostr client that reads and caches relevant data from the consensus, same way as a BIND9 client does. because the actual database is stored in a nostr relay, the name service client doesn't have to cache anything, it can just pick any random replica to query for name resolution requests. but you can also run a replica yourself, and always have an up to date database of all the registered names and never wait for the network to know where to connect.
i intend to build this thing in the near future. and i think that this, whether what i make catches on, or an improved version, is going to be 100% a thing on nostr within the next 12 months. we are going to most resolutely get the attention of the cabal rolling this technology out, though they aren't gonna figure it out until after it's already in the wild.
there may be small details and maybe my design isn't quite right to do the job fully yet but it's a likely good starting point, and once it exists, nostr can fully detach from the IANA namespace. so, please do read, and criticise the shit out of it, make counter-proposals and whatever else.
the sooner we can detach from the DNS and TLS cabals the better.
DNS is the main vulnerability in nostr right now. it depends heavily on it. if it could move that dependency INSIDE nostr that would be a phenomenal defense against compromise of the desirable properties of the protocol.
