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.
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.
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?)
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
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.
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.
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.
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.
> peer-to-peer connection ... without the need for ... any server infrastructure.
- https://github.com/mistweaverco/bananas/blob/623016aea330e61...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.
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 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.
This is exactly what I was asking myself, too.
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
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.
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.
Thanks for the detailed explanation!
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.
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.
Exactly this!
Really interesting. Will definitely test this! Greeting from the Sauerland @GorillaMoe
Hello, fellow German!
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.