[HN Gopher] Bananas: Cross-Platform screen sharing made simple
       ___________________________________________________________________
        
       Bananas: Cross-Platform screen sharing made simple
        
       Author : thunderbong
       Score  : 159 points
       Date   : 2024-11-28 07:49 UTC (15 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | greatgib wrote:
       | 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.
        
         | GorillaMoe wrote:
         | Thanks for the kind words.
         | 
         | I chose TS, because otherwise we had to put JSDoc everywhere.
        
           | yolkedgeek wrote:
           | No he meant "Why didn't you just write it in Rust, Duh"
        
             | GorillaMoe wrote:
             | 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.
        
       | LiamPowell wrote:
       | > peer-to-peer connection ... without the need for ... any server
       | infrastructure.                   iceServers: [{ urls:
       | 'stun:stun.l.google.com:19302' }],
       | 
       | - https://github.com/mistweaverco/bananas/blob/623016aea330e61...
       | 
       | It's P2P, but saying there's no server infrastructure is
       | objectively wrong.
        
         | K0nserv wrote:
         | 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.
        
         | eddyg wrote:
         | 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.)
        
         | GorillaMoe wrote:
         | 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.
        
         | porridgeraisin wrote:
         | 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.
        
           | LiamPowell wrote:
           | 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.
        
             | GorillaMoe wrote:
             | 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.
        
         | e12e wrote:
         | 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?
        
           | GorillaMoe wrote:
           | Will definitely make the servers list configurable via
           | settings in one of the next releases.
        
           | e12e wrote:
           | Btw, found this which explains a bit when you need a TURN
           | server:
           | 
           | https://webrtchacks.com/symmetric-nat/
        
       | kookamamie wrote:
       | WebRTC and "simple" are somewhat orthogonal concepts, I think.
        
         | K0nserv wrote:
         | Simple for users is not the same as simpler for developers,
         | WebRTC definitely is a beast.
        
           | GorillaMoe wrote:
           | Exactly this!
        
       | vstollen wrote:
       | 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.
        
         | cl3misch wrote:
         | > 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?
        
           | samiv wrote:
           | 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.
        
             | GorillaMoe wrote:
             | Thanks for the detailed explanation!
        
           | GorillaMoe wrote:
           | 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.
        
       | woodrowbarlow wrote:
       | 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?)
        
         | GorillaMoe wrote:
         | I'm currently on Wayland and it's working flawless for me. Will
         | test on X11 this evening.
        
         | avhception wrote:
         | This is exactly what I was asking myself, too.
        
         | GorillaMoe wrote:
         | I tested on X11 and Wayland it works flawless here.
        
       | avhception wrote:
       | Really interesting. Will definitely test this! Greeting from the
       | Sauerland @GorillaMoe
        
         | GorillaMoe wrote:
         | Hello, fellow German!
        
       | GorillaMoe wrote:
       | 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.
        
       | yawnxyz wrote:
       | 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
        
         | GorillaMoe wrote:
         | 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.
        
         | GorillaMoe wrote:
         | 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.
        
       | arnejenssen wrote:
       | Is this an alternative to team-viewer?
        
         | GorillaMoe wrote:
         | 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.
        
       | SoftTalker wrote:
       | 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.
        
         | Liquix wrote:
         | 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
        
         | GorillaMoe wrote:
         | 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.
        
         | nanomonkey wrote:
         | 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!
        
           | GorillaMoe wrote:
           | 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.
        
       | Jumziey wrote:
       | https://screego.net/#/
       | 
       | 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
        
         | GorillaMoe wrote:
         | 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.
        
       | Uehreka wrote:
       | 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".
        
         | laerus wrote:
         | this is a comment worthy of a wat? emoji
        
         | two_handfuls wrote:
         | Agreed, the emojis in the description are distracting.
        
       ___________________________________________________________________
       (page generated 2024-11-28 23:01 UTC)