Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unidirectional sync? #380

Open
skokenes opened this issue May 17, 2021 · 3 comments
Open

Unidirectional sync? #380

skokenes opened this issue May 17, 2021 · 3 comments

Comments

@skokenes
Copy link
Contributor

skokenes commented May 17, 2021

Can the new syncing protocol be used to sync in one direction only? Ie, assume we have a read-only peer that we don't want to accept changes from.

My use case involves a centralized server (hub) that peers communicate through. Some peers are meant to be in "read-only" mode; they should sync with data from other peers but aren't ever supposed to introduce their own changes.

Beyond the obvious "don't make changes to a peer you want to be read-only", is there a way to use the sync protocol in a way that ensures that even if a bad actor somehow makes a change to a peer that is supposed to be read-only, those changes will be rejected when syncing with other peers?

@ept
Copy link
Member

ept commented May 17, 2021

Interesting case. Can I restate it to see if I understood it correctly? Peer A is syncing with peer B, and you want to ensure that changes can only flow from A to B, but not vice versa. If B has made changes, A should reject them.

I haven't tried it, but I think the following might work. When A receives a message from B:

// Returns true if the message should be passed to receiveSyncMessage,
// or false if the message should be dropped and the connection closed.
function shouldProcessMessage(doc, message) {
  const parsedMsg = Automerge.Backend.decodeSyncMessage(message)
  const backend = Automerge.Frontend.getBackendState(doc)
  const headsKnown = parsedMsg.heads.every(head => Automerge.Backend.getChangeByHash(backend, head))
  return (parsedMsg.length === 0 && headsKnown)
}

@skokenes
Copy link
Contributor Author

Interesting, I will give that a go. The only part I don't understand is why you check parsedMsg.length === 0 at the end?

@ept
Copy link
Member

ept commented May 17, 2021

Oops, sorry, that should have been parsedMsg.changes.length === 0.

echarles pushed a commit to datalayer-externals/automerge-classic-arch that referenced this issue Feb 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants