SWIP-059: MEX — anchored message exchange with a previously unknown node

[zelig]

Summary

MEX (Message EXchange): a two-phase rendezvous-and-exchange pattern by which any node capable of push-sync and retrieval — including light, potentially non-reachable nodes — carries out a private, mutually authenticated message exchange with a previously unknown full node in the neighbourhood of a pre-agreed anchor. Built entirely from existing primitives: MIC/MOC (SWIP-42, #80), single-owner chunks, push-sync receipts, retrieval.

Extracted from the PubSub SWIP (#93), where it was worked out as Milestone 3, and generalised so it can be referenced independently — by PubSub as a dependency and by MIC/MOC as a use case — keeping the cryptographic detail out of the PubSub spec.

Also specifies:

• a leakless known-responder variant (PSS trojan first contact, two legs instead of three, reveals not even the fact of the exchange); the anchored and known-responder forms compose, so the anchor-side metadata leak is paid at most once (0–1×) per responder relationship
• security considerations incl. at-least-once delivery semantics ⇒ mandatory per-chunk-address session dedup (cf. bee#5486 comment)

Follow-ups

• trim Milestone 3 from Add: pubsub #93 and reference this SWIP as a dependency instead
• SWIP-42 (Add SWIP-42: Mined Owner Chunks (MOCs) for efficient notifications #80) to list MEX as a use case

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds a new SWIP (SWIP-58) specifying MEX (Message EXchange): a two-phase anchored rendezvous and mutually authenticated request/response exchange built from existing Swarm primitives (MIC/MOC, SOC/GSOC, push-sync receipts, retrieval). This extracts and generalizes the “Milestone 3” discovery/exchange pattern from the the outdated original PubSub SWIP #93 so other protocols can reference it as a standalone dependency.

Changes:

• Introduces the full SWIP-58 specification (terminology, phases, variant for known responder via PSS trojan, encryption/key derivation, rationale, security considerations).
• Adds explicit operational/security requirements (notably at-least-once delivery implications and mandatory per-chunk-address session dedup).
• Documents implementation links and test case scenarios.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.