Profile
Back to NewsBack
GitHub Trending 7 min
Reader Mode
go-i2p/go-i2p: Go implementation of the I2P Router protocol. Usable with NTCP2, I2CP, and I2PControl

go-i2p/go-i2p: Go implementation of the I2P Router protocol. Usable with NTCP2, I2CP, and I2PControl

11 hours ago

go-i2p

A pure Go implementation of the I2P router.

Status

go-i2p is in active development. We recently completed several significant milestones including:

  • Complete I2CP Protocol Server: Full session lifecycle management, message routing, and client support
  • End-to-End Message Routing: Complete message routing system connecting I2CP clients through tunnels to other destinations with garlic encryption
  • Tunnel System: Automatic tunnel building, pool management, and cryptographic processing
  • Transport Layer: Full NTCP2 implementation with session management
The core router functionality is now operational. We have tested functionality using i2psnark-standalone against our I2CP API server. Basic compatibility is available. We are now focused application layer protocols. We have a mostly-complete I2CP client, a prototype of a Streaming library, and a pretty boring Datagrams library, all of which are requirements for SAMv3.3(which we also have), which is what all our applications use. Refining these components and making them production-ready is the immediate goal.

go-i2p is still in very early development. It has bugs. It is probably very distinct on the network. You probably should use a more established router for now.

Advice for Developers: The API is still unstable below go-i2p/onramp. In fact, we're going to aggressively remove broken, crappy versions of functions from the low-level components over the 0.1.6 to 0.2.0 development cycle. The 0.2.0 release will have only the type-safe, memory-safe, functionally-correct versions of everything. We'll apply DEPRECATED notices to the godoc of anything we're removing in advance of removing it but it is going to go. How much low-level stuff you want to use is going to affect how much your life is going to change in the next ~4 big releases.

Also, we're picking up the pace. More little points between big releases. This is because issues surfaced in one repository may actually require fixes in an upstream repo and this way it's easier to keep the tags in sync.

Advice for Users: It's probably not safe yet, nor does it do the things you want yet. However, we have reached significant milestones in interacting with the network and are beginning to use it more regularly in a handful of non-anonymous services.

Anonymity-sensitive operators should review Anonymity-Safe Logging and avoid debug logging in production.

Implemented Features

  • Clients
- [X] I2CP Protocol Server (v0.9.67 - tested with i2psnark-standalone) - [X] Message routing (outbound I2CP → tunnels → garlic encryption) - [X] Inbound message delivery (tunnel → I2CP sessions) - [X] I2CP Client: https://github.com/go-i2p/go-i2cp - [X] Datagrams: https://github.com/go-i2p/go-datagrams - [X] Streaming: https://github.com/go-i2p/go-streaming - [X] SAM API v3.3: https://github.com/go-i2p/go-sam-bridge - Signing - [X] ECDSA_SHA256_P256 - [X] ECDSA_SHA384_P384 - [X] ECDSA_SHA512_P521 - [X] Ed25519 - Verifying - [X] DSA - [X] ECDSA_SHA256_P256 - [X] ECDSA_SHA384_P384 - [X] ECDSA_SHA512_P521 - [X] RSA_SHA256_2048 - [X] RSA_SHA384_3072 - [X] RSA_SHA512_4096 - [X] Ed25519 - [X] Red25519 - [X] ElGamal - [X] AES256 - [X] X25519 - [X] ChaCha20/Poly1305 - [X] Elligator2 - [X] HKDF - [X] HMAC - [X] Noise subsystem - [X] Garlic messages (thin adapter in lib/i2np/garlic_session.go → go-noise/ratchet.SessionManager) - [X] ECIES-X25519-AEAD-Ratchet (primary, implemented in go-noise/ratchet/) - [X] Tunnel build record crypto (adapter in lib/i2np/build_record_crypto_short.go → github.com/go-i2p/crypto/tunnel) - [ ] ElGamal/AES+SessionTag (not implemented - ECIES-only destinations supported)
  • I2NP
- [X] Message parsing and serialization - [X] Message interfaces and factory patterns - [X] Database Store/Lookup message structures - [X] Tunnel Build message structures - [X] Data, DeliveryStatus, TunnelData messages - [X] Build Request/Response Record parsing - [X] Message routing and handling
  • NetDB
