Thread

What people want is, I believe, the following things: Privacy: data protection, metadata protection, and IP privacy. Censorship Resistance: decentralization purports to assist in this goal, but I don't think "decentralization" is the goal.. the goal is censorship resistance. Control and Independence: people don't want to be locked-in to one provider that could in the future disappoint them. The following hot ideas are not so hot in my book: federation - if you are still locked in, this just changes the scale of centralized lock-in. blockchain - an ugly solution to a problem that nobody has. p2p - an artificial binding of clients to servers (I will explain in a sister thread).

IP privacy. I've talked about this before, but this is here for completeness. If you do something like outbox model, clients will be connecting to whatever servers the protocol (other people's events) is telling them to use, such as perhaps honeypot.nsa.gov. And this happens automatically without you typing it in and choosing it. BTW this also happens if I go to a website and that website tells my browser to pull a javascript library from honeypot.nsa.gov... it would happen automatically, I didn't type it in, and I'm not even aware that it happened. So IP privacy is a thing we care about. IP privacy, if achieved at the IP layer by a solution that is decoupled from the rest of the solution here, is IMHO the better outcome. Tangling together IP privacy solution (garlic/onion/leek routing) with a social protocol just locks you into a possibly inferior IP privacy solution. I think VPNs and Tor are 'ok' but maybe we will see a new better IP privacy solution come along. Sometimes you can solve IP privacy 'good enough' by having a node act as a proxy, and so at the social application layer that kind of architecture should be possible, but that doesn't need to be in scope when defining a client-server protocol.

p2p. People want it mainly because they don't want to rely on data centers. But let's walk through an example. Perhaps you have a node in your home network, and I have a node in my home network. For these to communicate, one of them has to contact the other one first. So let's say my node contacts your node. Ok. Then my node is acting like a client, and your node is acting like a server. So in fact p2p IS actually client-server. It is just a special case of client-server, where the clients and servers are forced to be glued togther into a node. Therefore IMHO, client-server architectures cover all p2p architectures and more. And gluing the client and server together is a completely unnecessary requirement. In fact, I want clients on transient machines, laptops that I turn off. But I don't want servers offline, I want them on hardware that stays on. So the p2p node idea falls apart. Clients and servers should be separate. But of course this isn't all that people are talking about when they talk about p2p. They are talking about hole-punching. So all I'm trying to argue here is that client-server is not some worse alternative to the superior peer-to-peer, but rather that client-server is the superior architecture. And it makes more sense to me to suggest that there should be ways to make servers acccessible to the Internet even if they run on home networks, perhaps with hole-punching rendezvous services. Running a server at home is an excellent idea. But nothing else about p2p seems like a good idea to me.

Nostr is a new topology. It's a multi-star topology. Its client-side replication control. It's sovereign identity. It's not mesh. It's not people. It's not blockchain. It's something new and it solves problems we didn't know we had until we had nostr.

P2P spell corrected is people.

I think people want connections, influence, friends, money, information

This slide jumped out at me: 1. privacy 2. censorship resistance 3. availability 4. control But privacy is a subset of control. Censorship resistance is a subset of availability. There are only two things here: control, and availability. control * availability = agency Therefore, the purpose of distributed systems is agency

you forgot sex

nice. He makes passing reference at people wanting control over data and metadata (point 4 in your list) but doesn't explain why, and counterpoints it with his best argument which is that centralized solutions can evolve faster.

End-to-end encryption isn't everything. We can never know if the encryption we are using is good enough. So it is always a good idea to use additional techniques for security. Even if those obscurity solutions are weaker, they are still something when added on top of the hopefully strong encryption. Governments spend inordinate amounts of money on decrypting things. They want to know what other world leaders are saying behind their backs. The USA has an entire agency dedicated to this, the NSA. But IMHO they aren't just decrypting everything. They most likely have to pick and choose where to focus their resources. If you route your data through Signal or Tor, you are painting a target on it that says "This data wants to be private". That makes such data more likely to be targetted by governments for decryption. If your data instead transits little-used servers in obscure data centers or in people's houses, like nostr relays, especially personal nostr relays, that target painting doesn't happen. So I'm not a fan of routing everything through Signal. Maybe even it is a bad idea for Iroh to route QUIC connections through their relays when hole punching fails. I'm sure Iroh relays aren't doing anything nefarious yet, but if it gets popular then the government(s) may force them to and also force them to not tell us. It is another target painting situation. And so I'm not sure that hole punching is such a great idea.

