Schedule peer interactions through muxrpc life-cycle events
pfrazee opened this issue · comments
Instructing the other side to replicate (as scuttlebot does now) is complex. I propose we define muxrpc's lifecycle events and have peers schedule their work independently of each other:
| state | event |
|---|---|
| both connected | connect |
| both working | - |
| one finished | 'finished' message |
| both finished | close |
On 'connect', the peers should evaluate each other (via metadata, #5) and determine which tasks they want to complete. The tasks then begin (working phase). When finished, the peer sends a 'finished' message, or, if a 'finished' message has already been received, the peer closes the connection.
For replication, scuttlebot would determine if the peer has the ssb-replication API, and, if so, issue its createHistoryStream calls
okay what I'm working on now, the first thing the clients do is authorize, my signing a timestamp, plus they indicate what role they have... so a replicating peer would be role: 'peer' but a client would be role: 'client'.
Replication can start after authorization.
Yeah, roles could be an interesting approach. Roles could encode quite a bit of information. I just posted #5 (comment), which I'd say should be a competing approach to roles. That is, we should go with one or the other -- either roles suggest what APIs are available and at what version, and peers decide how to act based on the roles, or API contracts suggest what the roles are, and peers decide to act based on the available functions.
This has been addressed in scuttlebot