A pure Go implementation of the I2P router.

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.

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

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 three available log levels:

• Debug

export DEBUG_I2P=debug

• Warn

export DEBUG_I2P=warn

• Error

export DEBUG_I2P=error

If DEBUG_I2P is set to an unrecognized variable, it will fall back to "debug".

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.

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.

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

• 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.

See CONTRIBUTING.md for more information.

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