Architectural Redesign: Daemon-based P2P with WASM Protocol Plugins

[amitu]

original prompt

our fastn-p2p currently is a crate, that rust programs that want to build p2p stuff want to use. but this has a few problems: keys are liberally shared: each client also need secret key, and clients have acceptbi etc features, which means clients can act like server, and if two cli instances are there, both calling acceptbi it wont work, so our design is all wrong. we also have performance issue, so each cli instance using our crate will have to create p2p connection, which takes a bit of time ~100s of ms, and so we can create a background daemon, which can open and keep the connections, and let client connect with the daemon over some sort of tcp or unix domain socket, so none of the clis need secret keys, only access to unix domain socket, and daemon can run as some other user, that has access to secret keys, making it hard to access secret keys.

now fastn-p2p users can be either clients or server, and for client the control server and IPC over unix socket makes sense, but for server, especially since each server in p2p kind of acts like a protocol, so like we have mail server, and ssh server, and soon file server and media server, but they also are full protocol implementations, like mail server handles email delivery, but also storage of email in some folder and sqlite file etc. similarly ssh etc, they are not just server, but protocol, as they expose well define apis, and any client following same protocol can access the same set of few protocol implementations, this allows us to have few protocols but many apps, like for any kind of email client you need mail protocol stuff.

so we want protocol handlers to be available to users, but we can not ship all protocol code as part of our binary, so we need plugin mechanism, so we will have some sort of global plugin repo, maybe just a folder containing wasm files, and all protocol handlers are written / shipped as wasm code, so end users can load untested protocol handlers, as they will each run in a security sandbox, so our main binary is small and yet end users get rich functionality without installing configuring as if I send a chat message to a peer who does not have chat related plugin installed, our system can auto install the chat protocol plugin, and when the peer comes online they can, be notified they have received some chat protocol data, and offer user to install of the compatible app registered against this protocol to start doing chat.

Problem Statement

The current fastn-p2p crate design has critical architectural issues:

Security Issues

• Secret key exposure: Every client application needs direct access to secret keys
• No privilege separation: CLI instances run with full cryptographic material access
• Shared key vulnerability: Keys are liberally shared across multiple processes

Concurrency Issues

• Port conflicts: Multiple CLI instances calling accept_bi fail due to port binding conflicts
• Resource contention: Each client acts as both client and server, causing resource conflicts

Performance Issues

• Connection overhead: Each CLI instance creates new P2P connections (~100ms overhead)
• No connection pooling: Connections not reused across CLI invocations
• Redundant handshakes: Every command performs full P2P handshake

Proposed Solution

1. Daemon Architecture

┌─────────────┐     Unix Socket    ┌─────────────┐      P2P      ┌─────────────┐
│  CLI/Apps   │◄──────────────────►│   Daemon    │◄─────────────►│   Peers     │
│ (No Keys)   │        IPC         │ (Has Keys)  │    Network    │             │
└─────────────┘                    └─────────────┘               └─────────────┘

Benefits:

• Daemon runs as privileged user with key access
• Clients connect via Unix domain socket (no keys needed)
• Single daemon manages all P2P connections
• Connection pooling and reuse
• No port conflicts

2. Protocol Plugin System (WASM)

Instead of monolithic binary with all protocols:

fastn-daemon
    ├── core (small, secure)
    └── plugins/
        ├── mail.wasm    (email protocol)
        ├── ssh.wasm     (SSH protocol)  
        ├── chat.wasm    (chat protocol)
        └── files.wasm   (file sharing)

Protocol Handler Design:

• Each protocol is a complete implementation (not just server)
• Protocols handle both networking AND storage/business logic
• Example: Mail protocol handles SMTP/IMAP + email storage in SQLite
• Sandboxed WASM execution for security

3. Auto-Discovery & Installation

// When receiving unknown protocol data
if !protocol_installed("chat/v1") {
    // Auto-download and install chat.wasm
    daemon.install_protocol("chat/v1").await?;
    // Notify user about new protocol
    notify_user("Chat messages received. Install chat app?");
}

Architecture Details

Daemon Components

1. Core Daemon

   • Key management (exclusive access)
   • P2P connection lifecycle
   • IPC server (Unix socket)
   • Plugin loader/manager

2. IPC Protocol

   // Client never touches keys
   client.send_to_peer(peer_id, protocol_id, data)?;
   
   // Daemon handles all crypto
   daemon.sign_and_send(peer_id, data)?;

3. Plugin API

   trait ProtocolHandler {
       fn handle_message(&self, from: PeerId, data: &[u8]);
       fn get_protocol_id(&self) -> &str;
       fn get_capabilities(&self) -> Vec<Capability>;
   }

Security Model

• Daemon: Runs as fastn-daemon user, owns secret keys
• Clients: Connect via Unix socket, no key access
• Plugins: WASM sandbox, no filesystem/network access except via API
• IPC: Unix socket permissions control access

Plugin Distribution

# Global plugin registry
~/.fastn/plugins/
  manifest.toml        # Plugin metadata
  mail-v1.0.0.wasm    # Email protocol
  chat-v2.1.0.wasm    # Chat protocol
  
# Auto-download from registry
https://plugins.fastn.io/
  /protocols/mail/latest.wasm
  /protocols/chat/latest.wasm

Implementation Phases

Phase 1: Daemon Foundation

• Extract daemon from current crate
• Implement Unix socket IPC
• Move key management to daemon
• Basic client library for IPC

Phase 2: Connection Management

• Connection pooling in daemon
• Persistent connections across CLI calls
• Multi-tenant connection handling
• Performance optimizations

Phase 3: Plugin System

• WASM runtime integration (wasmtime/wasmer)
• Plugin API definition
• Plugin loader/manager
• Sandbox security boundaries

Phase 4: Protocol Implementations

• Port existing protocols to plugins
• Mail protocol plugin
• Chat protocol plugin
• File sharing plugin

Phase 5: Auto-Discovery

• Protocol negotiation
• Auto-installation mechanism
• User consent/notification system
• Plugin registry/marketplace

Benefits

1. Security: Keys never leave daemon, clients have no crypto access
2. Performance: Connection reuse, no repeated handshakes
3. Scalability: One daemon serves many clients
4. Extensibility: New protocols via plugins without recompiling
5. User Experience: Auto-discovery of protocols, seamless communication
6. Small Binary: Core daemon is minimal, protocols are plugins

Technical Decisions Needed

