A question that frequently comes up: when will iroh support webrtc, or BLE, or LoRa, or ...
Iroh as of now supports only IPv4, IPv6 and relay transports out of the box. There is such a large variety of potentially interesting transports out there that we can't support all of them without turning the codebase into an unmaintainable maze of feature flags.
But we have added the ability to implement custom transports. That way your transport implementation can live in a completely separate crate.
Existing experimental custom transports include Tor, Nym and BLE. https://github.com/mcginty/iroh-ble-transport
Here is how custom transports work under the hood: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...
How current is the PyPI package? https://pypi.org/project/iroh/
> Tor
You are using a Tor daemon in it. Tor has a Rust implementation and when used with Rust has Stream objects etc.
An example of how it's used can be found in https://gitlab.torproject.org/tpo/core/oniux
Arguably directly embedding the rust tor implementation would be more useful for the typical iroh user that wants an embeddable library. I just did not get to it yet.
But thanks for the link.
I'm trying to understand it's limitations, if I used this to build a p2p client / server setup or even two peer machines, what else do I need to setup to be able to have connections between the two applications?
For example, could I create an application that runs on my phone and another that runs on my laptop and finally get a direct secured working connection between the two of them? Or is this solving a different problem? =)
-[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o
Here is a video of frando from our team demoing media over QUIC: https://www.youtube.com/watch?v=K3qqyu1mmGQ
If you use the default setup you are still depending on a tiny bit of cloud infrastructure such as our public relays to faciliate the hole punching. However, we also have optional local discovery using e.g. mDNS.
Strategy patterns and code-centralised feature management ftw :)
So you might get a lot of traffic. You can configure rate limiting, as we do on our public relays.
The traffic is fully encrypted and can not be decrypted by the relay. The only information the relay has is what is necessary for it to function - the endpoint id and ip addresses of the endpoints that are connected to it at any given time, as well as endpoint pairings.
You relay encrypted traffic with no egress to the open internet. So if you want to compare it with Tor, it would be like a tor guard/middle relay, not an exit node.
Nice. I already do rate limiting, traffic balancing using sch cake. This looks like an interesting project. I could envision open source NVR's implementing this. I also like the name of the project.
Last year, I was trying to choose between the two and went with that I know... but it feels like there's real momentum on Iroh's side.
I am not aware of a LoRa custom transport yet, but that is not unexpected given that the custom transport API is relatively new, and our main focus has been on getting iroh 1.0 out of the door.
There is already IPv6 and quic, you need vendor and major software to have any traction in that field.
Here is a concrete problem we solve. You have one device in your home WLAN behind a NAT. Your other device is in a 4g network, or behind another NAT at work.
In most cases we can give you a direct connection between the two devices very quickly via hole punching, so you get the highest possible bandwidth and the lowest possible latency.
This was not a solved problem until now.
p2p apps need direct connections.
The similarities are in an application lib to connect, and that tail net IPs correspond to device keys like in Iroh. The service using the Go library has its own Tailscale identity.
Here this is a decentralized network with a lot of existing public relays. But in principle a VPN can solve a lot of the same problems. It's just that commercial VPNs are not decentralized, and doing your own wireguard setup is a pain.
This allows you to provide information to an arbitrary person (a friend/coworker/etc) to let them access the thing without them having to jump through all the extra hoops of joining your tailnet/them joining yours/adding a VPN/etc.
There are policies defining who can talk to what; they are deployed from a GitHub repository with defined rules on who can modify them and who has to review them; there are zero scenarios where I want an alternative way of granting access to any device or service under our control.
If I wanted to share something internal with a friend I would use ngrok or any of the million alternatives.
Anyway, this is exactly why my top-level comment says that this project needs a "versus" page in the docs.
So libp2p builds many things on top of the underlying transport where we use QUIC directly and use existing mechanisms such as TLS ALPNs for protocol negotiation.
We also use the stream multiplexing that is built into QUIC instead of putting a stream multiplexer on top of QUIC.
You can think about it like this: libp2p abstracts transports as streams, and then puts many required features on top (protocol negotiation, stream multiplexing)
Iroh uses QUIC and abstracts transports below QUIC. We can work with any unreliable datagram transport that has (or can be hacked to have) a minimum MTU of 1200 bytes (needed to be QUIC compliant).
Iroh is still awesome.
You’ve asserted “THIS is not a solved problem,” which suggests everyone is clear on what THIS means. I think that is not a good assumption.
Lack of a true session layer in TCP/IP is why vmotion is normally only possible in a single broadcast domain because in this situation you only really use mac addresses for addressing and can thus use the IP as a stable identifier when the MAC address changes after a vmotion. And the switch mac address table handles the mapping.
And if you have another suitable system, you can also plug it in. E.g. you might want to use another DHT that allows mapping from a key to some address data.
Seems like it'll be a hard sell since steam is already so dominant and enterprise is dominated by tailscale... I see the proposal for being able to work with many different networks from different companies at the same time, but it's a pretty rare usecase and nothing some iptables can't solve.
I can see the argument for chat in heavily censored regions of the world, but not sure if there's any advantages that iroh can offer over other solutions.
Market fit will be hard to find, but best of luck.
> But to finance the development of it, we offer additional services to make it easier to deploy and run it, especially for larger or more specialized use caes.
Interesting (and somewhat proven) idea to finance it, smart :)
Did you guys started doing this already on a case-by-case basis and have some experience of it already, and if so what are the common things you typically help out with exactly? I'm just curious what sort of things a company who'd use a protocol like that might need help with, that they wouldn't have experience with in-house, since they're going down a P2P road already (assuming that, maybe maybe need help with greenfield projects)?
If you use their offering, you probably get some kind of web interface for metrics that isn't open-source.
https://docs.iroh.computer/concepts/relays https://www.iroh.computer/services/hosting
"we want to be infrastructure for people, and a business towards professionals."
stuck between "we need cash to operate" and "we want to be a public good infrastructural system." , with the negative parts of a for-profit whisked away with "Well it's open source."
it's a business concept i'm okayish with as long as the "Well it's open source." caveat doesn't come with a total bespoke and unusable code base to figure out.
Our code is as good as we can make it, and everything is modular and well documented. For example our QUIC implementation noq which underlies every iroh connection can also be used as a standalone QUIC impl that implements QUIC multipath.
https://docs.rs/noq/latest/noq/
If we wanted to have "total bespoke and unusable code" we would have inlined all of this into the iroh repo to make it unusable.
Tailscale is a great service that happens to be open source, but Iroh is clearly structured as a library that you can build into whatever you want.
If you want to run an ISP or AS, believe me it will cost you a decent chunk of money.
I love Tailscale, it's deployed on all my devices. But I might check this out for the transports part in particular.
IIUC you just send someone 'here is the connection information' and it just works automatically.
I love MagicDNS - A long time ago I wrote a stupid Python script to have it continually generate MagicDNS names until one of them contained a word I was looking for.
Tailscale is great for bringing devices/apps into a secure network when I cannot modify them in any way. If I have full access to the source code for everything, the story changes completely.
I think this tech (modern p2p) represents what agent-to-agent (a2a) should be built on.
Every agent should be reachable to each other without hosting itself as an http server.
related prototypes