Add browser P2P connection check

This commit is contained in:
vorotamoroz
2026-07-31 14:13:34 +00:00
parent e32e3f545e
commit 48c398948a
20 changed files with 2710 additions and 8 deletions
+31 -1
View File
@@ -29,6 +29,28 @@ Serve `src/apps/webpeer/dist/` over HTTPS, or from `localhost`, then open `index
Keep the page open while WebPeer is expected to announce or transfer changes.
## P2P connection check
`check.html` provides a disposable preflight check for P2P connectivity. It creates a random encrypted Setup URI and QR code locally, joins the generated room as a browser reference peer only after explicit confirmation, and displays the browser's WebRTC diagnostic totals beside the QR code.
Use a dedicated empty Vault for every device:
1. Select desktop or mobile, then prepare the check.
2. Start the browser connection monitor.
3. Open or scan the Setup URI in an empty Vault with Self-hosted LiveSync installed and enabled.
4. Enter the separately displayed Setup URI passphrase.
5. Keep both peers open for the observation period and watch the successful-connection total.
6. Use **Show the Setup QR again** to return to the existing configuration without regenerating it.
7. For the clearest device comparison, start a fresh check before testing the other device.
A successful total greater than zero means that the browser and target established at least one WebRTC connection. It does not verify note synchronisation, sustained connectivity, or a direct desktop-to-mobile path. If representative checks repeatedly do not connect, CouchDB is the more predictable synchronisation option. An optional final check can use two disposable empty Vaults to verify a note round trip directly between the user's devices.
After the first device connects, **Try another device without resetting** keeps the browser, room, credentials, first device, and cumulative counters in place. The page records a local baseline, shows the same QR code for another empty Vault, and reports an additional connection only after both a new successful connection state and another simultaneous active connection appear. Keep the first device connected. Connections are not device identities, so this same-room route is convenient but a fresh check remains easier to interpret because reconnect activity is isolated.
Serve the production build over HTTPS or from `localhost`. Downloading `check.html` alone is not supported because the page uses built module assets and origin-scoped browser storage. The generated credentials are temporary and must not replace the settings of a production Vault.
The detailed scope and result semantics are recorded in the [browser-assisted P2P connection-check ADR](../../../docs/adr/2026_07_p2p_connection_check.md).
## Storage and lifecycle
WebPeer stores its settings, metadata, and chunks in storage belonging to the page origin. Consequently:
@@ -79,11 +101,19 @@ npm run test:unit --workspace webpeer
npm run test:browser --workspace webpeer
```
The focused browser-to-Obsidian E2E test builds both production artefacts, manages the local Compose P2P relay, applies the browser-generated Setup URI to two isolated empty Vaults without resetting the browser room, and retains the successful additional-device result under the Obsidian diagnostics directory:
```bash
npm run test:e2e:obsidian:p2p-connection-check:services
```
Configure `OBSIDIAN_BINARY` and `OBSIDIAN_CLI` when the E2E runner cannot discover them automatically.
The unit tests are stored in `test/apps/webpeer/`, outside the Community Review source boundary.
## Composition
`WebPeerRuntime.ts` owns the browser service composition, local database lifecycle, P2P replicator, and peer actions. `WebPeerPersistence.ts` owns origin-scoped settings persistence, while the shared P2P pane supplies the connection and peer controls.
`WebPeerRuntime.ts` owns the browser service composition, local database lifecycle, P2P replicator, and peer actions. `WebPeerPersistence.ts` owns origin-scoped settings persistence, while the shared P2P pane supplies the connection and peer controls. The connection-check modules create an isolated runtime with in-memory test settings and derive user-visible results from Commonlib's browser-side diagnostic events.
## Licence