[HN Gopher] Bananas: Cross-Platform screen sharing made simple
       ___________________________________________________________________
        
       Bananas: Cross-Platform screen sharing made simple
        
       Author : thunderbong
       Score  : 216 points
       Date   : 2024-11-28 07:49 UTC (1 days 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.
        
             | greatgib wrote:
             | 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...
        
               | GorillaMoe wrote:
               | 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.
        
       | 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.
        
               | LiamPowell wrote:
               | 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.
        
               | GorillaMoe wrote:
               | 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.
        
             | porridgeraisin wrote:
             | 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.
        
         | 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!
        
             | cl3misch wrote:
             | 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.
        
               | GorillaMoe wrote:
               | 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)
        
           | 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.
        
         | Arnavion wrote:
         | 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.
        
           | GorillaMoe wrote:
           | Yes, that's right. But tbh, getting Mediastream in Electron
           | can be done by a 5y old.
        
             | zamalek wrote:
             | _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.
        
               | GorillaMoe wrote:
               | 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.
        
               | Arnavion wrote:
               | 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.
        
       | 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.
        
         | vlovich123 wrote:
         | 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.
        
           | GorillaMoe wrote:
           | Agreed!
        
       | 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.
        
         | binarysneaker wrote:
         | Team viewer is for remote administration. I think bananas is
         | for collaborative remote working.
        
       | 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
        
           | SoftTalker wrote:
           | 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.
        
         | 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.
        
         | emptiestplace wrote:
         | 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.
        
           | Uehreka wrote:
           | 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).
        
           | GorillaMoe wrote:
           | 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.
        
           | timeon wrote:
           | Adolf Loos would turn in his grave.
        
         | GorillaMoe wrote:
         | 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.
        
         | kiliancs wrote:
         | 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.
        
           | Uehreka wrote:
           | But this doesn't even solve the problem because I DO like
           | emojis!
        
       | binarysneaker wrote:
       | 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.
        
         | GorillaMoe wrote:
         | 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.
        
       | bentt wrote:
       | We in the game industry use Parsec. It's free and amazingly low
       | latency. Good enough to play games. How does this compare?
        
         | GorillaMoe wrote:
         | I never heard of Parsec, have to look it up, but Bananas should
         | be also real low latency, because it's a direct connection.
        
       ___________________________________________________________________
       (page generated 2024-11-29 23:02 UTC)