[aranibatta]

Most of the stuff we do that people seem to really like can't be technically or physically done inside of another browser's tab unfortunately. Chrome extensions are too limiting as well. We started off as a chrome extension inside of our previous company, and hit a wall pretty quickly.

For the LLM calls, the one's you currently see are patching calls to a variety of model providers. As long as they hold their end of the TOS you should be fine. Everything else is happening locally.

We will launch a self-host option for Muddy. Cool features like hosting the servers and build process yourself, custom icon and skin on the app, and other internal rules you can set up. Let me know if that's of interest.

[v3ss0n]

Still not enough. You are using Chromium but your software might not be secure enough. You are dealing with sharing data all over the internet and part of your code is not opensource.

If we cannot inspect or reproduce what you are doing , we cannot trust our work with your browser. We might as well consider you are stealing our data.

If you launch self-host option , you should opensource it.

What we have for opensource alternatives are :

https://github.com/BrowserBox/BrowserBox https://github.com/m1k1o/neko

[Terretta]

We are interested in your mixture-of-app-tabs for SaaSes with SSO, contained* in a secure MOAT™.

Offer Muddy to most people here, who DGAF (datafeed Google and Facebook).

Upsell MOAT™ and your self-hosted version (leveraging each of M365, Google, and AWS identities** for the browser profile, and hosted inside company VPC that also leverages that native IdP) to companies that would like to let employees use SaaS but haven't figured out how to put a circle around that.

If you are interested to discuss, reach out.

* See the inTune ecosystem where, building on MSFT notion of data container for their O365 suite, apps from arbitrary vendors can share a data-loss protected data space (see Zoom Workspaces for inTune). The way you are writing the browser yourself, you could, in theory, have an option that ensures a web app is using SSO or it can't receive data from the user, other than a white list such as the SSO IdP flow, search engines, and pre-SSO login pages of company's preferred apps.

** Start with M365 since 85% of businesses in U.S. market use it, the IdP is already in their Office user seat plan, supporting "Sign in with Microsoft" as well as "SSO" flows, which picks up most web SaaS companies need.