I like p2p for the following reasons Communication should work for two isolated nodes in a cave or on some planet in Andromeda. It is the only fully permissionless way to communicate. That being said. None of it is real. You can't actually connect any two devices without permission unless you are basically close enough to talk. So when I say peer-to-peer I always mean it very loosely. Or should I say specifically. I mean that if you can get data from node A to Node B then that should be all that the protocol requires. I shouldn't care about how that happens. I also shouldn't worry about any intermediary being able to sniff or spoof the data. They can deliver it... or not. You can't alter that. This is partially why I am going with sending metadata only packets. Node A sends some encrypted packet to Node B. Who cares what is in it. That is up to the application to care about. If you want more data, tell the other node a filehash in your notification packet and then they can ask anyone for it. Who cares where it is cached? It is just a blob of encrypted meaningless data. Of course since you get a whole packet to state your case for doing whatever actions the application is capable of, no reason not to just stick your 1024 byte tweet in there instead of downloading separately..... Anyway. I agree that the actual topology that you end up with is client server, but I still think it should work on a local network as well.

Peer-to-peer means not having a 3rd node sitting in the middle of the communication in some data center. E.g. rather than client->server->client it is just peer->peer. But I've run across people who think a client-server protocol necessarily isn't peer to peer. I'm just trying to argue that the p2p protocols are still client-server protocols. Nostr could be written as a p2p application without changing any of the NIPs, just by making every client also a relay. Your point is the part I didn't discuss because it wasn't in my head at the time --- the middleman. You want direct communication over anything with no middleman. Fair enough. And I think that should be achievable, even if the communicating pieces are a client and a server.

Leslie Lamport would fundamentally disagree with you regarding your 'not so hot' ideas.

In what respect? I'm a fan of his work.

Yes, that. I would add that the nodes should also have full control of what other nodes they connect to. Your Honey Pot is a good example. You also touched on it via protocols that have dedicated hole-punch IPs. I call this "no special nodes" No node should have a special or even default role in the network that any other node could not fulfill at the behest of client nodes. Some initialization is needed, but the closer it can be driven by end-point choice the better.

Solutions to the Byzantine generals problem such as Paxos or Raft are more general than blockchain. And other solutions to distributed computing problems exist like conflict-free replicated data types. My problem with blockchain is that it is an infinitely-growing public ledger, and that while bitcoin needed it, not much else needs precisely that. Many things may benefit from something *like* blockchain, but not actually blockchain. And for a decade people have been running around with a beautiful hammer (blockchain) looking for nails to hit, and not finding any interesting nails (problems) so they started creating nails so that they would have a use for their beautiful hammer. Take git for example. It is both distributed and it has a blockchain. But it's not a bitcoin-like blockchain requiring some network of nodes and Raft to operate. Most problems can be solved more like git and less like bitcoin. Bitcoin is the only real problem I can think of that actually needs what bitcoin did.

A rule that goes hand in hand is "no special codes" there will, of course, be protocol level identifiers, but things like Blockchains, URLs, global names that require an authority are out. All meaning is what the users say it is.

He would argue the Bitcoin blockchain is the first and only open system solution to the Byzantine Generals problem. He would also probably go on to say its temporal structure enforces agreement on history. Neither of those outcomes are ugly.

Lol, that is a funny statement. That is like a Royal line thinking they will evolve faster if they keep it in the family. I don't think we all know what evolve means.

