Love it - what about “multiple relays run by individuals in the group” rather than a single relay? That way you get better uptime, etc. or does trying to have multiple relays just make it harder?
People seem to be excited about my new project, Flotilla. It's still very much a WIP (probably a month out from MVP), but since it's been discovered I figured I'd go ahead and introduce it.
My goal for Coracle has for a long time been to support local in-person communities by replicating Facebook's events, groups, and marketplace. I've come to realize a few things about this project:
- Facebook is not the gold standard. In fact, people hate Facebook.
- There are many kinds of groups, for many different use cases.
- Very small chat groups work for most use cases.
- For almost all other groups, good moderation is key.
- Decentralization for groups works differently from decentralization for microblogging. Microblogging use cases benefit from simultaneous use of multiple relays. Community group use cases (in contrast to reddit-style groups) benefit from a single relay per group.
This is just the barest summary of what I've learned. But it's all in line with my long-held intuition that relays are, and should be, special. To that end, I'm creating a new client built around the dumbest form of communities that can be created: relays as communities.
Lots of code and specs need to be written to make this work, and as with Coracle, it'll be possible to host your own flotilla instance that only talks to a single relay, as well as use flotilla on desktop and mobile as a PWA and APK.
See the dev preview at https://flotilla.coracle.social. If you're interested in contributing, I've created several issues on the repository that should be good for first-time contributors: https://github.com/coracle-social/flotilla/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22
Discussion
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.
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