Topic

Engineering

@serve.zone/callrouter: HiFi Calling Engine for SIP, WebRTC, and social.io @serve.zone/callrouter puts high-fidelity Rust audio processing, hub-based call legs, and pluggable SIP/WebRTC workflows behind the calling layer social.io needs. Engineering, Infrastructure, serve.zone

@serve.zone/callrouter is the calling engine being built for serve.zone and social.io. It should be read less as a generic SIP router and more as the media/control boundary for calls that cross browsers, SIP trunks, LAN phones, voicemail, fax, and operator dashboards.

For social.io, the direction is explicit: @serve.zone/callrouter will solve calling by giving the product a Rust-backed media path and a TypeScript-owned operations layer. Browser WebRTC calls can live in the product surface, while trunk/device integration, call state, and media mixing stay in the service layer.

The project was already covered as part of the April 2026 code.foss.global update. The current 1.28.0 line makes the interesting part clearer: performance-sensitive media work is in Rust, call composition is hub-based, and the surrounding TypeScript service keeps the system configurable and operable.

Performance boundary: Rust owns the real-time path

The TypeScript side owns configuration, dashboard views, REST and WebSocket APIs, browser signaling, runtime status, and shutdown/reload orchestration. It does not parse raw SIP packets or process RTP audio.

The Rust proxy-engine owns SIP dialog handling, RTP I/O, WebRTC media sessions, codec boundaries, mixing, jitter handling, fax transport, and live call state. The two sides communicate through high-level commands and events over @push.rocks/smartrust, following the TypeScript/Rust split described in the foss.global bridge architecture note.

That matters for performance because the packet path does not depend on JavaScript timers, object churn, or application-level WebSocket handling once media is in the engine. No public benchmark numbers are documented, so the performance claim is architectural: real-time SIP/RTP/WebRTC work sits in the native process that owns the sockets and mixer.

The HiFi audio engine

The current media engine mixes calls on a 20 ms tick over a 48 kHz f32 internal bus. That is the right center of gravity for a service that has to bridge browser WebRTC and telephony codecs without treating every call as a lowest-common-denominator RTP relay.

Codec handling currently covers Opus, G.722, PCMU, and PCMA through codec-lib. The engine includes per-leg transcoding, resampling, adaptive jitter buffering, packet loss concealment, negotiated SDP payload handling, and denoising work from the recent Rust media updates.

HiFi here does not mean the public telephone network becomes lossless. It means @serve.zone/callrouter keeps an internal audio path that can normalize different codec, packet timing, and loss conditions before distributing mix-minus audio back to each participant.

Hub-based calls, not linear forwarding

@serve.zone/callrouter models a call as a hub with legs. Provider trunks, LAN SIP devices, browser WebRTC sessions, fax paths, recorders, TTS prompts, and tool legs can all be represented as participants in the same call structure.

Call hub
  provider leg: SIP/RTP trunk
  device leg: LAN SIP phone
  browser leg: WebRTC
  recorder/TTS/tool legs: call features
  fax leg: T.38/UDPTL-related paths

The mixer runs mix-minus output per leg, so each participant receives the call audio without its own contribution fed back into the stream. This is the difference between a router that forwards one SIP leg to another and a calling engine that can attach, remove, record, prompt, bridge, or extend legs around a single call state.

The REST surface reflects that model. Existing endpoints can originate calls, hang up calls, add registered device legs, add external dial-out legs, remove legs, start outbound fax jobs, list fax state, and manage voicemail messages. POST /api/transfer is present but still returns 501 not yet implemented, so transfer is not a finished workflow yet.

Pluggability around the call lifecycle

The useful spelling in prose is pluggability, and in @serve.zone/callrouter it is architectural rather than a public plugin marketplace. The service is built so call capabilities attach through typed commands, events, routes, and legs instead of being hardwired as one SIP-to-SIP path.

Browser clients plug in through WebRTC signaling on the dashboard WebSocket.
SIP providers plug in through provider registration, outbound proxy settings, digest auth, and route rules.
LAN phones plug in as registered SIP devices with explicit target matching.
Voicemail plugs in through voiceboxes, WAV storage, heard-state APIs, and call recording flows.
Fax plugs in through fax boxes, job tracking, inbox metadata, TIFF downloads, and T.38/UDPTL-related media paths.
Operations plug in through GET /api/status, WS /ws, dashboard views, and config reload paths.

That gives social.io a practical route to calling: browser-first calls can use the product UI, while @serve.zone/callrouter supplies the service-owned call engine underneath. If a call needs to leave the browser world, the same hub can bridge toward SIP trunks or devices instead of handing control to a separate PBX.

Ecosystem note. serve.zone services usually put operational control in TypeScript and move packet or media handling into Rust where latency, memory control, and protocol correctness matter. @serve.zone/callrouter applies that pattern to telephony.

The result is a focused calling layer: a high-fidelity Rust media engine, a hub-based leg model, and TypeScript-owned operations. That is why @serve.zone/callrouter is the right place to solve calling for social.io.

SmartDNS: Rust DNS Client and Server Behind a TypeScript API @push.rocks/smartdns keeps DNS APIs in TypeScript while moving UDP, DNS-over-HTTPS, packet parsing, and DNSSEC signing into Rust binaries connected over typed IPC. Engineering, Infrastructure, DNS

@push.rocks/smartdns is a TypeScript-first DNS toolkit with Rust binaries behind the wire-level DNS work.

The public surface stays in TypeScript: create a DNS client, choose a resolution strategy, register authoritative server handlers, retrieve ACME certificates, and wire the package into a larger service. Rust handles the parts where DNS is byte-oriented: UDP queries, DNS-over-HTTPS wire-format requests, packet parsing and encoding, async UDP and HTTPS listeners, and DNSSEC signing.

This is the same TypeScript/Rust split beta.news covered in the foss.global bridge architecture dispatch. TypeScript owns product shape and integration. Rust owns the data path. SmartDNS applies that pattern to DNS without turning the package into a general-purpose recursive resolver.

Three entry points

The package ships three import surfaces:

import { Smartdns } from '@push.rocks/smartdns/client';
import { DnsServer } from '@push.rocks/smartdns/server';
import { dnsClientMod, dnsServerMod } from '@push.rocks/smartdns';

The client entry point resolves records. The server entry point runs an authoritative DNS server with TypeScript handlers. The root entry point re-exports both modules.

The current public package version is 7.9.3. The export map points @push.rocks/smartdns/client to dist_ts_client, @push.rocks/smartdns/server to dist_ts_server, and the root package to dist_ts. The build pipeline runs tsbuild tsfolders --web and tsrust, so the TypeScript and Rust outputs ship together.

The major architecture changes landed in the 7.7.x and 7.8.x line. Version 7.7.0 added the Rust server backend and TypeScript bridge. Version 7.8.0 added the Rust DNS client binary for UDP and DoH. Version 7.8.1 removed the synchronous TypeScript packet-processing fallback; current raw packet processing requires the Rust bridge path.

The client: system resolver, Rust UDP, or Rust DoH

Smartdns supports five resolution strategies:

prefer-system: try the operating system resolver first, then fall back to Rust DoH;
system: use only Node's DNS module;
doh: use DNS-over-HTTPS through the Rust client;
udp: use raw UDP DNS through the Rust client;
prefer-udp: try Rust UDP first, then fall back to Rust DoH.

The difference is operational. The system resolver path honors local host behavior and does not start Rust. UDP and DoH use rustdns-client, which is spawned lazily on the first query that needs it and can be stopped with destroy().

import { Smartdns } from '@push.rocks/smartdns/client';

const dns = new Smartdns({ strategy: 'prefer-udp', timeoutMs: 5000 });

const aRecords = await dns.getRecordsA('example.com');
const mxRecords = await dns.getRecords('example.com', 'MX');
const txtRecords = await dns.getRecordsTxt('example.com');

dns.destroy();

The Rust client builds DNS wire-format queries with the recursion desired flag set. It adds EDNS0 with the DNSSEC OK bit, sends UDP queries to an upstream resolver or RFC 8484 DoH POST requests, parses the DNS response, decodes common RDATA types, and reports the upstream AD flag back to TypeScript as dnsSecEnabled.

Type-specific helpers cover A, AAAA, TXT, and NS lookups. Generic queries support A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, and SRV. That makes the client useful for propagation checks, certificate workflows, DNS validation in infrastructure services, and application code that needs predictable DNS behavior without making each consumer parse DNS packets.

The server: authoritative DNS with Rust I/O and TypeScript handlers

The server side is DnsServer. It is an authoritative DNS server, not a recursive resolver. Rust owns UDP socket handling, DNS packet parsing and encoding, DNS-over-HTTPS over Hyper and Rustls, DNSSEC key and signature work, and the IPC management loop. TypeScript owns server lifecycle, handler registration, ACME orchestration, domain authorization, and query events.

import { DnsServer } from '@push.rocks/smartdns/server';

const server = new DnsServer({
  udpPort: 53,
  httpsPort: 443,
  httpsKey: '...pem...',
  httpsCert: '...pem...',
  dnssecZone: 'example.com',
  primaryNameserver: 'ns1.example.com',
});

server.registerHandler('*.example.com', ['A'], (question) => ({
  name: question.name,
  type: 'A',
  class: 'IN',
  ttl: 300,
  data: '10.0.0.1',
}));

await server.start();

When a DNS query arrives, the Rust process emits a dnsQuery event over JSON IPC. TypeScript resolves the question against registered handlers. The answer list goes back to Rust, which assembles the DNS response and signs RRsets when DNSSEC was requested.

Handlers use glob patterns through minimatch, and multiple handlers can contribute records to the same response. That fits dynamic authoritative DNS cases: wildcard service records, generated internal hostnames, tenant-specific answers, ACME DNS-01 challenge records, and dashboard-managed zones.

The 7.9.3 release fixed a real DNS edge case in that handler path. Query names and record types are now normalized before matching, so DNS 0x20 mixed-case randomization still resolves registered records.

DNSSEC is in the Rust layer

DNSSEC is enabled through dnssecZone. The TypeScript server configuration currently sends ECDSA as the default algorithm, and the Rust key implementation covers ECDSA P-256 and ED25519. DNSKEY answers and RRSIG generation are produced in Rust, with RRsets serialized canonically before signing.

That placement is intentional. DNSSEC signing is sensitive to wire format details: canonical ordering, lower-case owner names, TTL handling, record-set boundaries, and the exact RDATA bytes. Those are better handled next to the Rust packet encoder than in an application-level fallback.

DNS-over-HTTPS on both sides

SmartDNS uses DNS-over-HTTPS in both directions.

As a client, rustdns-client sends RFC 8484 application/dns-message requests. Its default DoH endpoint is Cloudflare's https://cloudflare-dns.com/dns-query, and the default UDP upstream is 1.1.1.1:53.

As a server, the Rust backend can expose a DoH listener over HTTPS. The TypeScript options provide HTTPS bind interface, port, certificate, and key. ACME support can retrieve Let's Encrypt certificates through DNS-01 challenge records registered temporarily in the same handler system.

Manual binding and query events

Most deployments can let DnsServer.start() bind UDP and HTTPS directly. The options also support explicit UDP and HTTPS bind interfaces, so the server can be restricted to localhost, a LAN address, or different addresses per protocol.

Manual UDP and HTTPS modes let an outer service own socket placement. In current Rust mode, raw packet processing goes through processRawDnsPacketAsync(); the server must be started

Git.Zone IDE: AI Agents on Remote Workspaces Without Sending Keys Remote Git.Zone IDE keeps SSH and AI credentials local while giving SmartAgent native access to the remote workspace where files, terminals, Git, builds, and tests actually run. Engineering, Developer Tools, GitZone

Git.Zone IDE is an AI-first remote IDE built around a sharp boundary: SmartAgent can operate inside the remote workspace, while SSH keys and AI authentication remain on the local machine.

Theia over SSH is part of the implementation, but it is not the central product idea. The remote Theia backend gives the agent and the user a workspace substrate. The local Electron shell keeps the trust boundary, the SSH policy surface, the model connection, and the permission prompts.

The git.zone/ide repository is public and contains open-source code licensed under MIT. Its root package description is Remote-first Git.Zone IDE based on Theia, Electron, and SSH. The repository is public, while the workspace packages are currently private/unpublished package workspaces. The more precise operational framing is AI-first remote development: files, terminals, Git, language servers, builds, tests, and agent-assisted edits run on the SSH host where the project actually lives.

The May code.foss.global update noted that GitZone remote workspaces were moving from scaffold to product-shaped implementation. This dispatch corrects the emphasis: the interesting split is between local secrets and remote execution.

Ecosystem note. code.foss.global is the project forge and registry behind the monthly engineering updates. Git.Zone IDE is a Git.Zone product built on that stack, with SmartAgent handling agent workflows through explicit local permissions.

The credential split

The local Electron shell handles SSH host selection, runtime staging, local port forwarding, project tabs, and the SmartAgent control surface. SSH transport is delegated to the system ssh binary, so existing OpenSSH configuration remains the contract.

Git.Zone IDE reads standard entries in ~/.ssh/config, including HostName, User, Port, IdentityFile, ProxyJump, and ForwardAgent. That means the same agents, hardware keys, bastion hosts, and enterprise SSH rules used from a terminal are used by the IDE.

AI authentication stays on the local side as well. In the Electron shell, GitZoneAgentRuntime owns SmartAgent sessions and stores them under ~/.git.zone/ide/agent-sessions. Model creation reads OPENAI_API_KEY, OPENAI_TOKEN, local ChatGPT or Codex auth, or SmartAI auth from the local process and local auth stores. Those provider credentials are not exported into the remote command environment.

Surface	Owner	What the remote runtime receives
SSH private keys, SSH agent, hardware-key flow	Local OpenSSH	SSH authentication handled by the user's configured `ssh` path
AI provider tokens and ChatGPT/Codex/SmartAI auth	Local Electron shell and SmartAI side	No copied model credentials in remote tool environments
Project files, Git, builds, tests, terminals	Remote SSH host	Explicit file operations and commands run in the active project
Theia workspace backend	Remote SSH host, loopback only	A browser IDE served through the shell-managed SSH tunnel

There is one important caveat: if a user configures OpenSSH with ForwardAgent yes, normal OpenSSH agent-forwarding semantics apply. Git.Zone IDE does not change that contract. It also does not copy SSH private keys, AI API keys, ChatGPT auth, or SmartAI credentials into the remote Theia runtime.

SmartAgent has remote hands, local policy

SmartAgent runs with a local model connection and remote workspace tools. The system prompt identifies the session as the Git.Zone IDE SmartAgent for a remote SSH workspace and tells the agent to use remote tools instead of assuming that the local filesystem is the project filesystem.

The code path matches that prompt. createRemoteTools() builds SmartAgent shell, filesystem, and browser tools from a tool execution context. The shell tool calls runRemoteShellCommand(context, command, ...), which executes through ideSsh.runSshCommand on the selected host in the remote project working directory.

That detail matters for agent behavior. When SmartAgent runs git status, starts a build, reads a generated file, or executes a test command, it is using the repository, toolchain, environment, and network position of the remote host. The model is local from a credential perspective, but the work happens where the project state exists.

File tools follow the same shape. They call runRemoteNodeTool() over SSH with the staged runtime Node.js binary. The tool environment carries specific path and content data plus GITZONE_AGENT_ROOT. Path traversal checks keep file operations rooted to the active project directory, and the tool environment does not include AI auth credentials.

Permission is local. requestPermission gates tool actions through the Electron UI, and mutating actions plus shell commands require user approval before execution. The remote host receives the specific SSH-executed command or file operation that the user permitted, not the user's model credentials.

Theia is the workspace substrate

Remote Theia still matters. Git.Zone IDE uses Eclipse Theia as the browser IDE backend running on the selected SSH host. The current application uses Theia 1.71.0 packages and includes the editor, filesystem, terminal, SCM, tasks, search, preferences, workspace support, Monaco, markers, messages, process support, plugin extension support, and VSX registry integration.

Each active project starts a Theia backend on the remote host, bound to 127.0.0.1. The Electron shell opens a local SSH tunnel to that loopback port and renders the workspace in a webview. The remote backend is not intended to be reachable as a public IDE service.

Local Electron Shell
  | owns SSH selection, tunnel setup, AI auth, SmartAgent sessions, permissions
  | uses system ssh and local model authentication
  v
Remote SSH Host
  | runs Theia, files, terminals, Git, language servers, builds, tests
  | binds Theia to 127.0.0.1
  v
Shell-managed SSH Tunnel
  | forwards local loopback to remote loopback
  v
Electron WebView + SmartAgent Panel
  | displays the workspace and requests explicit remote tool actions

The Electron security layer also narrows what the shell will load. Git.Zone IDE URLs must resolve to local Theia addresses such as 127.0.0.1, localhost, or loopback equivalents; non-local Git.Zone IDE URLs are refused.

The current Theia app ships with Git.Zone product and remote-environment extensions and uses Dark 2026 as the default theme. Theia is the IDE surface the agent works inside, not the place where AI provider secrets need to live.

Runtime staging and project state

When a host is selected, the shell stages a content-addressed ephemeral runtime into

Monthly Update - May 2026 May's code.foss.global work tied App Store manifests, gateway ownership, MFA/passkeys, and release tooling into a clearer operations layer for hosted services. Monthly Update, Engineering, Infrastructure

May connected the operating layer that the April update made visible. April added persisted configuration, dashboards, migration tooling, identity-backed access, and operational metrics. May made those pieces speak the same install, upgrade, security, telemetry, and release languages.

App templates stopped being duplicated metadata. Onebox and Cloudly started sharing the same runtime model. DcRouter and RemoteIngress moved toward authenticated, observable, binary-distributed edge infrastructure. idp.global gained MFA and passkeys. GitZone made releases and remote workspaces more structured. New product surfaces landed around home automation, digital signing, and finance/compliance data.

The common May pattern was ownership boundaries becoming explicit: who can install, who can upgrade, which gateway client owns a route, which VPN identity can reach a target, which tenant owns storage, and which tool is allowed to run an interactive process.

serve.zone: App Store and hosted runtime converge

The largest May story across serve.zone was the move from app hosting as a local feature to App Store-driven runtime management shared by Onebox and Cloudly.

Shared App Store contracts. @serve.zone/appstore introduced a resolver client for linked servezone.appstore.json manifests, digest-tracked Docker image resolution, and curated template metadata in the 0.2.x line. @serve.zone/interfaces renamed the older app catalog contracts into App Store contracts, added upgrade preview and operation tracking, then extended the model with hosted app lifecycle and parent upgrade contracts.

Onebox becomes a stronger single-server PaaS. Onebox moved from the 1.25.x line to 3.0.0 in May. It gained dcrouter gateway client support for domains, DNS records, and route ownership; managed local dcrouter mode; grouped dashboard navigation; dedicated Admin UI domain routing; App Store support for declared volumes and raw published ports; runtime update prompts; self-upgrades launched safely outside the service cgroup; digest-tracked App Store images; upgrade progress tracking; interactive workspace processes; hosted app lifecycle; SmartData persistence; configurable storage classes; strict service deletion cleanup; Valkey naming; and a runtime migration from Deno to Node.js.

Cloudly consumes the same runtime model. Cloudly moved through the 5.6.0 to 6.4.3 line with grouped SPA navigation, service detail pages, live deployments, runtime actions, deployment IDE access, node jump codes, Spark telemetry ingestion, App Store browsing and installation, upgrade previews, async upgrade progress, hosted app lifecycle reporting, and parent upgrade controls when Cloudly itself runs as a hosted service.

Templates become operational objects. The App Store work went beyond catalog presentation. Templates now carry source provenance, resolved manifests, upgrade strategy, digest-pinned image data, volume declarations, published-port declarations, platform requirements, and hosted lifecycle expectations. Redis naming was replaced with Valkey across templates, platform requirements, contracts, UI labels, and runtime data migrations.

Onebox and Cloudly now point at the same application operations layer: one manifest model, one install flow, one upgrade model, and one hosted app lifecycle protocol across single-server and cluster deployments.

Ecosystem note. serve.zone is the hosting and operations product line in the foss.global stack. Onebox covers the single-server runtime, Cloudly covers clustered deployments, and App Store manifests give both the same install and upgrade contract.

dcrouter and RemoteIngress: authenticated edge operations

@serve.zone/dcrouter stayed one of the most active infrastructure projects in May. April expanded what the gateway could manage. May hardened who can manage it, how it is installed, and how operators can inspect live traffic.

Gateway client ownership. DcRouter 13.26.0 through 13.28.0 added persistent gateway client management, scoped gateway-client tokens, token-bound route and DNS ownership, hostname restrictions, allowed route targets, and dashboard administration for gateway clients. This gives systems like Onebox a narrower way to synchronize routes and DNS records without sharing a broad admin token or spoofing another client.

Admin bootstrap and API token auth. OpsServer moved toward persisted account-based administration. The May release line added first-admin bootstrap endpoints, database-backed admin accounts, optional idp.global login, admin user create/delete flows, environment-managed admin API token rotation, and scoped API token authorization across config, logs, stats, security, VPN, RADIUS, remote ingress, users, API tokens, and related handlers.

VPN authorization moves to authenticated metadata. DcRouter and the underlying smartproxy and smartvpn stack shifted VPN route authorization away from simple IP allow-list mutation. SmartVPN can now forward real client source IPs and authenticated VPN metadata through trusted PROXY v2 headers, while SmartProxy enforces VPN client ID and assigned-IP grants per connection. DcRouter maps target profiles to those grants and keeps live client source IPs visible as status data.

Network intelligence and RADIUS. DcRouter added queued IP intelligence observation, filtered retrieval for security views, top connected ASN activity, active connection snapshots from SmartProxy, and RADIUS integration backed by smartradius network secrets, including CIDR-based secret resolution and additional RADIUS attributes.

RemoteIngress performance and distribution. RemoteIngress 4.18.0 through 4.22.3 reduced TCP/TLS tunnel copy overhead, deferred upstream connects until first client data, added first-data and client-write timeouts, introduced server-first port handling, fixed stale-frame and QUIC stream exhaustion cases, and added Linux binary builds plus a one-line installer. DcRouter consumed those changes, added per-edge performance overrides, exposed hub settings management, and added its own CLI binary distribution and installer documentation.

By the end of May, dcrouter was no longer only a configured gateway service. It was becoming an installable edge product with scoped client ownership, identity-aware route security, live connection visibility, and tunable tunnel behavior.

Ecosystem note. dcrouter is the serve.zone edge control plane for routes, DNS, certificates, VPN access, RADIUS, and remote ingress. The May ownership work narrows what each gateway client can change.

push.rocks: network, storage, and AI substrate

The serve.zone work depended on a broad May round of push.rocks library releases.

SmartProxy and SmartVPN. @push.rocks/smartproxy gained authenticated VPN route security from trusted PROXY v2 metadata in 27.11.0, active connection snapshots with per-connection byte counters and protocol metadata in 27.12.0, CA-chain preservation for provisioned certificates, mixed port-range route matching, dedicated WebSocket lifecycle timeouts, and effective-client-IP rate limiting after PROXY parsing. @push.rocks/smartvpn added PROXY v2 real-source forwarding with

Monthly Update - April 2026 April's code.foss.global work made dcrouter, callrouter, idp.global, modelgrid, storage, and UI components more operable through persisted state and admin workflows. Monthly Update, Engineering, Infrastructure

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

Monthly Update - March 2026 March moved the Rust-hybrid stack into shipping infrastructure: dcrouter, smartproxy, objectstorage, registry, smartstorage, smartvpn, remoteingress, and onebox. Monthly Update, Engineering, Infrastructure

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.

Combining TypeScript and Rust in the foss.global Ecosystem: The Best of Both Worlds foss.global's TypeScript/Rust pattern pairs @git.zone/tsrust builds with @push.rocks/smartrust runtime IPC so services can keep typed APIs and Rust data planes. Engineering, TypeScript, Rust

