NTIP

Secure NetOps for Distributed Infrastructure, aka: New Technology IP

Comment

Inspiration

NTIP began with a practical infrastructure problem.

I manage and experiment with systems distributed across VPSs, virtual machines, local servers, development devices, and edge nodes. Many of these machines are behind NAT and use changing network environments, or cannot safely expose inbound ports.

Connecting them usually requires combining several independent tools:

  • VPN configuration (like WireGuard, OpenVPN, or IPsec)
  • Port forwarding
  • Firewall rules
  • Manually distributed credentials
  • Static routes
  • Monitoring systems
  • Separate management interfaces
  • Ad hoc troubleshooting commands

Each component may work individually, but the overall operational experience becomes fragmented. Establishing connectivity is only the beginning: operators must also understand which nodes are available, how they are configured, what routes they own, whether the desired configuration matches the observed runtime state, and why communication fails when something goes wrong.

I wanted a system that treated connectivity and operations as one coherent problem.

That idea became NTIP - New Technology Internet Protocol: a secure network operations platform for connecting, managing, observing, and troubleshooting distributed nodes—even when they are behind NAT.

OpenAI Build Week gave me the opportunity to evolve NTIP from a working protocol and command-line implementation into a more complete product with an integrated control plane with persistent state, authentication, a polished web dashboard, extensive automated verification, and an AI-assisted diagnostic capability.

The goal was not to build another generic AI dashboard. The networking system remains the core of NTIP. AI is used as a bounded operational assistant where it can provide meaningful value.

What it does

NTIP allows operators to create and manage secure logical networks across distributed infrastructure.

At the protocol level, NTIP connects registered nodes through centrally managed virtual network ranges, or VNRs. Each node has an identity, an assigned address, network membership, and an explicitly managed configuration.

The platform provides:

  • Secure node enrollment and identity management
  • Virtual network range creation and administration
  • Address allocation
  • Route and owned-prefix management
  • Connectivity between nodes behind NAT
  • Desired configuration management
  • Runtime and liveness observation
  • Node, network, route, and session inventory
  • Operational activity tracking
  • User authentication and session management
  • A centralized web-based control plane
  • Network topology visualization
  • Structured troubleshooting information

The dashboard gives operators an immediate overview of the infrastructure:

  • Number of configured VNRs
  • Registered nodes
  • Owned routes and prefixes
  • Online, offline, suspect, and unknown node states
  • Desired and effective configuration generations
  • Service posture
  • Recent activity
  • Nodes requiring attention

NTIP deliberately distinguishes between desired state and observed state.

A node may exist in the durable configuration while its current liveness, endpoint, session, or traffic state remains unknown. Instead of presenting assumptions as facts, the dashboard communicates that uncertainty explicitly.

The interface follows a progressive-disclosure model. Common operations and important status information are immediately visible, while advanced configuration and security features remain accessible through hierarchical network, node, route, user, session, and settings views.

NTIP also includes an optional AI-assisted diagnostic feature. It can analyze structured operational evidence such as node state, network membership, routes, observed endpoints, session information, and recent events. It then explains likely causes and recommends investigation steps.

The AI assistant is not the networking authority. Authentication, authorization, routing, protocol validation, and state changes remain deterministic and controlled by the NTIP implementation.

How we built it

NTIP is implemented as a multi-language monorepo with clearly separated systems and responsibilities.

Zig networking core

The protocol, server, client, command-line tooling, and authoritative control-plane runtime are implemented in Zig.

Zig was chosen because it provides:

  • Explicit memory management
  • Predictable runtime behavior
  • Direct control over networking and binary data
  • Small deployable binaries
  • Strong cross-compilation support
  • Minimal hidden runtime behavior

The Zig layer owns the actual networking model. It handles protocol state, node identities, VNR membership, addresses, routes, runtime observations, and configuration validation.

The dashboard never duplicates or independently interprets protocol behavior. It communicates with the authoritative control-plane API.

Integrated control plane

The control-plane API is integrated directly into the NTIP server instead of being implemented as a disconnected management service.

This enables the API to access both:

  • Durable configuration stored by the control plane
  • Live runtime information observed by the networking server

The control plane manages:

  • VNRs
  • Nodes
  • Addresses
  • Routes
  • Users
  • Authentication
  • Sessions
  • Runtime projections
  • Operational events
  • Desired and effective configuration generations

An embedded SQLite database stores persistent control-plane state.

SQLite was selected because it provides transactions, constraints, migrations, and reliable persistence without requiring operators to deploy and maintain a separate database server. This supports NTIP's objective of remaining straightforward to self-host.

Web dashboard

The operator dashboard is built with:

  • Next.js
  • React
  • TypeScript
  • Bun
  • shadcn/ui
  • Tailwind CSS

The frontend is part of the same monorepo but remains isolated from the Zig implementation through explicit API contracts.

The dashboard was designed as an operational interface rather than a generic administration template. It uses:

  • Consistent spacing and component dimensions
  • Reusable visual primitives
  • Clear status semantics
  • Stable sidebar navigation
  • Dense but readable tables
  • Hierarchical information architecture
  • Progressive disclosure
  • Restrained motion and decoration
  • A consistent 60–30–10 color hierarchy
  • Monospaced presentation where technical identifiers benefit from it

Simple information is immediately available, while advanced capabilities remain discoverable without overwhelming less experienced users.

Authentication and security

The control plane includes username-and-password authentication backed by server-managed sessions.

The server, rather than the browser, remains responsible for:

  • Credential validation
  • Session creation
  • Session expiration
  • Authorization
  • Administrative access control
  • Session revocation

Authentication and authorization are enforced by the control-plane API. The frontend is treated as an untrusted client and cannot grant itself additional privileges.

Testing and CI/CD

The project includes automated verification across the different parts of the monorepo.

The testing strategy covers:

  • Protocol behavior
  • Configuration validation
  • State transitions
  • Database operations
  • HTTP API behavior
  • Authentication
  • Authorization
  • Frontend type checking
  • Production builds
  • Integration between components
  • Regression scenarios

GitHub Actions orchestrates formatting, compilation, tests, frontend validation, and build verification. The objective is to detect incompatibilities between Zig, SQLite, TypeScript, and the dashboard before changes reach the main branch.

OpenAI and Codex

I used Codex throughout Build Week to help analyze the repository, implement components, generate and expand tests, review integration boundaries, investigate failures, improve documentation, and validate changes across Zig and TypeScript.

Codex was especially valuable for accelerating work across a multi-language codebase while maintaining the architecture and constraints I had defined.

I remained responsible for the protocol model, product direction, security boundaries, architecture, technical decisions, and final review of the resulting implementation.

Challenges we ran into

Evolving a protocol into a complete product

A functional network protocol is not automatically a usable network operations platform.

NTIP needed persistent state, a control-plane API, authentication, operational projections, documentation, a dashboard, and reliable deployment workflows. The primary architectural challenge was introducing these layers without duplicating or weakening the networking core.

Keeping desired and observed state separate

One of the most important challenges was representing two different forms of truth:

  1. What the operator configured
  2. What the running system currently observes

Combining them would have made the dashboard misleading. A configured node is not necessarily connected, and an expected route is not necessarily active.

NTIP therefore models desired configuration and runtime observation independently and exposes both through the control plane.

Maintaining consistency across languages

The repository combines Zig, SQL, TypeScript, React, shell tooling, and GitHub Actions.

A field renamed in the Zig API could affect database queries, TypeScript types, frontend components, tests, and documentation. Maintaining consistent contracts across these boundaries required deliberate module separation and automated verification.

Persisting state safely

Integrating SQLite into the networking server required careful handling of:

  • Schema initialization
  • Migrations
  • Transactions
  • Constraints
  • Concurrent access
  • Error propagation
  • Durable configuration generations
  • Recovery after failed mutations

The database needed to remain an authoritative and reliable store without making the core unnecessarily dependent on complex infrastructure.

Designing a useful infrastructure interface

Operations dashboards frequently become either too simplistic or too dense.

The challenge was to expose enough technical detail for experienced operators while keeping the common workflows understandable. This led to the hierarchical interface and progressive-disclosure approach used throughout the dashboard.

Testing distributed and failure-oriented behavior

Distributed systems rarely fail only in clean, predictable ways.

