Transport layer for private (off-chain) notes

[Dominik1999]

Canonical Transport Layer for Private Notes

TL;DR

Goal: Create a secure and user-friendly transport layer for off-chain private notes in the Miden ecosystem.
Why it matters: Miden users cannot consume private notes without receiving the note data directly — and no canonical, scalable solution for this exists yet.
Opportunity: We're looking for collaborators to help build a PoC and iterate toward a decentralized production system.

---

Problem: Private Note Data Is Off-Chain

Miden’s private notes are not stored on-chain. Instead, only a commitment to the note is recorded in the Note DB. This preserves privacy but creates a challenge:
To consume a private note, an account must have access to the full note data. Since this data lives off-chain, consumers cannot fetch it from the blockchain — they must receive it directly, off-chain, from the note creator.

Miden supports exporting a note as a .mno file via the wallet or client. You can test this using the faucet, then manually share the file with another client.
However, there is no canonical, secure, and scalable way to transmit private notes between peers.

---

Current Workaround

Today, developers share .mno files manually using Signal, Telegram, or email. This is fine for prototyping, but:

• It doesn’t scale to production apps
• It lacks privacy guarantees
• It creates friction and fragmentation

Each team could build their own solution — via WebRTC, decentralized storage, etc. — but that fragments the ecosystem and raises the barrier to entry.

---

Vision: Canonical Transport Layer

We want to provide a canonical way to transmit private notes between users.
This will be part of Miden’s core infrastructure and will support both the wallet and third-party applications.

We are looking for a development partner to help prototype and iterate toward a robust, decentralized implementation.

---

PoC Requirements

The goal of the proof-of-concept is to validate a minimal viable solution that can be integrated into early clients:

• Confidentiality: Note files must be encrypted. An operator may see “Alice sends something to Bob” but not the content.
• Liveness: Alice can send a note even if Bob is offline. Bob retrieves it once online.
• Simple API: Easy integration with wallet and clients (Rust and Web environments).
• Existing tech: If possible, use existing tech like IPFS or data sharing layers.

The PoC can be centralized.

---

Final Product Direction

Long-term, we aim for a decentralized and privacy-preserving transport layer:

• All PoC features, plus:
  • Privacy: Only Alice and Bob know that a transfer happened.
  • Group Sharing: Alice can define a group of recipients (e.g. OTC trade counterparties).
  • Fees: Find a convincing solution how to collect fees for your system.
  • Optional decentralization: Use of DA layers (e.g., Avail, Celestia) or decentralized storage.

---

PoC Deliverables & Timeline

• A centralized prototype server enabling encrypted note transmission between two users
• Rust and Web APIs for:
  • Sending a note (to a user ID or address)
  • Fetching pending notes (for the recipient)
  • Marking notes as received
• Basic CLI or Web UI for local testing
• Integration documentation

Timeline: We aim to validate a working PoC within 4–6 weeks of kickoff.

---

Non-Goals (for PoC)

• No need for decentralized infrastructure (yet)
• No user authentication or wallet integration
• No content validation — only encrypted file transfer is in scope

---

How to Engage

• Comment on this discussion to express interest
• Or email dominik@miden.team with a brief note about your team and relevant experience
• We’ll schedule a short call to align on scope and next steps

---

What We're Looking For

• Strong experience in Rust or secure backend systems
• Familiarity with cryptographic APIs and secure file handling
• Clear communication and ability to iterate quickly

---

Related Resources

• Private Notes
• Note Database
• Testnet Faucet