Proof Of Concept
In a world where decentralization often hinges on the strength of its weakest node, the idea of federation—applied not to content moderation or identity, but strictly to **communication protocols**—opens up intriguing possibilities. In this model, **Nostr relays** do not operate in total isolation, nor do they function in a single cohesive mesh. Instead, they **form selective, encrypted alliances**, communicating through **secure tunnels** while preserving autonomy.
---
### 💡 The Core Idea
**Relays remain sovereign**, but may establish **peer-to-peer encrypted channels** with other trusted relays using **Elliptic Curve Diffie-Hellman (ECDH)** to generate shared secrets. These secrets are then used to encrypt communication tunnels—facilitating a federated communication layer.
Each relay is free to choose:
- **Whom it speaks to**
- **How often**
- **What types of events are relayed through the tunnel**
But *never* must it rely on a central coordinator.
---
### 🔁 Schnorr for Authentication
While ECDH can create the secure tunnel, **Schnorr signatures** (already a part of Nostr’s pubkey-based design) can be used to **authenticate the origin** of the data inside. This keeps the integrity of messages intact even when traveling over shared or hostile networks.
Use case:
- Relay A and Relay B establish an ECDH-based shared key.
- All communication is tunnel-encrypted with this shared key.
- Inside the tunnel, every message still carries a Schnorr signature, proving its source.
This separation of **transport-level encryption** from **message-level authenticity** provides an elegant layering of security.
---
### 🌐 Practical Benefits
- **Obfuscation**: Encrypted tunnels reduce visibility into relay-to-relay traffic patterns.
- **Privacy**: Federation over encrypted channels shields metadata and protects against surveillance.
- **Resilience**: Relays can route around censorship by tunneling through less obvious peers.
- **Synergy**: Specific relay clusters can form ephemeral or long-term alliances—say, art relays or academic relays—without disclosing their full graph to the world.
---
### 🧩 Optional Enhancements
- **Noise Protocol Framework** to standardize encrypted relay tunnels.
- **Tor Hidden Services** or **I2P** for transport obfuscation.
- **Relay Reputation Systems** to gauge trust before federation.
- **Dynamic Federation Negotiation**: using NIP-like proposals over encrypted handshakes to initiate or terminate communication agreements.
---
### 🌱 Case In Point
This is not about governing content, users, or identities—this is about strengthening how relays *talk*. By embracing federated communication via ECDH and Schnorr-secured tunnels, Nostr relays could evolve into a resilient underground of trust-minimized, pseudonymous routers that defy surveillance while amplifying decentralization.
---
**federated communication via ECDH and Schnorr-authenticated encrypted tunnels between Nostr relays**:
---
```markdown
NIP-xyz: Federated Encrypted Relay Communication
Status: Draft
Type: Relay
Created: 2025-04-22
```
---
## Summary
This NIP proposes a method for **encrypted, authenticated communication between Nostr relays** using **ECDH-based tunnels** for transport encryption and **Schnorr signatures** for payload integrity. This federation model allows relays to communicate securely while maintaining full autonomy, enhancing privacy, censorship resistance, and interoperability.
---
## Motivation
Nostr’s decentralized architecture relies heavily on relays, which currently operate in isolated or broadcast modes. There is no standard for secure, peer-to-peer communication **between relays themselves**, outside of client interactions.
Introducing encrypted tunnels between relays offers:
- **Privacy**: Reduces metadata leakage across public or adversarial networks.
- **Resilience**: Allows relays to forward events and metadata through trusted peers when direct access is blocked or filtered.
- **Autonomy**: Federation is opt-in and purely communicational—no centralized authority or directory is involved.
- **Extensibility**: Enables experimental protocols or content-specific subnets without altering the global Nostr model.
---
## Specification
### 1. Key Exchange via ECDH
Each relay maintains:
- A persistent **relay keypair**: `relay_pubkey`, `relay_privkey`
- Optionally: rotating session keys for forward secrecy
When two relays (A and B) wish to establish communication:
- They exchange their public keys (`relay_pubkey_A` and `relay_pubkey_B`)
- Both calculate a shared secret using ECDH over `secp256k1`:
```plaintext
shared_secret = SHA256(ECDH(relay_privkey_A, relay_pubkey_B))
```
This `shared_secret` is used to derive an encryption key for an **authenticated symmetric cipher**, such as AES-GCM or ChaCha20-Poly1305.
---
### 2. Encrypted Tunnel Establishment
Once the shared secret is derived:
- All messages between relays are sent through an **encrypted tunnel**
- Transport can be TCP, WebSocket, or HTTP/3 over QUIC, optionally via Tor or I2P
A **RelayHello** message is exchanged encrypted, optionally containing:
```json
{
"type": "relay_hello",
"relay_name": "nostr.relay.example",
"features": ["forwarding", "dedup", "metadata"],
"timestamp": 1684000000,
"sig": ""
}
```
The `sig` is a Schnorr signature from the `relay_pubkey`, verifying the message content.
---
### 3. Event Forwarding
Relays may forward selected event types across tunnels, such as:
- Kind 1 (Text Note)
- Kind 3 (Contacts)
- Kind 5 (Deletion Notices)
- Custom kinds (with mutual agreement)
All forwarded events MUST retain original client-level signatures. Relay-to-relay metadata (like timestamps, relay hints, or scores) may be added in a separate metadata envelope.
---
### 4. Access Control and Policies
Each relay maintains a **federation list**, including:
- Public key of the peer relay
- Features enabled
- Rate limits and quotas
- Last active session or rotation timestamp
Relays MAY:
- Deny tunnel requests
- Rotate keys periodically
- Restrict communication to a whitelist
- Use Proof-of-Work or tokens for DoS protection
---
### 5. Optional Features
- **Forward Secrecy**: ephemeral key pairs with HKDF for short sessions
- **Relay Reputation**: signed relay trust scores (future NIP)
- **Message Compression**: gzip or zstd on tunnel payloads
- **Encrypted Gossip**: tunnel-specific metadata routing
---
## Compatibility
This NIP is **backward-compatible**. Relays that do not implement it will simply not participate in tunnel-based communication.
No changes are required from Nostr clients.
---
## Reference Implementation (Proposed)
- `nostr-tunnel-relay`: Rust-based relay that supports federated encrypted tunnels
- `nostr-relay-link`: CLI tool to establish and monitor tunnels
- Example configs for federation policies in JSON or TOML
---
## Rationale
- ECDH ensures only the two relays involved can decrypt tunnel data
- Schnorr signatures authenticate content without duplicating identity schemes
- Federation is scoped **only to communication**, preserving Nostr’s core simplicity
---
## Security Considerations
- Relay pubkeys must be carefully verified to prevent MITM
- Session expiration and key rotation should be configurable
- Replay protection and nonce management are required for AEAD ciphers
- Metadata leakage minimized by default obfuscation or Tor-based transport
---
NIP.eshgham
