This is great. My takeaway is : lets use a mapping system(dht) from a source key to a destination record that has proven for over a decade to be decentralised and have vast scale , rather than invent a convoluted square wheel of dubious or unknown value to do the same thing. If pkarr can seemlessly provide a generic application bridge to dht, then can nostr use that or are the two irretrievably incompatible ?
Check out this new interview with nostr:npub1jvxvaufrwtwj79s90n79fuxmm9pntk94rd8zwderdvqv4dcclnvs9s7yqz, a dedicated Synonym engineer responsible for Pubky Core.
He goes into lots of detail about the pragmatic thinking behind Pubky's design, and of course, Nostr comparisons.
I'm also very proud to see more of the team branching out and doing interviews.
The Synonym team is going to be turning heads in 2025!
Discussion
They cover this a bit in the interview, but generally Nostr devs don't like PKARR/Mainline because you can't use secp keys to do this.
Since we have to bootstrap it ourselves, it gives us the freedom to design things in a more elegant way, so we have our own homerservers (instead of relays), our own separated indexer and graph concepts, and soon, our own app to demonstrate most popular publishing and social use cases.
Home servers are the answer, it seems. Arent all bittorrent clients , by default, also configurable relays ? I know each meshtastic node is also a relay(effectively a homeserver), and each meshtastic node only sees a subset of the network because of physical radio broadcast distance constraints. Messages are propagated outwards through more distant nodes that see futher parts of the network. I think you spoke about some sort of similar constraint(algorithmically?) on the size of the subset of nodes accessible by each #pubky node ?
I dont fully understand the details, but am very excited about your work in principle