TypeScript is great for building applications. The type system catches bugs, the tooling is mature, and you can hire for it. But if you've ever tried to build a high-throughput TLS proxy, a DNS server with DNSSEC, or an SMTP security pipeline that needs to verify DKIM signatures at wire speed, you know where Node.js starts to hurt: CPU-bound work, memory-sensitive long-running daemons, and anything that needs to talk to the kernel.

We ran into this repeatedly at foss.global, where we build open-source infrastructure tools for startups and SMEs. Our answer wasn't to rewrite everything in Rust. Instead, we built two packages that let TypeScript and Rust coexist in the same project, compiled with a single pnpm build, and connected by typed IPC at runtime. Today, eight of our production services use this pattern.

The Two Packages

@git.zone/tsrust is the build side. It follows the same convention as @git.zone/tsbuild: TypeScript source lives in ts/ and compiles to dist_ts/. Rust source lives in rust/ and compiles to dist_rust/. Running tsrust from your project root parses the Cargo workspace, calls cargo build --release, and copies the binaries into dist_rust/.

@push.rocks/smartrust is the runtime side. It provides RustBridge<T>, a generic class that spawns a Rust binary (or connects to an existing daemon via Unix socket), talks to it over newline-delimited JSON, and gives you typed sendCommand() calls.

Your build script looks like this:

{
  "scripts": {
    "build": "tsbuild tsfolders && tsrust"
  }
}

Both languages compile in one step.

Ecosystem note. @git.zone packages usually own build and workspace tooling, while @push.rocks packages provide reusable runtime libraries. tsrust and smartrust split the Rust bridge along that same line: build first, IPC at runtime.

No Rust Installation Required

tsrust can install Rust for you. If cargo isn't on the system, it downloads a minimal toolchain (~70-90 MB) to /tmp/tsrust_toolchain/ and reuses it on subsequent runs. This means pnpm install && pnpm build works on a fresh CI runner or a teammate's machine that has never seen Rust before.

Cross-compilation uses friendly target names:

tsrust --target linux_arm64 --target linux_amd64

The output binaries get platform suffixes (rustproxy_linux_arm64, rustproxy_linux_amd64), and the TypeScript bridge knows how to find the right one at runtime based on process.platform and process.arch.

How the Bridge Works

You start by defining a type map that describes every command the Rust binary supports:

type TDnsCommands = {
  start: {
    params: { config: IDnsConfig };
    result: Record<string, never>;
  };
  stop: {
    params: Record<string, never>;
    result: Record<string, never>;
  };
  ping: {
    params: Record<string, never>;
    result: { pong: boolean };
  };
};

Then you create a bridge and call commands on it:

import { RustBridge } from '@push.rocks/smartrust';

const bridge = new RustBridge<TDnsCommands>({
  binaryName: 'rustdns-server',
  cliArgs: ['--management'],
  requestTimeoutMs: 30_000,
  localPaths: [
    path.join(packageDir, 'dist_rust', 'rustdns-server'),
  ],
});

const ok = await bridge.spawn();
if (!ok) throw new Error('Failed to start DNS server');

// params and return type are inferred from TDnsCommands
await bridge.sendCommand('start', { config: myDnsConfig });

const { pong } = await bridge.sendCommand('ping', {});

Under the hood, the protocol is newline-delimited JSON over stdin/stdout. The Rust binary reads a JSON request, does its work, and writes a JSON response. No FFI, no native addons, no node-gyp. Two processes talking over a pipe.

Stdio vs. Socket Mode

bridge.spawn() launches the Rust binary as a child process. Your TypeScript app owns the lifecycle.

bridge.connect('/var/run/daemon.sock') connects to a Rust process that's already running, typically as a system service. This matters when the Rust side needs root privileges (binding to port 443, managing TUN devices for a VPN) but the TypeScript control plane should run unprivileged. Socket mode has auto-reconnect with exponential backoff:

await bridge.connect('/var/run/smartvpn.sock', {
  autoReconnect: true,
  reconnectMaxDelayMs: 30_000,
  maxReconnectAttempts: 10,
});

The sendCommand() API is the same in both modes.

Streaming

Some operations produce output over time: a traceroute returning hops one by one, a log tail, a chunked file transfer. For these, you add a chunk type to your command definition and use sendCommandStreaming:

type TNetworkCommands = {
  traceroute: {
    params: { host: string; maxHops?: number };
    chunk: { ttl: number; ip: string; rtt: number | null };
    result: { totalHops: number };
  };
};

const stream = bridge.sendCommandStreaming('traceroute', { host: 'example.com' });

for await (const hop of stream) {
  console.log(`Hop ${hop.ttl}: ${hop.ip} (${hop.rtt}ms)`);
}

const result = await stream.result;
console.log(`Trace complete: ${result.totalHops} hops`);

The timeout resets on each chunk, so it works as an inactivity timer rather than an absolute deadline.

What's Running in Production