1. IPC Protocol: JSON-RPC, gRPC, or custom binary?
2. WASM Runtime: wasmtime vs wasmer vs wasm3?
3. Plugin Distribution: Centralized registry vs P2P distribution?
4. Plugin Signing: How to verify plugin authenticity?
5. Resource Limits: CPU/memory limits for plugins?

Migration Path

1. Current crate users continue working (deprecated)
2. New daemon runs alongside for testing
3. Gradual migration of protocols to plugins
4. Deprecation timeline for direct crate usage

Related Work

• IPFS daemon architecture
• Browser extension model (sandboxed plugins)
• Docker daemon/client split
• SystemD socket activation

This redesign fundamentally improves security, performance, and extensibility while enabling a rich ecosystem of P2P protocols without bloating the core binary.

[amitu]

Since our daemon could be managing more than one peer identities, instead of a single control server unix file, lets keep one file per identity, so we can selectively grant permissions to diff users for different identities. And since for each identity, we have different protocol we may use, we can even create one socket file per protocol per identity giving us even finer grained permission.

[amitu]

Technical Design Response: Multi-Identity Socket Structure

This is a technical design proposal in response to your multi-identity requirement.

---

Excellent point about multi-identity support and fine-grained permissions! This would significantly enhance the security model.

Proposed Socket Structure

~/.fastn/sockets/
├── identities/
│   ├── alice_52charID/
│   │   ├── control.sock         # Identity-level control
│   │   └── protocols/
│   │       ├── mail.sock         # Mail protocol for alice
│   │       ├── chat.sock         # Chat protocol for alice
│   │       └── files.sock        # File sharing for alice
│   └── bob_52charID/
│       ├── control.sock         # Identity-level control
│       └── protocols/
│           ├── ssh.sock          # SSH protocol for bob
│           └── chat.sock         # Chat protocol for bob
└── daemon.sock                   # Global daemon control (admin only)

Permission Model

# Different users/groups can access different identities
chown alice:mail-users ~/.fastn/sockets/identities/alice_*/protocols/mail.sock
chown bob:ssh-admins ~/.fastn/sockets/identities/bob_*/protocols/ssh.sock

# Apps can be granted specific protocol access
chmod 660 ~/.fastn/sockets/identities/alice_*/protocols/chat.sock
setfacl -m u:chat-app:rw ~/.fastn/sockets/identities/alice_*/protocols/chat.sock

Benefits

1. Multi-tenancy: Single daemon managing multiple identities
2. Fine-grained access: Apps only get access to specific protocols they need
3. Identity isolation: Complete separation between different peer identities
4. Protocol-specific permissions: Mail client only accesses mail.sock, can't touch SSH
5. Audit trail: Each socket connection can be logged separately

API Changes

// Connect to specific identity/protocol
let client = DaemonClient::connect_protocol(
    identity_id: "alice_52charID",
    protocol: "mail"
)?;

// Client automatically connects to:
// ~/.fastn/sockets/identities/alice_52charID/protocols/mail.sock

Additional Considerations

• Discovery: Clients can list available identities/protocols they have access to
• Dynamic creation: Daemon creates socket files on-demand when protocols are installed
• Cleanup: Remove socket files when identities/protocols are removed
• Systemd integration: Use socket activation for each protocol socket

This architecture would make fastn-p2p suitable for multi-user systems where different applications and users need controlled access to specific P2P identities and protocols.

[amitu]

If we are using Unix Domain Socket Is it possible for us to find the UID/GID (and thus username) of the CLI connecting with us, so we can do username based rules in some sort of iptables like mechanism that we will have to build in to act like p2p level firewall and ipfilter. The daemon itself will have to maintain state, as the allow/deny list can be dynamic, say like fail to ban use case for ssh (or any protocol for that matter), on third failure we do not want our daemon to accept any more connection that that peer for example. So we need to think of such rules, and the kind of sqlite table schema we would need.

Let's also sketch a management cli that can be used to inspect such rules, ongoing connections / "sessions" and modify them. Maybe we also keep some statistics like how many times a banned peer was actually rejected.

Since our application model is "session based", (our abstraction on top of iroh bidirectional streams, exposed over the control socket), some application data like protocol, and application header is available to fastn p2p core, so our filtering and rule engine can include the protocol and even some header level queries, header we can treat as json, so I can create a block rule with protocol=http & header.path == "*.php" or something.

[amitu]

Technical Design: P2P Firewall & Access Control

This is a technical architecture proposal addressing your requirements for UID/GID-based rules and P2P firewall capabilities.

---

Great security architecture thinking! Unix domain sockets do indeed allow peer credential retrieval, which opens up powerful access control possibilities.

UID/GID Retrieval

Yes, we can get peer credentials using SO_PEERCRED (Linux) or LOCAL_PEERCRED (BSD/macOS):

// Get connecting process credentials
let creds = socket.peer_cred()?;
let uid = creds.uid();
let gid = creds.gid();
let pid = creds.pid();  // Also available

// Resolve to username
let username = users::get_user_by_uid(uid)?.name();

P2P Firewall & Rule Engine

SQLite Schema

-- Access rules
CREATE TABLE rules (
    id INTEGER PRIMARY KEY,
    priority INTEGER NOT NULL,
    action TEXT CHECK(action IN ('allow', 'deny', 'rate_limit')),
    -- Match conditions
    peer_id TEXT,                    -- Target peer ID52
    local_identity TEXT,              -- Which local identity
    username TEXT,                    -- Unix username
    uid INTEGER,                      -- Unix UID
    protocol TEXT,                    -- Protocol name
    header_query TEXT,                -- JSON query expression
    -- Metadata
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    expires_at TIMESTAMP,             -- For temporary bans
    comment TEXT
);

-- Connection attempts log
CREATE TABLE connection_log (
    id INTEGER PRIMARY KEY,
    peer_id TEXT NOT NULL,
    local_identity TEXT NOT NULL,
    username TEXT,
    uid INTEGER,
    protocol TEXT,
    headers TEXT,                     -- JSON
    action TEXT,                      -- allow/deny
    rule_id INTEGER,                  -- Which rule matched
    timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (rule_id) REFERENCES rules(id)
);

-- Ban list with fail2ban logic
CREATE TABLE bans (
    peer_id TEXT,
    local_identity TEXT,
    protocol TEXT,
    failure_count INTEGER DEFAULT 1,
    first_failure TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    last_failure TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    banned_until TIMESTAMP,
    ban_count INTEGER DEFAULT 0,      -- How many times banned
    PRIMARY KEY (peer_id, local_identity, protocol)
);

