Congrats iroh team!
Iroh addresses are (currently Ed25519) keys. They are not scarce, so you can create them on demand and keep them as you move from one network to another.
If IPv6 was everywhere I guess the hole punching feature of iroh would become less important, but the dial by key feature would remain just as important.
Regarding security, one thing to be aware of is that iroh connections are just standard QUIC connections secured using standard TLS with the (also standard) raw public keys in TLS extension.
We don't roll our own crypto. What little non-standard crypto we had previously was removed on the path to iroh 1.0.
So iroh connections are just as secure as the QUIC/TLS connections your browser makes to your banking app. Whenever there are some new concerns like for example post quantum security, we can benefit from industry standards.
E.g. we do already support optional post quantum key exchange to secure connections.
For example: dns control, tls certification bans (just this month both let’s encrypt and globalsign started revoking Russian certificates), once google starts really complaining about https it gets ugly.
Russia aside, anyone else is closely watching (europe, brics, what have you)
E.g. you could write an excellent encrypted chat app using iroh, the Tor or Nym custom transport, and BLE or direct wifi for local connections.
You have to be careful though to make sure you configure the transports correctly in order not to expose data you don't want exposed. Iroh can be used in highly restricted environments, but the defaults favour performance over complete metadata privacy.
How does it support semi-connected devices, intermittent connection failures, etc?
Iroh is built for environments where connectivity is unreliable or intermittent, so it can be a good fit for use cases involving connection failures, offline periods, or semi-connected devices.
We provide a range of peer-to-peer protocols that don't require a central server, including key-value stores, blob transfer, collaborative documents, and streaming audio/video. These protocols are designed to synchronize devices back to a consistent state, even after long disconnections or network interruptions.
If you'd like to explore whether iroh could work for your use case, we're happy to chat. Feel free to email us at support@iroh.computer, and we can set up a call.
Besides, as a lot of people have mentioned already, if you want a dedicated server there are a lot of existing options.
We did write a few small dedicated applications to show off iroh, sendme https://www.iroh.computer/sendme and dumbpipe https://www.dumbpipe.dev/ .
Up to now our users are mostly teams that have a rust or C/C++ core, such as https://delta.chat/ . But now that we have bindings teams who use other languages should be able to use iroh.
So you can write e.g. an android and ios app that uses iroh direct connections under the hood, and the app user does not have to know or care about this at all.
About tailscale: It's similar, but iroh is not a VPN, so it doesn't add a TUN interface. Instead, you'd build iroh directly into your application. Using iroh you can build a VPN, and there are projects that do so (iroh-lan/iroh-vpn are some hobbyist projects). The upside of building it into your application is that it doesn't need special permissions and is easy to ship to the user.