Oddbean

Neat, thanks. I have another follow up question based on when I tried to use off the shelf clients (damus, iris, snort) with a single private relay and kept seeing events leak into public relays… are you worrying about the problem of using existing clients and preventing them from re broadcasting notes to relays which might be hardcoded (or cached maybe) in the client code? Back when I tried using a single private relay between multiple off the shelf clients, my process was: 1. Download a client 2. Remove all initial relays in settings 3. Add my private relay 4. Use the app And I couldn’t get events to stay off the public relays. Granted this was a while ago, and if a client can render an event, then it necessarily has everything it needs to send it elsewhere and a code audit might be the only actual solution. Anyway curious if you’ve thought on this and are focusing or testing this problem at all?

Yeah, I've thought a lot about it. In theory, there's nothing you can really do to keep private data private once it's published — someone can always take a screenshot of your note. There are a variety of techniques that can help in practice though: - Use AUTH to implement read access - Use NIP 70 to ask other relays not to store your events - Strip signatures (this is the nuclear option, it basically breaks nostr, but could be used in specific situations) - Encrypt your content - Use clients that are smart about replicating stuff - Include relay urls in events and have both relays and clients validate that the event came from the designated relay (this isn't done anywhere, but I may use it for flotilla).

strip signatures is an interesting one the farcaster protocol has a signature system whereby the signature is delegated via the hub you post to, you can't verify it unless you can get the hub's pubkey directory and find the key i dunno if it really changes anything except making the event questionable... ah yes, and repudiation has a benefit here, if the key were revoked before the date of the event it could be surmised that a compromise has occurred

oh i thought of another one... certificate chains, like DNS certificates your client can demand such attestation about the software and if it doesn't provide one then it can refuse to send the event to it certification organisations are a very important part of decentralised governance governments are shit at it because it's not voluntary

hm that one is a hard one though... since the only way to verify source code is to hash the binary, and what is the process for how to sign the binary as it's running exactly that's a good question... it's on my mind because i've been inspecting the CosmWasm architecture this last week and one of the things they have in there is a verification that ensures that a source code and a binary version are linked, this thing is a big issue in smart contract engineering - how to ensure that things are deterministic, and it kinda matters with source code too there's a lot more to but how exactly can you be sure a server is running the software version it says it is, and not some altered version? you can't! at least not trivially

this question of identifying the software being run on the other side of a network connection is a bit of a difficult one and one that i can see there being problems with snooping tyrants enforcing software development licensure and preventing broad access to software that is either in-development or outlawed uncle bob had a good speech on that one and this train of thought has got me wondering ultimately it doesn't matter, does it? right? the relay has some database, doesn't mean it's the same as another relay, doesn't mean the same code is running, any protocol decision based on such things probably is doomed to be useless ultimately because you can probably not enforce this for real without an inordinate amount of resources spent because of the bazillion ways that it can probably be worked around but... well, government... this would be a sign of the latest stage of a technocratic system though, software licensing... it's been a theme in cyberpunk for decades nostr:nevent1qvzqqqqqqypzqnyqqft6tz9g9pyaqjvp0s4a4tvcfvj6gkke7mddvmj86w68uwe0qqsg75la9mtrcy49fg9r9a8maae6nmjwuf752lq2y9xpe30gnq4glucjawvm3

there's too many moving parts to ever make it practical to certify what you are connecting to Don't Trust, Verify this is not just the mantra of #bitcoin but it is the mantra of the internet we now have AIs that probably can produce reasonable fingerprints of server code that can be used as identifiers they are not deterministic because the code is one thing, and the data is another, and the interplay between them can be unexpected and random certificate chains on deterministically produced software can exist and have a purpose but they only are of use to those actually executing the code and gathering state in their application that interacts with that code, as well as the inputs from the outside ultimately, it is a great black void you connect to, and everything that comes back from it is untrustworthy by default, unless you can verify it nostr makes it so the users themselves create the authentication on their content and after having dealt with the schemes of Bluesky and Farcaster, neither of which have a direct signature on events, i can say that the epic vulnerabilities this could create cannot be underestimated if bluesky or farcaster ever have a large enough economy tied to them the profitability of violating their consensus system will be very high you simply can't do that with nostr... all events are only authorized by the users, the data the relay handles is intrinsically untrustworthy, exactly the same as the relay software itself

ah thanks means relay .env either allow all or explicitly need to enable "event kind 5" NIP-09 github .com/nostr-protocol/nips/ i am trying easiest relay and been fooling around with few so far kind_whitelist: enabled: true kinds: [10209,209,0,1,3,4,5,7,9,10,11,13,14,28934,10001,10003,9735] still got 😭 or another one try - open all then put filter slowly https://image.nostr.build/0ab2b367002083cac59170d80f144c403a89fa9ad5fe23c91b8a115e2e589d45.png