Contact me on Tilde.Chat to exchange banners!
SSB Log Entry 1101
pigeon-protocol
Huge Brainstorming Doc - Part II
Out-of-Band Signals via query.pgn
This is an idea that I would appreciate feedback on from all the smart SSB / Earthstar / Bamboo folks.
What if, instead of signalling interest about feeds in-band, interest was instead signaled out-of-band?
Theory of operation:
- Every time you give a peer a bundle, you add a
query.pgnfile to the bundle. query.pgncontains a list of all the blobs, messages and feeds (or partial feeds) you care about.- You could also request resources on behalf of a friend-of-a-friend.
- The size of
query.pgnwould shrink and grow over time, depending how out-of-sync your peer is.
- (Possibly dangerous??) The
query.pgnfile is signed by the author using their feed key to verify authenticity. Does authenticity even matter if clients are free to ignore response messages they didn't ask for? Does not signing a query add a layer of plausible deniability (privacy)? - (Possibly less dangerous but more complicated?) The
query.pgnfile is signed by the author using a special key? (Where would we generate such a key? And does it matter?) - After ingesting a
query.pgnfile, the remote peer makes a note of desired resources for the peer that requested it. This would be implementation specific, but basically every client would maintain a "routing table" for the sake of bundle creation. - The next time the remote peer sends an inbound bundle, it might contain the resources the peer requested (if available). It might contain things the user didn't ask for, but those can be selectively ignored.
Here's a pseudo code example of what information a query.pgn file would Convey:
I want blob FILE.JKL
I want all of USER.XYZ's feed. The whole thing, including any blobs it references.
I want USER.ABC's feed, starting at message `TEXT.DEF` and ending at message TEXT.GHI, including blobs referenced and any Lipmaalinks required for partial verification.
I want message ____, plus the minimum required Lipmaalinks required to verify.
The time is now 2:34am
The signature for this message is _____
Your direct peers would have access to the things you want to block and follow, but a well behaved client would never store that information in a feed. Outside observers would never know what resources you have asked for in the past unless a peer maliciously leaks your query.pgn file. Making query.pgn unsigned could add a layer of deniability, but might come with security risks (feedback welcome).
Advantages: * Less meta-data, less "noise", more privacy * It's ephemeral * Don't need to tell peers who we're requesting the information on behalf of * Peer never needs to tell anyone who they are following / blocking. * Peer never explicitly states what information it has on disk- either the resource shows up in the next bundle sync or it doesn't. * You could make "custom bundles" that are significantly smaller than regular bundles because they were created with a specific recipient.
Disadvantages:
* It's a two step process. It could take days or weeks for the request/response cycle to complete.
* You would not be able to set a hops setting like in SSB- hops would be stuck at 2, since you only know the peers of direct peers (maybe OK for Pigeon's intended design).
* You would need to either:
* Use your signing key to sign meta data that lives outside the log (a bad thing?)
* Create a "friendship key pair" or a "meta data keypair" for signing out-of-band signalling documents.
* You would probably need to broadcast the public key in your feed.
Unsigned query files might be impossible or a huge security risk. More thinking is required in that regard.
Feedback Appreciated
To conclude I am trying to:
- Efficiently synchronize two peer's feed, even if conservation of disk space is not a design concern, it would be a nice-to-have.
- Improve privacy
- Improve ease of implementation for third party clients
- Reduce feed sizes by not storing meta-data in-band.
What does everyone think about this?
- Have I made a huge oversight with this idea?
- Are there risks associated with out-of-band interest/disinterest signalling?
- Are there risks in having plausibly deniable interest signalling? Denial of service comes to mind. :thinking_face: