5e3b4788ec
This PR rewrites the Mix Protocol RFC for clarity, layering, and implementability. It reorganizes the spec into a modular structure aligned with RFC 7322 and RFC 2119, with clean separation between protocol logic, integration, and pluggable components. ### Goals - Clearly define Mix as a **message-based routing protocol**, not a transport or application-layer solution. - Support **per-message anonymity** via a `mixify` flag and **external integration** through Entry and Exit layers. - Adopt a clean, layered structure: motivation → integration → routing model → cryptographic structure → node behavior. - Use correct RFC formatting, keywords, and SEMBR for implementation clarity. ### Changes Completed in This PR #### Sections 0–5: Foundational Structure and Protocol Layering * [x] **Abstract**: Concise, non-repetitive summary of protocol purpose and scope. * [x] **§1 Introduction**: Cleanly describes protocol role, document scope, and integration model. * [x] **§2 Terminology**: Defines all key terms; includes correct use of `MUST`, `SHOULD`, and informal variants. * [x] **§3 Motivation and Background**: Articulates need for sender anonymity in libp2p; includes `§3.1 Comparison with Tor`. #### Section 4 Mixing Strategy and Packet Format * [x] **§4.1 Mixing Strategy**: Defines continuous-time mixing; justifies choice over batching. * [x] **§4.2 Packet Format Overview**: Defines what a mix packet must achieve; outlines Sphinx format properties and rationale. #### Section 5 Protocol Overview and Integration * [x] **§5 Protocol Overview**: Clean, layered walkthrough of core protocol behavior and layering in libp2p. * [x] **§5.1 Integration with Origin Protocols**: External interface components (Mix Entry/Exit layers). * [x] **§5.2 Mixify Option**: Per-message flag defined. * [x] **§5.3 Why a Protocol, Not a Transport**: Explains why Mix is layered as a libp2p protocol, not a transport. * [x] **§5.4 Protocol Interaction Flow**: Three-phase diagram and explanation (entry → routing → exit). #### Section 6 Pluggable Components * [x] Discovery: advertise Mix support via ENR, X25519 key * [x] Delay strategy: sender-defined per-hop delay * [x] Spam protection: PoW/VDF/RLN options, exit node validation * [x] Cover traffic: periodic loops for unobservability * [x] Incentivization: nodes MUST participate to send #### Section 7 Core Mix Protocol Responsibilities * [x] Define Sender, Intermediary, Exit node roles * [x] Specify lifecycle and message flow per role #### Section 8 Sphinx Packet Format (Detailed Spec) * [ ] Full field definitions (α, β, γ, δ, delays, MACs) * [ ] Encoding and padding behavior #### Section 9 Node Behavior (Mix Protocol Handler) * [ ] Describe sender node logic: path selection, packet wrapping * [ ] Describe intermediary/exit node behavior: decryption, delay, forwarding #### Section 10 Limitations and Future Work * [ ] SURB-based reply support (unimplemented) * [ ] DoS/Sybil attack surface * [ ] Path overlap, message reordering, end-to-end acks #### Appendices * [ ] Appendix A: Proof-of-Work Example * [ ] Appendix B: ENR-Based Discovery Example
Vac Request For Comments(RFC)
NOTE: This repo is WIP. We are currently restructuring the RFC process.
This repository contains specifications from the Waku, Nomos, Codex, and Status projects that are part of the IFT portfolio. Vac is an IFT service that will manage the RFC, Request for Comments, process within this repository.
New RFC Process
This repository replaces the previous rfc.vac.dev resource.
Each project will maintain initial specifications in separate repositories,
which may be considered as a raw specification.
All Vac raw specifications and
discussions will live in the Vac subdirectory.
When projects have reached some level of maturity
for a specification living in their repository,
the process of updating the status to draft may begin in this repository.
Specifications will adhere to
1/COSS before obtaining draft status.
Implementations should follow specifications as described, and all contributions will be discussed before the stable status is obtained. The goal of this RFC process will to engage all interseted parities and reach a rough consensus for techcinal specifications.
Contributing
Please see 1/COSS for general guidelines and specification lifecycle.
Feel free to join the Vac discord.
Here's the project board used by core contributors and maintainers: Projects
IFT Projects' Raw Specifications
The repository for each project raw specifications: