People are going to start doing this a lot more as agents improve. Most people only need a very small fraction of the features of SaaS, and that fraction is slightly different for everyone, so the economics of companies trying to use features to chase users is bad. Even worse, if you're on SaaS you can't modify the code, which will be crippling, so the whole SaaS model is cooked.

I think co-management is going to be the next paradigm.

What's co-management?

Managed services that you have some ability to modify, to customize or add functionality.

Yes, the established standard here is known collectively as Interactive Connectivity Establishment (ICE) [1] which WebRTC relies on -- there are a few good libraries out there that implement it and/or various elements of it [2] [3].

libp2p [4] may be what you're after if you want something geared more towards general purpose connectivity.

[1] https://datatracker.ietf.org/doc/html/rfc8445

[2] https://github.com/pion/webrtc

[3] https://github.com/algesten/str0m

[4] https://libp2p.io

Thank you for the resources! I will study them.

FWIW, libp2p also enforces transport encryption, quote:

> Encryption is an important part of communicating on the libp2p network. Every connection must be encrypted to help ensure security for everyone. As such, Connection Encryption (Crypto) is a required component of libp2p.

I've exposed `Android` as a support OS. Give it a shot now.

Thanks!

Noted! I'll update it to use the Unix instructions in that case. Thanks for the feedback!

Unfortunately the app wasn't designed to intake test results from runs that didn't originate from itself. We wanted to make it harder to submit fake results, and didn't want to add a lot of friction around user auth and such.

Would you accept a pull request that enables this in a secure and privacy first manner? My team is looking for a project.

PRs welcome! We may not have much bandwidth to help, but happy to review anything that comes along. We can discuss further perhaps on a GitHub issue so the rest of the Firezone team can offer input: https://github.com/firezone/probe/issues/new.

Great! Did the test report the block accurately for you?

We have a few intrepid users self-hosting the entire Firezone stack, but we don't have documentation to support it (yet), and wouldn't recommend it for production. It's something we'd like to write and maintain eventually, even if only for smaller / hobby deployments.

We do have a self-hosted community support channel on Discord if you are feeling adventurous: https://discord.gg/DY8gxpSgep

I would recommend starting here with a local development cluster:

https://github.com/firezone/firezone/blob/main/docs/CONTRIBU...

Thank you so much. Will check it out and probably create a pull request to add the documentation while I'm implementing it.

We don't support full-tunnel yet, but it's just around the corner. Track this issue if you're interested in its progress: https://github.com/firezone/firezone/issues/2667

Thanks!

Erlang/OTP has so far been an excellent platform to build on for a product like Firezone. We chose it specifically for its reputation for powering soft realtime systems. Phoenix Channels are an added bonus that allow us to push all updates where they need to go, in just a few hundred lines of code.

We couldn't be happier with the stack choice.

Are you referring to the macOS client app? It's built in Swift with an FFI bridge to the Rust-powered connectivity layer. Source is here: https://github.com/firezone/firezone/tree/main/swift/apple

I am referring to the web app

I think it's LiveView for the frontend-backend comms and Tailwind CSS for some of the frontend, not sure if that answers your question

-- (non-web) developer at Firezone