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.

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?

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.

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

Agreed, the emojis in the description are distracting.

this is a comment worthy of a wat? emoji

I tested on X11 and Wayland it works flawless here.

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.

This is exactly what I was asking myself, too.

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

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.

Simple for users is not the same as simpler for developers, WebRTC definitely is a beast.

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.

I never heard of Parsec, have to look it up, but Bananas should be also real low latency, because it's a direct connection.

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!

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

Hello, fellow German!

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.

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.

Thanks for the kind words.

I chose TS, because otherwise we had to put JSDoc everywhere.