On Peers in Automerge-Repo: Design about automerge-repo HOT 2 OPEN

re: storage being passive - I was thinking of trying to shim in something (when I'm further along on the implementation) to allow the storage to not be passive. In particular, I can watch for and get notifications of filesystem changes, which I could use as a "something changed" signal (for example, if someone updated the file on Dropbox and it sync'd across).

I haven't fully implemented the remote-heads bits in my work, but the hooks are there. I honestly hadn't been sure what the purpose for them was and how they were used, and it's on my reading list to sit down and trace javascript code to find out, so you short-circuited that by quite a bit by cobbling this (thank you! - kind of like finding a syncstate in local storage)

re: Peers, right now I'm not storing or tracking anything what IS right now, so no historical tracking of peers. That said, I have expanded on what a peer is for the peer to peer networking pieces that I'm in the midst of writing - in addition to a peer_id, I've added a human-friendly name that can be included with that peerId. I'm sticking to UUID for the peer Ids - although I accept any string. I'd like to have some confidence that it had some uniqueness properties though - I'm just "hoping" right now, and it would be an annoying bug if they weren't)

Along those lines, I'd really like to see us firm up any constraints/expectations on PeerId in terms of uniqueness guarantees, if not specific format.

I'm also applying "peer" to the owner of a repo, since. a repo can have multiple network adapters, to handle the scenario where you might be connected to a peer over two different networks, and I want to avoid the duplication of tracking. So I'm somewhere between "peer as owner" and "peer as session", which probably isn't a great place to land.

The only issues I saw with perhaps using the storage Id as a "true peer" are:

1. you don't HAVE to have a storage adapter, and at that point there's no storage Id, which throws a monkey wrench into a lot of this - what's the fallback there? Or do we say we always have a storage Id, even if it's ephemeral/in-meory only like a repo with no storage provider?

2. there's no clear communication channel upward for a storage system today to say "I just got this update, please apply it to your in-memory representations". Other than an in-memory test storage provider, I haven't written any providers for the swift/Apple native platform pieces yet, where I might tackle the signal back up from storage to the repo, letting it know there's been an external change.

from automerge-repo.

If I was starting from scratch this is how I'd maybe set it up:

• userId: A stable identifier for a single human, bot, or server. Assigned by the application. Could be a uuid, domain name, or email address. Replaces peerId as used by sharePolicy.
• sessionId: An ephemeral identifier for a single instance of Repo. A uuid, randomly assigned in the constructor.
• deviceId: A stable identifier for the device we're running on. A uuid, randomly created on first use by the storage adapter. Different browsers on the same physical device count as different devices. (This is just storageId but with semantics that make more intuitive sense to me.)
• peerId: { userId, sessionId, deviceId }

from automerge-repo.