Add a SharePolicy

[alexjg]

Problem: we announce documents to all connected peers and we share documents with anyone who knows the document ID. Most applications probably want some control over authorization.

Solution: introduce SharePolicy, which is a trait users implement and pass to Repo::with_share_policy to control when documents are shared.

This is a pretty naive encoding of a SharePolicy trait. In particular it returns a BoxFuture<'static, ..> for each method on SharePolicy, which means we're doing dynamic dispatch on every access control decision. I think this is probably not an issue given that the IO we're doing should dominate runtimes, but if it becomes an issue we can add a generic parameter to Repo and thread that through.

[gterzian]

Reviewing...

[gterzian]

Looks good, and I think the design could be made clearer by moving stuff around and ending up with a state machine approach similar to DocState.

Something like a authorization_states: HashMap<RepoId, ShareAuthorization> to be found on DocumentInfo, and which would contain all data, including futures to poll, with only share_decisions_to_poll: HashSet<(DocumentId, RepoId)> found on the Repo as a way to integrate with the event-loop.

[gterzian]

Request is ambiguous here, because it could be that we've succesfully loaded the whole doc from storage. Could have a branch that requests if is_boostrapping, and one that announces otherwise if should_sync.

[gterzian]

I would rather see:

fn enqueue_share_decisions(
    doc_info: &mut DocumentInfo,
    share_authorizations_to_poll: &mut HashSet<(DocumentId, RepoId)>,
    /// the same below
)

Which would only process repos for the document which do not have already an authorization.

[alexjg]

Great feedback. I've not done quite what you suggested. Instead I've introduced a PeerConnection enum, which is similar to the ShareAuthorization idea you've suggested but it doesn't track the futures, which I have left on the Repo. There are a few reasons for this:

• I think we will definitely need multiple futures running at once. The first place this will become necessary is in a change I want to introduce soon where we persist sync states to disc. In this case as well as waiting for authorization we will also need to wait for storage to load the sync state. Tracking the futures in the PeerConnection enum would mean every variant of the enum having to track every combination of futures. It seems cleaner to track the futures at the Repo level.
• Fairly soon I am planning to extract the core state machine of this libary into a separate module which is independent of IO and runtime so that we can use it via FFI in other platforms (esp. Swift and Kotlin). In this case the future would be an artifact of the integration with async runtimes in Rust.

[gterzian]

extract the core state machine of this libary into a separate module

Great idea!

Reviewing...

[gterzian]

LGTM, with some comments that may need addressing.

[gterzian]

Are these not just the keys of pending_share_decisions, in which case this is redundant?

[gterzian]

first apply received sync messages?

So this branch is hit if the peer sends us a sync message while our announce request is pending, in a way it happens when two peers connect, and one of them get permission to announce, and we receive the sync message before the local request to announce has completed?