>the Outbox model is as complicated as it is and often not supported because it's complexity
>>wut? What is so complicated about the outbox model? Also, the fact it is often not supported is because most developers did not realise that was the intended way of doing things, a notion that fairly recently got more traction. So whether it is too complicated to implement is something that remains to be seen, but certainly not the reason why it is not commonplace today.
It’s definitely more complicated
but everything is so simple in nostr that more complicated means still pretty easy compared to most protocols
Compared to a DHT? especially one that you don't have to implement because it is already implemented plenty and you only need one function call to find exactly where the endpoint is because the user authoritatively said so?
Outbox model not at least an order of magnitude harder to deal with? Forget about the happy path when both you and your target use the same relay set... let's talk about what happens when you don't and you have to find the relays they published their profile on.
ill let you know when I’ve implemented them both and compared them
Sure, but is it prohibitively complicated?
Lol nah. Nostr devs are just spoiled by most things being so easy to implement that you barely need to be awake to build them.
true
Who said anything about difficulty.. it is complex, as in there are too many things you have to reason about to achieve any acceptable level of reliability compared to DNS.
Maybe I am totally wrong, but my ignorant assumption is, the moment you and your target don't happen to use the same relays, and you have to go find their profiles somehow else, you immediately start looking at a very much worse algorithm than Kademlia...and a one with way more assumptions most of them about social graphs ... compare that to Kademlia and DNS.
Anyway, we both options are available and if either has enough demand it will be used.
We have a solution if your contacts have a nostr address: you can store your relays in your nip05 metadata. Unfortunately i don’t think many nip05 providers set this up properly from your relay list.
We currently rely on a few large hub relays to store relay lists, but as the network gets bigger a dht might make more sense. Not sure what nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 thinks.
Of course, relying on DNS is a perfect way to scale.. the question is do you want to use ICANN as the root server, or millions of nodes in an overlay network that has been actually winning censorship fights for more than a decade.
Fiatjaf keeps insisting that DHTs don't work regardless of how many proofs I show him. He also would rather make up a bespoke tiny DHT than use Mainline because he thinks breaking compat with secp would kill Nostr.
I can't say it won't.
But if you can support nip5... you can support Pkarr. Or don't I am in this for the system design conversation, more than any desire to change how any existing systems or products work.
I agree that breaking compat with secp would be unnecessary complexity
I think the combination of "well-known" public relay list (kind:10002) directories like purplepag.es + nip05 hints + relay hints in events whenever someone is mentioned in a Nostr event + nprofile/nevent relay hints are enough to allow any client find out where any other public key is publishing to. The world is not so big after all and even on the internet no real person is capable of consuming content from more than a few thousand others at best.
If nostr:npub1jvxvaufrwtwj79s90n79fuxmm9pntk94rd8zwderdvqv4dcclnvs9s7yqz wants to call this a kind of DHT that sucks so be it, to me it makes more sense because it is more flexible and fluid, can be implemented in parts and incrementally, and in the best-case scenario (the one in which you get the relay address from an immediate hint, for example) it is more efficient than any DHT.
I am also not against having a Nostr DHT for this either, as I told him a million times. But the DHT would necessarily be just another method to help in the task of finding a relay list.
Here is Kademlia algorithm:
1. you ask the closest nodes you know about, about a key.
2. some will answer either data, some will respond with the even closer nodes they know about.
3. you repeat step 1 for the nodes you were told about from step 2 until you run out of nodes you haven't visited already.
You can implement this in a month in a new programming language that you are still learning. Better yet you can graph one of the 100s of implementations and get access to millions of nodes.
Now, what is the simplest algorithm for the Outbox model if I am trying to dind the Outbox relay of a key that hasn't published their profile to a relay I am already connected to?
Is it only simple when we all have one relay in common? Because everything is simple when there is one central reliable source of truth.
nostr:note1ft33hptz4csg4p7kmdvx692fra5m07ufz5ye5mtyrngqz2s6rzuqc6gvs8
