Bananas: Cross-Platform screen sharing made simple
github.com225 points by thunderbong 8 months ago
225 points by thunderbong 8 months ago
> peer-to-peer connection ... without the need for ... any server infrastructure.
iceServers: [{ urls: 'stun:stun.l.google.com:19302' }],
It's P2P, but saying there's no server infrastructure is objectively wrong.
Anytime I see “P2P”, I assume a STUN server is involved because of the ubiquitous nature of NAT with IPv4. I read such claims as meaning that the tool itself does not require dedicated servers or persistent storage for its core functionality. (And there are plenty of public STUN servers to choose from.)
You are completely right, the website has been updated to reflect the correct flow of data.
As other users already stated, we need that to agree on connection details, but once that is done, the flow of your media data like audio, video and text is just between the two parties.
It's a fundamental limitation of P2P that you need NAT hole punching. If you use IPv6 it's truly peer to peer since you can generate ICE host candidates directly.
Also, you don't actually need NAT hole punching if you use fixed ports and port forwarding at the router level.
Useful, correct-enough information > objectively pedantically correct information. When people say lack of server infra in the context of a screensharing app, it is plain and obvious they exclude STUN/TURN, especially on HN. Come on now.
To me "P2P with no servers" implies something like Kademlia that truly require no central servers after bootstrapping, although it is immediately obvious that they don't mean this when there's no details about the protocol presented prominently.
Bootstrapping in Kademlia also requires either a server or a Kademlia Node that previously has run the bootstrapping process, so I can't really see the benefit except of having more resilience against DDoS attacks.
I don't think there's any real benefit to be clear, I just thought that saying P2P and then saying "no servers" implied some fancy new distributed protocol.
Oh, thanks for the clarification! And to be frank, you're right on that it was somehow misleading. I hope the current state of the website is more clear on this topic.
WebRTC doesn't need it either in principle. The stun server is only to exchange IP addresses for the purpose of hole punching through NATs.
Even in p2p implementations that use kademlia, you need a way to figure out hole punching. In IPFS, while there is a decentralised hole punching method as an alternative to a centralised STUN server, it requires atleast one participant to not be behind a NAT, so for this purpose it's besides the point.
Might work with coturn or turn-rs, others?
https://github.com/coturn/coturn
https://github.com/mycrl/turn-rs
Maybe there are some projects doing only stun - if that is enough?
Will definitely make the servers list configurable via settings in one of the next releases.
Just fyi: it's planned that Bananas supports not only a direct peering of two parties, but rather a set of "unlimited" parties, where the host acts as some kind of relay server for all peers.
This means that in the future you should always choose the one with the beefiest hardware and network connection as host.
Swapping who is presenting without the need to reconnect, + chat is also planned for V1.
Transparent leader election fail over with the relay would be necessary. Otherwise a dead battery for the relay or dead internet connection amplifies the outage instead of reliability going up with number of people in the call.
This looks fantastic! But…
I love emojis, I hate to be _that guy_ about this, but the emojis on the introduction page make it hard to read. Like, I don’t notmally associate the radar emoji with sharing or the twinkle emoji with features, so my brain read “screen monitor sharing radar dish”.
They aren't my preference either, but I wonder if you might be taking them a bit too literally. They aren't necessarily intended as a direct representation of anything, they are just there to decorate the text and express a bit of silly fun in a way that may or may not be immediately relevant.
The problem is that many people do in fact use emojis instead of words in the flow of text. It’s a super common idiom (think about how people use the eggplant emoji in texts). So you can’t just use emojis to duplicate words in a sentence or people will read it as the same word twice (or worse, two completely different words that break the sentence’s grammar).
That's exactly how I use them. I'll probably add a selector for "with Emojis | Plain text" on the website. So we can make everyone happy.
The website will ask you "do you like emojis?" once. If you answer with yes, you see emojis, if you answer no, all emojis will be hidden from you from that point on.
Now the website asks if you like emojis or not. I don't mind the emojis, but if I did, I think I'd prefer them to the popup.
on Linux, screen sharing works very differently on X11 versus wayland, and both are commonly found in the wild right now. has this app been tested on both X11 and wayland? (might be a good thing to add to the website?)
I'm currently on Wayland and it's working flawless for me. Will test on X11 this evening.
It's "just" using Electron's built-in screencasting capability (`desktopCapturer`), and Electron supports both X11 screencasting and the xdg-desktop-portal+pipewire approach used by Wayland compositors.
Yes, that's right. But tbh, getting Mediastream in Electron can be done by a 5y old.
If you're using a recent Electron. Nearly everything (Discord, Slack, you name it) does not. This is all from memory, but I believe Wayland was "fixed" in Electron 19, but with a showstopper bug that was never backported. Many Electron apps are on 18 to this day.
Yes, I was just triggered by the "just" somehow :( it is not the hard part that I was trying to solve. The hard part is the UX/UI and the WebRTC part itself.
I believe you interpreted it exactly the opposite of what I wanted. I put "just" in quotes precisely to make the point that that there's a lot more to your application than getting the screencast buffer.
Do both the sharing and receiving users need to install the app? If not, it would probably be much easier to start using the app if at least the receiving user could view my screen from their web browser.
Apart from that, I often fall back to https://github.com/adamyordan/laplace when I need to share my screen. It works in the browser and has great image clarity. Sadly, the demo instance is down, so you need to host it yourself. Also, it can have trouble inside some enterprise network/firewall setups.
> the receiving user could view my screen from their web browser
How would this be possible "without the need for an account or any server infrastructure" claimed by this project?
With WebRTC the "without any server infrastructure" only refers to the P2P part. The session initiation is outside of this. So in practice this means you need a server for the initial handshakes and then the actual session is P2P.
Running over WebRTC the web browser based person can communicate with the host person who is running a native WebRTC app.
The session initialization needs some kind of middle man (server) that lets both parties to agree on the session communication details. This per se doesn't really need any account.
The person who wants to host the session could generate a temporary one time auth token that they then communicate to their peer using whatever means (send a pigeon, use email, chat app) that lets the client to connect to their host.
Sure, but somebody will have to host the website for the "web browser based person"? Even though the audio/video traffic will be P2P, there has to be some interface in the browser?
I keep wondering whether this browser interface would be possible on a static website with all code running client-side.
That is totally possible if you just want to join a driver/host.
If you want to take over and become the driver that would not be possible or with some real limitations (not being able to give access to your keyboard/mouse and also not having the ability to show the cursors of the participants)
Probably doable as the participant does not need to do the heavy lifting of the host with drawing cursors over other windows.
Might sketch out a quick demo at web.getbananas.net this weekend.
This should be also OSS and everyone should be able to host their own version of that web Framework.
Just want to give it a shout out in this context, same tech and quite mature. Been using it successfully at work for remote pair programming and it feels like your looking at your co workers screen
That's quite impressive! But I've also have to admit that it would not solve the issue I was having when pairing: showing my driver exactly where I was looking at.
This can be done in Bananas via remote Cursors.
WebRTC and "simple" are somewhat orthogonal concepts, I think.
Simple for users is not the same as simpler for developers, WebRTC definitely is a beast.
When Covid began I needed something that could replicate sitting next to a coworker and debugging or pair programming. I discovered https://pop.com and I've been using it ever since. Lightweight multi-platform client, multi-cursor, annotations, and a web viewer too. How much? It's been free for years. No affiliation.
Does remote control and drawing really work on all platforms? I remember screen hero and Linux support was always an after thought and did never work well with all features.
We in the game industry use Parsec. It's free and amazingly low latency. Good enough to play games. How does this compare?
I never heard of Parsec, have to look it up, but Bananas should be also real low latency, because it's a direct connection.
This is not a critique but it seems like any screen sharing I’m involved with lately is using Zoom. How much do people use other sharing and in what situations?
Thinking of my workplace, the friction involved with using anything other than Zoom would be a non starter for most people.
Assuming you're on a paid plan then and afaik that's not that cheap. You might also challenge C level execs that you might save a lot of money using something like Bananas (once we reach v1 and have added needed features).
Also if zoom goes bankrupt, zoom stops functioning. Bananas is not (that) reliant on servers (except for negotiation of communication details, currently using Google's servers for that, but you could also use your own).
Zoom also has your account data and media is transferred through their servers, which for some people is not a big deal, but for others it might.
We use Google Workspace at work and their meeting functionality, which is quite limited. Previously I used Office365, which wasn't any better.
I'm a big fan of Tuple, but that's limited to Windows and MacOS, which is a deal breaker for me (using Linux).
Also, they want to have your data, including account setup.
I'm not saying that Bananas never evolves into something with accounts and friend-lists, but that should be always fully optional and opt in and open source.
Most of the groups I work with use Signal or Jitsi...so it really depends upon the group you're working with. We never use Zoom!
I remember Jitsi being awesome, but as far as I can remember, you need to have a Jitsi server running, right? I wanted it to be as independent as possible of servers or orgs, so that when I get rolled over by a bus and stop paying for services, it still continues to work for everyone.
it's mostly a matter of what you use, inertia and incumbency, no? for example we use slack and asking someone to download and install zoom to screen share would be a non starter for most people, as slack has the feature built in. in a teams shop asking someone to download slack or zoom would be a non starter, etc
Yes this was really what I meant. Zoom is our standard for virtual meetings, so suggesting or asking anyone to install something else to do a screen share would get pushback if not outright denied.
Really interesting. Will definitely test this! Greeting from the Sauerland @GorillaMoe
this is perfect for a talk I'm giving next week!
However on MacOS I'm getting lots of "need to give permission" popups for mic and screen share, and I'm giving permissions but it keeps popping those errors up
Seems to be either related to MacOS 14 or some settings voodoo of MacOS, because we already have users reporting that issue on GH, but other users have successfully tested that it works on MacOS 15.
There seems to be an issue on MS Windows Server 22 as well, but Win10/11 confirmed to be fully functional.
Seems to be related to a known bug with unsigned apps.
I'll implement signing and notarizing in the next release.
Wanted to enroll today, but apple seems to have a maintenance window now.
Is this an alternative to team-viewer?
It could be seen as an alternative. Currently it only supports multi cursor mode and pinging with the participant's cursor on the host's screen. But taking over keyboard and mouse is planned.
Team viewer is for remote administration. I think bananas is for collaborative remote working.
I support the idea of this project as something simple and not going through a third party service is a need.
Just sad that it is based on typescript.
Thanks for the kind words.
I chose TS, because otherwise we had to put JSDoc everywhere.
No he meant "Why didn't you just write it in Rust, Duh"
I started the project PoC in Tauri, didn't work with WebRTC, then I tried that in wails, did not work either. Then I was tired and chose something from what I knew that I can make it work somehow.
Not saying that writing this completely in Rust without relying on WebRTC is completely out of reach, but Zig is also around and attractive as well.
Yes, indeed I meant not typescript, not js but something to do a real desktop app.
I'm not specially fan of Rust, but here what annoys me is to have to use an electron based app...
I'm not against a complete rewrite at some point in the future, to be not reliant on electronjs anymore.
But to be honest, that is not something I want to tackle alone. I need (code-)contributors for that. Basically someone who is well versed in MacOS native development and someone who is willing to take on native Windows stuff. I can take on the Linux part, but that's the minimum I would expect for it to work.
Next thing is getting signing certificates for MacOS and Windows.
MacOS costs USD99/y and Windows USD 350+/y or with the beta program USD 120/y
Which I'm willing to take on, if Bananas hits a nerve and people start really using it.