GorillaMoe

If the last sentence was meant for me: I don't care, if companies want to use this or not. I don't need/want funding. I don't need or want to get certified and I don't want customers (I'm pretty happy to have a lot of users). It was built to solve a problem I had. It solved it. According to the GH stars and downloads and Feedback in Discord, a lot of other people liked it as well.

It's completely open source. You can just clone the repo and build it yourself, if your org doesn't trust the GitHub CI (which builds the binaries and creates releases).

I wonder what these orgs do when they're buying licenses for Teamviewer or something?! This is fully closed source then and you never know what these clients really do!

IDK if some of you also struggle with passing `.env` files..

It's getting a bit ridiculous at the moment, because we have so many teams working on different projects and when you're jumping in and trying support a different team we mostly have to ask around for the latest dotenv files to get the projects working locally, after cloning.

I know there are solutions like hashicorp vault and doppler out there, but they are not cheap and I don't want another service handling my secrets, because they are stored in gcp secrets anyway and mostly managed via terraform / terragrunt / terramate.

I implemented a really hacky way of "automatically" creating a .env file when you first checkout the project and have access to the secrets, but it was really messy and did just work on macos and linux (and additionally required you to have gcloud and direnv installed).

So I basically wanted something like doppler, but for free and it should just work with gcp, azure and aws, so that people who are using the secret managers by these cloud providers don't have to change anything (regarding how they store their secrets).

I couldn't find anything, so I build the first version of it: https://github.com/mistweaverco/kuba

Disclaimer: Currently, it only supports GCP so far, because that was my main goal for my day-job. I'm going to add AWS and Azure support tomorrow.

You can use Kimbia to run a series of tasks like linting, testing, building, and deploying your application.

Zana aims to be like Mason.nvim, but with the goal of supporting not only Neovim, but rather any other editor.

Zana is swahili for "tools" or "tooling".

A minimal package manager for Neovim (and other editors) which uses the Zana Registry to install and manage packages.

By its spiritual predecessor Kulala.nvim, bringing .http files support to a nice GUI app.

Why?

You should own your data (.http files in your vcs). You shouldn't have to worry about logins or accounts. It should be mostly compatible with Kulala.nvim, Rest.nvim, VsCode RestClient, IntelliJ and Visual Studio.

You can see the current WIP here: https://bsky.app/profile/mistweaverco.com/post/3lhfmepcw322s

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.

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.

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

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.

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)

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.

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.

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.

Yes, that's right. But tbh, getting Mediastream in Electron can be done by a 5y old.

Agreed!

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.

Will definitely make the servers list configurable via settings in one of the next releases.

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.

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.

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

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.

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.

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.

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.

I tested on X11 and Wayland it works flawless here.

Thanks for the detailed explanation!

Hello, fellow German!

Thanks for the kind words.

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