feat: add approach card for private institutional messaging by Darkjay123 · Pull Request #215 · ethsystems/map

Darkjay123 · 2026-11-10T01:25:07Z

What this adds

approaches/approach-private-messaging.md, filling the "Approach TBD" gap on use-cases/private-messaging.md.

The card compares three designs for institutions (banks, asset managers, corporates) that need private messaging between known entities:

Anchored off-chain messaging (documented, I2I): messages live off-chain on self-hosted infrastructure (Matrix/Synapse, XMTP, Waku), with periodic on-chain cryptographic anchors for proof-of-existence, ordering, and commitment. This is the recommendation, because it is the variant compatible with existing compliance tooling (WORM archives, regulator exports, e-discovery) while still buying the institution a credible-exit, forkable stack.
Mixnet-routed messaging (concept): Nym-style layered routing; strongest unlinkability, weakest fit for institutional audit obligations.
Threshold-encrypted on-chain channels (concept): messages stored on-chain encrypted to a participant threshold key, at L2 only; strongest on-chain durability, highest cost and weakest operational fit.

Also included: a 10-row comparison matrix, three persona perspectives (ops head, compliance officer, security engineer), an explicit recommendation with the conditions that would change it, and five open questions.

Validation

Follows approaches/_template.md structure (frontmatter, sub-approaches, comparison, personas, recommendation, open questions)
Pattern slugs referenced exist in patterns/ (l2-encrypted-offchain-audit, regulatory-disclosure-keys-proofs, commit-and-prove, mixnet-anonymity, onion-routing, threshold-encrypted-mempool, user-controlled-viewing-keys)
Open-source implementations cited: element-hq/synapse, xmtp/libxmtp, waku-org/nwaku
No marketing language; facts and trade-offs only

…thsystems#215)

rymnc

thank you for your PR! left some comments in-line

rymnc · 2026-11-10T06:52:00Z

+  - url: https://github.com/xmtp/libxmtp
+    description: "XMTP messaging protocol client library (encrypted, wallet-keyed messaging)"
+    language: Rust
+  - url: https://github.com/waku-org/nwaku


Suggested change

- url: https://github.com/waku-org/nwaku

- url: https://github.com/logos-messaging/logos-delivery

I think a couple things might be out of date here.

rymnc · 2026-11-10T07:28:47Z


 ## [Unreleased]

+- feat(approach): [Private Institutional Messaging](approaches/approach-private-messaging.md), filling the "Approach TBD" gap on [Private Messaging](use-cases/private-messaging.md). Compares anchored off-chain messaging (documented, I2I), mixnet-routed messaging (concept) and threshold-encrypted on-chain channels (concept), with a 10-row comparison matrix, persona perspectives, a conditional recommendation and open questions. ([#215](https://github.com/ethsystems/map/pull/215))


this line says that the pr fills the Approach TBD gap. the pr does not change the use case. line 55 of use-cases/private-messaging.md still says Approach TBD, and the use case does not link to this card.

suggestion: replace section 5 of the use case with a link to this approach.

rymnc · 2026-11-10T07:28:58Z

+  - pattern-l2-encrypted-offchain-audit
+  - pattern-regulatory-disclosure-keys-proofs
+supporting_patterns:
+  - pattern-commit-and-prove


refer to the comment on line 67. after that change, no sub-approach uses this pattern.

Suggested change

- pattern-commit-and-prove

rymnc · 2026-11-10T07:28:59Z

+    description: "Matrix homeserver reference implementation (federated, Olm/Megolm message encryption)"
+    language: Python
+  - url: https://github.com/xmtp/libxmtp
+    description: "XMTP messaging protocol client library (encrypted, wallet-keyed messaging)"


libxmtp now uses mls for end-to-end encryption, and an inbox id is the identity (readme). "wallet-keyed" describes the older protocol.

Suggested change

description: "XMTP messaging protocol client library (encrypted, wallet-keyed messaging)"

description: "XMTP messaging protocol library (MLS end-to-end encryption, inbox ID identity)"

rymnc · 2026-11-10T07:29:00Z

+    description: "XMTP messaging protocol client library (encrypted, wallet-keyed messaging)"
+    language: Rust
+  - url: https://github.com/waku-org/nwaku
+    description: "Waku v2 node implementation (privacy-preserving relay, mixnet-ready messaging for web3)"


logosdeliverynode replaced wakunode2 in this repo (changelog line 76). so "waku v2 node" is stale. mix sender anonymity is opt-in per send (line 77). mix nodes ship only in the dev and test presets (line 79).

Suggested change

description: "Waku v2 node implementation (privacy-preserving relay, mixnet-ready messaging for web3)"

description: "Logos Delivery node, formerly nwaku (Logos Messaging protocols, opt-in mix sender anonymity)"

rymnc · 2026-11-10T07:29:14Z

+|---|---|---|---|
+| **Maturity** | documented | concept | concept |
+| **Context** | i2i | i2i | i2i |
+| **CROPS** | CR:med O:part P:part S:med | CR:med O:part P:full S:med | CR:hi O:y P:full S:med |


rymnc · 2026-11-10T07:29:15Z

+| **Trust model** | Node operators + anchor schedule | Mix node majority | Threshold committee |
+| **Privacy scope** | Content hidden; metadata visible | Content + metadata hidden | Content hidden; existence public |
+| **Performance** | Real-time; anchoring periodic | Seconds to minutes (batching) | Per-message chain latency |
+| **Operator req.** | Yes (nodes + key escrow) | Yes (mix infrastructure) | No (chain-native) |


the trust model at line 159 is a threshold committee. line 142 also says that an l2 adds an operator. approach-private-broadcasting.md lists the same design as Threshold network.

Suggested change

| **Operator req.** | Yes (nodes + key escrow) | Yes (mix infrastructure) | No (chain-native) |

| **Operator req.** | Yes (nodes + key escrow) | Yes (mix infrastructure) | Yes (threshold committee) |

rymnc · 2026-11-10T07:29:16Z

+| **Performance** | Real-time; anchoring periodic | Seconds to minutes (batching) | Per-message chain latency |
+| **Operator req.** | Yes (nodes + key escrow) | Yes (mix infrastructure) | No (chain-native) |
+| **Cost class** | Low | Medium | High (per-message gas) |
+| **Regulatory fit** | Strong (scoped disclosure, retention) | Unproven (retention and eDiscovery open) | Strong content audit; traffic visible |


this row rates the anchored design and the on-chain channels as strong. line 179 says that it is unsettled whether regulators accept scoped key disclosure. line 200 keeps ediscovery over ciphertext as an open question. line 150 says to avoid on-chain channels when institutions need off-chain ediscovery.

suggestion: rate both as unproven, or give the reason for each "strong".

rymnc · 2026-11-10T07:29:17Z

+
+### Technical perspective
+
+The anchored approach is mostly integration work: federated or wallet-keyed messaging protocols exist and run, and the engineering lifts are the hash-chain anchoring job and multi-year key management, which is an unsolved operational problem more than a cryptographic one. Mixnets are the simplest to deploy as a sidecar but hardest to keep effective on thin institutional traffic; batching needs volume that two-party channels rarely produce. On-chain channels require the least infrastructure to operate and the most cryptographic care per message, and they inherit consensus-level liveness, which is either a feature or an outage dependency depending on the deal.


this line says that mixnets are the simplest to deploy. line 111 says that mixnets add operational complexity. line 171 says that they are expensive to sustain.

suggestion: make this sentence agree with the threat model and the business perspective.

rymnc · 2026-11-10T07:29:18Z

+
+### Hybrid
+
+Run the anchored design as the base layer, add mixnet routing on the most sensitive negotiation channels, and move contract milestones (signed term sheets, amendment notices) into on-chain encrypted channels so their ordering is trustless. One disclosure-key scheme spans all three layers so a regulator request has a single entry point.


the mixnet sub-approach lists no disclosure pattern (line 96). the mixnet pattern leaves content to a separate layer. the threshold committee releases each slot key to everyone, so it is not a scoped key (line 86). so one disclosure-key scheme cannot span all three layers with the cited patterns.

suggestion: limit the single scheme to the anchored layer, or remove this sentence.

…saging (ethsystems#215) - replace stale libxmtp (MLS, inbox ID) and nwaku (Logos Delivery) entries - cite the L2 audit log pattern for anchoring, drop commit-and-prove - name sender signatures for non-repudiation; drop the dispute-path parenthetical - name the retention regimes (SEC 17a-4(b)(4), CFTC 1.31(b)) instead of a blanket 5-7 year window - add the counterparty-identity requirement and note the anchored design does not meet it alone - correct mixnet and threshold crops (p partial, o partial) - on-chain channels: encrypt to counterparty keys only, drop the threshold mempool citation (committee releases keys after inclusion, so content would go public); rename the variant - re-rate regulatory fit rows with the reason for each claim - align the mixnet sidecar claim with the trade-off sections; scope the disclosure-key scheme to the anchored layer - link the Private Messaging use case's recommended-approaches section to the card

rymnc

@Darkjay123 could you comment on the reasoning behind the specific crops ratings, here in github, so we're on the same page?

Darkjay123 · 2026-11-10T11:51:55Z

Thanks for the review. All 21 line comments are applied in 8d1b43b, including the three CROPS values you suggested. Here is the reasoning behind each, per the rubric in CONTRIBUTING.md:

Anchored Off-chain Messaging (cr: medium, o: partial, p: partial, s: medium)

CR: medium. Access is gated (federation membership or a node-operator relationship), but a participant can run their own node or move operators without approval, which fits the rubric's "credible independent path to participate or exit" bar for medium.
O: partial. The node software (Matrix, XMTP, Logos) is open, but no open-source deployment ships the anchoring plus disclosure-key scheme end to end, so the critical path is not fully forkable today.
P: partial. Nodes hold ciphertext only, but the design requires structured disclosure to a regulator (scoped keys), and on-chain anchors leak timing and counterparty pairs.
S: medium. Security rests on operational trust (at least one party anchoring honestly), with sender signatures now named as the non-repudiation mechanism rather than assumed.

Mixnet-routed Institutional Messaging (cr: medium, o: partial, p: partial, s: medium)

CR: medium. Mix infrastructure is operator-run; the same gated-but-escapable shape as the anchored design.
O: partial. Logos ships mix sender anonymity, but mix nodes ship only in the dev and test presets, so production observability is limited.
P: partial. Matches the mixnet pattern's own rating; regulator disclosure still rides on top of the design, and low-volume institutional channels defeat the batching cover.
S: medium. Anonymity degrades under thin traffic and full compromise rather than failing loudly.

On-chain Encrypted Channels (cr: high, o: partial, p: partial, s: medium)

CR: high. Inclusion is consensus-backed, with no operator able to exclude a participant.
O: partial. The threshold-encrypted mempool pattern rates itself o: partial, and no open implementation runs this exact design end to end.
P: partial. Content is hidden from non-key-holders, but channel existence and volume are public, and the design requires regulator disclosure.
S: medium. Threshold-committee trust, and the committee's slot-key release makes each message public after inclusion.

If you read any of these differently against the rubric, point me at the row and I will adjust.

rymnc

thanks for your contribution!

feat: add approach card for private institutional messaging

2973620

Darkjay123 requested review from cygnusv, oskarth and rymnc as code owners November 10, 2026 01:25

docs: changelog entry for private institutional messaging approach (e…

89deb11

…thsystems#215)

rymnc reviewed Nov 10, 2026

View reviewed changes

rymnc approved these changes Nov 10, 2026

View reviewed changes

rymnc merged commit 7fd964d into ethsystems:master Nov 10, 2026
4 checks passed

	- url: https://github.com/waku-org/nwaku
	- url: https://github.com/logos-messaging/logos-delivery


		## [Unreleased]

		- feat(approach): [Private Institutional Messaging](approaches/approach-private-messaging.md), filling the "Approach TBD" gap on [Private Messaging](use-cases/private-messaging.md). Compares anchored off-chain messaging (documented, I2I), mixnet-routed messaging (concept) and threshold-encrypted on-chain channels (concept), with a 10-row comparison matrix, persona perspectives, a conditional recommendation and open questions. ([#215](https://github.com/ethsystems/map/pull/215))

	description: "XMTP messaging protocol client library (encrypted, wallet-keyed messaging)"
	description: "XMTP messaging protocol library (MLS end-to-end encryption, inbox ID identity)"

	description: "Waku v2 node implementation (privacy-preserving relay, mixnet-ready messaging for web3)"
	description: "Logos Delivery node, formerly nwaku (Logos Messaging protocols, opt-in mix sender anonymity)"

	\| CROPS \| CR:med O:part P:part S:med \| CR:med O:part P:full S:med \| CR:hi O:y P:full S:med \|
	\| CROPS \| CR:med O:part P:part S:med \| CR:med O:part P:part S:med \| CR:hi O:part P:part S:med \|

	\| Operator req. \| Yes (nodes + key escrow) \| Yes (mix infrastructure) \| No (chain-native) \|
	\| Operator req. \| Yes (nodes + key escrow) \| Yes (mix infrastructure) \| Yes (threshold committee) \|


		### Technical perspective

		The anchored approach is mostly integration work: federated or wallet-keyed messaging protocols exist and run, and the engineering lifts are the hash-chain anchoring job and multi-year key management, which is an unsolved operational problem more than a cryptographic one. Mixnets are the simplest to deploy as a sidecar but hardest to keep effective on thin institutional traffic; batching needs volume that two-party channels rarely produce. On-chain channels require the least infrastructure to operate and the most cryptographic care per message, and they inherit consensus-level liveness, which is either a feature or an outage dependency depending on the deal.


		### Hybrid

		Run the anchored design as the base layer, add mixnet routing on the most sensitive negotiation channels, and move contract milestones (signed term sheets, amendment notices) into on-chain encrypted channels so their ordering is trustless. One disclosure-key scheme spans all three layers so a regulator request has a single entry point.

Conversation

Darkjay123 commented Nov 10, 2026

What this adds

Validation

Uh oh!

rymnc left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rymnc left a comment

Choose a reason for hiding this comment

Uh oh!

Darkjay123 commented Nov 10, 2026

Uh oh!

rymnc left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants