Love to see P2P coming back. Back in 2013 I built a P2P application platform called Firestr (https://www.firestr.com) that was targeted as an all in one platform to build and share graphical P2P apps. The apps were built using a built-in collaborative app editor. You could build P2P apps with friends using P2P!
You create a conversation with one or more people and can then launch apps into that conversation. The people on the other side didn't have to have the apps installed. If they liked an app, they can install it with one click and use it in their own conversations. If they wanted to change the app, they can do that too using the built in editor! All across a real-time encrypted p2p channel.
Despite how easy all these new P2P app frameworks are, none of them are as easy as Firestr was.
That's really cool—big props to you! Really dig being able to effortlessly create and share graphical P2P apps with others.
I'm keen to test this with others and dive deeper. The docs were a bit vague on what 'identity' means—is it just a username, or more like a public key? The idea of connecting or 'joining' others in P2P apps seems complex for many. Sharing keys or long strings might be intimidating for widespread use.
Did Firestr gain much traction? Was there an effort to expand it? It seems like an opportune moment for a comeback!
Identity is a public key. You have a contact list that you add keys too. When two people exchange keys and add them to their lists, they automatically connect and can have conversations. Exchanging keys you needed another channel (email, sms, etc) or use the introduction system inside the app where you can introduce one person to another.
In regards to total users? I have no idea. By it's design there isn't a central user list. I have no idea who is talking with who using it.
I believe one limitation was that identities were really tied to a device and I never made a phone version of it. So it being limited to desktop limited it's reach as a communication system.
Maybe it can inspire others. I would love to see P2P as the main way to communicate.
I've been following Holepunch developments for a while. There does not seem too much publicly available about who's building with it, but I personally regularly use Holepunch's Keet[1] for video calls with friends in parts of the world with censored Internet. I'm able to chat with voice and image quality surpassing anything else I've used.
It's frigging cool. It's super hard to make a meaningful model for p2p applications because they need all kinds of data structures that are research tier or have scarce real-world data. It's not just connectivity that's hard. If they manage to do everything decentralized and create meaningful constructs. This could be the start of actually realizing all the rhetoric these kind of projects have been promising. This seems to have technical merit, imo.
This looks exciting and I'm pleased to see more and more frictionless ways of making p2p apps. I've been building a somewhat similar hobby project [1] that aims to connect peers in the browser by piggybacking on open protocols out on the net (BitTorrent, MQTT, Nostr, IPFS, etc).
This project seems to be using Hyperswarm which I've looked at for use as a peering medium but it seems like it's not supported in the browser. I'd love to implement it if that story changes since it's so easy to distribute apps on the web.
Sorry if this is silly question but just because I have an ipv6 address doesn't mean anyone else with an ipv6 address can communicate with me, right? Here is my simplified understanding
(You) <-- (lots of stuff) --> my modem <--> my router <--> my phone
So like even if you had my ipv6 address, am I really addressable? Like can you ping my phone? Send me files across the Internet?
Thank you for answering. I have so many questions but I'll start with this... When I ping an ipv4 address from outside the home, if something responds to the ping it is my modem/router, right? As in even if I had no computers in the house, you couldn't tell the difference when you ping my ipv4 address, right? My Internet service provider owns my IPv4 address, not me, right? What changes with ipv6? The ISP still owns the IP addresses and is free to reassign them wherever? It isn't like a phone number where I own the number and have a right (in the US) to port it?
> When I ping an ipv4 address from outside the home, if something responds to the ping it is my modem/router, right? As in even if I had no computers in the house, you couldn't tell the difference when you ping my ipv4 address, right? My Internet service provider owns my IPv4 address, not me, right?
Right. IPv4 addresses are expensive, so it's uncommon to have more than one at home.
> What changes with ipv6?
Not a lot. You just have many addresses instead of one. If there were no firewall, someone could ping your router or individual devices, as they have different addresses.
> The ISP still owns the IP addresses and is free to reassign them wherever?
Yes.
> It isn't like a phone number where I own the number and have a right (in the US) to port it?
Correct. You would need direct BGP access to use a portable IPv4/IPv6 address. That generally is not available on residential connections.
Is this the same Tether as in the USDT stablecoin that's been accused of pumping up the volume in Bitcoin markets and possibly being secretly insolvent?
Genuine curiosity: What's the issue with a company being backed by Tether?
I understand that, as it stands today, Holepunch appears to be operated or contributed to by several staff members from Bitfinex and Tether. However, if Holepunch is open source and Tether were to implode, Holepunch would still exist and could be adopted by anyone, irrespective of Tether/Bitfinex, etc., correct?
Open-source projects where all the developers work for one company tend not to do too well when that company dies, especially if there isn't a large ecosystem around the software yet.
The fact that you are using loaded words (stolen from the population) and putting words in my mouth (by asserting that I agree with banks getting bailouts) shows that you are absolutely dishonest.
I certainly had no intention of attempting to put words in your mouth, but I believe the words you wrote have the implications that I highlighted.
I disagree that I am being dishonest. I stand by the fact that the money is stolen. Bank rescues are financed through the monetisation of government debt, this causes monetary debasement which directly confiscates purchasing power of those who hold the money, without their permission. This fits the definition of theft.
Clearly implies that you either really mentioned bailouts as a positive feature, or that commentary of yours makes no sense. Why do you call your opponent dishonest? If you mean something else it's probably better to explain than to immediately enter holywar mode.
and my point is that their overlapping features of custody and their overlapping vulnerability to bank runs (or lack thereof) is more important
if banks operate at 3-10% reserves or immediate liquidity, all the time, then tether is just as or more resilient.
if you need to move the goal post to insurance, simply to look at differences, its apt to remember that banks are private corporations that thought it would be funny to codify state sponsored insurance to bolster their own business of deposits. putting the con in congress. similarly uninsured products have been covered in bailouts for the exact same reason. And can happen again. There is zero history that suggests crypto products would be excluded simply for being crypto. Its far more likely that crypto industry grows big enough, and crypto friendly personnel run regulatory agencies and congress to be ready to act and advocate for it.
But even that isnt important to me, only an observation. I dont need that confidence game just to move the goalpost even further on tether, you might.
My only point is that we’re clear on what the controversies are and why. Its withstood extremely trying macroeconomic environments because it is designed better, and that was the only thing people were worried about.
That being said, I would like an even better designed product. Overcollateralized stablecoin with completely onchain collateral. We’ve been close but not quite.
>"Holepunch is a technology platform that allows tech developers to create apps with no servers whatsoever. The company provides its peer-to-peer platform on an open source basis, allowing developers to contribute to the project, and to utilize the open source code at no server infrastructure cost.
Holepunch provides a collection of “small javascript modules” which can be combined to create unlimited P2P apps, from VPNs to communication tools like Keet.
This is the first I've seen of combining the ideas of a P2P framework and a client-side (which becomes "server-side" because a local P2P Client -- is also and/or can become a remote P2P Server) JavaScript execution engine...
Now that's... different! :-) (For lack of a better word!)
At least in a "that sounds novel!" kind of way...
It'll be interesting to see where all of this goes in the future!
Can someone help me compare this to libp2p, or just using webrtc with peer.js etc.. on both the peers? Is it just about having access to their DHT for session management?
It would be nice to see a technical overview, but this is absent from their docs. Looking at their modules reference docs the runtime seems to comprise:
- A distributed replicated log
- Peer discover via a distributed hash table
- UDP holepunching to set up direct connections
- A TCP like protocol running over the UDP connection
- Key-based crypto routing (ala wireguard)
I assume there needs to be some servers available to facilitate the holepunching. Not sure how that works.
> needs to be some servers available to facilitate the holepunching
Not needed.
Other phones can help you determine connectable ports. You can create a phone-to-phone overlay and even puncture carrier-grade NATs. See our birthday paradox attack and initial dozen SIM cards measurements: https://arxiv.org/abs/2311.04658
Older university project, similar to Holepunch with more dev docs: github.com/Tribler/trustchain-superapp/
I totally thought this was an article about a phreaking [1] method of passing P2P messaging using actual hole-punches going pear shaped.
Having now read the actual article, I'm not sure what I actually read. There was so much ad speak, I think it was "disrupting web 2.0 with serverless P2P aps"?
I'm guessing its due to the NATs they use. Carrier-grade NATs with made-up IPs and symmetric NATs. You can have some kind of options for symmetric NATs. But I'm not too sure about carrier-grade NATs yet as I've never even written code for this yet.
Keeping links open P2P requires keepalive because NATs will time out. Even with IPv6 there are usually stateful firewalls in the way that will time out. This means you're constantly sending little packets, and if you have a lot of links there's a lot of keep alive cycles that have to be serviced. This keeps radios and baseband hardware from being able to sleep, draining the battery faster.
Mobile devices almost always have IPv6 on cell networks these days, which makes the actual hole punching almost 100% successful.
This seems like it should be solvable by having the stateful firewall support e.g. Port Control Protocol (RFC6887). Obviously that has to be done by the network rather than the client, but what's stopping them? It can't be resource consumption, it's an efficiency measure for the network too and "we don't kill your battery life" is an advertisable feature.
Mobile carriers have less than zero incentive to do this, so it’s dead.
Middle boxes in general have to be treated like natural laws or acts of god by developers. There’s like zero chance of affecting them outside the very narrow homelab segment. Even enterprise vendors generally can’t persuade companies to alter policies there.
Expecting all networks to do this is a pipe dream because there are too many of them and a large proportion are administered by people you might not have anything charitable to say about. And then you're stuck falling back to something ugly, like tunneling over HTTPS to a device that can map that port and using it as a relay.
But you could still use it wherever it's available. Mobile devices spend a significant proportion of the time on home WiFi networks.
And there are only three major US wireless carriers. That isn't a matter of convincing a million absentee corporate firewall administrators, it's a matter of convincing three specific entities, any one of which would be a major win.
I'm half tempted to start making "enterprise firewalls" (i.e. a thin wrapper around Linux netfilter running on commodity hardware) and then enable RFC6887 by default and put a warning in the documentation not to turn it off because forcing applications to tunnel traffic over outgoing HTTPS can impair the functionality of intrusion detection systems and remove valuable information from audit logs.
You'll face a lot of those problems on residential ISP connections too. The bigger issue with mobile devices is that they're roaming between towers, so there are frequent changes to the network topology. But p2p networks usually require a long-ish bootstrapping step that might not even finish by the time the physical network shifts underneath it. (Tor bootstrapping takes on the order of ~30 seconds, for example.) As the linked paper notes, this is disruptive not only to the local client, but also to the rest of the network that needs to re-learn (and re-propagate) the location of mobile peers.
Any particular reason their products are a downloadable app instead of a web app running in the browser? Like write it in Rust, compile to Wasm, call it a day. Or am I missing sth?
I can't speak for Rust+Wasm, but I would assume that web applications might face performance issues. Additionally, there could be WebRTC blocking by some ISPs, potentially leading to a less consistent user experience.
You create a conversation with one or more people and can then launch apps into that conversation. The people on the other side didn't have to have the apps installed. If they liked an app, they can install it with one click and use it in their own conversations. If they wanted to change the app, they can do that too using the built in editor! All across a real-time encrypted p2p channel.
Despite how easy all these new P2P app frameworks are, none of them are as easy as Firestr was.
Example apps
https://github.com/mempko/firestr/tree/master/example_apps
Example p2p drawing application
https://github.com/mempko/firestr/blob/master/example_apps/d...
I've stopped developing it years ago. Maybe I should pick it up again if P2P is becoming interesting again for folks.