str4d / ire Goto Github PK

Required for legacy Destinations, and the occasional old Router. I haven't found any Rust crates that provide it, so we'll likely need to implement it ourselves.

Requires the ability to:

• Configure, measure, and rate-limit bandwidth.
• Detect reachability.

NTCP handshake messages don't have IDs, and are identified based on send order. As a result, there are currently two state machines inside the NTCP engine:

• IBHandshakeState and OBHandshakeState in HandshakeTransport.state, which handle the higher-level state transformations.
• HandshakeState in InboundHandshakeCodec and OutboundHandshakeCodec, which defines which handshake message the codec is listening for or expects to be sent.

The reason for having two separate state machines is that HandshakeTransport calls stream.framed() to get a Framed transport that wraps the stream with a codec, and then itself wraps that transport. This makes it tricky to have a single state machine that is used by both parts of the engine (bearing in mind that I wrote the engine partly as an exercise in learning Rust). But having two state machines that are supposed to always be in sync is clearly prone to bugs.

We should deduplicate the state machine. I can see two ways of doing this:

• Give a remote reference to the HandshakeTransport state machine to *HandshakeCodec (which is probably easier than I think it is using something like RefCell, which I still need to learn about).
• Remove the use of Framed by implementing stream framing in HandshakeTransport, and pass the state machine through to the codec.

The local netDB should regularly explore the global netDB for new routers, by searching for random hashes.

Enable simple deployment of Ire in participant mode on devices running DD-WRT or OpenWRT. This would be a way for users to easily contribute to the network; it would not enable them to run I2P services themselves.

Depends on #47.

Given that Ire is intended to be usable as a library, we need good error-handling with a usable interface and sufficient context. The failure crate is probably the best base to build upon.

Uncommon generally, so there aren't any good implementations available compared to P256 and P384.

These are now appearing in reseed bundles, causing parser failures.

At the same time, we should make parsing of RouterInfos more resilient by adding some way to represent Unknown key types (given that a KeyCertificate can indicate its total length).

If a RouterIdentity hash or Destination hash is not known to the local netdb, it should trigger a lookup from a known floodfill.

This should be a modular wrapper around the various transports. It should provide a way for callers to send I2NP packets to a peer without needing to care about the available transports, and to register for receiving incoming I2NP packets.

This is going to be absolutely hellish. I started ire in 2017 as a way to learn Rust, and decided the best way to do that was to dive head-first into 2017-era async Rust. Things have changed... a bit... since then.

The signatory-* crates have been abandoned in favour of native support for the traits signatory uses in each concrete provider. ed25519-dalek provides this, but I don't know if ring does (and even if it does, we currently pin a fork of it with I2P-specific modifications).

Meta-issue for implementing the various extra mechanisms necessary to operate as a floodfill router:

• Kademlia DHT.
• Keyspace rotation.
• Flooding.
• Changes to netDB exploration.
• DatabaseLookup message-handling.
• DatabaseStore message-handling.
• Automatic enabling of floodfill mode as appropriate (with config overrides).

Stretch goal. By default Ire will use Ed25519 for locally-generated keys.

Some Destinations and routers use this type of signature. There are crates that provide at least P-256 and P-384 (e.g. ring), and it should be possible to extend them to support P-521 as well.

Should support:

• Configuration via a TOML file or programmatically via the builder.
• Watching the file for changes (though some settings will require a restart to take effect).
• Separate configuration per-router (i.e. not a global static).

https://crates.io/crates/config looks like a good crate to leverage.

Currently, if a message is sent to an unconnected peer, but the transport handshake fails, the message persists in the pending session cache for that transport. When a subsequent message is sent to that peer, the presence of the peer in the pending session cache means that it is also cached, on the assumption that a session is pending. The result is that if a connection fails to a peer due to transient issues, it can never be reached again within the current router.

It should be easy to configure Ire as a purely-participating router, i.e. a router that:

• Integrates itself into the network (via netDB exploration, possibly with a few exploratory tunnels).
• Collects peer profiles.
• Accepts tunnel build requests.
• Routes tunnel messages.

It might make sense to have this be a separate binary, that can be easily compiled and deployed (e.g. as a Docker image).

In order to be as lightweight as possible, this mode should probably not enable floodfill mode (#46).

There aren't any existing Rust crates that provide this, so we'll have to implement it ourselves.

Hey @str4d this is zab. I know this isn't suitable for a GitHub issue, so feel to free to close or even delete it after you read it.

I've been trying to reach you on Twitter as well as LinkedIn. I'm very interested in contributing to Ire and intend to start learning Rust. That's all I have to say on GitHub, if you're interested to hear more, reach to me via those other channels.

zab.