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.