-- Active sessions
CREATE TABLE sessions (
    id TEXT PRIMARY KEY,               -- Session UUID
    peer_id TEXT NOT NULL,
    local_identity TEXT NOT NULL,
    username TEXT,
    uid INTEGER,
    protocol TEXT,
    headers TEXT,                      -- JSON
    started_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    last_activity TIMESTAMP,
    bytes_sent INTEGER DEFAULT 0,
    bytes_received INTEGER DEFAULT 0,
    state TEXT DEFAULT 'active'
);

-- Statistics
CREATE TABLE stats (
    peer_id TEXT,
    local_identity TEXT,
    protocol TEXT,
    rejected_count INTEGER DEFAULT 0,
    accepted_count INTEGER DEFAULT 0,
    bytes_sent_total INTEGER DEFAULT 0,
    bytes_received_total INTEGER DEFAULT 0,
    last_seen TIMESTAMP,
    PRIMARY KEY (peer_id, local_identity, protocol)
);

Management CLI

# Rule management
fastn-p2p rules list [--identity alice]
fastn-p2p rules add --deny --peer bob_52char --protocol ssh
fastn-p2p rules add --deny --username suspicious-user
fastn-p2p rules add --deny --protocol http --header-query '$.path LIKE "%.php"'
fastn-p2p rules add --rate-limit 10/min --protocol chat --peer charlie_52char
fastn-p2p rules remove <rule-id>

# Ban management
fastn-p2p bans list
fastn-p2p bans add --peer eve_52char --duration 1h --reason "Spam"
fastn-p2p bans lift --peer eve_52char

# Session inspection
fastn-p2p sessions list [--active] [--protocol mail]
fastn-p2p sessions show <session-id>
fastn-p2p sessions kill <session-id>
fastn-p2p sessions kill --peer bob_52char --all

# Statistics
fastn-p2p stats show [--peer alice_52char]
fastn-p2p stats top --rejected          # Top rejected peers
fastn-p2p stats bandwidth --last 24h

# Real-time monitoring
fastn-p2p monitor                       # Live connection feed
fastn-p2p monitor --protocol ssh        # Filter by protocol

Rule Engine Examples

