feat: pluggable sync transports — Azure relay (primary), Vercel (backup), Hyperswarm (direct)

[kayodebristol]

Summary

Design the sync transport layer as pluggable, with three modes:

Priority	Transport	Environment	Details
Primary	Azure relay	Corporate / anywhere	WSS on port 443, looks like normal HTTPS traffic
Backup	Vercel relay	Corporate / anywhere	Edge WebSocket functions, free tier, *.vercel.app domain
Direct	Hyperswarm	Home/personal only	DHT + UDP holepunching — triggers corporate IDS, not safe for work networks

Motivation

Hyperswarm direct P2P is excellent for home networks but uses UDP on non-standard ports + DHT traffic that resembles BitTorrent. Corporate IDS/firewalls will flag it. We need a corporate-safe transport that looks like normal web traffic.

PluresDB already has Azure relay infrastructure (azure/ directory — Bicep templates, deploy/destroy scripts, relay tests). This issue extends that into a proper pluggable transport system.

Design

Transport Trait (Rust)

#[async_trait]
pub trait SyncTransport: Send + Sync {
    async fn connect(&self, topic: &[u8; 32]) -> Result<Box<dyn AsyncStream>>;
    async fn listen(&self, topic: &[u8; 32]) -> Result<Box<dyn AsyncStream>>;
    fn name(&self) -> &str;
}

Three Implementations

1. RelayTransport (Azure — primary)

• Connects via WSS to Azure Container Instance relay
• Port 443, TLS — indistinguishable from normal HTTPS
• Relay matches peers by topic hash, pipes encrypted bytes
• Uses existing azure/infrastructure/ Bicep templates
• Relay is stateless, horizontally scalable

2. VercelRelayTransport (backup)

• Same protocol as Azure relay but hosted on Vercel edge functions
• *.vercel.app domain — universally whitelisted
• Free tier sufficient for signaling + small data relay
• Deploy: vercel deploy from a small project

3. HyperswarmTransport (direct)

• Full Hyperswarm DHT + UDP holepunching
• Best throughput, no relay dependency
• Only for home/personal networks

4. AutoTransport (recommended default)

• Try Hyperswarm direct first
• If UDP blocked → fall back to Azure relay
• If Azure unavailable → fall back to Vercel relay

Connection Flow (relay modes)

Phase 1: Discovery via relay (corporate-safe)
A ──wss:443──► Relay ◄──wss:443── B
               match by topic hash
               exchange connection info

Phase 2: Upgrade to direct (if possible)
A ◄─────── direct connection ──────► B
           (relay dropped)

Phase 3: Fallback (if direct fails)
A ──wss:443──► Relay ──wss:443──► B
               (relay pipes bytes)

Config

{
  "syncTransport": "auto",
  "syncRelay": "wss://pluresdb-relay.azurewebsites.net",
  "syncRelayFallback": "wss://pluresdb-relay.vercel.app",
  "syncKey": "<shared-secret>"
}

Implementation Plan

1. Define transport trait in hyperswarm-rs crate (plures/hyperswarm)
2. Build Azure WSS relay server (extend existing azure/ infra)
3. Build Vercel relay (new small project, ~100 LOC)
4. Implement RelayTransport (JS first, then Rust)
5. Implement AutoTransport with fallback chain
6. Update superlocalmemory to use pluggable transport config
7. Deploy Azure relay to test environment
8. Deploy Vercel relay as backup
9. Integration tests across all three transports

Related

• feat: P2P sync transport via Hyperswarm (DHT discovery + NAT holepunching) #70 — P2P sync transport via Hyperswarm
• Rust implementation roadmap hyperswarm#1 — Rust implementation roadmap
• azure/ directory — existing relay infrastructure