Why though, why should Nostr solve what Matrix protocol already did extensively, Nostr shouldn't reinvent private messages or rooms, ammend and incorporate what's already great out there.

The simplicity argument won't hold forever as you tackle hard problems.

Alternatively we can use a decentralized discoverable identity that abstract both Nostr and Matrix and much more, so users and clients use what the web already has.

Shameless plug etc pkarr.nuh.dev

No, that's not how Signal works

We can build an adhoc DHT from Nostr relays, or even try to host the entire set of profiles of everyone on every relay, or implement gossip protocols between relays etc.

But all of these solutions are both unnecessary given that Bittorrent exist, and using relays for discovery contradicts their inherent interest of keeping paying users from migration.

Finally, decentralized discovery is useful for applications that doesn't speak Nostr at all, or doesn't want to use websockets etc. They still would benefit from a DNS interface backed by a permissionless distributed registry instead of centralized servers.

1- self authenticated records (data is signed, no need to trust the resolver)

2- permissionless (anyone can submit their data without negotiating with a small set of gatekeepers)

3- censorship resistant (taking down nodes or forcing them to censor some data doesn't disrupt discovery)

From an evolutionary perspective, Bittorrent DHT is the Bitcoin of decentralized discovery, it is the one system that was attacked the most by businesses and governments and it emerged from these attacks and out lasted them.

I am curious about Webdav and reading about it, although I am thinking it might be so old that something new is needed.

Either way, I think it makes sense to use Ed225519 as the base of identity to leverage Bittorrent DHT as Pkarr does. It shouldn't be used often anyways.

Didn't know that is at all possible, derive as in actually I can see npub and ed pubkey and verify they are related?

Either that works, or Nostr profiles include the ed25519 key, then use Pkarr to lookup the current relays if the user ever switched to an obscure or even single tenant relay.

Really bullish on this as I have stress tested as much as I could and didn't crack yet.

You can however (and I hope I get time to do it) fork a nostr client, so that it can return nostr events from a Pkarr key, if it had _nostr record, just like how clients support Nip05

No unfortunately it has to be ed25519 keys because it leverages the massive 15 yrs old BitTorrent DHT, and it doesn't return events it returns a <1000 bytes compressed array of Resource Records

Think of how BlueSky use TXT records to map domain names to DIDs, well the same but the domain name is a publickey and the Resources Records are signed.

The whole point of Pkarr is to only be anxious about the security of one key that is rarely used.

Also, while not part of the spec, I never store the keys anywhere, rather generate it in memory by hashing a passphrase which is secure enough and easily memorable. (Rhe CLI implemented this, and the web demo will have it soon).

So I guess if anyone cares, they can check my key and find out my current npub

https://pkarr.nuh.dev/?pk=o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy

Tried few things and never bothered to backup keys. This plebstr app is the first android app that feels good enough to invest in!

SRV assumes that you are running your own server and merely pointing to its ipv4/6. A better analogy is TXT records where you can point to both the server and the username in that server.

TXT is alive and well, we just need to make DNS more accessible and less rent-seeky

do me a favor, check pkarr.nuh.dev, and see if you can imagine using that to turn Matrix into a federated network with sovereign identity (like Bsky but with open DHT instead of consortium), and avoid reinventing that wheel

I am doing my part at pkarr.nuh.dev, soon I will build proof of concept for a client that leverages that identity, but in the meantime I need to actually get people to care

That is my point, the same solution for Nostt discoverability would allow you to own your identity in Matrix or at least a fork of Matrix clients: I.e using the DHT

Added Nostr to my resource records alongside Matrix id

https://pkarr.nuh.dev/?pk=o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy

Here is my key mapped to both Marrix and Nostr

https://pkarr.nuh.dev/?pk=o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy

One DHT based Resource Records to abstract and connect them all.

For example Nostr/Bluesky for timeliness, and Matrix for encrypted chat rooms and VoIP

I built the MVP as I promised, and validated its scalability (120k users' records can be kept alive with one 4 cores vps, before any caching layers)

github.com/nuhvi/pkarr

Any comments and issues are welcome there too.

Nostr lacks decentralized discovery, although with some open mindedness it can be added easily, and I did some work to prove it can scale (120,000 users records kept alive on Bittorrent DHT with one 4cores vps) see more at github.com/nuhvi/pkarr

But I am curious, if you do have decentralized identity with Pkarr, and you can add that to Matrix protocol, to patch the need for identity servers, what else is going to be missing from Marrix, it is also signed events protocol, but with a lot of time to mature and state of the art encrypted chat rooms with moderation and access control.

What is your best argument against Matrix? Also how long can Nostr stay simpler than Matrix if it is going to have all these features you mentioned?

Try pkarr.nuh.dev