@automerge/automerge-repo-network-websocket 1.1.4 → 1.1.8

package/README.md

@@ -25,38 +25,37 @@ Before sync can continue each peer needs to exchange peer IDs and agree on the
 protocol version they are using (although currently there is only one version).
 Handshake is the following steps:
 
-* Once a connection is established the initiating peer sends a
+- Once a connection is established the initiating peer sends a
   [join](#join) message with the `senderId` set to the initiating peers ID and
   the `protocolVersion` set to "1"
-* The receiving peer waits until it receives a message from the initiating
+- The receiving peer waits until it receives a message from the initiating
   peer, if the initiating peer receives a message before sending the join message
   the initiating peer SHOULD terminate the connection.
-* When the receiving peer receives the join message
-    * if the `protocolVersion` is not "1" the receiving peer sends an
-      [error](#error) message and terminates the connection
-    * otherwise
-        * store the `senderId` as the peer ID of the initiating peer
-        * emit a "peer-candidate" event with the sender ID as the peer
-        * respond with a [peer](#peer) message with the `targetId` set to the
-          initiating peers peer ID, the `senderId` set to the receiving peers
-          peer ID and the `selectedProtocolVersion` set to "1"
-        * begin the sync phase
-* Once the initiating peer has sent the join message it waits for a peer message
+- When the receiving peer receives the join message
+  - if the `protocolVersion` is not "1" the receiving peer sends an
+    [error](#error) message and terminates the connection
+  - otherwise
+    - store the `senderId` as the peer ID of the initiating peer
+    - emit a "peer-candidate" event with the sender ID as the peer
+    - respond with a [peer](#peer) message with the `targetId` set to the
+      initiating peers peer ID, the `senderId` set to the receiving peers
+      peer ID and the `selectedProtocolVersion` set to "1"
+    - begin the sync phase
+- Once the initiating peer has sent the join message it waits for a peer message
   in response. If it receives any other message type before the join message
   the receiving peer should send an [error](#error) message and terminates the
   connection
-* When the initiating peer receives the peer message
-  * it stores the `senderId` as the peer ID of the receiving peer.
-  * it emits a "peer-candidate" event with the sender ID as the peer
-  * if the `selectedProtocolVersion` is anything other than "1" the initiating
+- When the initiating peer receives the peer message
+  - it stores the `senderId` as the peer ID of the receiving peer.
+  - it emits a "peer-candidate" event with the sender ID as the peer
+  - if the `selectedProtocolVersion` is anything other than "1" the initiating
     peer sends an [error](#error) message and terminates the connection
-  * it begins the sync phase
+  - it begins the sync phase
 
 #### Peer IDs and storage IDs
 
 The peer ID is an ephemeral ID which is assumed to only live for the lifetime of the process which advertises the given ID (e.g. a browser tab). Peers may optionally advertise a storage ID in the `join` and `peer` messages, this is an ID which is assumed to be tied to a persistent storage of some kind (e.g. an IndexedDB in a browser). Many peer IDs can advertise the same storage ID (as in the case of many browser tabs). The use of a storage ID allows other peers to know whether to save and reload sync states for a given peer (if the peer advertises a storage ID, then save and reload the sync state attached to that storage ID).
 
-
 ### Sync Phase
 
 In the sync phase either side may send a [request](#request), [sync](#sync),
@@ -71,13 +70,13 @@ from the `NetworkAdapter` on receipt.
 
 In some cases peers wish to know about the state of peers who are separated from them by several intermediate peers. For example, a tab running a text editor may wish to show whether the contents of the editor are up to date with respect to a tab running in a browser on another users device. This is achieved by gossiping remote heads across intermediate nodes. The logic for this is the following:
 
-* For a given connection each peer maintains a list of the storage IDs the remote peer is interested in (note this is storage IDs, not peer IDs)
-* Any peer can send a [`remote-subscription-changed`](#remote-subscription-changed) message to change the set of storage IDs they want the recipient to watch on the sender's behalf
-* Any time a peer receives a sync message it checks:
-  * Is the sync message from a peer with a storage ID which some other remote peer has registered interest in
-  * Is the remote peer permitted access to the document which the message pertains to (i.e. either the `sharePolicy` return `true` or the local peer is already syncing the document with the remote)
-* The local peer sends a [`remote-heads-changed`](#remote-heads-changed) message to each remote peer who passes these checks
-* Additionally, whenever the local peer receives a `remote-heads-changed` message it performs the same checks and additionally checks if the timestamp on the `remote-heads-changed` message is greater than the last timestamp for the same storage ID/document combination and if so it forwards it.
+- For a given connection each peer maintains a list of the storage IDs the remote peer is interested in (note this is storage IDs, not peer IDs)
+- Any peer can send a [`remote-subscription-changed`](#remote-subscription-changed) message to change the set of storage IDs they want the recipient to watch on the sender's behalf
+- Any time a peer receives a sync message it checks:
+  - Is the sync message from a peer with a storage ID which some other remote peer has registered interest in
+  - Is the remote peer permitted access to the document which the message pertains to (i.e. either the `sharePolicy` return `true` or the local peer is already syncing the document with the remote)
+- The local peer sends a [`remote-heads-changed`](#remote-heads-changed) message to each remote peer who passes these checks
+- Additionally, whenever the local peer receives a `remote-heads-changed` message it performs the same checks and additionally checks if the timestamp on the `remote-heads-changed` message is greater than the last timestamp for the same storage ID/document combination and if so it forwards it.
 
 In the `browser <-> sync server <-> browser` text editor example above each browser tab would send a `remote-subscription-changed` message to the sync server adding the other browsers storage ID (presumably communicated out of band) to their subscriptions with the sync server. The sync server will then send `remote-heads-changed` messages to each tab when their heads change.
 
@@ -205,7 +204,6 @@ it
 
 Sent when a peer wants to send an ephemeral message to another peer
 
-
 ```cddl
 {
   type: "ephemeral",

package/dist/index.d.ts

@@ -14,6 +14,6 @@
  * */
 export { BrowserWebSocketClientAdapter } from "./BrowserWebSocketClientAdapter.js";
 export { NodeWSServerAdapter } from "./NodeWSServerAdapter.js";
-export type { FromClientMessage, FromServerMessage, JoinMessage, LeaveMessage, ErrorMessage, PeerMessage } from "./messages.js";
+export type { FromClientMessage, FromServerMessage, JoinMessage, LeaveMessage, ErrorMessage, PeerMessage, } from "./messages.js";
 export type { ProtocolVersion, ProtocolV1 } from "./protocolVersion.js";
 //# sourceMappingURL=index.d.ts.map

package/dist/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;KAaK;AACL,OAAO,EAAE,6BAA6B,EAAE,MAAM,oCAAoC,CAAA;AAClF,OAAO,EAAE,mBAAmB,EAAE,MAAM,0BAA0B,CAAA;AAC9D,YAAY,EAAE,iBAAiB,EAAE,iBAAiB,EAAE,WAAW,EAAE,YAAY,EAAE,YAAY,EAAE,WAAW,EAAE,MAAM,eAAe,CAAA;AAC/H,YAAY,EAAE,eAAe,EAAE,UAAU,EAAE,MAAM,sBAAsB,CAAA"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;KAaK;AACL,OAAO,EAAE,6BAA6B,EAAE,MAAM,oCAAoC,CAAA;AAClF,OAAO,EAAE,mBAAmB,EAAE,MAAM,0BAA0B,CAAA;AAC9D,YAAY,EACV,iBAAiB,EACjB,iBAAiB,EACjB,WAAW,EACX,YAAY,EACZ,YAAY,EACZ,WAAW,GACZ,MAAM,eAAe,CAAA;AACtB,YAAY,EAAE,eAAe,EAAE,UAAU,EAAE,MAAM,sBAAsB,CAAA"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@automerge/automerge-repo-network-websocket",
-  "version": "1.1.4",
+  "version": "1.1.8",
   "description": "isomorphic node/browser Websocket network adapter for Automerge Repo",
   "repository": "https://github.com/automerge/automerge-repo/tree/master/packages/automerge-repo-network-websocket",
   "author": "Peter van Hardenberg <pvh@pvh.ca>",
@@ -13,7 +13,7 @@
     "test": "vitest"
   },
   "dependencies": {
-    "@automerge/automerge-repo": "1.1.4",
+    "@automerge/automerge-repo": "1.1.8",
     "cbor-x": "^1.3.0",
     "debug": "^4.3.4",
     "eventemitter3": "^5.0.1",
@@ -31,5 +31,5 @@
   "publishConfig": {
     "access": "public"
   },
-  "gitHead": "e819a7ed6302ce34f372b119ea3e8bab052e3af6"
+  "gitHead": "fa2e5c0309458f244a81e49501dc882c5074f8ad"
 }

package/src/index.ts

@@ -1,9 +1,9 @@
 /**
  * A `NetworkAdapter` which connects to a remote host via WebSockets
  *
- * The websocket protocol requires a server to be listening and a client to 
+ * The websocket protocol requires a server to be listening and a client to
  * connect to the server. To that end the {@link NodeWSServerAdapter} does not
- * make outbound connections and instead listens on the provided socket for 
+ * make outbound connections and instead listens on the provided socket for
  * new connections whilst the {@link BrowserWebSocketClientAdapter} makes an
  * outbound connection to the provided socket.
  *
@@ -14,5 +14,12 @@
  * */
 export { BrowserWebSocketClientAdapter } from "./BrowserWebSocketClientAdapter.js"
 export { NodeWSServerAdapter } from "./NodeWSServerAdapter.js"
-export type { FromClientMessage, FromServerMessage, JoinMessage, LeaveMessage, ErrorMessage, PeerMessage } from "./messages.js"
+export type {
+  FromClientMessage,
+  FromServerMessage,
+  JoinMessage,
+  LeaveMessage,
+  ErrorMessage,
+  PeerMessage,
+} from "./messages.js"
 export type { ProtocolVersion, ProtocolV1 } from "./protocolVersion.js"

package/test/Websocket.test.ts

@@ -10,7 +10,7 @@ import {
 import { generateAutomergeUrl } from "@automerge/automerge-repo/dist/AutomergeUrl"
 import { eventPromise } from "@automerge/automerge-repo/src/helpers/eventPromise"
 import { headsAreSame } from "@automerge/automerge-repo/src/helpers/headsAreSame.js"
-import { runAdapterTests } from "@automerge/automerge-repo/src/helpers/tests/network-adapter-tests.js"
+import { runNetworkAdapterTests } from "@automerge/automerge-repo/src/helpers/tests/network-adapter-tests.js"
 import { DummyStorageAdapter } from "@automerge/automerge-repo/test/helpers/DummyStorageAdapter.js"
 import assert from "assert"
 import * as CBOR from "cbor-x"
@@ -27,7 +27,7 @@ describe("Websocket adapters", () => {
   const serverPeerId = "server" as PeerId
   const documentId = parseAutomergeUrl(generateAutomergeUrl()).documentId
 
-  runAdapterTests(async () => {
+  runNetworkAdapterTests(async () => {
     const {
       clients: [aliceAdapter, bobAdapter],
       server,
@@ -422,7 +422,7 @@ describe("Websocket adapters", () => {
         documentId: DocumentId
       }> {
         const storage = new DummyStorageAdapter()
-        const silentRepo = new Repo({ storage, network: [] })
+        const silentRepo = new Repo({ storage })
         const doc = A.from<T>(contents)
         const handle = silentRepo.create()
         handle.update(() => A.clone(doc))
@@ -587,7 +587,7 @@ describe("Websocket adapters", () => {
       }
 
       let localHeads = A.getHeads(clientDoc)
-      let remoteHeads = A.getHeads(handle.docSync())
+      let remoteHeads = handle.heads()
       if (!headsAreSame(localHeads, remoteHeads)) {
         throw new Error("heads not equal")
       }