Interesting project, towards a decentralized Internet!
The heavy lifting is done in this function, pairing. You link your personal devices together, solid idea [0].
This Flipflop project relies on the Iroh library for NAT/Firewall puncturing, external address discovery and overlay networking. 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] :-)
We (iroh) don't do birthday paradox hole punching yet. There is some internal debate whether it is worth it.
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.
Yeah, we need "generic Internet infrastructure" for linking devices.
By 2030 we hopefully understand the mathematics-of-trust and can link all the billions of citizens together in a single overlay.
> non KYC server rented via ZCash would be interesting though if you are super paranoid.
What will happen if a decentralized Internet emerged and presented an existential threat to existing profit margins? Company lawyer would start to attack you, correct?
I think you're both missing the forest for the trees. P2P connectivity is
about as solved as it will get, and the last % will stay unsolved.
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.
>What will happen if a decentralized Internet emerged and presented an existential threat to existing profit margins? Company lawyer would start to attack you, correct?
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.
The self-replicating seedbox is a cool idea. Some places offer interest on stable coin deposits. I wonder if there could be a way to set up an account for AI use that would be self-replenishing so long as a budget is maintained.
> 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.
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.
I wish someone would revisit the idea of a single, global, P2P file search mesh like Gnutella/Gnutella2 but using a modern P2P stack (or WebRTC) instead of raw TCP/UDP like the old days.
I don’t think IPFS was built for search. I see some unmaintained projects that sniff DHT traffic for hints, but (correct me if I am wrong here) the protocol maintainers never added a search layer. Eg I can’t search for “violin” and find the hash for “learn violin.pdf”.
This actually looks good and uses the established Iroh.
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.
Better, who knows. Seems different in that Flipflop uses P2P connections directly to the peer, alternatively via other available peers (and initial connection might use central signaling server), while taildrop seems to depend on a tailnet, which is typically hosted by Tailscale (unless you run that yourself).
I guess it's a bit like comparing WeTransfer with Airdrop, one tries to use the network they're on already (internet) where the other favors local-local connections.
I think it always does the initial connection via the DERP relays, doesn't it? Even if a direct initial connection in theory is possible (no NATs or anything else in the way), the connection itself is always established via the relays, then "upgraded" to a local connection. But maybe they've changed this since I looked at it?
Beyond that, even with a local connection established, all the coordination traffic will still go via the tailnet, those don't suddenly become local-first. But this might also have changed.
What I'm sure is still there today, is that all Tailscale clients automatically upload their logs to Tailscale's servers unless you opt out:
> Each Tailscale agent in your distributed network streams its logs to a central log server (at log.tailscale.com). This includes real-time events for open and close events for every inter-machine connection (TCP or UDP) on your network. - https://tailscale.com/docs/features/logging
Of course, doesn't stop a local connection from working so is only tangentially related, but worth keeping in mind that a "local tailscale connection" still has a lot of external traffic related to it, even though the data you transfer, when possible, uses more local connections.
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.
yes you understand correctly. The assumption is that you already have Tailscale for remote access and you get taildrop "for free". Installing tailscale just to get file sharing doesn't make sense if FlipFlop already does it and that is the only thing you need.
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).
iroh is different and more than just a vpn, where you use a bunch of tools together, you can do it all in iroh with one identity, the tunnel, the file transfer, the ssh access, and others. Look at tunnet for example https://github.com/tunnetio/Tunnet to get a better idea.
Nice idea, but for personal sharing between my devices, I have a syncthing folder that's synced between my laptop, phone and media center/NAS, and I've been finding that most of my day to day files have been migrating into it, and I hardly ever use things outside of it.
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.
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.
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)
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.
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.
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
Looks very interesting, I have been building few things on top of iroh past few weeks and I love it, from the ability to run it on some iot all the way to be rf agnostic (almost, can’t use LoRa with iroh due to its datagram limit), and best part, MoQ runs natively on iroh where on wireguard you will need to encrypt twice so more cpu, but i found kernel wireguard performs better at bulk throughput, and layer 3 isn’t by default unless you have TUN like added.
Mind sharing the bit about IOT? I'm also looking for a way to get iroh working on something like esp32 for audio streaming. Was wondering if moq can be used here
"Because Microsoft hates the world, they will show a "Windows protected your PC" warning when you try.
Because Apple hates the world even more, I can't publish it for iOS."
Gold
Interesting project, towards a decentralized Internet!
The heavy lifting is done in this function, pairing. You link your personal devices together, solid idea [0].
This Flipflop project relies on the Iroh library for NAT/Firewall puncturing, external address discovery and overlay networking. 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] :-)
[0] https://github.com/andunieee/flipflop/blob/62bb498520aacb60e...
[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
We (iroh) don't do birthday paradox hole punching yet. There is some internal debate whether it is worth it.
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.
Yeah, we need "generic Internet infrastructure" for linking devices.
By 2030 we hopefully understand the mathematics-of-trust and can link all the billions of citizens together in a single overlay.
> non KYC server rented via ZCash would be interesting though if you are super paranoid.
What will happen if a decentralized Internet emerged and presented an existential threat to existing profit margins? Company lawyer would start to attack you, correct?
I think you're both missing the forest for the trees. P2P connectivity is about as solved as it will get, and the last % will stay unsolved.
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.
>What will happen if a decentralized Internet emerged and presented an existential threat to existing profit margins? Company lawyer would start to attack you, correct?
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.
The self-replicating seedbox is a cool idea. Some places offer interest on stable coin deposits. I wonder if there could be a way to set up an account for AI use that would be self-replenishing so long as a budget is maintained.
> 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.
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.
I wish someone would revisit the idea of a single, global, P2P file search mesh like Gnutella/Gnutella2 but using a modern P2P stack (or WebRTC) instead of raw TCP/UDP like the old days.
It’s something I’ve thought about a lot recently.
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.
IPFS?
I don’t think IPFS was built for search. I see some unmaintained projects that sniff DHT traffic for hints, but (correct me if I am wrong here) the protocol maintainers never added a search layer. Eg I can’t search for “violin” and find the hash for “learn violin.pdf”.
Loosely related list of browser based and CLI tools to send files p2p https://gist.github.com/SMUsamaShah/fd6e275e44009b72f64d0570...
Big list, without much description. Does anyone have any suggestion for something like a private Napster for a friend group?
How do you get 50 contributors on a project with 116 stars that's 3 months old? There are no PR's? Only one issue?
This actually looks good and uses the established Iroh.
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.
This is a pretty good idea, it didn't occur to me, I'll try to implement it.
I never tried Iroh in the browser, but supposedly it works (by always using a relay).
Keeping the tunnel available between sends is the nice part. Once it's set up with someone, you can just use it.
Doesn’t Iroh rely on relays? If so, is it possible to run my own?
Yes, it's even encouraged. You can either pay for the company behind iroh to host one for you or host your own one.
Cool! I'll have to look deeper to see if I could use it as a base for porting https://github.com/akavel/catation to Rust+Iroh! (EDIT: related, do you maybe have plans to merge flipflop with https://github.com/andunieee/my-beloved-rubble ?)
May I ask, was it vibed/LLM-assisted to some extent, or is it purely human-made?
Iroh released something similar awhile back
https://www.iroh.computer/sendme
Ok nice find! Did you try it?
cool project. slint looks nice
> filesharing for the meatspace era
serious question: what does this mean lol
I assume individuals have to meet in order to become peers.
Can you talk a bit about the performance characteristics? What's the max throughput? How does that change with latency and jitter?
Is it better/different than https://tailscale.com/docs/features/taildrop ?
Taildrop looks good, I didn't know about it.
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.
> which relies on a central server and someone who "owns" that network
Tailscale connections are peer-to-peer. They only own the coordination server, which you can ignore and host your own.
Yes, but someone, a user with an account on Tailscale, is the manager of that network and can decide what devices can get in, etc.
For some cases that is good, but Flipflop is addressing a slightly different use case.
The Readme literally says "Use it to share stuff between all your devices".
I would argue that Tailnet is a good match for this.
Maybe expand the readme to cover other use cases interesting to existing Tailscale users?
Yes but TailScale specifies "your devices" as "devices registered to a TS account" whereas FlipFlop specifies "your devices" to mean "your devices."
It is better in one way: Taildrop supports iOS.
I agree with this
Better, who knows. Seems different in that Flipflop uses P2P connections directly to the peer, alternatively via other available peers (and initial connection might use central signaling server), while taildrop seems to depend on a tailnet, which is typically hosted by Tailscale (unless you run that yourself).
I guess it's a bit like comparing WeTransfer with Airdrop, one tries to use the network they're on already (internet) where the other favors local-local connections.
> which is typically hosted by Tailscale
Tailscale hosts relay servers as a fallback. Connections are peer-to-peer between devices.
I think it always does the initial connection via the DERP relays, doesn't it? Even if a direct initial connection in theory is possible (no NATs or anything else in the way), the connection itself is always established via the relays, then "upgraded" to a local connection. But maybe they've changed this since I looked at it?
Beyond that, even with a local connection established, all the coordination traffic will still go via the tailnet, those don't suddenly become local-first. But this might also have changed.
What I'm sure is still there today, is that all Tailscale clients automatically upload their logs to Tailscale's servers unless you opt out:
> Each Tailscale agent in your distributed network streams its logs to a central log server (at log.tailscale.com). This includes real-time events for open and close events for every inter-machine connection (TCP or UDP) on your network. - https://tailscale.com/docs/features/logging
Of course, doesn't stop a local connection from working so is only tangentially related, but worth keeping in mind that a "local tailscale connection" still has a lot of external traffic related to it, even though the data you transfer, when possible, uses more local connections.
It is two completely different things
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.
> It is two completely different things
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.
yes you understand correctly. The assumption is that you already have Tailscale for remote access and you get taildrop "for free". Installing tailscale just to get file sharing doesn't make sense if FlipFlop already does it and that is the only thing you need.
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).
tailscale does P2P too, it only fails back relays to when it cannot do P2P.
iroh is different and more than just a vpn, where you use a bunch of tools together, you can do it all in iroh with one identity, the tunnel, the file transfer, the ssh access, and others. Look at tunnet for example https://github.com/tunnetio/Tunnet to get a better idea.
Nice idea, but for personal sharing between my devices, I have a syncthing folder that's synced between my laptop, phone and media center/NAS, and I've been finding that most of my day to day files have been migrating into it, and I hardly ever use things outside of it.
I have a similar setup. I have my git repos as headless repos in my syncthing folder and use it instead of github.
I also use Syncthing, been using it for many years, it is great
I'm working on something similar, could you please turn on discussions so we can chat directly?
I've turned discussions on, although we could chat here too
What are discussions?
Why native code?
I would think this could be done completely in the browser using WebRTC?
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.
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.
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)
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.
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.
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.
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
Looks very interesting, I have been building few things on top of iroh past few weeks and I love it, from the ability to run it on some iot all the way to be rf agnostic (almost, can’t use LoRa with iroh due to its datagram limit), and best part, MoQ runs natively on iroh where on wireguard you will need to encrypt twice so more cpu, but i found kernel wireguard performs better at bulk throughput, and layer 3 isn’t by default unless you have TUN like added.
A list of iroh based tools are also found here https://github.com/n0-computer/awesome-iroh
Mind sharing the bit about IOT? I'm also looking for a way to get iroh working on something like esp32 for audio streaming. Was wondering if moq can be used here