I like the idea. A couple of questions:

1. How does Iroh handle key rotation / leakage? Could you build some kind of hot/cold system on top of it, where you'd have a cold "identity key" in airgapped, secure storage, used only to issue certificates for your hot "traffic acceptance" key?

2. Is there any kind of peer discovery / DHT, either built-in directly or through some semi-official higher-level protocol, like DNS for IP?

3. What about human-friendly peer names? Those are almost required for end-user friendly applications. Most solutions of that problem either assume that every single user is willing to dedicate their life to configuring DNS, rely on a trusted third party, or delegate the responsibility to a blockchain.

4. What are the channel reliability properties, and are they configurable? Can you decide how to handle out-of-order or lost packets, or does the protocol enforce a decision? If you're willing to tolerate loss, duplication and reordering, can you avoid head-of-line blocking?

5. Is peer anonymity a goal?

6. What about two mostly-offline peers who wish to communicate (think smartphone apps that can't be connected 24/7 due to battery concerns)?

Overall, cool project.

1. Currently we are using Ed25519 keys. You could use our existing discovery services to add a level of indirection from a root key to the currently active key. It wouldn't be that much code, since the discovery services are pretty generic. But we haven't done so yet.

2. We have a centralized DNS based discovery mechanism enabled by default, and an optional bittorrent mainline DHT based discovery mechanism. We also have mDNS for local networks, and you can plug in your own.

3. Our current keys are non scarce but also not human readable. You can use another level of indirection via DNS or some blockchain based naming system like ENS to assign a human readable alias, but that is not built in.

4. Iroh streams are just QUIC streams, and reliable and ordered by default. There are APIs to receive data as it arrives, but this for really advanced users. Most users are best served by just using the streams as-is.

https://docs.rs/noq/latest/noq/struct.RecvStream.html#method...

There is also an escape hatch if you don't want streams at all, e.g. if you have a consumer like a video codec that can deal with data loss themselves. We support QUIC unreliable datagrams ( https://datatracker.ietf.org/doc/html/rfc9221 ).

https://docs.rs/noq/latest/noq/struct.Connection.html#method...

5. Peer anonymity as in hiding the ip addr of a endpoint id can be achieved, but not with the default config. The default config is tuned for performance. You can hide your ip address by using one of the mixnet custom transports and disabling the ip transport.

6. Iroh is just connections. If a and b are never online at the same time they won't be able to communicate. You would have to write an iroh protocol that talks to some always online node. We do have some protocols that can be used to implement this, such as iroh docs, but that is not the main product.