It does make it more complex, mostly because you then need to coordinate which relays constitute a group, and/or deal with missing context when relays don't actively replicate content between them, and when members only join one or the other. My plan is the go between the horns of the dilemma and support multiple relays, but in serial rather than in parallel through migration events.
Discussion
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
Interesting 🤔.
Who's revoking what key in that last part? The user, his key?
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
Delete content possible by user inside flotilla ? any plans for content delete feature?
Delete already exists, it would just be up to the relays to support it
does flotilla support NIP-42 auth same like coracle? if enable at relay then only WL can enter