search

ssbc / ssb-ebt

secure scuttlebutt replication with epidemic-broadcast-trees
MIT License
18 stars 10 forks source link

Actively replicating up until a specific sequence #79

Open staltz opened 1 year ago

staltz commented 1 year ago

Context

Private Groups (and removal of peers) seems like it will require a change to ssb-ebt, for a feature that currently doesn't exist.

Private Group removal has a specific requirement that the removed peer's feed should still be preserved (also for new members, which means that the removed peer's feed has to be actively replicated), BUT simultaneously all new messages published by the removed peer have to be ignored.

One option is to continue replicating the removed peer's feed, but hide them in the UI. This might likely be a good enough strategy for a first deployment of this feature. But soon enough, we will have to stop replicating new messages for that feed, because it's a security risk. If the removed peer was pathologically dangerous, we don't want to give that peer the opportunity to explicitly spam the group and cause an overflooding of msgs in every peer's log.

Problem

ssb-ebt currently seems to allow replicating (reminder: this means both serving that feed and requesting that feed) a feed, but no other customizations are allowed. Since we need new group members to get the removed peer's old messages, we have to serve that feed via ssb-ebt, but serving also means requesting updates to it.

Proposals

A

One idea is to allow specifying a sequence number to truncate the feed.

B

Another idea is to split the replication input so that you can serve a feed as a separate operation from requesting that feed. For most cases, you would default to doing both serve & request, but for the use case of removed group members, we could just serve the feed without requesting it.

However, that has a problem: a new group member needs to request the feed of the removed group member, and this may cause them to accidentally get the newer post-removal msgs (suppose e.g. that the new group member is a friend of the removed group member, and they are connecting directly via LAN).

Maybe we can do both options A and B?

arj03 commented 1 year ago

Will respond to these later today

arj03 commented 1 year ago

If we go with the multiple feeds solution, then I think we should be able to use the rx/tx flags in EBT to signal that we can replicate the messages we already have for the removed peer, but we will not receive later messages from that peer. A new peer that might want these old messages could set their mode to receive and later when in sync with these messages would change their state. This is somewhat related to #80. Will respond there as well.