No adapter is implemented yet. The three adapter crates
(adapters/web2, adapters/web3, adapters/legacy) are placeholders — one
doc comment each. The Adapter trait they will implement is real and
specified in spec/adapter-contract; everything
described here about specific adapters is design intent.This page is kept because the boundary it describes is a genuine
architectural decision, not because the code behind it exists.Tracking: openNTL/ntl#14.
Adapters are the compatibility boundary where NTL interfaces with existing systems. They translate between NTL’s signal-based transport and traditional protocols.
Think of adapters as the peripheral nervous system — they interface with the external world using whatever language external systems speak, while internally everything is neural signals.
Architecture
Adapter Types
Web2 Adapter
Translates HTTP, gRPC, WebSocket, and GraphQL into NTL signals. This is how existing web applications, APIs, and services connect to NTL without modification.
Web2 Adapter Reference →
Web3 Adapter
Interfaces with blockchain networks, decentralized identity (DID), and token systems. Signals can carry chain-verifiable payloads, initiate smart contract calls, and verify identity through decentralized mechanisms.
Web3 Adapter Reference →
Legacy API Adapter
A specialized adapter for connecting legacy REST/SOAP APIs that can’t be modified. The adapter wraps existing API endpoints and exposes them as NTL signal handlers.
Legacy API Adapter Reference →
The Adapter Contract
All adapters implement the Adapter trait:
Building Custom Adapters
NTL ships with Web2, Web3, and Legacy adapters. For specialized protocols, you can build custom adapters:
Adapter as API Gateway
For organizations migrating from traditional architectures, NTL adapters can function as an API gateway — accepting REST/GraphQL traffic on the outside while internally routing through the neural transfer layer. This allows incremental adoption without rewriting existing clients.
Last modified on September 11, 2026