// Rule evaluation with JSON header queries
let rule = Rule {
    action: Action::Deny,
    protocol: Some("http"),
    header_query: Some(r#"
        $.method == "POST" AND 
        ($.path LIKE "%.php" OR $.path LIKE "%.cgi")
    "#),
};

// Fail2ban-like logic
if auth_failure {
    let mut ban = get_or_create_ban(peer_id, protocol);
    ban.failure_count += 1;
    
    if ban.failure_count >= 3 {
        ban.banned_until = now() + Duration::hours(1);
        ban.ban_count += 1;
        // Exponential backoff for repeat offenders
        if ban.ban_count > 3 {
            ban.banned_until = now() + Duration::hours(24);
        }
    }
}

// Rate limiting
let rate_limit = RateLimit {
    max_requests: 10,
    window: Duration::minutes(1),
};

Advanced Filtering

# Example rule configurations
rules:
  - action: deny
    priority: 100
    protocol: http
    header_query: |
      $.user_agent LIKE "%bot%" OR
      $.path IN ("/admin", "/wp-admin")
    
  - action: rate_limit
    priority: 200
    protocol: chat
    limit: "100/hour"
    username: "guest*"
    
  - action: allow
    priority: 300
    uid: 1000  # Allow specific user
    protocol: "*"

Integration with Daemon

// Before accepting connection
async fn handle_connection(socket: UnixStream) {
    // Get peer credentials
    let creds = socket.peer_cred()?;
    let username = resolve_username(creds.uid());
    
    // Check rules
    let decision = rule_engine.evaluate(
        peer_id,
        username,
        creds.uid(),
        protocol,
        headers
    );
    
    match decision {
        Action::Deny => {
            log_rejection(&peer_id, &protocol);
            update_stats(&peer_id, rejected: true);
            socket.shutdown();
        }
        Action::Allow => {
            create_session(&peer_id, &username, &protocol);
            proceed_with_connection(socket);
        }
        Action::RateLimit(limit) => {
            if !rate_limiter.check(&peer_id, limit) {
                socket.shutdown();
            }
        }
    }
}

This architecture provides defense-in-depth with multiple layers of filtering, comprehensive logging for forensics, and flexible rule management for different security policies.

[amitu]

Technical Design: Windows Support & Cross-Platform Considerations

This is a technical design response addressing Windows platform support for the P2P daemon architecture.

---

Good point! Windows requires a different approach for IPC and credential retrieval:

IPC Options on Windows

1. Named Pipes (Recommended for Windows)

// Windows named pipe path
\\.\pipe\fastn\identities\alice_52char\protocols\mail

// Server
let pipe = ServerOptions::new()
    .first_pipe_instance(true)
    .create(r"\\.\pipe\fastn\daemon")?;

// Client  
let mut client = OpenOptions::new()
    .read(true)
    .write(true)
    .open(r"\\.\pipe\fastn\daemon")?;

2. AF_UNIX on Windows 10+ (Build 17063+)

// Windows 10+ supports Unix sockets!
// Path: %TEMP%\fastn\sockets\...
let socket = UnixListener::bind(r"C:\Temp\fastn\daemon.sock")?;

Credential Retrieval on Windows

Windows uses different mechanisms for process identification:

#[cfg(windows)]
fn get_peer_credentials(pipe: &NamedPipe) -> Result<PeerCreds> {
    use windows::Win32::System::Pipes::*;
    use windows::Win32::Security::*;
    
    // Get client process ID
    let mut pid = 0u32;
    GetNamedPipeClientProcessId(pipe.as_raw_handle(), &mut pid)?;
    
    // Get process token
    let process = OpenProcess(PROCESS_QUERY_INFORMATION, false, pid)?;
    let mut token = HANDLE::default();
    OpenProcessToken(process, TOKEN_QUERY, &mut token)?;
    
    // Get user SID
    let user_sid = get_token_user(token)?;
    let username = lookup_account_sid(user_sid)?;
    
    Ok(PeerCreds {
        pid,
        username,
        sid: user_sid.to_string(),
    })
}

Cross-Platform Abstraction

pub enum IpcSocket {
    #[cfg(unix)]
    Unix(UnixStream),
    #[cfg(windows)]
    NamedPipe(NamedPipe),
}

pub struct PeerCredentials {
    pub pid: u32,
    pub username: String,
    #[cfg(unix)]
    pub uid: u32,
    #[cfg(unix)]
    pub gid: u32,
    #[cfg(windows)]
    pub sid: String,  // Windows Security Identifier
}

impl DaemonClient {
    pub fn connect(identity: &str, protocol: &str) -> Result<Self> {
        #[cfg(unix)]
        let socket = UnixStream::connect(
            format!("~/.fastn/sockets/{}/protocols/{}.sock", identity, protocol)
        )?;
        
        #[cfg(windows)]
        let socket = NamedPipe::connect(
            format!(r"\\.\pipe\fastn\{}\protocols\{}", identity, protocol)
        )?;
        
        Ok(Self { socket: IpcSocket::from(socket) })
    }
}

Windows Permission Model

// Windows uses ACLs instead of Unix permissions
#[cfg(windows)]
fn set_pipe_permissions(pipe_name: &str, allowed_users: &[&str]) -> Result<()> {
    use windows::Win32::Security::*;
    
    // Create DACL (Discretionary Access Control List)
    let mut dacl = DACL::new();
    
    for username in allowed_users {
        let sid = lookup_account_name(username)?;
        dacl.add_ace(
            AceType::AccessAllowed,
            AceFlags::None,
            GENERIC_READ | GENERIC_WRITE,
            sid,
        )?;
    }
    
    // Apply to named pipe
    set_named_pipe_security(pipe_name, dacl)?;
}

Platform-Specific Paths

pub fn socket_base_path() -> PathBuf {
    #[cfg(unix)]
    {
        dirs::home_dir()
            .unwrap()
            .join(".fastn")
            .join("sockets")
    }
    
    #[cfg(windows)]
    {
        // Use Local AppData on Windows
        dirs::data_local_dir()
            .unwrap()
            .join("fastn")
            .join("pipes")
    }
}

pub fn socket_path(identity: &str, protocol: &str) -> String {
    #[cfg(unix)]
    {
        format!("{}/identities/{}/protocols/{}.sock",
            socket_base_path().display(), identity, protocol)
    }
    
    #[cfg(windows)]
    {
        format!(r"\\.\pipe\fastn\{}\{}", identity, protocol)
    }
}

Windows Service Integration

# Windows Service configuration
[Service]
Name=fastn-daemon
DisplayName=Fastn P2P Daemon
Description=P2P communication daemon with WASM protocol plugins
StartType=Automatic
Account=LocalSystem

# Run with restricted privileges
ServiceSidType=Restricted

Modified CLI for Cross-Platform

# Unix/Linux/macOS
fastn-p2p daemon start --socket-dir ~/.fastn/sockets

# Windows
fastn-p2p daemon start --pipe-prefix \\.\pipe\fastn

# Cross-platform (auto-detects)
fastn-p2p daemon start

SQLite Schema Addition for Windows

-- Modify the rules table for Windows
ALTER TABLE rules ADD COLUMN windows_sid TEXT;  -- Windows Security ID
ALTER TABLE sessions ADD COLUMN windows_sid TEXT;

-- Platform-specific view
CREATE VIEW platform_sessions AS
SELECT 
    id, peer_id, protocol,
    CASE 
        WHEN windows_sid IS NOT NULL THEN windows_sid
        ELSE username || ':' || uid
    END as user_identifier
FROM sessions;

This ensures fastn-p2p works seamlessly across all major platforms while maintaining the security model.

[amitu]

Technical Clarification: Separating Local vs Peer Access Rules

This is a technical design correction addressing the distinction between local client access control and peer network access control.

---

You're absolutely right! We need to separate local access control from peer access control. These are two distinct security boundaries.

Revised SQLite Schema

Local Client Access Rules (IPC/Socket Access)

-- Which local users/processes can access the daemon
CREATE TABLE local_access_rules (
    id INTEGER PRIMARY KEY,
    priority INTEGER NOT NULL,
    action TEXT CHECK(action IN ('allow', 'deny')) NOT NULL,
    
    -- Match conditions for local clients
    username TEXT,                    -- Unix username or Windows account
    uid INTEGER,                      -- Unix UID
    gid INTEGER,                      -- Unix GID
    windows_sid TEXT,                 -- Windows Security ID
    process_name TEXT,                -- e.g., 'mail-client', 'chat-app'
    
    -- What they can access
    identity_pattern TEXT,            -- Which identities (glob pattern)
    protocol_pattern TEXT,            -- Which protocols (glob pattern)
    operations TEXT,                  -- JSON array: ['send', 'receive', 'manage']
    
    -- Metadata
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    expires_at TIMESTAMP,
    comment TEXT
);

-- Log local client connections
CREATE TABLE local_access_log (
    id INTEGER PRIMARY KEY,
    username TEXT,
    uid INTEGER,
    pid INTEGER,
    identity TEXT,
    protocol TEXT,
    operation TEXT,
    action TEXT,                      -- allow/deny
    matched_rule_id INTEGER,
    timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (matched_rule_id) REFERENCES local_access_rules(id)
);

Peer Access Rules (P2P Network Access)

-- Which remote peers can connect to us
CREATE TABLE peer_access_rules (
    id INTEGER PRIMARY KEY,
    priority INTEGER NOT NULL,
    action TEXT CHECK(action IN ('allow', 'deny', 'rate_limit')) NOT NULL,
    
    -- Match conditions for remote peers
    peer_id_pattern TEXT,             -- Specific peer or pattern
    peer_ip TEXT,                     -- IP address/range (if applicable)
    
    -- Protocol and data filters
    local_identity TEXT,              -- Which of our identities they're connecting to
    protocol TEXT,                    -- Which protocol they're using
    header_query TEXT,                -- JSON query on protocol headers
    
    -- Rate limiting
    rate_limit_spec TEXT,             -- e.g., "10/min", "100/hour"
    
    -- Metadata
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    expires_at TIMESTAMP,
    comment TEXT
);

-- Log peer connection attempts
CREATE TABLE peer_access_log (
    id INTEGER PRIMARY KEY,
    peer_id TEXT NOT NULL,
    peer_ip TEXT,
    local_identity TEXT NOT NULL,
    protocol TEXT,
    headers TEXT,                     -- JSON
    action TEXT,                      -- allow/deny/rate_limited
    matched_rule_id INTEGER,
    timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (matched_rule_id) REFERENCES peer_access_rules(id)
);

-- Peer-specific bans (fail2ban style)
CREATE TABLE peer_bans (
    peer_id TEXT,
    local_identity TEXT,
    protocol TEXT,
    failure_count INTEGER DEFAULT 1,
    first_failure TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    last_failure TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    banned_until TIMESTAMP,
    ban_count INTEGER DEFAULT 0,
    reason TEXT,
    PRIMARY KEY (peer_id, local_identity, protocol)
);

Example Rules

Local Access Rules

-- Allow user 'alice' to access all her identities
INSERT INTO local_access_rules (priority, action, username, identity_pattern, protocol_pattern)
VALUES (100, 'allow', 'alice', 'alice_*', '*');

-- Allow 'mail-daemon' user to only access mail protocol
INSERT INTO local_access_rules (priority, action, username, protocol_pattern, operations)
VALUES (200, 'allow', 'mail-daemon', 'mail', '["send", "receive"]');

-- Deny all access from user 'guest'
INSERT INTO local_access_rules (priority, action, username)
VALUES (50, 'deny', 'guest');

Peer Access Rules

-- Block all PHP requests on HTTP protocol
INSERT INTO peer_access_rules (priority, action, protocol, header_query)
VALUES (100, 'deny', 'http', '$.path LIKE "%.php"');

-- Rate limit chat messages from specific peer
INSERT INTO peer_access_rules (priority, action, peer_id_pattern, protocol, rate_limit_spec)
VALUES (200, 'rate_limit', 'spammer_52char_id', 'chat', '10/hour');

-- Allow specific peer full access to alice's mail
INSERT INTO peer_access_rules (priority, action, peer_id_pattern, local_identity, protocol)
VALUES (300, 'allow', 'trusted_52char_id', 'alice_52char', 'mail');

Access Control Flow

// Step 1: Local client connects via Unix socket/Named pipe
async fn handle_local_connection(socket: UnixStream) {
    let creds = socket.peer_cred()?;
    let username = resolve_username(creds.uid());
    
    // Check local access rules
    let decision = local_rule_engine.evaluate(
        username, creds.uid(), 
        requested_identity, requested_protocol
    );
    
    if decision == Action::Deny {
        log_local_rejection(username, requested_identity);
        return socket.shutdown();
    }
    
    // Local client authorized, proceed
    establish_client_session(socket);
}

// Step 2: When local client wants to communicate with peer
async fn handle_peer_communication(peer_id: &str, protocol: &str, headers: &Json) {
    // Check peer access rules
    let decision = peer_rule_engine.evaluate(
        peer_id, local_identity, protocol, headers
    );
    
    match decision {
        Action::Deny => {
            log_peer_rejection(peer_id, protocol);
            return Err("Peer blocked by rules");
        }
        Action::RateLimit(spec) => {
            if !check_rate_limit(peer_id, spec) {
                return Err("Rate limited");
            }
        }
        Action::Allow => proceed_with_peer_connection()
    }
}

Management CLI Updates

# Local access management
fastn-p2p local-rules list
fastn-p2p local-rules add --allow --user alice --identity "alice_*"
fastn-p2p local-rules add --deny --user guest --all
fastn-p2p local-rules test --user bob --identity alice_52char --protocol mail

# Peer access management  
fastn-p2p peer-rules list
fastn-p2p peer-rules add --deny --peer "evil_*" --all
fastn-p2p peer-rules add --rate-limit "10/min" --protocol chat
fastn-p2p peer-rules test --peer bob_52char --protocol ssh

# View both types of logs
fastn-p2p logs local --user alice --last 1h
fastn-p2p logs peer --protocol mail --denied

This separation makes the security model much cleaner and allows for independent management of local vs remote access control.

[amitu]

How would we implement multiplexing over Unix Socket? A protocol handler may require basic data (in/out/err), or stream (in/out or in/out/err), may require more than one streams (thinking audio/video/meeting etc streaming, each track may require its own stream). We want to multiplex all of them over a single socket connection per client. Or otherwise we maintain some sort of session object between client and control server, where we open multiple unix domain socket, enough for each stream and somehow tie them together using the session object.

[amitu]

Technical Design: Multiplexing Strategies for Unix Socket IPC

This is a technical analysis of stream multiplexing options for the daemon architecture.

---

Excellent question! Protocol handlers need flexible stream management. Here are two approaches:

Approach 1: Single Socket with Multiplexing

Use a framing protocol to multiplex multiple logical streams over one Unix socket:

// Frame structure for multiplexing
struct Frame {
    stream_id: u32,           // Logical stream identifier
    stream_type: StreamType,  // Control, Data, Audio, Video, etc.
    flags: u8,                // SYN, FIN, RST, etc.
    payload: Vec<u8>,
}

enum StreamType {
    Control,      // Session management
    StdIn,        // Standard input
    StdOut,       // Standard output  
    StdErr,       // Standard error
    Audio(u8),    // Audio track ID
    Video(u8),    // Video track ID
    Data(u16),    // Generic data stream with ID
}

Wire Protocol (Length-Prefixed Frames)

[4 bytes length][4 bytes stream_id][1 byte type][1 byte flags][payload]

Implementation

pub struct MultiplexedConnection {
    socket: UnixStream,
    streams: HashMap<u32, StreamHandle>,
    next_stream_id: AtomicU32,
}

impl MultiplexedConnection {
    // Open new logical stream
    pub async fn open_stream(&self, stream_type: StreamType) -> StreamHandle {
        let stream_id = self.next_stream_id.fetch_add(1, Ordering::Relaxed);
        
        // Send SYN frame
        let frame = Frame {
            stream_id,
            stream_type,
            flags: FLAGS_SYN,
            payload: vec![],
        };
        self.send_frame(frame).await?;
        
        StreamHandle { conn: self, id: stream_id }
    }
}

// Usage example
let conn = daemon.connect("alice_52char", "video-chat").await?;
let control = conn.open_stream(StreamType::Control).await?;
let video_out = conn.open_stream(StreamType::Video(0)).await?;
let audio_out = conn.open_stream(StreamType::Audio(0)).await?;

Pros:

• Single socket to manage
• Lower resource usage
• Easier permission management
• Similar to HTTP/2, QUIC multiplexing

Cons:

• Head-of-line blocking (one slow stream affects others)
• Need to implement flow control per stream
• More complex implementation

Approach 2: Multiple Sockets with Session

Create a session with control socket + data sockets:

pub struct Session {
    id: Uuid,
    control_socket: UnixStream,
    data_sockets: HashMap<String, UnixStream>,
}

// Session establishment protocol
#[derive(Serialize, Deserialize)]
enum SessionCommand {
    CreateSession { protocols: Vec<String> },
    OpenStream { session_id: Uuid, stream_type: String },
    CloseStream { session_id: Uuid, stream_id: String },
}

#[derive(Serialize, Deserialize)]
struct SessionResponse {
    session_id: Uuid,
    streams: HashMap<String, String>, // stream_type -> socket_path
}

Socket Layout

~/.fastn/sockets/sessions/
├── <session_uuid>/
│   ├── control.sock       # Session control
│   ├── stdin.sock         # Standard input
│   ├── stdout.sock        # Standard output
│   ├── stderr.sock        # Standard error
│   ├── audio_0.sock       # Audio track 0
│   ├── video_0.sock       # Video track 0
│   └── data_<n>.sock      # Additional data streams

Implementation

impl DaemonClient {
    pub async fn create_session(&self, identity: &str, protocol: &str) -> Session {
        // Connect to main control socket
        let control = UnixStream::connect(
            format!("~/.fastn/sockets/{}/protocols/{}.sock", identity, protocol)
        ).await?;
        
        // Request session creation
        let cmd = SessionCommand::CreateSession {
            protocols: vec!["stdin", "stdout", "stderr"],
        };
        control.send_json(&cmd).await?;
        
        let response: SessionResponse = control.recv_json().await?;
        
        // Connect to individual stream sockets
        let mut data_sockets = HashMap::new();
        for (stream_type, socket_path) in response.streams {
            let socket = UnixStream::connect(socket_path).await?;
            data_sockets.insert(stream_type, socket);
        }
        
        Session {
            id: response.session_id,
            control_socket: control,
            data_sockets,
        }
    }
}

Pros:

• True parallel I/O (no head-of-line blocking)
• Can use existing Unix tools (e.g., socat, nc)
• Simpler per-stream implementation
• Natural backpressure per stream

Cons:

• Multiple file descriptors
• More complex session management
• Race conditions during setup
• Higher resource usage

Hybrid Approach (Recommended)

Combine both: Control channel with multiplexing + optional high-bandwidth sockets:

pub struct HybridSession {
    // Multiplexed control/low-bandwidth streams
    control_mux: MultiplexedConnection,
    
    // High-bandwidth streams get dedicated sockets
    dedicated_streams: HashMap<StreamId, UnixStream>,
}

impl HybridSession {
    pub async fn open_stream(&self, stream_type: StreamType) -> Stream {
        match stream_type {
            // Small, latency-sensitive data uses multiplexed channel
            StreamType::Control | StreamType::StdErr => {
                self.control_mux.open_stream(stream_type).await
            }
            
            // High-bandwidth streams get dedicated sockets
            StreamType::Video(_) | StreamType::Audio(_) => {
                let socket_path = self.request_dedicated_socket(stream_type).await?;
                let socket = UnixStream::connect(socket_path).await?;
                Stream::Dedicated(socket)
            }
        }
    }
}

Protocol Handler Interface

// Protocol handlers declare their stream requirements
trait ProtocolHandler {
    fn stream_requirements(&self) -> StreamRequirements {
        StreamRequirements {
            multiplexed: vec![StreamType::Control, StreamType::StdIn, StreamType::StdOut],
            dedicated: vec![],  // No high-bandwidth streams
        }
    }
}

// Video chat protocol needs dedicated streams
impl ProtocolHandler for VideoChatProtocol {
    fn stream_requirements(&self) -> StreamRequirements {
        StreamRequirements {
            multiplexed: vec![StreamType::Control],
            dedicated: vec![
                StreamType::Video(0),  // Camera feed
                StreamType::Video(1),  // Screen share
                StreamType::Audio(0),  // Microphone
            ],
        }
    }
}

Flow Control & Backpressure

For multiplexed approach, implement per-stream flow control:

struct StreamWindow {
    stream_id: u32,
    send_window: AtomicU32,    // Bytes we can send
    recv_window: AtomicU32,    // Bytes peer can send
}

// Window update frames
struct WindowUpdate {
    stream_id: u32,
    increment: u32,  // Add to peer's send window
}

Comparison with Existing Solutions

Approach	Similar To	Use Case
Single Socket Multiplex	HTTP/2, QUIC	Low-latency control protocols
Multiple Sockets	Traditional Unix tools	High-bandwidth streaming
Hybrid	gRPC + sidecar streams	Mixed workloads

The hybrid approach gives us flexibility for different protocol needs while maintaining efficiency.

[amitu]

So we are going to have three protocol patterns, request-response, single bi-directional stream, and multi stream (multiple tracks, one logical "session"). And we want to mostly write the server side code by using tokio::copy() like methods to pipe the streams in session between iroh and unix domain. Multiple stream feels better as tokio::copy() etc will ensure there is end to end (between the two peers) back pressure possibility (we are aiming for this, but not necessarily v1 blocker).

[amitu]

Technical Design: Protocol Patterns & Stream Architecture

This is a technical design response outlining the three protocol patterns and zero-copy stream bridging implementation.

---

Great insight! Using tokio::copy() for zero-copy bridging between iroh and Unix sockets will give us excellent performance and natural backpressure. Let's go with multiple sockets per session.

Three Protocol Patterns

1. Request-Response Pattern

Simple RPC-style protocols (DNS, HTTP GET, etc.)

trait RequestResponseProtocol {
    async fn handle_request(&self, req: Request) -> Response;
}

// Single Unix socket for req/resp
struct ReqRespSession {
    socket: UnixStream,
}

2. Single Bi-directional Stream

SSH, simple chat, telnet-like protocols

trait SingleStreamProtocol {
    async fn handle_stream(&self, stream: BiStream);
}

// Two Unix sockets (or one bidirectional)
struct SingleStreamSession {
    stdin: UnixStream,   // Client -> Daemon -> Peer
    stdout: UnixStream,  // Peer -> Daemon -> Client
}

3. Multi-Stream Session

Video conferencing, screen sharing with audio, complex protocols

trait MultiStreamProtocol {
    fn declare_streams(&self) -> Vec<StreamDeclaration>;
    async fn handle_session(&self, streams: HashMap<String, BiStream>);
}

struct StreamDeclaration {
    name: String,        // "video", "audio", "control"
    direction: Direction, // In, Out, Bidirectional
    required: bool,
}

// Multiple Unix sockets per logical session
struct MultiStreamSession {
    session_id: Uuid,
    streams: HashMap<String, UnixStream>,
}

Zero-Copy Bridge Implementation

The key insight: use tokio::copy() to create zero-copy bridges with automatic backpressure:

// Core bridge between iroh P2P stream and Unix socket
async fn bridge_streams(
    mut iroh_stream: quinn::BiStream,
    mut unix_socket: UnixStream,
) {
    let (iroh_send, iroh_recv) = iroh_stream.split();
    let (unix_read, unix_write) = unix_socket.split();
    
    // Bridge in both directions with automatic backpressure
    let to_peer = tokio::io::copy(&mut unix_read, &mut iroh_send);
    let from_peer = tokio::io::copy(&mut iroh_recv, &mut unix_write);
    
    // Run both directions concurrently
    tokio::select! {
        res = to_peer => {
            if let Err(e) = res {
                tracing::debug!("Bridge to peer closed: {}", e);
            }
        }
        res = from_peer => {
            if let Err(e) = res {
                tracing::debug!("Bridge from peer closed: {}", e);
            }
        }
    }
}

Session Manager

pub struct SessionManager {
    sessions: Arc<RwLock<HashMap<Uuid, Session>>>,
}

impl SessionManager {
    // Client requests a new session
    pub async fn create_session(
        &self,
        peer_id: &str,
        protocol: &str,
        pattern: ProtocolPattern,
    ) -> Result<SessionInfo> {
        let session_id = Uuid::new_v4();
        let socket_dir = format!("/tmp/fastn/sessions/{}", session_id);
        std::fs::create_dir_all(&socket_dir)?;
        
        match pattern {
            ProtocolPattern::RequestResponse => {
                let socket_path = format!("{}/rpc.sock", socket_dir);
                self.create_socket(&socket_path).await?;
                
                SessionInfo {
                    session_id,
                    sockets: vec![socket_path],
                }
            }
            
            ProtocolPattern::SingleStream => {
                let stdin_path = format!("{}/stdin.sock", socket_dir);
                let stdout_path = format!("{}/stdout.sock", socket_dir);
                
                self.create_socket(&stdin_path).await?;
                self.create_socket(&stdout_path).await?;
                
                SessionInfo {
                    session_id,
                    sockets: vec![stdin_path, stdout_path],
                }
            }
            
            ProtocolPattern::MultiStream(declarations) => {
                let mut sockets = vec![];
                
                for stream in declarations {
                    let path = format!("{}/{}.sock", socket_dir, stream.name);
                    self.create_socket(&path).await?;
                    sockets.push(path);
                }
                
                SessionInfo {
                    session_id,
                    sockets,
                }
            }
        }
    }
    
    // When peer connects, bridge all streams
    pub async fn handle_peer_connection(
        &self,
        session_id: Uuid,
        mut peer_conn: quinn::Connection,
    ) {
        let session = self.sessions.read().await.get(&session_id).cloned();
        let Some(session) = session else { return };
        
        // Accept/open streams based on protocol pattern
        match session.pattern {
            ProtocolPattern::MultiStream(ref streams) => {
                // Spawn a task for each stream bridge
                for stream_decl in streams {
                    let socket_path = format!("{}/{}.sock", session.socket_dir, stream_decl.name);
                    
                    tokio::spawn(async move {
                        // Accept Unix socket connection
                        let unix_listener = UnixListener::bind(&socket_path)?;
                        let (unix_stream, _) = unix_listener.accept().await?;
                        
                        // Open/accept iroh stream
                        let iroh_stream = if stream_decl.direction == Direction::Out {
                            peer_conn.open_bi().await?
                        } else {
                            peer_conn.accept_bi().await?
                        };
                        
                        // Bridge with automatic backpressure
                        bridge_streams(iroh_stream, unix_stream).await;
                    });
                }
            }
            _ => { /* Similar for other patterns */ }
        }
    }
}

Client Library

pub struct P2PClient {
    daemon_socket: UnixStream,
}

impl P2PClient {
    pub async fn start_video_chat(&self, peer_id: &str) -> VideoChat {
        // Request multi-stream session
        let req = CreateSession {
            peer_id: peer_id.to_string(),
            protocol: "video-chat",
            pattern: ProtocolPattern::MultiStream(vec![
                StreamDeclaration { name: "control", direction: Bidirectional, required: true },
                StreamDeclaration { name: "video_out", direction: Out, required: true },
                StreamDeclaration { name: "video_in", direction: In, required: false },
                StreamDeclaration { name: "audio_out", direction: Out, required: true },
                StreamDeclaration { name: "audio_in", direction: In, required: true },
            ]),
        };
        
        let session_info = self.send_request(req).await?;
        
        // Connect to individual sockets
        let control = UnixStream::connect(&session_info.sockets[0]).await?;
        let video_out = UnixStream::connect(&session_info.sockets[1]).await?;
        let video_in = UnixStream::connect(&session_info.sockets[2]).await?;
        let audio_out = UnixStream::connect(&session_info.sockets[3]).await?;
        let audio_in = UnixStream::connect(&session_info.sockets[4]).await?;
        
        VideoChat {
            control,
            video_out,
            video_in, 
            audio_out,
            audio_in,
        }
    }
}

// Client can now use standard Unix I/O
let mut chat = client.start_video_chat("peer_52char").await?;

// Write video frames - backpressure automatically handled
chat.video_out.write_all(&video_frame).await?;

// Read audio - blocks if no data available
let mut audio_buffer = [0u8; 1024];
chat.audio_in.read(&mut audio_buffer).await?;

Backpressure Flow

[Client App] -> Unix write() -> [Unix Socket Buffer] -> tokio::copy() -> 
[iroh/quinn Send Buffer] -> QUIC flow control -> [Network] ->
[Peer quinn Recv Buffer] -> tokio::copy() -> [Peer Unix Socket] -> [Peer App]

If any buffer fills up, backpressure naturally propagates back to the source.

Benefits of Multiple Sockets

1. Natural Backpressure: Each stream has independent flow control
2. Zero-Copy: tokio::copy() uses sendfile/splice when possible
3. Simple Client: Clients just read/write to Unix sockets
4. Parallel I/O: No head-of-line blocking between streams
5. Standard Tools: Can use socat, nc, ffmpeg directly with sockets
6. Clean Separation: Each stream failure isolated from others

Example: SSH over P2P

// SSH is single bidirectional stream
let session = client.create_session("peer_id", "ssh", ProtocolPattern::SingleStream).await?;

// Connect local SSH client to daemon
std::process::Command::new("ssh")
    .arg("-o").arg(format!("ProxyCommand=socat - UNIX:{}", session.sockets[0]))
    .arg("user@peer")
    .spawn()?;

// Daemon bridges SSH traffic to peer transparently

This architecture gives us maximum flexibility while keeping implementation simple through tokio::copy().

[amitu]

Let's simplify our lives and only handle request-response and single bidirectional stream. They are both just single bidirectional stream, and they map cleanly with both Unix Socket and the iroh bi directional stream interface. The stdout/err thing is a very SSH specific thing, so for now ssh can implement output multiplexing over single stream. And for at least audio we settled on a client fetch pattern leading audio streaming to become a case of request-response (whenever audio output buffer is running low client requests for next chunk, no real streaming, not sure how live will work, but this is good enough for v1).

[amitu]

Technical Design: Simplified Single Stream Architecture

This is a technical design response simplifying the architecture to use only single bidirectional streams.

---

Excellent simplification! You're right - both request-response and streaming are just single bidirectional streams with different usage patterns. This maps perfectly to both Unix sockets and iroh's BiStream.

Unified Protocol Pattern

// All protocols use the same pattern
trait ProtocolHandler {
    async fn handle_stream(&self, stream: BiStream);
}

// Single Unix socket per session
struct Session {
    id: Uuid,
    peer_id: String,
    protocol: String,
    unix_socket: UnixStream,  // Single bidirectional socket
    iroh_stream: BiStream,     // Single bidirectional stream
}

Zero-Copy Bridge - Dead Simple

impl SessionManager {
    // One function handles everything
    async fn bridge_session(&self, session: Session) {
        let (unix_read, unix_write) = session.unix_socket.split();
        let (iroh_send, iroh_recv) = session.iroh_stream.split();
        
        // Bridge with automatic backpressure
        let to_peer = tokio::io::copy(&mut unix_read, &mut iroh_send);
        let from_peer = tokio::io::copy(&mut iroh_recv, &mut unix_write);
        
        tokio::select! {
            _ = to_peer => {},
            _ = from_peer => {},
        }
    }
}

Session Creation

impl DaemonClient {
    pub async fn connect_peer(&self, peer_id: &str, protocol: &str) -> UnixStream {
        // Create session
        let session_id = Uuid::new_v4();
        let socket_path = format!("/tmp/fastn/sessions/{}.sock", session_id);
        
        // Request daemon to establish P2P connection
        let req = CreateSession {
            session_id,
            peer_id: peer_id.to_string(),
            protocol: protocol.to_string(),
            socket_path: socket_path.clone(),
        };
        
        self.control_socket.send_json(&req).await?;
        
        // Connect to the Unix socket
        UnixStream::connect(&socket_path).await?
    }
}

Protocol Examples

Request-Response (HTTP-like)

let mut stream = client.connect_peer("peer_52char", "http").await?;

// Send request
stream.write_all(b"GET /api/data\r\n\r\n").await?;

// Read response
let mut response = Vec::new();
stream.read_to_end(&mut response).await?;

Streaming (Chat)

let mut stream = client.connect_peer("peer_52char", "chat").await?;

// Bidirectional messaging
loop {
    tokio::select! {
        // Send messages
        msg = user_input.recv() => {
            stream.write_all(msg.as_bytes()).await?;
        }
        
        // Receive messages
        result = stream.read(&mut buffer) => {
            let n = result?;
            println!("Received: {}", String::from_utf8_lossy(&buffer[..n]));
        }
    }
}

SSH with Multiplexing

// SSH handles its own stdout/stderr multiplexing
struct SSHProtocol;

impl ProtocolHandler for SSHProtocol {
    async fn handle_stream(&self, stream: BiStream) {
        // SSH protocol internally multiplexes stdin/stdout/stderr
        // over the single bidirectional stream
        ssh::handle_multiplexed_session(stream).await;
    }
}

// Client side - SSH client handles demultiplexing
let stream = client.connect_peer("peer_52char", "ssh").await?;
// Pass to SSH client which knows how to demux

Audio with Pull Pattern

// Audio uses request-response for chunks
let mut stream = client.connect_peer("peer_52char", "audio").await?;

// Audio player pulls chunks as needed
loop {
    if audio_buffer.remaining() < THRESHOLD {
        // Request next chunk
        stream.write_all(b"NEXT_CHUNK\n").await?;
        
        // Receive chunk
        let mut chunk = vec![0u8; CHUNK_SIZE];
        stream.read_exact(&mut chunk).await?;
        
        audio_buffer.append(chunk);
    }
    
    audio_player.play_from_buffer(&mut audio_buffer);
}

Benefits of Single Stream Model

1. Simplicity: One socket, one stream, one bridge function
2. Clean Mapping: Unix socket ↔ iroh BiStream (both bidirectional)
3. Flexibility: Protocols decide their own framing/multiplexing
4. Efficiency: tokio::copy() handles everything optimally
5. Less State: No complex session management with multiple streams

Socket Layout (Simplified)

/tmp/fastn/sessions/
├── <session_uuid_1>.sock    # HTTP request to peer A
├── <session_uuid_2>.sock    # SSH session to peer B
├── <session_uuid_3>.sock    # Chat with peer C
└── <session_uuid_4>.sock    # Audio stream from peer D

Daemon Core Loop

impl Daemon {
    async fn run(&self) {
        loop {
            tokio::select! {
                // Handle local client requests
                Ok((client_socket, _)) = self.control_listener.accept() => {
                    let session = self.create_session(client_socket).await?;
                    
                    // Open P2P connection
                    let iroh_stream = self.connect_to_peer(
                        &session.peer_id, 
                        &session.protocol
                    ).await?;
                    
                    // Bridge them - that's it!
                    tokio::spawn(bridge_session(session, iroh_stream));
                }
                
                // Handle incoming P2P connections
                Ok((peer_stream, peer_id)) = self.p2p_listener.accept() => {
                    // Read protocol header
                    let protocol = read_protocol_header(&mut peer_stream).await?;
                    
                    // Create Unix socket for this session
                    let socket_path = create_session_socket().await?;
                    
                    // Notify interested local clients
                    self.notify_protocol_handlers(&protocol, &socket_path).await;
                    
                    // Bridge when client connects
                    let unix_stream = wait_for_unix_connection(&socket_path).await?;
                    tokio::spawn(bridge_session(unix_stream, peer_stream));
                }
            }
        }
    }
}

This is beautifully simple - everything is just bridging single bidirectional streams!