[rklaehn]

You don't have to use it. But here are some answers:

Re-issuing keys is as simple as generating a new Ed25519 keypair.

let secret_key = SecretKey::generate(); // takes less than a millisecond

Iroh as of now has no fleet management. So the concept of revoking a key is something you would have to add yourself.

We have extensive logging for iroh. You can enable trace logging and even enable qlog for detailed connection logs. You can view the logs in any qlog viewer. We have written one, but there are others. It is an open standard for QUIC logs.

https://datatracker.ietf.org/doc/draft-ietf-quic-qlog-main-s... https://github.com/n0-computer/qlog-viewer

The iroh relay library and binary are open source just like everything else in the core. You can of course run a relay in your intranet, but the exact details depend on the use case. Get in touch if you have a demanding use case and want us to help.

[angry_octet]

Thanks for responding.

By logging I mean a gateway/proxy which logs connection metadata, not client side logging. Possibly this is something that could be added to a private relay. With a network of private relays you could form admission controlled virtual overlay networks for each application.

For key revocation, it is necessary to be able to invalidate a server accepting a key, without necessarily having the key. E.g. maybe you have a pre-generated proof enabling revocation.

Observability is super important for organisations. Especially with LLM servers and MCP interfaces popping up everywhere.