The test strategy had to account for:

  • Invalid credentials
  • Duplicate identities
  • Disconnected nodes
  • Unknown liveness
  • Failed enrollment
  • Stale sessions
  • Invalid routes
  • Database constraint violations
  • Malformed API requests
  • Divergence between configured and effective state
  • Partial service availability

This made testing part of the architecture rather than something added only after implementation.

Keeping the AI capability trustworthy

It would have been easy to give the AI assistant excessive control and present it as an autonomous network administrator.

Instead, the challenge was to define a useful but safe boundary. The assistant receives structured evidence and produces explanations or recommendations. It does not replace deterministic validation, authorization, or protocol logic.

Accomplishments that we're proud of

The largest accomplishment is that NTIP is not merely a dashboard prototype.

It includes a real systems-level networking core, a working client and server, durable control-plane state, authentication, operational APIs, and a functional management interface.

I am particularly proud of:

  • Building the protocol and product as one coherent system
  • Integrating the control plane directly with the networking core
  • Preserving a clear boundary between authoritative protocol logic and presentation
  • Creating a multi-language monorepo without obscuring component ownership
  • Implementing embedded persistence without requiring external database infrastructure
  • Separating desired configuration from observed runtime state
  • Designing a dense but approachable operator dashboard
  • Building authentication and revocable server-managed sessions
  • Establishing automated testing across backend and frontend components
  • Creating GitHub Actions workflows that verify the complete repository
  • Treating security properties as implementation and testing requirements
  • Giving AI a useful but deliberately bounded role
  • Producing a platform that I intend to continue using and developing after the hackathon

The project demonstrates an end-to-end workflow rather than an isolated technical experiment:

  1. Define a virtual network
  2. Register distributed nodes
  3. Assign identities and addresses
  4. Establish connectivity
  5. Observe the resulting state
  6. Identify inconsistencies or failures
  7. Investigate them through the control plane

What we learned

The most important lesson was that a protocol specification, implementation, control plane, database, and dashboard must all represent the same underlying system from different perspectives.

We also learned that:

  • Protocol state machines should be explicit
  • Security guarantees should be expressed as testable invariants
  • Desired and observed state must remain distinct
  • Unknown state should be communicated rather than hidden
  • Operational interfaces must explain the system, not merely display raw data
  • Embedded databases can dramatically simplify self-hosted deployment
  • Monorepos are effective when ownership boundaries remain explicit
  • Cross-language contracts require automated validation
  • CI should verify system behavior, not only whether individual components compile
  • Infrastructure software benefits from progressive disclosure in its interface
  • AI is most reliable when it receives bounded, structured evidence
  • AI-generated recommendations should never silently become privileged actions
  • Documentation is part of the implementation of a protocol, not an optional supplement

Codex also changed the way I approached development during the project. It was most valuable not as a replacement for architecture or engineering judgment, but as an implementation, review, testing, and investigation partner operating within clearly defined constraints.

What's next for NTIP

OpenAI Build Week established the foundation of NTIP as a complete secure network operations platform, but there is substantial work ahead.

The next priorities include:

  • Expanding the formal NTIP protocol specification
  • Building a dedicated protocol conformance suite
  • Increasing parser and protocol fuzz-testing coverage
  • Performing a deeper independent security review
  • Strengthening key rotation and credential revocation
  • Improving replay and downgrade protections
  • Adding richer network policy controls
  • Expanding route and reachability diagnostics
  • Improving topology and traffic visualization
  • Adding historical telemetry and configuration timelines
  • Introducing configuration rollback
  • Supporting more granular roles and permissions
  • Adding stronger audit-log capabilities
  • Improving multi-platform packaging and installation
  • Producing signed release artifacts and software bills of materials
  • Adding reproducible release pipelines
  • Evaluating high-availability control-plane deployments
  • Supporting larger and more complex network topologies
  • Expanding AI-assisted diagnostics while preserving explicit approval boundaries
  • Publishing additional deployment guides and real-world examples

The long-term objective is to make secure distributed networking easier to deploy, observe, understand, and troubleshoot without hiding its behavior behind unnecessary complexity.

NTIP will continue beyond the hackathon as an actively developed systems and infrastructure project.

Built With

Share this project:

Updates