Yeah, the weight floor can be hit or miss with regards to striking convos with strangers. Many of the people there want to make friends too, but many just want to focus on their workout.
Two related contexts that I've found to be much more friendly for this:
1. Climbing gyms, for reasons mentioned previously
2. The sauna! Actually very ideal for convos with strangers. Max overlap time is ~15 minutes, people are generally relaxed, no phones to distract and if it doesn't go well either party can always leave.
I remember yanking out the onstar unit in my 2015 silverado to physically disconnect the cell antenna. This was (is?) the only practical way to disable cellular in that vehicle.
Kudos to Rivian for making this a supported user privacy feature.
At Firezone we started with soft-deletes thinking it might be useful for an audit / compliance log and quickly ran into each of the problems described in this article. The real issue for us was migrations - having to maintain structure of deleted data alongside live data just didn't make sense, and undermined the point of an immutable audit trail.
We've switched to CDC using Postgres which emits into another (non-replicated) write-optimized table. The replication connection maintains a 'subject' variable to provide audit context for each INSERT/UPDATE/DELETE. So far, CDC has worked very well for us in this manner (Elixir / Postgrex).
I do think soft-deletes have their place in this world, maybe for user-facing "restore deleted" features. I don't think compliance or audit trails are the right place for them however.
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.
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.
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.
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:
Firezone's DNS-based routing is able to manage access to multiple services independently, even if they share the same IP address. So you could for example allow access to gitlab.company.com but not jira.company.com even if they were on the same webserver / loadbalancer.
It took a couple iterations to get it right - lots of fun edge cases involved. We ended up having to build automatic NAT64 and 46 for DNS resources to handle some of them. We wrote a post on how this works: https://www.firezone.dev/blog/how-dns-works-in-firezone
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.
This is a fairly common scenario and one that we had in mind when building the NAT traversal implementation. The short answer is that you wouldn't need to sign out of Firezone when in the office -- the connection should hairpin off the nearest common router and go directly to the SMB share in this case.
Ah yes, don't get me started on all the fun edge cases involved in supporting cross platform network stacks and all their subtle tunnel API differences :-)
We're trying to stay focused on keeping policies easy to define and manage so that access management is... manageable as you scale. That and the fact data doesn't go through the cloud / intermediary have been a couple of the reasons customers say they prefer us.
Two related contexts that I've found to be much more friendly for this:
1. Climbing gyms, for reasons mentioned previously
2. The sauna! Actually very ideal for convos with strangers. Max overlap time is ~15 minutes, people are generally relaxed, no phones to distract and if it doesn't go well either party can always leave.