Just found out about the app!!

[jj10133]

Hi @hanfour ? sorry I didn't even search on appstore for peerdrop before working on it!! This my version https://github.com/jj10133/PeerDrop. Now our implementation are a bit different but you using stun/ice and I'm using DHT for peer discovery, transport using webrtc and udp... I'm super amazed since I have a P2P app for video/audio calling using webrtc without stun/ice but DHT works on small scale, so would like to ask for now is the app scaling well for just audio calls? I'm just curios since I was testing webrtc using video calls

[jj10133]

Sorry is the app meant for local network only?

[jj10133]

Since my version uses DHT so we could use it over WAN or any "network" may be around 80% unless we trapped under many CGNATs since its holepunching

[hanfour]

Hi @jj10133,

Seeing another "PeerDrop" out there is a fun coincidence! Love the repo. I thought it might be useful to share some notes on how we tackled similar challenges:

Scope First: We focus strictly on 1:1 transfers. By capping rooms at 2 peers, we avoid the headaches of scaling for group audio, keeping 1:1 calls very stable.

How we handle the "Connection":

Local-First: On the same network, we go native (Bonjour/BLE/UWB) via TCP to bypass WebRTC overhead. It's significantly faster for large files.

The WAN Gap: For remote transfers, we use a Cloudflare/Google STUN+TURN stack. Unlike a pure DHT approach, we use Network Fingerprinting to detect hard NATs immediately. If hole-punching won't work, we skip the wait and jump straight to TURN relay.

The Philosophy:
Our goal was "100% connectivity" for non-technical users. DHT is amazing for decentralization, but we found the churn and join-times on mobile a bit tricky for the "instant" feel we wanted. We basically traded some server costs (TURN bandwidth) for a "it just works" experience.

If you ever want to boost your success rate under CGNAT without losing your decentralization roots, adding a fallback TURN server (like a $5 VPS running coturn) might be the perfect middle ground!

Happy to chat more or compare notes anytime. Feel free to ping me or open an issue on our side. Cheers!

[jj10133]

That's awesome!! so far DHT has been going good for me and holepunch does work atleast where I'm based but kind of depends... have the mac app so test it out!! I loved your app since I have little projects you kind of merged them so yeah!!

Waiting for approval for the apps... though my mac app is out and yeah let me know if its going smooth!! I'm learning more on callkit on your side to have something with webrtc but quic over media is something i wanna look into and havent dug more on it.

[jj10133]

I'm using different tech stack and approach completely!!

Have been a fan of hypercore protocol -> hypercore, hyperbee, hyperswarm. At present, it was hard to have js side of code running on native platforms... I meant nodejs there's a work around but not supported nor works smoothly.

So folks that I have been following made bare runtime to run across all platforms!! I embedded js runtime in order to have hyper* ecosystem accessible. So at present using bare-kit to integrate with swift and kotlin and kmp as well...

This just is a simple tool that's following electron like things but its not electron even tho bare uses v8 engine but recently supports the apple javascript-core as well though I haven't tried it out.

Goal is simply for normal users to send files across any platform so at present its only apple side of things but working on android and later linux.

[hanfour]

That’s a really clean architectural call. The Holepunch / Hypercore stack is easily one of the most impressive bits of decentralized infra out there—what they did with Keet is wild. Bare seems like the perfect solution for bringing Hyperswarm to mobile without the massive overhead of dragging Node.js along. You’re tackling the "cross-platform + DHT-native" challenge head-on, and those are definitely the right primitives for it.

We took the opposite path—pure native Swift, no embedded runtime, and accepted the "iOS-only" limitation as the trade-off. It gives us a tiny binary and zero JIT/startup costs, but we’ll eventually have to pay the "Android rewrite tax." Your path is definitely the more ambitious one.

Since you mentioned not having tried Bare’s JavaScriptCore (JSC) mode yet, I wanted to flag a potential hurdle:

On the App Store, using JSC isn't just a performance choice—it’s almost a compliance requirement. Apple strictly limits JIT entitlements to their own JavaScriptCore framework. Third-party engines (including V8) are forced to run in interpreter-only mode on non-jailbroken devices. This is the same wall React Native hit years ago, which is why JSC/Hermes became the defaults.

Switching Bare to JSC for your Apple builds is likely a necessary move for the store, though you'll want to benchmark any JIT-heavy hot paths early to see how the performance holds up without V8’s optimizations.

Really looking forward to putting the Mac build through its paces this week. Good luck with the Android port—ping me when that iOS build finally clears review!

[jj10133]

For sure will ping once it's ready!! At the same time have been working on P2P browser -> https://github.com/jj10133/Vinjari which is serving website using Hyperdrive over hyperswarm. The recent macOS 26 webkit's api helped me lot to stream sites into the webview.

At present, we have static sites and all content like video/photos work and its sparsely getting the data though haven't had more approach towards P2P site focusing on reactivity. Open to any ideas on this...

Currently had a simple blog and was wondering on have comments but hypercore has its limits here!! since autobase approach is multiwriter but I'm not a fan of it for my use case... I like willow protocol as well but haven't been following more on.

Though JSC no switch needed unless they changed the rules since I have my real-time location sharing app there for sometime now!! though its not that that great but good enough just for real time locations!! Have been working on it lately so hoping to get something feasible and then release. This is where I loved hypercore cause I utilized protomaps and completely served over hyperswarm into MapLibre and works but iOS support sometimes break since not good support and andoird was amazing and I was shocked that it works!!

The same maps project I tried it out recently on my browser project where I have no local http server but I was relying over ipc to stream maps data from hyperswarm into webkit's webview and it does work smoothly...

[jj10133]

All good atleast the macos app is approved!! now working on ios submission soon!!

[hanfour]

Massive congrats on the macOS approval — proper milestone. iOS next.

Thanks for the V8 ground truth — beats my policy-doc squinting any day. Sounds like Bare-on-V8 just ships, and JSC only matters if perf bites. Filed.

Vinjari looks fun. Hyperdrive + macOS 26 WebKit + IPC-streaming-into-WKWebView (no localhost) is a really clean combo. And given protomaps sometimes breaks on iOS, my hunch is the IPC variant ends up being the more robust path there too — less to fight WKWebView about.

On comments without autobase: invert the model. Each commenter owns their own hypercore, blog aggregates known cores at render. Many logs + reader merges, instead of many writers + one log. Discovery via a per-post hyperswarm topic where commenters announce their core. Willow's namespace/subspace/path maps cleanly if fan-in gets unwieldy.

For reactivity in general — P2P doesn't have a great real-time story yet, so for a browser I'd lean into "read-mostly + optimistic writes + eventual propagation" rather than chase it.

Sympathies on the iOS wait. We've got v4 in PREPARE_FOR_SUBMISSION with v5 code-complete behind it. The cycle is eternal.