This pattern isn't theoretical. Here's what we've shipped with it:

smartproxy is an HTTP/TLS reverse proxy. The Rust side is 8 workspace crates handling TLS termination (with automatic Let's Encrypt via ACME), domain-based routing, SNI passthrough, nftables integration, and Prometheus metrics export. TypeScript handles configuration and route management.

smartmta is a mail transfer agent. Rust runs the SMTP server and client, connection pooling, and a full security pipeline: DKIM signing and verification, SPF validation, DMARC policy enforcement, IP reputation checks, and content scanning. It uses tokio for async I/O and mimalloc to avoid memory fragmentation in long-running processes.

smartdns is a DNS server with DNSSEC. The Rust workspace handles protocol parsing, UDP and DNS-over-HTTPS serving, key management, and zone signing. TypeScript provides the configuration and zone management API.

smartfs wraps filesystem operations in a Rust daemon that handles file reads, writes, atomic operations, and filesystem watching (via the notify crate). The TypeScript side connects over a Unix socket.

smartnetwork does ICMP ping and traceroute. It uses cross-compiled, platform-suffixed binaries (rustnetwork_linux_amd64, rustnetwork_macos_arm64) so the right binary is picked up at runtime.

smartvpn is a VPN daemon using the Noise protocol for encryption. It runs as a privileged system service; TypeScript connects over a Unix socket to manage tunnels.

Why JSON-over-IPC Instead of FFI or WASM

There are other ways to call Rust from TypeScript. napi-rs gives

Embracing Rust smartproxy kept its TypeScript interface while moving network operations into Rust for high-workload proxying. Org, Engineering, TypeScript

Embracing Deno foss.global's Deno adoption note records the shift toward modules that run in both Deno and Node.js without splitting the TypeScript package line. Org, Engineering, TypeScript

@push.rocks/smartdata: A TypeScript-First MongoDB Wrapper for Modern Applications @push.rocks/smartdata brings decorator-defined MongoDB models, type-safe queries, EasyStore, distributed coordination, and live sync into a TypeScript-first data layer. Release, Engineering, TypeScript

In the world of TypeScript development, finding the right database tools that combine type safety with powerful features can be challenging. As applications grow in complexity, particularly in distributed environments, the need for robust data management becomes ever more critical. This is where @push.rocks/smartdata enters the picture - a TypeScript-first MongoDB wrapper designed to simplify complex data operations while providing powerful features for modern application development.

What is @push.rocks/smartdata?

@push.rocks/smartdata is a comprehensive MongoDB wrapper that provides strong TypeScript integration, offering type-safe operations, automated schema handling, and advanced features for distributed systems. Created by the foss.global team (which I am a part of), this library aims to simplify database interactions while adding powerful features that extend MongoDB's capabilities.

Ecosystem note. push.rocks is the shared library namespace in the foss.global stack. smartdata is a MongoDB-backed data layer for TypeScript services, not a hosted database product.

Key Features That Set It Apart

What makes @push.rocks/smartdata stand out from other MongoDB wrappers? Let's explore its most distinctive features:

1. True TypeScript-First Approach

Unlike many libraries that add TypeScript as an afterthought, @push.rocks/smartdata is built from the ground up with TypeScript in mind. This provides several advantages:

Decorator-Based Schema Definition: Define your MongoDB schemas using TypeScript decorators
Type-Safe CRUD Operations: Eliminate runtime errors with compile-time type checking
Deep Query Type Safety: Fully type-safe queries for nested object properties via DeepQuery<T>

2. Advanced Search Capabilities

The library implements a powerful and intuitive search system that goes beyond basic queries:

// Define a model with searchable fields
@Collection(() => db)
class Product extends SmartDataDbDoc<Product, Product> {
  @unI() public id: string = 'product-id';
  @svDb() @searchable() public name: string;
  @svDb() @searchable() public description: string;
  @svDb() @searchable() public category: string;
  @svDb() public price: number;
}

// Advanced search options
await Product.search('"Kindle Paperwhite"'); // Exact phrase across all fields
await Product.search('Air*'); // Wildcard search
await Product.search('name:Air*'); // Field-scoped wildcard
await Product.search('category:Electronics AND name:iPhone'); // Boolean operators
await Product.search('(Furniture OR Electronics) AND Chair'); // Grouping

This search functionality supports Lucene-style queries with exact matches, wildcards, field-scoping, boolean operators, and more - all while maintaining type safety.

3. EasyStore for Simple Key-Value Storage

For simpler data needs, @push.rocks/smartdata offers EasyStore - a type-safe key-value storage system with automatic persistence:

interface ConfigStore {
  apiKey: string;
  settings: {
    theme: string;
    notifications: boolean;
  };
}

// Create a type-safe EasyStore
const store = await db.createEasyStore<ConfigStore>('app-config');

// Write and read with full type safety
await store.writeKey('apiKey', 'secret-api-key-123');
await store.writeKey('settings', { theme: 'dark', notifications: true });

const apiKey = await store.readKey('apiKey'); // Type: string
const settings = await store.readKey('settings'); // Type: { theme: string, notifications: boolean }

4. Built-in Distributed Coordination

One of the most powerful features is the built-in support for distributed systems:

// Create a distributed coordinator
const coordinator = new SmartdataDistributedCoordinator(db);

// Start coordination
await coordinator.start();

// Handle leadership changes
coordinator.on('leadershipChange', (isLeader) => {
  if (isLeader) {
    // This instance is now the leader
    startPeriodicJobs();
  } else {
    // This instance is no longer the leader
    stopPeriodicJobs();
  }
});

// Execute tasks only on the leader
await coordinator.executeIfLeader(async () => {
  // This code only runs on the leader instance
  await runImportantTask();
});

This makes it significantly easier to build reliable distributed applications with leader election, task coordination, and more.

5. Real-Time Data Synchronization

For applications requiring real-time updates, @push.rocks/smartdata provides watchers with RxJS integration:

// Create a watcher for active users
const watcher = await User.watch(
  { active: true },
  { fullDocument: true, bufferTimeMs: 100 }
);

// Subscribe to changes using RxJS
watcher.changeSubject.subscribe((change) => {
  console.log('Change operation:', change.operationType); 
  console.log('Document changed:', change.docInstance);
  
  // Handle different operations
  if (change.operationType === 'insert') {
    notifyNewUser(change.docInstance);
  }
});

This simplifies building reactive applications that respond to data changes in real-time.

Practical Implementation

Let's walk through a practical implementation to see how @push.rocks/smartdata can be used in a real-world scenario.

Setting Up Your Database Connection

First, establish a connection to your MongoDB database:

import { SmartdataDb } from '@push.rocks/smartdata';

// Create a database instance
const db = new SmartdataDb({
  mongoDbUrl: 'mongodb://localhost:27017/myapp',
  mongoDbName: 'myapp',
  mongoDbUser: 'username',
  mongoDbPass: 'password',
});

// Initialize and connect
await db.init();

Defining Your Data Models

Next, define your data models using TypeScript classes with decorators:

import {
  SmartDataDbDoc,
  Collection,
  unI,
  svDb,
  index,
  searchable,
} from '@push.rocks/smartdata';
import { ObjectId } from 'mongodb';

@Collection(() => db)
class User extends SmartDataDbDoc<User, User> {
  @unI()
  public id: string = 'user-' + Math.random().toString(36).substring(2, 9);

  @svDb()
  @searchable()
  public username: string;

  @svDb()
  @searchable()
  @index()
  public email: string;

  @svDb()
  public organizationId: ObjectId; // Stored as BSON ObjectId

  @svDb()
  public profilePicture: Buffer; // Stored as BSON Binary

  @svDb({
    serialize: (data) => JSON.stringify(data),
    deserialize: (data) => JSON.parse(data),
  })
  public preferences: Record<string, any>;

  constructor(username: string, email: string) {
    super();
    this.username = username;
    this.email = email;
  }
}

Performing CRUD Operations

With your models defined, you can now perform fully type-safe CRUD operations:

// Create a user
const user = new User('johndoe', 'john@example.com');
user.preferences = { theme: 'dark', notifications: true };
await user.save();

// Retrieve users
const singleUser = await User.getInstance({ username: 'johndoe' });
const users = await User.getInstances({ email: /example\.com$/ });

// Update a user
singleUser.email = 'john.doe@example.com';
await singleUser.save();

// Upsert operation
const upsertedUser = await User.upsert(
  { username: 'janedoe' },
  { email: 'jane@example.com', preferences: { theme: 'light' } }
);

// Delete a user
await singleUser.delete();

Using Advanced Features

For more complex scenarios, leverage the advanced features:

// Using transactions for atomic operations
const session = db.startSession();
try {
  await session.withTransaction(async () => {
    const sender = await User.getInstance({ id: 'user1' }, session);
    const recipient = await User.getInstance({ id: 'user2' }, session);
    
    // Transfer credits atomically
    sender.credits -= 100;
    recipient.credits += 100;
    
    await sender.save({ session });
    await recipient.save({ session });
  });
} finally {
  await session.endSession();
}

// Implementing document lifecycle hooks
@Collection(() => db)
class Order extends SmartDataDbDoc<Order, Order> {
  @unI()
  public id: string = 'order-' + Date.now();

  @svDb()
  public items: string[];

  @svDb()
  public total: number = 0;

  // Hook called before saving
  async beforeSave() {
    // Calculate total from

Domain centric packages The domain-centric package shift groups related server, client, service-worker, and edge-worker exports into fewer packages with clearer import boundaries. Engineering, TypeScript, code.foss.global

2024-05 updates The May 2024 update covers smartbucket, Docker registry migration, typedserver PWA support, automated docs work, and smartguards changes. Monthly Update, Engineering, Infrastructure