p2party 0.8.0 → 0.14.2

package/docs/getting-started.md

@@ -0,0 +1,203 @@
+# Getting started with p2party 0.14
+
+p2party has two entry points:
+
+- `p2party` owns the browser room mesh: signaling, WebRTC, Redux state,
+  IndexedDB, OPFS when available, the protocol-v4 handshake, and message
+  transfer.
+- `p2party/session` owns only the protocol-v4 handshake and message
+  cryptography. Use it with Node, Bun, a native shell, tests, or your own
+  transport and storage.
+
+Install is in the [README](../README.md#install). This guide assumes you have
+the package and picks up from there.
+
+## Browser room mesh
+
+The root entry point requires a browser with WebRTC, WebAssembly, WebCrypto,
+Worker, and IndexedDB. OPFS is optional; the receive path falls back to
+IndexedDB when it is unavailable.
+
+```ts
+import p2party from "p2party";
+
+const invite = p2party.generateRoomInvite();
+const room = await p2party.joinRoom(invite);
+
+console.log("joined room", room.id);
+```
+
+`joinRoom()` is `connect()` plus a wait for the signaling service to assign the
+room its id. Use the two separately when you want to render a joining state, or
+when you need a deadline or cancellation:
+
+```ts
+await p2party.connect(invite);
+const room = await p2party.waitForRoom(invite, {
+  timeoutMs: 10_000,
+  signal: controller.signal,
+});
+```
+
+Every peer that joins the same room is connected to every other present peer.
+The signaling service coordinates discovery and WebRTC setup; it is not the
+message hub. A room with `n` participants therefore has up to `n(n - 1) / 2`
+peer edges.
+
+`connect()` resolving does not by itself mean that every peer edge has
+completed protocol-v4 authentication. The library gates message cryptography on
+the authenticated handshake. A UI should render peer and message state from
+the exported store rather than treating `connect()` as a global room-ready
+event.
+
+## Compact, fragment, and word invites
+
+Generate one capability and derive every presentation from the same bytes:
+
+```ts
+const capability = p2party.generateRoomCapability();
+
+const compact = p2party.encodeRoomCapabilityBase64Url(capability); // 43 chars
+const fragment = p2party.encodeRoomInviteFragment(capability); // v1.<compact>
+const words = await p2party.encodeRoomCapabilityWords(capability); // 24 words
+
+const fromCompact = p2party.decodeRoomCapabilityBase64Url(compact);
+const fromFragment = p2party.decodeRoomInviteFragment(`#${fragment}`);
+const fromWords = await p2party.decodeRoomCapabilityWords(words);
+
+await p2party.connect(fragment);
+```
+
+`generateRoomInvite()` is the one-line form when only the versioned fragment is
+needed. Put it after `#` in an HTTPS URL so ordinary HTTP requests do not carry
+the capability. The current `legacy-signaling` connection path still sends a
+normalized form to the signaling service, so this is not server-blind
+rendezvous.
+
+The word form is a checksum-protected encoding of the same 256-bit capability,
+not a lower-entropy replacement. Its fixed word-list identifier is exported as
+`ROOM_INVITE_WORDLIST_ID`.
+
+## PIN room with an exact ML-KEM suite
+
+Room policy is immutable after local room creation. Every peer must use the
+same policy and the same PIN bytes. The suite is fixed before the handshake;
+there is no in-band negotiation, downgrade, or classical fallback.
+
+```ts
+import p2party, { type RoomPolicyV1 } from "p2party";
+
+const invite = p2party.generateRoomInvite();
+const policy = {
+  ...p2party.DEFAULT_ROOM_POLICY_V1,
+  authMode: "pin",
+  pqMode: "hybrid-mlkem1024",
+} satisfies RoomPolicyV1;
+const pin = new TextEncoder().encode("replace with a room secret");
+
+try {
+  await p2party.connect(invite, undefined, undefined, { policy, pin });
+} finally {
+  // connect() copied it into the in-memory room vault.
+  pin.fill(0);
+}
+```
+
+The exact supported `pqMode` values are `hybrid-mlkem512`,
+`hybrid-mlkem768`, and `hybrid-mlkem1024`; ML-KEM-768 is the default. PIN
+bytes are deliberately absent from the public policy, Redux, persistent room
+records, and logs. PIN mode adds CPace authentication to the identity and
+ML-KEM handshake; it does not replace identity possession.
+
+Scheduled timing cover is wired as of 0.14: a policy may pin `coverMode:
+"scheduled"` with a cadence, lane count, and frames per cell, and every edge in
+the room then emits fixed-size cells on that schedule whether or not data is
+queued. Private rendezvous modes are still rejected by `connect()` because
+their live transport wiring is not complete.
+
+## Send, cancel, and read
+
+Wait until the room has peers before sending. Each logical send has a random
+transfer ID and opens a per-message data channel on every eligible peer edge.
+
+```ts
+const handle = p2party.sendMessage("hello room", "chat", room.id);
+
+console.log("transfer", handle.transferId);
+
+// Wire this to a cancel button. It also works during hashing/channel setup.
+const cancel = () => handle.cancel();
+
+try {
+  const result = await handle.done;
+  console.table(result?.outcomes);
+
+  const opened = await p2party.readMessage(result!.merkleRootHex);
+  console.log(opened.message, opened.percentage);
+} catch (error) {
+  // `done` REJECTS when no peer took delivery — an empty room, or a cancel.
+  // Both are ordinary outcomes, not bugs. The error carries the same per-peer
+  // detail a resolved value would have.
+  if (error instanceof p2party.MessageDeliveryError)
+    console.table(error.result.outcomes);
+}
+
+void cancel; // Remove when a UI event uses it.
+```
+
+`sendMessage()` returns a `MessageTransferHandle`, not a promise. `done`
+settles after all started peer sends and cleanup and reports ordered per-peer
+outcomes. A peer may be delivered, failed during setup/transfer, or skipped
+because it is disconnected, unauthenticated, or the transfer was cancelled.
+
+For an inbound message, take `merkleRootHex` (and, if needed, `sha512Hex`) from
+the room's exported `messages` state:
+
+```ts
+const rooms = p2party.roomSelector(p2party.store.getState());
+const message = rooms
+  .find((candidate) => candidate.id === room.id)
+  ?.messages.at(-1);
+
+if (message) {
+  const metadataOnly = await p2party.readMessage(
+    message.merkleRootHex,
+    message.sha512Hex,
+    false,
+  );
+  console.log(metadataOnly.filename, metadataOnly.size);
+}
+```
+
+`materialize = false` avoids assembling a completed file Blob; text is always
+returned. The application limit is 10 GiB. Cancellation is scoped most
+precisely by the handle's transfer ID, so prefer `handle.cancel()` over a
+content-hash lookup for concurrent identical sends.
+
+## Package artifacts and WASM
+
+The 0.14 package exports:
+
+- `p2party` — browser ESM/CJS root with declarations;
+- `p2party/session` — store-free ESM/CJS session API with declarations;
+- `p2party/libcrypto.wasm` — the exact compiled cryptographic module;
+- `p2party/libcrypto.provenance.json` — source/toolchain/digest provenance;
+- `p2party/docs/getting-started.md`, `p2party/docs/session-api.md`, and
+  `p2party/docs/protocol-v4-security.md` — installed developer and threat-model
+  documentation;
+- `p2party/examples/standalone-e2ee.ts` — a runnable source-checkout and
+  installed-package session example;
+- `p2party/THIRD_PARTY_NOTICES.md`; and
+- `p2party/package.json`.
+
+The tarball also contains the UMD browser build and generated database worker.
+The root bundle embeds the worker source; normal package consumers do not
+construct its URL.
+
+The browser root fetches the exact versioned CDN WASM under a build-pinned
+SHA-384 Subresource Integrity value. JavaScript and WASM are one release unit —
+never pair 0.14 JavaScript with an older WASM.
+
+Self-hosting those bytes, and passing them directly to `p2party/session`, are
+both covered in the
+[README](../README.md#local-self-hosted-or-release-pinned-wasm).

package/docs/protocol-v4-security.md

@@ -0,0 +1,158 @@
+# Protocol-v4 security boundary
+
+This document states what p2party 0.14's code path does, what observers still
+learn, and which adjacent mechanisms are not production properties. It is a
+developer threat-model summary, not an independent audit or a formal proof.
+
+Protocol v4 is a clean wire break. Missing, malformed, older, and mismatched
+wire versions fail closed; there is no legacy cryptographic fallback.
+
+## What establishes a peer edge
+
+There are three different acknowledgements in the system:
+
+1. An `RTCDataChannel` becoming `open` means the DTLS/SCTP transport and that
+   channel are ready. An in-band channel may have completed its DCEP OPEN/ACK,
+   but this is not p2party identity or key confirmation.
+2. The protocol-v4 handshake runs over the open main channel. After HELLO,
+   responder CONFIRM, initiator CONFIRM, and responder FINISH, the peers have
+   authenticated the same hybrid root and initial ratchet keys.
+3. Authenticated 65-byte receipt frames acknowledge message chunks and final
+   transfer completion. They are delivery/reconciliation signals, not handshake
+   establishment.
+
+An open data channel therefore is necessary transport readiness, not an
+established p2party crypto session.
+
+The handshake combines:
+
+- interactive 3DH proving possession of fresh ephemeral X25519 keys and
+  dedicated long-term X25519 identity keys;
+- Ed25519-pinned identities cross-signing those X25519 identity keys with a
+  domain-separated transcript;
+- one room-fixed ML-KEM-512, ML-KEM-768, or ML-KEM-1024 shared secret;
+- draft-21 CPace in PIN rooms; and
+- HKDF/HMAC transcript binding and three chained key-confirmation flights.
+
+The authenticated channel input binds the channel identifier, initiator and
+responder Ed25519 identities, ordered endpoint fingerprints, and exact ML-KEM
+suite tag. The room policy is fixed before traffic; a suite/mode mismatch
+poisons the transcript instead of negotiating or falling back.
+
+The initiator returns established only after receiving and verifying FINISH.
+The responder returns after successfully sending FINISH. Losing that final
+flight can leave the responder complete while the initiator waits and
+eventually fails. That is an availability/common-knowledge limit of the final
+message, not evidence that an attacker learned the root key.
+
+## Post-handshake message protection
+
+Every authenticated peer edge owns independent Double Ratchet state. Either
+role may send first, and simultaneous first sends are tested. Each logical
+message consumes one message-key step; its chunks share the authenticated
+ratchet header and use fresh nonces. Failed authentication rolls back the
+candidate receive state, and skipped-key storage is bounded.
+
+Each chunk frame is exactly 65,490 bytes:
+
+```text
+type(1) || DH public key(32) || N(8) || PN(8) || PQ epoch(8) ||
+nonce(12) || encrypted fixed plaintext cell(65,405) || AEAD tag(16)
+```
+
+The 69-byte clear header is authenticated as AAD, excluding the fresh random
+nonce. The PQ epoch is an unsigned 64-bit counter — widened from v3's single
+byte so the sparse post-quantum healing epoch cannot wrap.
+
+The fixed frame geometry absorbs the ratchet and AEAD overhead into the cell
+budget. Random padding and decoy slots can hide the exact payload length within
+one transfer's chosen number of frames. Receipts have a distinct fixed 65-byte
+geometry. Handshake flights are suite- and step-dependent rather than
+65,490-byte cells.
+
+Per-message channels give each transfer an independent lifecycle for
+cancellation, bounded channel accounting, receipts, selective retransmission,
+and reconnect resume. Channel isolation is a UX and reliability property; it
+does not make timing or channel count invisible.
+
+## Guarantees, assuming authenticated peer keys
+
+With a correctly pinned peer Ed25519 identity, uncompromised endpoints, matching
+room configuration, and successful confirmation, the implementation is
+designed to provide:
+
+- mutual possession authentication for the cross-signed X25519 identities;
+- optional shared-PIN authentication in addition to identity authentication;
+- a hybrid initial root dependent on both classical 3DH and the selected
+  ML-KEM exchange;
+- transcript binding to roles, identities, endpoint fingerprints, policy
+  suite, KEM fields, and initial ratchet public keys;
+- confidentiality and integrity for message cells;
+- forward evolution and post-compromise recovery from later uncompromised
+  classical DH ratchet turns;
+- replay/tamper rejection within the ratchet and transfer protocols; and
+- bounded out-of-order key retention and bounded per-edge transfer resources.
+
+These are implementation claims, not a claim of equivalence to Signal's PQXDH
+proofs or to a standardized X-Wing combiner. p2party's handshake is interactive,
+includes transport and optional CPace binding, and uses its own explicitly
+domain-separated combiner. The code has not completed an independent
+third-party cryptographic audit or a ProVerif/CryptoVerif analysis.
+
+## Observable metadata
+
+Encryption does not hide all communication metadata.
+
+The current legacy signaling operator can observe:
+
+- the normalized room capability and room membership;
+- peer identifiers and presented public identity keys;
+- signaling timing, SDP, ICE candidates, IP/network information, and TURN use;
+- room joins, leaves, and connection attempts; and
+- any fallback/relay metadata explicitly sent through server-controlled paths.
+
+A network observer can still estimate connection timing, endpoints where
+WebRTC exposes them, packet volume, transfer duration, and traffic bursts. An
+endpoint peer necessarily learns plaintexts it decrypts, peer identity, message
+ordering, and transfer activity.
+
+Fixed chunk cells hide exact plaintext length only within the frame-count
+bucket and chosen decoy allocation. With immediate delivery, observers still
+see when a message starts, how many cells/channels are active, when receipts
+flow, and when a transfer ends. Fixed cells without a room-wide schedule are
+not continuous cover traffic.
+
+Putting the capability in a URL fragment keeps it out of ordinary HTTP
+requests and common access logs, but the shipped legacy signaling path still
+receives its normalized value. A fragment is not a server-blind meeting point.
+
+## Shipped, implemented core, and research
+
+| Status                    | Exact boundary in 0.14                                                                                                                                                                                                                                                                                                                                                                                                  |
+| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Shipped public path       | Full WebRTC room mesh; protocol-v4 hybrid 3DH + exact room-fixed ML-KEM-512/768/1024 bootstrap; optional CPace PIN rooms; chained triple confirmation; per-edge Double Ratchet; fixed message cells and in-transfer decoys; per-message channels; authenticated receipts, cancellation, selective retransmission, reconnect resume; compact/fragment/word invites; store-free `createSession()`/`restoreSession()` API. |
+| Shipped, newer            | Sparse post-quantum healing (OFFER/ADVANCE/ACK epoch exchange) with persist-before-dispatch and application traffic blocked while an epoch is in flight. Room-wide scheduled timing cover: policy-pinned cadence, lanes, and frames per cell, emitted whether or not data is queued.                                                                                                                                    |
+| Research/design direction | Opaque/server-blind rendezvous and blind meeting points; a private BitTorrent-compatible swarm extension; multi-device/group-state designs beyond independent pairwise mesh edges; and machine-checked formal analysis comparable in scope to PQXDH work.                                                                                                                                                               |
+
+Scheduled cover is a room-wide property: it hides _when_ a peer has something
+to say only for as long as every edge in the room keeps emitting on the
+schedule. It does not hide room membership from the signaling operator, and it
+does not apply to rooms whose policy selects immediate delivery.
+
+## Deployment obligations
+
+Applications using `p2party/session` own several security-critical jobs:
+
+- authenticate or explicitly TOFU-pin peer Ed25519 keys;
+- bind the session to a real transport context and route handshake frames
+  without cross-session confusion;
+- keep long-term Ed25519/X25519 secrets in protected storage;
+- encrypt snapshots at rest and enforce rollback protection;
+- wipe caller-owned PIN, identity-secret, WASM scratch, and snapshot buffers
+  when their lifecycle ends;
+- enforce timeouts, message-size/resource limits, and abuse controls; and
+- update JavaScript and its exact release-matched WASM together.
+
+For browser-mesh setup and artifact behavior, see
+[Getting started](getting-started.md). For the standalone transport and
+snapshot contract, see [Store-free session API](session-api.md).

package/docs/references.md

@@ -0,0 +1,157 @@
+# References
+
+What p2party is built from, and what it is built on. Every entry links to a
+primary source: a standard, a paper, or the implementation itself.
+
+For the full research treatment — including a per-claim novelty assessment and
+142 verified citations — see
+[Related work and prior art](paper-prior-art-and-related-work.md).
+
+## 1. Cryptographic dependencies
+
+These are compiled into the shipped `libcrypto.wasm` or bundled into the
+package. Licences and notices are reproduced in
+[THIRD_PARTY_NOTICES.md](../THIRD_PARTY_NOTICES.md).
+
+| Project                 | Used for                                                           | Link                                                                                       |
+| ----------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ |
+| libsodium               | X25519, Ed25519, ChaCha20-Poly1305, BLAKE2b, HKDF, Argon2, SHA-512 | [github.com/jedisct1/libsodium](https://github.com/jedisct1/libsodium)                     |
+| mlkem-native            | ML-KEM-512/768/1024 (FIPS 203)                                     | [github.com/pq-code-package/mlkem-native](https://github.com/pq-code-package/mlkem-native) |
+| Emscripten              | Compiles the C cryptography to the pinned WASM module              | [emscripten.org](https://emscripten.org/)                                                  |
+| BIP-39 English wordlist | The 24-word room-capability encoding                               | [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md)       |
+| Redux Toolkit           | Browser-root state store                                           | [redux-toolkit.js.org](https://redux-toolkit.js.org/)                                      |
+
+## 2. Standards the wire format implements
+
+| Standard                                   | Where it appears in p2party                               | Link                                                                                                          |
+| ------------------------------------------ | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
+| **FIPS 203** — ML-KEM                      | Room-fixed post-quantum bootstrap and healing epochs      | [csrc.nist.gov/pubs/fips/203/final](https://csrc.nist.gov/pubs/fips/203/final)                                |
+| **RFC 8439** — ChaCha20-Poly1305           | AEAD for every chunk frame                                | [rfc-editor.org/rfc/rfc8439](https://www.rfc-editor.org/rfc/rfc8439.html)                                     |
+| **RFC 5869** — HKDF                        | Root and chain-key derivation                             | [rfc-editor.org/rfc/rfc5869](https://www.rfc-editor.org/rfc/rfc5869.html)                                     |
+| **RFC 7748** — X25519                      | Interactive 3DH and the ratchet DH turns                  | [rfc-editor.org/rfc/rfc7748](https://www.rfc-editor.org/rfc/rfc7748.html)                                     |
+| **RFC 8032** — Ed25519                     | Long-term identity keys and cross-signatures              | [rfc-editor.org/rfc/rfc8032](https://www.rfc-editor.org/rfc/rfc8032.html)                                     |
+| **draft-irtf-cfrg-cpace-21** — CPace       | PIN-room balanced PAKE                                    | [datatracker.ietf.org](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-cpace-21)                        |
+| **RFC 8831 / 8832** — WebRTC data channels | The transport every peer edge runs over                   | [8831](https://datatracker.ietf.org/doc/html/rfc8831) · [8832](https://datatracker.ietf.org/doc/html/rfc8832) |
+| **RFC 8122** — SDP DTLS fingerprints       | Endpoint fingerprints bound into the handshake transcript | [datatracker.ietf.org](https://datatracker.ietf.org/doc/html/rfc8122)                                         |
+| **RFC 9794** — PQ/T hybrid terminology     | How the hybrid security boundary is described             | [rfc-editor.org/rfc/rfc9794](https://www.rfc-editor.org/rfc/rfc9794.html)                                     |
+
+## 3. Papers the design follows
+
+**Ratcheting and the Signal lineage**
+
+- M. Marlinspike, T. Perrin. _The Double Ratchet Algorithm._ Signal, 2016.
+  https://signal.org/docs/specifications/doubleratchet/
+- M. Marlinspike, T. Perrin. _The X3DH Key Agreement Protocol._ Signal, 2016.
+  https://signal.org/docs/specifications/x3dh/
+- J. Alwen, S. Coretti, Y. Dodis. _The Double Ratchet: Security Notions,
+  Proofs, and Modularization for the Signal Protocol._ EUROCRYPT 2019.
+  https://eprint.iacr.org/2018/1037
+- K. Cohn-Gordon, C. Cremers, B. Dowling, L. Garratt, D. Stebila. _A Formal
+  Security Analysis of the Signal Messaging Protocol._ EuroS&P 2017; J.
+  Cryptology 33(4), 2020. https://eprint.iacr.org/2016/1013
+
+**Post-quantum messaging**
+
+- E. Kret, R. Schmidt. _The PQXDH Key Agreement Protocol._ Signal, 2023.
+  https://signal.org/docs/specifications/pqxdh/
+- K. Bhargavan, C. Jacomme, F. Kiefer, R. Schmidt. _Formal Verification of the
+  PQXDH Post-Quantum Key Agreement Protocol._ USENIX Security 2024.
+  https://www.usenix.org/system/files/usenixsecurity24-bhargavan.pdf
+- Y. Dodis, D. Jost, S. Katsumata, T. Prest, R. Schmidt. _The Triple Ratchet: A
+  Bandwidth Efficient Hybrid-Secure Signal Protocol._ EUROCRYPT 2025.
+  https://eprint.iacr.org/2025/078
+- B. Auerbach, Y. Dodis, D. Jost, S. Katsumata, T. Prest, R. Schmidt.
+  _Post-Quantum Ratcheting for Signal._ NIST 6th PQC Standardization
+  Conference, 2025.
+  https://csrc.nist.gov/csrc/media/events/2025/sixth-pqc-standardization-conference/post-quantum%20ratcheting%20for%20signal.pdf
+- M. Barbosa et al. _X-Wing: The Hybrid KEM You've Been Looking For._ IACR
+  Communications in Cryptology, 2024. https://eprint.iacr.org/2024/039
+- F. Linker, R. Sasse, D. Basin. _A Formal Analysis of Apple's iMessage PQ3
+  Protocol._ USENIX Security 2025.
+  https://www.usenix.org/conference/usenixsecurity25/presentation/linker
+
+p2party's sparse post-quantum healing is directly inspired by Signal's SPQR
+design; the two are not the same construction, and p2party's has not been
+independently analysed.
+
+- Signal Foundation. _SPQR: Signal Protocol and Post-Quantum Ratchets._ 2025.
+  https://signal.org/blog/spqr/ ·
+  https://github.com/signalapp/SparsePostQuantumRatchet
+
+**PAKE and channel binding**
+
+- M. Abdalla, B. Haase, J. Hesse. _Security Analysis of CPace._ ASIACRYPT 2021.
+  https://eprint.iacr.org/2021/114
+- N. Williams. _RFC 5056: On the Use of Channel Bindings to Secure Channels._
+  https://www.rfc-editor.org/rfc/rfc5056.html
+
+**Traffic analysis and cover traffic** — the basis for scheduled cover, and for
+the honest limits stated in the
+[security boundary](protocol-v4-security.md).
+
+- A. Piotrowska, J. Hayes, T. Elahi, S. Meiser, G. Danezis. _The Loopix
+  Anonymity System._ USENIX Security 2017. https://arxiv.org/abs/1703.00536
+- X. Cai, R. Nithyanand, T. Wang, R. Johnson, I. Goldberg. _A Systematic
+  Approach to Developing and Evaluating Website Fingerprinting Defenses
+  (Tamaraw)._ ACM CCS 2014. https://doi.org/10.1145/2660267.2660362
+- T. Pulls, E. Witwer. _Maybenot: A Framework for Traffic Analysis Defenses._
+  WPES @ CCS 2023. https://doi.org/10.1145/3603216.3624953
+- S. Sasy, I. Goldberg. _SoK: Metadata-Protecting Communication Systems._
+  PoPETs 2024. https://doi.org/10.56553/popets-2024-0030
+- M. Weisenseel, C. Döpmann, F. Tschorsch. _The Last Hop Attack: Why Loop Cover
+  Traffic over Fixed Cascades Threatens Anonymity._ PoPETs 2025.
+  https://doi.org/10.56553/popets-2025-0067
+- K. Nikitin et al. _Reducing Metadata Leakage from Encrypted Files and
+  Communication with PURBs._ PoPETs 2019.
+  https://petsymposium.org/popets/2019/popets-2019-0056.php
+
+## 4. Related open-source systems
+
+Projects solving adjacent problems. Several informed p2party's design; none
+share its code.
+
+**Browser E2E ratchets**
+
+- [matrix-org/vodozemac](https://github.com/matrix-org/vodozemac) — Rust/WASM
+  Olm and Megolm for Matrix.
+- [wireapp/core-crypto](https://github.com/wireapp/core-crypto) — MLS and
+  Proteus for Wire, compiled to WASM.
+- [PeculiarVentures/2key-ratchet](https://github.com/PeculiarVentures/2key-ratchet)
+  — Double Ratchet + X3DH on WebCrypto (archived).
+- [PeculiarVentures/pqc-ratchet](https://github.com/PeculiarVentures/pqc-ratchet)
+  — post-quantum Double Ratchet, ML-KEM-768 + X25519.
+- [LukaJCB/ts-mls](https://github.com/LukaJCB/ts-mls) — TypeScript MLS
+  (RFC 9420) with post-quantum ciphersuites.
+
+**Browser peer-to-peer transfer**
+
+- [saljam/webwormhole](https://github.com/saljam/webwormhole) — CPace over
+  WebRTC with DTLS-fingerprint binding; the closest prior art to p2party's PIN
+  rooms.
+- [magic-wormhole](https://github.com/magic-wormhole/magic-wormhole-protocols) —
+  SPAKE2 code-phrase transfer; origin of the short-code UX.
+- [schlagmichdoch/PairDrop](https://github.com/schlagmichdoch/PairDrop) and
+  [kern/filepizza](https://github.com/kern/filepizza) — WebRTC file transfer
+  without accounts.
+- [js-libp2p](https://libp2p.io/docs/webrtc-browser-connectivity/) — WebRTC
+  browser transport with Noise.
+
+**Traffic shaping and obfuscation**
+
+- [Yawning/obfs4](https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt)
+  — padding and timing obfuscation for Tor pluggable transports.
+- [maybenot](https://github.com/maybenot-io/maybenot) — the framework behind
+  the traffic-analysis defence paper above.
+
+## 5. How to cite p2party
+
+p2party has not been published as a paper and has not completed an independent
+third-party security audit. Cite the implementation:
+
+```bibtex
+@software{p2party,
+  title  = {p2party: protocol-v4 end-to-end encryption over a WebRTC room mesh},
+  url    = {https://github.com/p2party/p2party-js},
+  note   = {Version 0.14.2}
+}
+```