Show HN: p2p.kiwi – Cross-Platform (macOS <-> Windows <-> Linux) P2P Screenshare | Hacker News Reader

Show HN: p2p.kiwi – Cross-Platform (macOS <-> Windows <-> Linux) P2P Screenshare

p2p.kiwi

3 pointsGorillaMoe5 comments

Full E2EE Cross-Platform (MacOS <-> Windows <-> Linux) P2P Mesh.

This project started almost 2 years ago (by that time it went with the name "Bananas Screen Sharing", which still yields results on Google) and has come a long way.

This started, because I was fed up with the lack of proper screenshare support on Linux (even when supported, the clients degrade to only being able to view, but not really participate).

Additionally, I got tired of this dance:

"Here.. no.. almost.. a bit to the top.. yeah, almost.. no.. more to the right.." .. when someone is sharing the screen and I try to help them navigate..

This is why p2p.kiwi supports multiple virtual cursors (they can't take control, but on double-click, they make a long sound on the presenter and grow in size..).

The kiwi also supports full remote control (mouse and/or keyboard) with an emergency eject key-chord (if people start typing rm -rf, you'd better press the emergency chord quickly..).

There is no p2p.kiwi cloud and no forced accounts.

Think of it as Skype's nerdy little sister, but E2EE, Chat, Voice, Screenshare, Remote-Controls, a P2P mesh network and completely free and open-source.

Open articleView on HN

How do you get this through security and compliance checks at an org with tight controls?

It's completely open source. You can just clone the repo and build it yourself, if your org doesn't trust the GitHub CI (which builds the binaries and creates releases).

I wonder what these orgs do when they're buying licenses for Teamviewer or something?! This is fully closed source then and you never know what these clients really do!

Doesn't matter, unfortunately. Third party audited compliance certifications are the key to get in. Companies like Teamviewer are behind a gate forged in gold. Get funded, get certified, get customers.

If the last sentence was meant for me: I don't care, if companies want to use this or not. I don't need/want funding. I don't need or want to get certified and I don't want customers (I'm pretty happy to have a lot of users). It was built to solve a problem I had. It solved it. According to the GH stars and downloads and Feedback in Discord, a lot of other people liked it as well.

I develop and ship a notarized macOS app, and the part I’d be most interested in hearing about is permission handling. Screen sharing plus remote keyboard/mouse crosses Screen Recording and Accessibility permissions, and the difficult part is often getting users through TCC state changes and required relaunches without leaving the app in a confusing half-authorized state. How are you handling onboarding and permission revocation on macOS? Does everything run in the main app process, or do you use a helper? Also, kudos for distinguishing WebRTC’s DTLS-SRTP transport encryption from actual end-to-end encryption and documenting the MLS + SFrame layers. Many products describe any encrypted WebRTC connection as E2EE even when an intermediary could access the media.

Reply on news.ycombinator.com