upvote
Iroh networking isn’t available in browser, and presents some cool ways to link things together - i suspect the connection by using iroh is more robust and solid than webrtc, but i’m just guessing.
reply
There are some projects that implement an iroh webrtc custom transport that works in the browser. E.g. https://iroh-webrtc-demo.datei.jetzt/#?addpeer=fd4341f14b4eb...

But iroh is designed bare metal first, we currently support the browser via WASM, but only with relay mode.

We will solve browser eventually, but I think it is a mistake to build peer to peer tech browser first. We think it is better to make it extremely efficient on bare metal first, and then grow into the restricted browser ecosystem where possible.

Browsers are very restricted environments.

reply
WebRTC only works in very specific conditions, most of the time you'll need a TURN server anyway, so it's probably better to just use an Iroh relay (you can run your own)
reply
I see P2P working 80%+ of the time for my deployments. Other people have posted data about this also https://medium.com/the-making-of-appear-in/the-most-likely-t...

P2P is better then TURN/Iroh Relay. Even if traffic is encrypted the size of what you are passing through is valuable metadata. Or the time at what you send things. P2P is always better for users.

reply
Of course P2P is better, my point was that it doesn't work in the browser most of the times, and your link seems to corroborate it.
reply
That is strictly true but there are work arounds. For example you can talk to an Iroh relay server from inside of a browser. You can also get round this with extensions. Unfortunately Google whitelist who can do this but it can be done on Safari.
reply
the tl;dr seems to be simply that it wasn't implemented yet

i've been pretty interested in this as well and got this snippet from chatgpt: `So could Iroh add direct browser-to-native connections without a proxy? Yes, by adding WebRTC support to the native side as well. Iroh’s own browser roadmap describes that approach and identifies the additional native WebRTC stack as a significant dependency cost. It does not describe a fundamental impossibility.`

i may take a stab at adding this functionality soon

reply