Slave mode (non-duplex)

[refset]

This would be a useful feature for an implicit authorisation model.

[dominictarr]

you can't be a slave with out a master, so you'll need that too.

basically, a master will not allow any update, except from itself https://github.com/dominictarr/scuttlebutt/blob/master/index.js#L67

(or maybe a small set of co-masters)

And a slave should regect local updates https://github.com/dominictarr/scuttlebutt/blob/master/index.js#L59

Also, don't do this if it's a slave https://github.com/dominictarr/scuttlebutt/blob/master/index.js#L147

And skip this if it's in master mode: https://github.com/dominictarr/scuttlebutt/blob/master/index.js#L163

[refset]

Ah, then maybe I don't mean "slave" in the normal sense then, because I want local updates - sorry! Basically I want one-way replication. So you can still use both scuttlebutts like normal.

Master-slave as your describing though would be good for some type of clustering load distribution, I'm sure.

[juliangruber]

You can also check out https://github.com/juliangruber/authoritee which lets you add authoritative nodes to your meshes.

[dominictarr]

@jez0990 what is your use-case?

[refset]

As it's topical: using a decentralised public data set (e.g. npm 2.0) where you don't want private/local data (modules) propagating upstream but keeping a uniform/transparent/minimal API for the layer above (e.g. npm cli)

[dominictarr]

I am concerned about mixing a read only replication with a datamodel you can update.
seems like you could get into messy states... are you sure that is the best way?

[refset]

That concern is valid, this would only be appropriate for a class of CRDT models that don't abstract over the history. So crdt's Seq wouldn't work but Set and my DAGDoc thing would.

[refset]

Okay so I just realised that being able to work out retrospectively what is and isn't local/private would be very difficult with what I'm proposing. And that feels important. So scrap this!

I think the solution to what I want is to have two scuttlebutts where contents from one can reference the id's from within the other. No replication between them :)

[dominictarr]

sounds like you are using one scuttlebutt as a local data model - nothing wrong with that, really. you could use that for persistance or, for replicating data across tabs.