If you have a reference I'd appreciate it. I believe Paxos is the first solution invented way back in 1989 but published in 1998. And Raft is technically equivalent to Paxos. I'm sure he's proud that such a solution is now widespread in bitcoin, but bitcoin blockchain isn't the first and only solution. But these are solutions to the problem of consensus among bad actors. Do we need consensus in social media applications? The only reasonable place we might want consensus is usernames, not that we need them, but that users seem to want to declare and own a globally unique one and you would need a consensus system to give users what they want. But I'm not sure the juice is worth the squeeze, and petnames avoid all the trouble. If you are going to bother building a network of peers, a consensus algorithm, and an ever growing blockchain, you'd better be solving a problem that is worth all that trouble. Bitcoin clearly was. Usernames in a social media protocol don't seem to be worthy of such a heavyweight solution. I shouldn't have said "ugly", I should have said "heavyweight."

Yes I would agree with that. Outside bitcoin and obviousness of a time chain very little else benefits from blockchain and it's bloat.

Theoretical solutions count for nothing. Only open systems impacting reality. But obviously technically you are correct.

And yes I agree with the overarching position that blockchain really only matters if you are solving for a fundamental truth of universal ongoing value.

At least in nostr with the outbox model, there is no routing, and nodes don't control which other nodes they communicate with. I imagined the thing just like browsers connecting to websites. But a completely different architecture could be routed, where a node connects to certain known and trusted neighbors only, and data is routed node-to-node. Such protocols are slower and less reliable, having so many middle-men, but of course if you use Tor under nostr you are pretty much doing that same thing. I lean towards clients connecting to untrusted nodes. And clients being considered very difficult to develop because they must be security hardened. In the same way that browsers must be. In a similar way that computer hardware has to be bug-free before they tape out. Making nostr "simple" proliferates insecure half-assed software. I lean towards complexity as a way of weeding out developers who can't be trusted to make hardened software. But this is just a current leaning. I'm interested in exploring architectures where clients don't have to talk to nodes they don't trust... I just don't see the big picture right now of how this could work without so many downsides.

I should also say that open timestamps are well solved by blockchain. So that's 3 things: money, timestamps, and universally unique usernames.

I don't think it has to be super complicated.. at least you can aim for exactly what you need and nothing you don't to try to keep implementation "easy" and bugs low. For instance I wouldn't send a timestamp. It isn't that you don't want them, it is that you can't trust them. Things are just going to break if you require timestamps and then try to do clever things with them. No one will use them consistently or correctly. I do agree that Nostr's simplicity makes everything else you want hard. If you want to encrypt properly.. good luck. The best you can do is TLS and just trust your relays. Back to p2p, yes it is slow and buggy, but we can have the best of both worlds by doing web-of-trust stuff in a peer-to-peer like fashion but actually disseminate data in a traditional hub and spoke architecture. I wouldn't make it wide open. I think you want authentication as part of the protocol for automatic spam suppression, but you can still have big servers serving stuff. I am tempted to make requesting files non-authenticated. If they are just identified by their hash, good luck guessing a 32byte string. The counter argument is that if you know a commonly shared file "never gonna give you up" then you could find out who is interested in it by seeing whose relays have it cached. Authentication should be fairly straightforward however, a server just accepts connections from a list of keys (not the user's master, just one they use for talking to that server) If I am using a particular relay as a mailbox, I can give it a list of my friends keys to filter on. So every request is something like <Recipient Encryption Key> <Sender Signing Key> <Ephemeral Sender Encryption Key> <Signature> <Payload> I complect things further by having those first two keys Scoped to specific application permissions so the final destination node knows how to unpack the Payload. Key management needs to be perfect. I don't want a "Words with Friends" app to be able to read bank transactions. With properly scoped keys you could leak your whole keystore database to a malicious application developer and still not be compromised. (Assuming encrypted at rest) All that, I get off on such tangents, to say, while the key requirements etc may be complicated the actual protocol does not need to be.

Speaking of software and security, does Gossip AppImage look for new updates or would that be a security issue?

It doesn't look for new updates. I'm not against it though.

Neither Paxos or Raft count .. all these solutions assume a permissioned set of mostly trusted but maybe unreliable actors. Bitcoin is in a different game; permissionless set of adversarial assholes.