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:

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:

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:

{
  "type": "relay_hello",
  "relay_name": "nostr.relay.example",
  "features": ["forwarding", "dedup", "metadata"],
  "timestamp": 1684000000,
  "sig": "<Schnorr-signed payload>"
}

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