Holepunch Unveils P2P Platform "Pear Runtime" | Hacker News Reader

Holepunch Unveils P2P Platform "Pear Runtime"

pears.com

92 pointsyosoyubik52 comments

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.

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.

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!

Thanks for the positive feedback!

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.

Thank you for your reply and for breaking down how identity worked. It makes perfect sense now.

The idea of having no user tracking also aligns brilliantly with the ethos of a truly P2P application.

I'm right there with you, hoping to see more decentralised models of communication in the future!

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.

[1] https://keet.io/

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.

Feels like creating small, ephemeral groups is an easier part of p2p too, so it fits that particular use case well.

Sounds like a job for Conflict-free Replicated Data Types https://crdt.tech/

looks great. Pied Piper irl

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.

[1] https://github.com/dmotz/trystero/

I think the biggest thing we need to push for p2p apps is IPv6 just so that everyone has a real address without NAT

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?

Yes, I could ping your phone if there wasn't a firewall blocking it between you and me.

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.

Thanks for building trystero. Fun and easy p2p in browser.

> Created by Holepunch, a Tether-backed company

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?

Seems so.

https://tether.to/en/tether-bitfinex-and-hypercore-launch-ho...

The same company. The claims about pumping Bitcoin are ridiculous, but being secretly insolvent? It seems unlikely at this point, but maybe.

This seems like an unneeded attempt to try politicalize a technical innovation...

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.

because using kleptocurrencies implies bad engineering decisions. code will likely have Blockchain were you could have used a queue, etc.

it's like seeing something was a java applet or activex component in the 2000s

Non-sequitur.

Yes, I guess. But it's still a signal if you are in a hurry.

you realize the biggest tether controversy involves them being briefly 800% more solvent than banks, instead of 1,000% more solvent than banks?

and we know that because they’ve been investigated by multiple authorities in the US and paid fines for that specific reason?

just making sure we are on the same page about the controversy

Banks can be rescued by governments. Tether can not.

Banks are allowed to have fractional reserve. Tether's whole promise was that they would keep 1:1 reserves.

>"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.

https://holepunch.to/"

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 have something to do with tether but I'm can't parse all the marketing speaking on that page.

What dreadful marketing drivel on their site.

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.

https://pears.gitbook.io/pears-docs/

> 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"?

[1] https://en.wikipedia.org/wiki/Phreaking

Are there any plans to support mobile platforms?

mobile platforms have some unique challenges for P2P stuff, from what I looked into back in the day.

https://www.researchgate.net/publication/200753717_Challenge...

(from 2009)

P2P stuff is really hard.

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.

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.

No it's mostly the battery limitations.

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.

Seems like you could mitigate some of that by establishing some kind of clock:

1. wake up & enable radios

2. see if peers are in range

3. gossip updates for 30 sec

4. sleep for 5 minutes

5. repeat

Already supported :)

Will this be documented at some point?

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.

> zero server infrastructure costs, ever, to developers.

Aha. Who pays for it?

Reply on news.ycombinator.com