How ATS Works: A Technical Deep-Dive

The architecture behind the PWA, the relay network, and the post-platform web.

A Quick Note: This is the technical companion post to my main article, Building the Post-Platform Web

If you’re here for the “why,” the political mission, the high-level vision, and the call to action, I strongly recommend reading that article first.

This post is for the builders, the developers, the skeptics, and the deeply curious. We’re going to lift the hood and look at the engine. This is the “how.”

No more filters. Let’s get into the architecture.

The First Feature: Why a “Simple” Ping Matters

In the main article, I revealed ATS — AllTheServices. The first feature is deliberately humble: I broadcast a ping to a topic (say #ice_block), and subscribers in range see it on a map.

The important part isn’t the dot; it’s the path. The ping never touches the ATS main server. It rides only across the relay layer. Right now I’m operating the relays to prove the system; next, I’m releasing the relay software so anyone can run one. As others join, the backbone becomes community-run by design.

What this first “simple” ping demonstrates—end to end, in the real world:

• Open-web distribution: The app installs as a PWA directly from the site (no store to approve or yank).

• Minimal identity, then autonomy: You sign in with minimal info (email today) to establish an identity; after that, the act of broadcasting and receiving pings does not depend on the main server.

• Keys kept safe: The ATS KMS (Key Management System) stores sensitive keys separately on your device; even a compromised web app server can’t impersonate you or scrape push credentials.

• Encrypted publish (exact event location): Your device sends an encrypted ping (topic + precise coordinates + ephemeral ID) to its relay so the alert marks the right spot. Relays can route and deliver it, but cannot identify who sent it.

• Least info, always: Routine heartbeats don’t include location; they simply keep the connection healthy.

• Intelligent relay routing: Relays subscribe to a single, coarse (precision-4) geohash cell, ensuring no global blast. The PWA itself filters all pings based on the user’s specific radius.

• Self-healing failover: The main server provides an ordered list of N top root relays for each tree. If the primary root fails, relays automatically failover to the next-highest-ranked root, healing the network in minutes.

• Range + topic delivery: Relays forward all pings for a (topic, cell) to subscribers. The PWA then filters to show only the pings within the user’s chosen radius.

• Push without a platform middleman: Relays use time-limited JWTs to deliver push notifications to devices—still without the main server in the path.

• Privacy by minimization: Locations are quantized, pings are ephemeral, and relays see tokens/topics, not your identity.

• No residue: After the short TTL, relays discard the event; there’s no durable trail of “who was where, when.”

• Generalizable rails: The very same relay orchestration (publish, route, deliver, discard) is what powers the next steps—private messaging (Signal), small service media, the Direct Work Marketplace, live A/V, and streamed media.

In other words, the “simple” ping isn’t a toy—it’s a live proof that the core ATS machinery already works: open-web install, key isolation, decentralized routing, range/topic targeting, privacy by default, and delivery without a corporate or platform chokepoint.

Today it moves a pin; tomorrow it moves our conversations, our work, and our media—on the same rails.

The Core Pieces at a Glance

• Relays (the backbone). Think of relays as small, purpose-built servers that move messages. They join multicast trees based on two simple things: the topic and a single precision-4 geohash (e.g., “dqcj”) provided by the PWA. To do this, they connect to the highest-priority available root relay from an ordered list provided by the main server.

• The PWA app (your gateway). A Progressive Web App installs straight from the website—no app store needed—and works like a normal app: home-screen icon, offline support, push notifications. The PWA is the user gateway into the relay layer.

• ATS KMS (keys, kept safe). A new model for a Verifiable Web Enclave. It keeps sensitive keys separate from the app in dedicated storage on your device. (This is a core innovation; see the dedicated section below).

• ATS main server (minimal by intent). The “mothership” is deliberately boring. It handles user authentication, propagates the relay directory to relays, and coordinates the NAT tunneling for new relays. When the marketplace launches—will facilitate payments between customers and providers and distribute the network share to relay operators. It is intentionally as “dumb” as possible when it comes to network operation.

• Privacy by minimization (the design rule). Every operation carries only the minimum information required to complete it. Locations are quantized; pings are ephemeral; relays see topic traffic and signed tokens—not identities. We don’t collect what we don’t need.

How We Make Relays Work for Everyone (The NAT Solution)

This is the most critical piece of the architecture. Running a server from home is notoriously difficult due to NAT, firewalls, and dynamic IP addresses. Here’s how ATS solves it:

When a user deploys a new relay-node (e.g., on their home computer or a small VPS) and “claims” it, the ATS main server instantly and automatically:

1. Assigns a Subdomain: The main server provisions a unique, secure subdomain for the relay from our ats.run ops domain. The name is based on the relay-id, following a memorable adjective-color-noun pattern (e.g., skilled-aqua-fog.ats.run).

2. Establishes a Tunnel: The server simultaneously sets up a persistent, secure tunnel from that public subdomain directly to the relay-node software.

This means that regardless of NAT, firewalls, or other network issues, the user’s relay is immediately operable and reachable by the rest of the network. It can instantly begin connecting to nearby users via a secure WebSocket (WSS) connection, all without the user needing to configure port forwarding, firewall rules, or dynamic DNS.

The Core Routing “Magic”: Dynamic Roots & Auto-Failover

The most important piece of the relay network is its resilience to failure. This is achieved through a dynamic, main-server-coordinated root system.

Here’s how it works:

1. A user subscribes to a topic (e.g., #lost_pet) in a geohash cell (e.g., dqcj) on their local relay.

2. That relay must now join the multicast tree for that topic and cell.

3. Instead of calculating the roots itself, the relay receives its instructions from the main server. The main server—which monitors the health of the entire network—calculates and passes down an ordered list of N top root relays for that tree.

4. This list ([root[0], root[1], ... root[N-1]]) is sent to the relay along with the directory. The main server can adjust ‘N’ on the fly as the network grows or shrinks, optimizing the network’s health.

This design enables a powerful, self-healing failover system:

• Failover: The relay’s job is to be connected to the highest-priority available root. It will always try to connect to root[0] first. If root[0] is down or unreachable, the relay automatically tries to connect to root[1]. If root[1] is also down, it tries root[2], and so on.

• Healing: The system consistently re-checks for higher-priority roots. If root[0] comes back online, the relay will detect this and automatically drop its connection to root[1] to reconnect to the primary root[0].

This architecture is the direct answer to catastrophic, single-point-of-failure events like a major AWS outage.

In that scenario, if a primary root server (root[0]) went offline, the network wouldn’t collapse. Instead, ATS would experience a brief, minor degradation—perhaps for a minute or so—as all connected relays automatically failed over to the next-highest-priority root (root[1]). When the primary root came back, the network would heal itself, with relays seamlessly migrating back.

This provides massive resilience and fault tolerance, not just in theory, but by design.

Future Vision: Full Decentralization via Relay Gossip

The server-coordinated root system provides immediate, high-performance resilience. The long-term vision is to make this network resilient even against a total main-server failure.

This will be achieved in two future phases:

1. Relay Gossip Protocol We will be implementing a relay gossip protocol as a secondary, decentralized update path.

• How it Works: While the main-server directory is the fastest path to a network update, relays will also periodically gossip their known directory versions to their peers.

• Self-Healing: If a relay detects it has an older version than its peers (and the main server is unreachable), it can request the new directory directly from them.

• The Benefit: Even if the main server goes offline for an extended period, the relay network can still propagate directory changes and heal itself.

2. Promoted “Quasi-Main-Servers” This gossip model enables a potential future where the network’s health isn’t dependent on a single entity. We are designing a system where long-running, highly-trusted relays (based on uptime, performance, and community vouching) can be promoted to “quasi-main-servers.”

These trusted nodes could then take on limited, critical operations—like validating and propagating directory updates—creating a federated, multi-leader system that is truly decentralized and resistant to a single point of failure.

The “Why” of the ATS KMS: A Verifiable Web Enclave

This isn’t just another key store; it’s a new trust model based on systemic transparency, not opaque hardware trust.

The entire system is open-source, and I’ve made the code public for a reason. You can audit it today at: https://github.com/Lukium/ats-kms-enclave

I am submitting this work to universities like MIT and Caltech for research partnerships because it’s a potential answer to critical issues that proprietary hardware can’t solve.

The strategic difference is simple:

• Proprietary Hardware (like Apple’s Secure Enclave) is a “black box.” You must trust the vendor. It’s opaque, closed-source, and can’t be independently audited.

• The ATS Web Enclave is a “glass box.” It’s built on verifiable proof. Anyone can reproduce the build, verify its hash, and prove the deployed code matches the public source.

This model is superior in contexts where institutional trust, not physical theft, is the primary threat. It’s designed to solve:

• Institutional Coercion: A hardware vendor can be pressured to push a silent, backdoored firmware update. With our web enclave, any change—however small—alters the hash and is immediately detectable by the public via SRI verification and transparency logs. It’s designed to resist vendor and government backdoors.

• Election Integrity & Verifiable Trust: Think about the widespread distrust in “black box” voting machines. The very same principles behind the ATS KMS—public source code, reproducible builds, and public hash verification—could be used to secure election software. This model would allow officials, parties, and the public to mathematically prove that the code running on a voting machine is the exact, unaltered, and approved version, building institutional trust through transparency rather than vendor assurances.

• Platform Fragmentation: Instead of 5+ fragmented native apps for each hardware-specific API, the web enclave is one consistent, auditable module for all browsers.

• Opaque Compliance: Auditors no longer have to “trust” a vendor’s certification. They can mathematically prove the deployed code matches the audited source.

• Slow Patching: We can patch vulnerabilities instantly on page load—with cryptographic proof of the fix—rather than waiting weeks for app store approvals.

This new model shifts security from trust in authority to trust in transparency.

How ATS Is Not the Dark Web—and Not Crypto

A technical audience will (and should) be skeptical. Let’s be precise about what this is not.

• Open web, not hidden services. ATS apps install as PWAs from the public internet. No Tor, no .onion, no special browsers. It’s built for lawful, above-ground coordination in daylight.

• Accountable privacy, not impunity. We protect ordinary people from surveillance capitalism with minimization and end-to-end design choices—without creating a black-market sanctuary. Privacy is the default; abuse is not the goal.

• Real payments, no tokens. No coins, no tokenomics, no mixers. When the Direct Work Marketplace goes live, the target split is ~95% to providers and ~5% to sustain the relays/infrastructure. Transparent, auditable, boring finance.

• User-run resilience, not secrecy theater. Decentralization here isn’t about evasion; it’s about eliminating chokepoints. As relay software is released and others run nodes, the backbone becomes civic—operated by many, captured by none.

The Path Forward

This architecture is the foundation for everything that comes next. It’s built to be resilient, private, and independent by design.

If this mission and this model resonate with you, here’s how you can get involved:

1. Try the App: The PWA is live. Install it and test the ping feature today:

   1. Please note: This is an alpha build. It’s functional most of the time, but you will likely find bugs. We’re still testing how the architecture will perform at large scale, so please be patient and report any issues you find.

2. Support the Build: This is a user-funded mission. If you’re able to, please consider supporting this project by becoming a paid subscriber (I’m also working on a crowdfunding campaign). This is what keeps us free from VCs and ad-tech.

3. Read the Manifesto: If you landed here first, go read the main post to get the full political and strategic vision.