- [X] Local storage interface - [X] Reseed functionality (basic implementation) - [X] Persistence to disk - [X] RouterInfo management - [X] LeaseSet management - [X] Lookups - [X] Expiry - [X] Exploration - [X] Publishing - [X] Floodfill - [X] LS2 and Encrypted Leasesets (I2CP clients can publish blinded EncryptedLeaseSets; storage/retrieval supported; inbound client-side decryption and MetaLeaseSet resolution implemented; per-client authorization (DH and PSK) supported on both the publishing and resolving halves)
  • Transport Layer
- [X] Transport manager and interfaces - NTCP2 - [X] Session handshake using noise protocol - [X] Connection management - [X] I2NP message framing and unframing - [X] Session lifecycle management - [X] Message queuing and worker threads - SSU2 (currently experimental — see docs/ssu2-experimental.md for what is and is not proven, and the --transport.ssu2-enabled help text) - [X] Session handshake - [X] Connection management - [X] Peer Tests (experimental — all roles implemented; end-to-end integration ongoing) - [X] Introducers (experimental — registration and republish wired) - Noise Subsystem (see also https://github.com/go-i2p/go-noise) - [X] Noise Socket Framework - [X] NTCP2 Socket Framework - [X] ECIES-X25519-AEAD-Ratchet engine (ratchet/ package) - [X] SSU2 Socket Framework
  • Tunnels
- [X] Message structure parsing (delivery instructions) - [X] Fragment handling and reassembly - [X] Build Request/Response record interfaces - [X] Tunnel building and management - [X] Tunnel cryptography (layered encryption) - [X] Gateway and endpoint implementation - [X] Participant functionality - [X] Keys and Cert - [X] Key Certificates - [X] Certificate - [X] Lease - [X] Lease Set - [X] Router Info - [X] Router Identity - [X] Router Address - [X] Session Key - [X] Signature Types - [X] Destination - [X] Data Types - [X] Session Tag

Verbosity

Logging can be enabled and configured using the DEBUG_I2P environment variable. By default, logging is disabled.

Note: Logging is configured via environment variables (not config.yaml or command-line flags) because it is managed by an external logger package and needs to be set before the application starts.

There are four available log levels:

  • Debug (very high volume — hot-path / crypto detail; local troubleshooting only)
export DEBUG_I2P=debug
  • Info (lifecycle and operational milestones; recommended default for ./run.sh and day-to-day runs)
export DEBUG_I2P=info
  • Warn
export DEBUG_I2P=warn
  • Error
export DEBUG_I2P=error

If DEBUG_I2P is set to an unrecognized value, go-i2p falls back to info.

Fast-Fail mode

Fast-Fail mode can be activated by setting WARNFAIL_I2P to any non-empty value. When set, every warning or error is Fatal. It is unsafe for production use, and intended only for debugging and testing purposes.

export WARNFAIL_I2P=true

If WARNFAIL_I2P is set and DEBUG_I2P is unset, DEBUG_I2P will be set to debug.

I2CP Server

The I2CP (I2P Client Protocol) server allows client applications to communicate with the I2P router. It is enabled by default and listens on localhost:7654.

Configuration

You can configure the I2CP server using command-line flags:

# Disable I2CP server
go-i2p --i2cp.enabled=false

Change listen address

go-i2p --i2cp.address=0.0.0.0:7654

Adjust maximum sessions (default is 100)

go-i2p --i2cp.max-sessions=200

Valid range for i2cp.max-sessions is 1-320

Use Unix domain socket instead of TCP

go-i2p --i2cp.network=unix --i2cp.address=/tmp/i2cp.sock

Features

  • Session Management: Create, reconfigure, and destroy client sessions
  • Message Protocol: Full I2CP v0.9.67 protocol implementation
  • Multi-client Support: Handle multiple concurrent client sessions (default: 100)
  • Thread-safe: Concurrent session access with proper synchronization
Note: messageReliability=Guaranteed is not yet implemented. Sessions
requesting guaranteed delivery fall back to BestEffort silently. Applications
requiring acknowledgment must implement their own delivery-confirmation layer
(e.g., via the go-streaming library).

For more details, see lib/i2cp/README.md.

Contributing

See CONTRIBUTING.md for more information.

License

This project is licensed under the MIT license, see LICENSE for more information.

Chat with me