By that I mean the trackerless bittorrent, pure DHT, it is a marvel and very underappreciated
Bittorrent, ~tens of millions of nodes.
DNS is needed for a reason though, for making URL useful even after IPs change.
People following each other can always find each other, but for public keys to be useful beyond that as URLs, they need to be resolvable in a censorship resistant way and not depend on relays to be that layer, rather use the biggest overlay network in existence now, and never assume that relays list records will be stored for long.
Basically, publish records on Mainline BEP0044 and keep republishing them periodically.
I have working code showing how that works and scales very nicely github.com/nuhvi/pkarr
Example:https://pkarr.nuh.dev/?pk=o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy
Bittorrent DHT is simple enough this can be implemented in any language, currently trying to reimplement it in Rust
I wish Nostr architecture was described as message queues too.
Message queues are great for ephemeral messaging, but once you need to host a web page, or backup important data for long term, you will need more. You will need personal data servers and you will need stable long-lived identifiers and you will need direct relationship with a trusted hosting provider(s), not a loose set of random relays, you will also need versioning like Git and access control like Dropbox or Google drive.
If we don't build that it will be left to AtProtocol and then the did:plc will become the defacto identity for that use case, and that did is even worse than ION, at least ION aims for the right things.
If you make VoIP chat using webrtc you are leaking your IP to your contact, even in Signal, hell, you are leaking your IP to signal server all the time, it is all tradeoffs.
There is no such thing as perfect privacy.
Don't get me wrong, all of that effort and work is great, it's by no means a must have and telling people that Matrix has unacceptable privacy issues, while they are using Telelgram and Twitter DM, is a bit unwise.
I am all for client side embedded servers/nodes, but you didn't solve much if you still need a store and forward server.
The only difference here is then, users will be custodial of the signing keys instead of the server offering availability. Is that a good thing? Depends, it comes with its pains.
Regardless, metada will still leak, that's the nature of relaying data in a performant way, as in non-onion-routing
Sir routers can see what IPs you are visiting, regardless of Https, so unless you are using Tor you are leaking metadata, even a VPN is just changing who you are leaking to.
If you are concerned about metadata, run your own server, p2p won't help you here because simply put: you still need a hosted highly available homeserver, otherwise the UX and reliability will be unacceptable to most people.
Anyways, this is overstated and exaggerated a lot, people leak metadata to their ISP and their favorite cafe's wifi router all the time.
If anything that can be done it will be added to Matrix, in the meantime, it is the best there is.
Almost all of the metadata leak is in the centralized identity server, I am proposing using no identity server at all and relying on public keys ans local contact lists.
Also, there is no alternative, Signal is not an open protocol or a federated network that you can integrate in Nostr clients, it is either Matrix or reinvent your own.
Eventually the Matrix Protocol phopea will subside and Nostr clients will implement Matrix rooms. All Signal's privacy, with no phone numbers or centralized server.
npubs won't work with any existing DHT because they are secp, ed25519 works great though.
Check: pkarr.nuh.dev
and github.com/nuhvi/pkarr
as for private groups, if we just use something like Pkarr, you can open a Matrix account and clients can use both your nostr key for timeline as well as Matrix for encrypted groups
for example I already publish both my npub and Matrix ID (you can find that on my Nostr timeline and Twitter bio arnazeh)
Not only they are very vocal, but they are also not that much of a minority, maybe middle easterners won't be as much of antifas but they will be anti alot of stuff.
Also, weighted by their income, which matters for sustainable businesses, they are a massive majority.
Your vision and proposal screams Personal Data Servers with access control etc. Something like Solid or RemoteStorage or Matrix but with less focus on rooms and more generic API closer to the spirit of S3
As you said, there might be a good chance whoever is going to build that platform won't be as chaotic as Nostr
It is hard to design that platform well regardless of the model.
users demand it, go on Bluesky and see how many users are screaming that they want moderation not federation nor decentralization... it is the nature of Twitter clones.
the vulnerability to protocol capture by popular apps is true, but Nostr is not immune to that.
if you create your own relay, and the most popular client simply refuses to connect to any relay that hosts you, or censor any of your events, you get the same problem.
the best point in this post was the criticism of did:plc, because that is just a shit show
Bridges prove that people are fairly trusting of unsigned data, unless they have a reason not to. Not sure how to feel about that.
However it suggests that routing to a source of truth is even more important, as in, people would go check the source of truth, not verify a signature!
So maybe signed data should focus on decentralized markets and reputation systems, not broadcasting and speech.
Is it terrible or is it advanced and you weren't there from the ground floor? Can you see a way to deliver the same features without becoming as complex? Or is Nostr going to stay forever as simple as it is now to keep the simplicity claim?
There is a good chance Nostr will stay resistant to features (Nip26 not widely adopted nor any alternative), but then the question is how are we going to have personal data stores, more user friendly identity and private chats and VoIP?
My answer is as I said, an identity that abstracts Nostr and email and others, so clients that want these advance features can actually compose them.
The good news is, that is already possible without the permission of any protocol or client. But it will expose interoperability for what it is; very political.
Here is my ID served fresh from Bittorrent DHT, and kept alive by refreshing every hour, I also validated that a single 4 cores vps can keep 120k records with ease.
This is the most simplest solution for decentralized discovery ever, it gets hairy any direction you go. (Strong opinion held lightly etc)
https://pkarr.nuh.dev/?pk=o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy