There might be a small misunderstanding here. Our relays do two things. They relay user data, and relay a small number of special packets to help with hole punching. Other than that they are very simple. They never see unencrypted data, so they don't know anything more about the nodes they serve than what they need to function.

Connections are TCP https websocket connections, because this is most likely to get through even the most restrictive firewalls.

Discovery is handled outside the relays, via either a special DNS server or via the bittorrent mainline DHT. You can even implement your own discovery.

The two sides are peers when it comes to connection establishment, but once you have a connection they can and frequently will have different roles.

Many existing iroh protocols have clear client and server roles once the connection is established. E.g. gossip is a peer to peer protocol, blobs is a client server protocol in that one side provides data and the other requests it.

For a client you can use an ephemeral node id and not publish your info to discovery, since you will never be dialed yourself.

We decided to keep things simple. In general we try to provide one good way to do something instead of having a lot of options.

E.g. we only provide Ed25519 for keys and in iroh-blobs only BLAKE3 for hashing, instead of having a multihash scheme. Having the public key directly available is sometimes useful, e.g. for verifying signatures. It also allowed us to directly use the mainline extension BEP_0044 to store data for public keys.

That being said, I am very confident that we will be able to provide a relatively smooth transition if we ever have to switch from Ed25519 to another public key format.

For connection encryption we use a TLS extension called raw public keys in TLS, and here of course the keys are prefixed, and we could easily upgrade to another key format and then at some point stop supporting Ed25519 keys.

raw public keys in TLS: https://datatracker.ietf.org/doc/html/rfc7250 storing arbitrary data in the DHT: https://www.bittorrent.org/beps/bep_0044.html

Yes. Iroh itself provides direct QUIC connections. iroh-blobs is a protocol on top of iroh that provides content-addressed data transfer of BLAKE3 hashed data.

What you describe sounds like https://www.dumbpipe.dev/ , a tool/demo built on top of iroh to provide a bidirectional pipe across devices, somewhat like netcat.

Dumbpipe also has a mode where it listens on a port using TCP.

It sounds like you want to basically build dumbpipe for UDP. You can of course use a QUIC stream, but QUIC has an extension, which we support, to send datagrams: https://docs.rs/iroh/latest/iroh/endpoint/struct.Connection....

This basically allows you to opt out of QUIC streams, but you still do get TLS encryption.

To expand on this: iroh is a rust library. A NodeId is just an Ed25519 public key, but of course it has a distinct type. If in the future we want a different public key standard, it would be a different rust type.

Encoding keys is mostly left to the user. The only exception are tickets. Tickets are postcard serialized and have a version field, so we can keep tickets compatible if we ever want to use a different public key standard or hash function.

(disclaimer, I also work on iroh)