Show HN: Flipflop, iroh-powered persistent tunnels for filesharing (github.com)
This is a project that spun from my frustrations of using LocalSend and DashBeam to transfer stuff between devices, and with the extra goal of being fast, trying out the Slint framework and, most importantly, establishing a communication channel with trusted external people that can be left always on.
77 comments
[ 0.19 ms ] story [ 8.1 ms ] threadI would think this could be done completely in the browser using WebRTC?
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.
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.
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
I won't like - webrtc will probably never graduate to a built-in transport. But we would be very happy about a bare metal webrtc transport and link it from our official docs for people that need it.
This Flipflop project relies on the Iroh library for NAT/Firewall puncturing and external address discovery. Connecting two 5G devices, without a coordinating central server is possible, but very hard. Iroh simply relies on a server which you could self-host. Cool stuff, we stress tested it a while ago and it somewhat worked.
NAT connectivity is unsolved. My university lab conducted one of the bigger puncturing studies a decade ago [1]. Recently, we also bought 40+ or something 4G and 5G SIM cards in Europe for puncturing [2]. My master student traveled Europe by bus to get these local SIM cards. He worked day-and-night to connect these weird symmetric 5G NAT filter boxes and got it working. Simple sync collision and birthday paradox brute force... It all works sometimes, but insufficiently reliable for mass-adoption. You can't build a decentralized social media ecosystem on top. Like Iroh, best to use a central server. So then you have legal liability for your users. Unless an AI agent buys the server fully autonomously using Bitcoin, next years students got that working[3] :-)
[1] UDP NAT and Firewall Puncturing in the Wild, https://inria.hal.science/hal-01597969v1/document
[2] Mass Adoption of NATs: Survey and experiments on carrier-grade NATs, https://arxiv.org/html/2311.04658v2
[3] Self-replicating seedbox servers using programmable money, https://arxiv.org/abs/2609.05431
So if you are in an extremely weird NAT you will fall back to a relay, either our public relays, your own relays rented from us via iroh services, or a self-hosted relay.
But I would argue that a p2p social application that occasionally uses a relay is very much preferable to a centralised app.
The relay is generic internet infrastructure. It just forwards end to end encrypted connections. It can not learn anything about the content.
A relay that is hosted on a non KYC server rented via ZCash would be interesting though if you are super paranoid.
By 2030 we hopefully understand the mathematics-of-trust and can link all the billions of citizens together in a single overlay.
I think it's very misplaced concern. Commercially-viable internet will not be decentralized because of legal restrictions. If whatever engineering solution will be found to weaken them, governments will step in to curtail it. FWIW any moderately successful decentralization effort is more likely to be attacked from exactly this side: some countries will hate it for uncontrolled information dissemination, others for fiscal reasons.
Also what kind of attitude is this? Government is too powerful, we might as well give up. Where's the fun in that. It is hard but also very rewarding.
>Government is too powerful, we might as well give up.
That's not what I wrote. My note is about proper understanding of real threats and obstacles.
The final goal for decentralization is something like: no central party should become the irreplaceable master over data, community, feeds, moderation, UI and identity.
We already know the minimum pieces needed to avoid that kind of centralization: hashed, linked, signed records(/packets), so their validity and causal order don't depend on whatever connection carried them or whatever physical server received them.
Once we have that, apps 'transcend' the connection layer, and the parties that control identity, community, feeds, moderation, etc become signing keys that can operate from anywhere.
The real problem for a decentralized internet, or "local-first apps", is that writing applications at this layer, or writing the library that lets you write them, is hard and nobody has solved it.
IIRC Iroh tried this early on, then pivoted to the p2p socket library it is today.
I'm not sure where the Delft stack sits with its ambitions atm.
There is one last centralized part they built to avoid using a blockchain, the PLC system, but it's designed to be tamper proof and easy to replace with a new server. The only thing a malicious operator can do is censorship in the p2p sense (ignoring a user's actions) but that would break trust and make the community migrate to a new provider.
What I’m getting at is that we haven’t nailed the right abstraction. A "sockets" or "HTTP/HTML" moment that collapses the design space, to such an extent we've collectively forgotten there were more complicated alternatives they replaced.
These links are 2 examples of the problem: https://atproto.com/guides/understanding-atproto and https://atproto.com/articles/atproto-for-distsys-engineers.
Somebody spend a lot of time and effort to make this as simple as possible. This is the best & simplest version of it.
Yet its not simple enough. Repositories, event logs, view servers, DID, ...Lexicon RPC (XRPC)? What’s the minimal version of this that still works? Not an SDK hiding the concepts; fewer concepts.
It’s hard to explain what I want precisely because I don’t think that abstraction exists yet. Maybe atproto gets us closer, but the on-ramp feels like endless links to sub-concepts. The average developer's eyes glaze over.
You can, ATProto has the example schematics for how, but it's has a federated rather than distributed architecture, but I don't think "federation" is a hard constraint of the design, more like an implementation detail, and as long as you can do the signalling centrally, to connect the peers, you can do the rest P2P. So sure, legal liability for the connection of peers, but all data transfers would still be directly P2P. AFAIK, Iroh also does "Centralized signaling > P2P data transfers", even when NAT is in the way.
Nice idea with the browser link to share with devices that dont have flipflop on the same LAN. This would be a killer if this would also work via internet! Not sure if Iroh can run in the browser though.
I never tried Iroh in the browser, but supposedly it works (by always using a relay).
Tailscale hosts relay servers as a fallback. Connections are peer-to-peer between devices.
1. The co-ordination server for the initial handoff. You can self-host if you want
2. Derp relays (for actual traffic). you can also self-host (peer relays)
Actually if self-hosting is that important to you, there are also newer solutions like netbird and netmaker that might worth a look.
Yes, as I noted, those differences wouldn't stop you from sending data locally. But since parent originally requested how they're different (without stating what exactly is important for them), I figured it is important at least to note what actually is the difference between taildrop and Flipflop.
It'd seem then if you wanted "local-first P2P transfer", with taildrop you'd need ~3 separate services running, unless I misunderstand you? Flipflop seems to do all those things in one package, although again, signaling (for NAT punching) is still via a central server.
Tailscale is super popular with people that have a homelab or nas/cameras/photos etc, and they have already solved the NAT problem (which iroh itself markets).
But it's more for when you already use Tailscale, which relies on a central server and someone who "owns" that network.
In Flipflop you don't need anything besides the app, and each two peers form a "network" of their own, with no owner and no management.
The exact same thing as Tailscale (they have public servers or you can host your own)
Am I missing something here?
Tailscale connections are peer-to-peer. They only own the coordination server, which you can ignore and host your own.
A list of iroh based tools are also found here https://github.com/n0-computer/awesome-iroh
https://github.com/n0-computer/iroh-esp32-examples
Most examples that I did so far were about simple sensors, but audio streaming should work as well. If you need high bandwidth you might want to look into using the esp32 built in crypto hardware acceleration though.
Although audio is probably fine, but if you want to do video via an esp32 you will need the hardware crypto.
https://www.iroh.computer/sendme
Sendme is a demo for iroh and a very useful standalone tool, but it is more about quick ad-hoc transfers.
I think flipflop is using iroh-blobs for data transfer, so you can think about it as like sendme but with permanent connections.
May I ask, was it vibed/LLM-assisted to some extent, or is it purely human-made?
Because Apple hates the world even more, I can't publish it for iOS."
Gold
Yet at the end of the day, Microsoft is a Rust Foundation platinum member.
Remember when they bought github in order to "benefit" the open-source community, then we found out they used everyone's data to train their models and sell data to other companies? Yea...Microsoft.
But if you are technically proficient enough to run your own infra we are happy too. Our relay is open source just like the rest of iroh, and we even try to make it very easy to run them, no weird hoops to jump through.
> filesharing for the meatspace era
serious question: what does this mean lol
I decided not to build it because I think open, decentralized, and encrypted file sharing with good search is something of a Pandora’s box.
Great to see people building open source in this space since p2p sharing gets a lot more expansive and harder to get right with AI agents.
Have you been using this with personal agents like instinct or grok bot? Would be a great way to share files without allowing full computer use/exposing more access than you have to!
[0] https://github.com/layervai/qurl-go