code.foss.global

Across the ecosystem, the recurring pattern was clear: services gained durable state, explicit policy models, and admin surfaces that make them manageable in production rather than merely functional in isolation.

dcrouter: From Gateway to Datacenter Control Plane

@serve.zone/dcrouter remained the most active infrastructure project in April, reaching the 13.20.x release line and expanding from protocol gateway into a broader datacenter edge control plane.

DB-backed DNS management -- DNS providers, domains, and records are now persisted and managed through the runtime and Ops UI. Provider-managed domains can be mirrored locally for API and dashboard visibility while remaining authoritative at the upstream provider. dcrouter-hosted domains are handled directly by the built-in DNS path.

ACME configuration in the dashboard -- Certificate behavior moved into database-backed configuration with reusable UI flows for provider setup and domain/certificate management. April also aligned dcrouter with smartacme's new forced-renewal support, including safeguards around valid certificates.

Email domain lifecycle management -- Email domains can now be created and managed through dcrouter with DKIM generation, DNS provisioning, validation, optional subdomain support, persistent smartmta storage, and runtime synchronization between configured domains and the mail server.

Unified route ownership -- Route management was reorganized around persisted route origins: config, email, dns, and api. System-generated routes can be shown separately from user-managed routes, while API-owned routes support full CRUD. This gives dcrouter one route model across HTTP, DNS, email, remote ingress, and programmatic configuration.

Profile-based VPN access -- The VPN access model moved away from tag-based rules toward source and target profiles. Source profiles describe who or what is connecting; target profiles describe reachable networks, hosts, and ports. Routes can then reference those profiles instead of embedding ad hoc access rules.

Remote ingress controls -- Route configuration gained remote ingress controls and preserve-port targeting, making tunnel-backed services easier to expose without losing backend port semantics.

Ops dashboard reorganization -- The web UI was reorganized into grouped operations areas covering overview, domains, DNS, certificates, email, access, security, network, routes, VPN, and remote ingress. Tables gained filtering, live update highlighting, and clearer monitoring views as dees-catalog evolved underneath.

Network monitoring -- dcrouter now consumes the richer smartproxy metrics model: protocol distribution, bandwidth-ranked IP and domain activity, request-based domain aggregation, and route-aware traffic statistics.

The result is a gateway that is no longer configured only as a static edge process. It is becoming the operational system of record for routing, certificates, DNS, email, VPN access, and ingress policy.

Ecosystem note. dcrouter is the serve.zone edge control plane. In monthly updates it usually means routing, certificates, DNS, mail, VPN access, and ingress policy are moving from static config into managed runtime state.

callrouter: A Rust-Backed Telephony Stack

April introduced heavy activity around @serve.zone/callrouter, a SIP and WebRTC routing system with a TypeScript control plane and Rust media/SIP data plane.

SIP B2BUA and WebRTC bridge -- callrouter handles SIP provider and device legs, browser WebRTC legs, and internal tool or recording legs as a multi-leg call hub. The architecture is built around controlled call legs rather than a simple pass-through proxy.

Rust proxy engine -- SIP dialog handling, RTP port management, WebRTC bridging, outbound calling, voicemail, IVR, recording, and dashboard event reporting are handled by a Rust-backed proxy engine integrated with the TypeScript runtime.

Audio engine upgrades -- The media pipeline moved to 48 kHz float processing with adaptive RTP jitter buffering, stable 20 ms resampling, Opus packet loss concealment, negotiated SDP payload handling, and per-leg denoising.

Voicemail, IVR, and TTS -- April added DTMF-driven IVR flows, prompt playback, voicemail recording, dashboard management, and Kokoro-based TTS generation with caching and live streaming interaction support.

Guided provider setup -- The dashboard gained guided provider creation, explicit inbound DID routing, provider-based number matching, incoming number ranges, and improved diagnostics for inbound routing.

Fax support -- The 1.26.x line added fax routing, job tracking, inbox management, and T.38/UDPTL media support.

Docker release pipeline -- callrouter also gained multi-architecture Docker build support and tagged release automation.

This is a new major building block for serve.zone: telephony, browser calling, voicemail, IVR, and fax in the same infrastructure style as the existing gateway stack.

idp.global and Swift Tooling: Identity Moves to Devices

April's identity work connected backend authentication, native clients, and Swift automation.

idp.global authentication hardening -- idp.global added argon2 password hashing, legacy hash migration, rotating hashed refresh tokens, refresh-token reuse detection, and persisted email action tokens and registration sessions.

OIDC persistence and consent -- Authorization codes, access tokens, refresh tokens, and user consent records are now stored in SmartData-backed persistence with hashed token storage. OIDC flows gained consent-aware continuation after login and stronger abuse protection around login, magic links, password reset, and token exchange.

Passport device flows -- The identity provider gained passport device enrollment, signed device requests, challenge approval, push token registration, alert lifecycle APIs, and alert-rule management. This pushes identity beyond password/OIDC sessions toward device-backed approvals.

Native companion app -- idp.global/swiftapp built out a SwiftUI companion app for iPhone, iPad, Mac, and Apple Watch. The app now uses the live idp.global backend by default for pairing, dashboard loading, approvals, and alerts. Pairing includes a welcome flow, QR scanning, manual fallback, NFC pairing, and NFC identity proof with signed GPS position on supported devices.

@git.zone/tsswift -- A new Swift/Xcode workflow CLI emerged in April. tsswift can detect SwiftPM, Xcode project, and workspace layouts; run doctor, build, test, run, emulator, launch, screenshot, review, and watch workflows; persist simulator preferences; and operate named remote macOS builders over SSH with rsync-based project sync. Remote screenshot capture syncs outputs back into the local project.

@api.global/swiftsupport -- api.global gained a Swift transport support package for typedrequest over POST /typedrequest and typedsocket over WebSocket, including typed clients, correlation metadata, retry handling, and typed transport errors.

Together, these pieces make Swift clients first-class participants in the code.foss.global identity and API ecosystem rather than one-off consumers.

Ecosystem note. idp.global is

The Rust-hybrid stack goes production.

Over the past two months, the code.foss.global ecosystem underwent a fundamental architectural shift: critical infrastructure projects gained Rust data planes while keeping TypeScript control planes. February laid the groundwork -- Rust networking engines, IPC bridges, and toolchain automation. March turned that groundwork into shippable products: a self-hosted S3-compatible storage appliance, a multi-protocol package registry, a unified datacenter gateway handling seven protocol families, and a VPN system that matured from proof-of-concept to deployment-ready.

The Hybrid TypeScript/Rust Architecture

The foundation enabling this shift is @push.rocks/smartrust, the bridge library that establishes IPC channels between TypeScript processes and compiled Rust binaries via stdio and Unix domain sockets. smartrust handles serialization, process lifecycle, and bidirectional message passing, letting any TypeScript module offload compute-intensive work to a Rust subprocess without abandoning its existing API surface.

@git.zone/tsrust complements this with zero-setup Rust toolchain management and cross-compilation. It detects the host platform, downloads the appropriate Rust toolchain on first run, and compiles Rust crates as part of the standard pnpm build pipeline. No manual rustup or cargo configuration required.

@git.zone/tsdeno launched in March as a new companion tool: a smart wrapper around deno compile that isolates package.json during compilation, preventing devDependencies from inflating binaries by hundreds of megabytes. It supports cross-compilation, config-based multi-target builds, and a programmatic API for CI/CD integration.

Ecosystem note. The Rust/TypeScript bridge keeps the public API and build workflow in TypeScript while moving packet, storage, media, or VM data paths into Rust subprocesses where native I/O is useful.

dcrouter: The All-In-One Datacenter Gateway

@serve.zone/dcrouter was the most actively developed project across both months. What started as an HTTP reverse proxy is now a unified infrastructure gateway consolidating seven protocol-level services into a single deployment.

HTTP/HTTPS with Automatic TLS -- TLS termination with automatic certificate provisioning via ACME, including Cloudflare DNS-01 challenges for wildcard certificates. Routing decisions are based on SNI and Host headers, supporting both termination and transparent passthrough for services that manage their own certificates.

HTTP/3 and QUIC -- A full QUIC listener alongside the TCP stack enables HTTP/3 for clients that support it. The QUIC implementation shares the same routing table as the HTTP/1.1 and HTTP/2 paths, so configuration is unified regardless of transport.

TCP/SNI Proxying -- Transparent TCP passthrough based on SNI extraction from the TLS ClientHello, for services that require end-to-end TLS without termination at the gateway.

Multi-Domain SMTP -- An integrated SMTP server (powered by smartmta) with per-domain routing, DKIM signing, SPF validation, and DMARC policy enforcement. Inbound mail is routed to backend services based on recipient domain, making dcrouter the MX entry point.

DNS Server (Rust-backed) -- An authoritative DNS responder implemented in Rust for packet parsing and response assembly, serving zone data configured through dcrouter's TypeScript API. Eliminates the need for a separate DNS daemon.

RADIUS Authentication -- Network device authentication via RADIUS supporting PAP, CHAP, MAC-based authentication, and VLAN assignment. This enables dcrouter to serve as the AAA backend for switches, access points, and VPN concentrators.

Remote Ingress -- A NAT traversal system allowing nodes behind firewalls to register with dcrouter edge instances and receive proxied traffic via persistent WebSocket or QUIC tunnels with PROXY protocol headers to preserve client IP information.

OpsServer Dashboard -- A built-in web UI exposing real-time connection counts, throughput graphs, certificate status, and per-route health checks.

The result is a single deployment that replaces nginx, postfix, bind, freeradius, and a reverse tunnel service.

smartproxy: Kernel-Level Forwarding and Unified Route Config

@push.rocks/smartproxy reached a major milestone in March with a complete routing overhaul and kernel-level packet forwarding.

Unified Route-Based Configuration -- All proxy behavior is now defined through a single route configuration system. Each route specifies match criteria (domain patterns, IP ranges, ports), the action (forward, terminate, redirect, block), and backend targets. This replaces the previous separate configuration for HTTP, TCP, and TLS modes.

NFTables Kernel-Level Forwarding -- For high-throughput passthrough routes, smartproxy can now install NFTables rules to forward packets entirely in kernel space, bypassing both the Rust and Node.js layers. The TypeScript API manages rule lifecycle while the actual forwarding happens at line rate in the kernel's netfilter subsystem.

Rust Networking Engine -- Connection acceptance, TLS handshake, protocol detection, and byte-level forwarding all run in Rust. The Rust engine communicates with TypeScript via socket-based IPC. For passthrough routes, bytes never touch the Node.js event loop. For terminated routes, the Rust layer handles TLS and forwards plaintext to the TypeScript-managed backend pool.

PROXY Protocol v1/v2 -- Both sending and receiving PROXY protocol headers, enabling smartproxy to sit behind or in front of other proxies while preserving original client addresses through the entire chain.

JWT Authentication -- Route-level JWT validation with configurable JWKS endpoints, claim-based routing decisions, and token refresh handling.

IP Filtering and Rate Limiting -- Per-route IP allowlists/denylists and token-bucket rate limiting, evaluated in the Rust layer before connections reach backend services.

Real-Time Metrics -- Per-connection byte counters and throughput sampling at configurable intervals, exposed via IPC and a Prometheus-compatible HTTP endpoint.

Ecosystem note. smartproxy is the shared proxy engine beneath dcrouter and related gateway services. dcrouter owns the operator-facing control plane; smartproxy owns route matching and network forwarding.

lossless.zone/objectstorage: Self-Hosted S3 in a Single Docker Image

lossless.zone launched as a new organization in March, debuting with objectstorage -- a fully-featured, self-hosted S3-compatible storage server with a web-based management interface packaged as a single Docker image.

Rust Storage Engine -- Built on @push.rocks/smartstorage, the storage layer uses hyper 1.x with streaming I/O, zero-copy data paths via sendfile(2), and optional Reed-Solomon erasure coding for distributed deployments.

SigV4 Authentication -- Full AWS Signature Version 4 request signing, making it compatible with any S3 client library, the AWS CLI, and tools like rclone or s3cmd.

IAM-Style Policy System -- Bucket-level access policies with principal-based permissions, enabling fine-grained access control for multi-tenant deployments.

We are moving to more domain centric packages with multiple exports.

Ecosystem note. Domain-centric packages group server, client, service-worker, and edge-worker exports inside one package when those pieces share the same product boundary. The goal is clearer imports, not larger unrelated bundles.

Examples:

• @api.global/typedserver now includes server, inject script, serviceworker, serviceworker client, and workerd based edgeworker. In other words: the package contains everything to serve a super performant service, website, SaaS app or even PWA.
• @push.rocks/smartdns now includes a server and a client, as to just a client from before. You can now import the server as `import * as smartdnsServer from '@push.rocks/smartdns/server'.

• @push.rocks/smartbucket got a major overhaul
• host.today now publishes its docker images to code.foss.global as main docker registry.
• We are gradually shifting resources from gitlab to code.foss.global allowing for gitlab to act as mirror. The mirror setup will work by aggregating all projects on gitlab in a congruent pattern under the gitlab.com/foss.global/ namespace.

Ecosystem note. code.foss.global is the canonical forge and registry for foss.global projects. GitLab can remain a mirror, but packages and Docker images are moving to the hosted code.foss.global namespace.

• @api.global/typedserver now contains a complete solution to serve PWAs from development to production. It includes the server with mechanics for live reloading, a service worker, a service worker client that can be imported into your app for control purposes, and last but not least an edgeworker that can be deployed anywhere that supports workerd (like Cloudflare workers).

Ecosystem note. typedserver is the @api.global server layer for typed APIs and web apps. The PWA work adds development reload, service-worker control, and workerd-compatible edge deployment around that runtime.

• We started work on docs.foss.global which will scrape all projects automatically to provide a coherent and automated docs experience.
• You may have noticed a change in project documentation. We are now using @git.zone/tsdoc to create docs using AI.
• `@push.rocks/smartguards` got a major overhaul and is now supported by @api.global/typedrequest