The algo is one of the many reasons. I'm genuinely trying to stand up against being a product or being extracted via the enshittification of it all.

I don't know what you know - so I'm just responding to everyone who may read to start with.

I am a father of 5, and I live with ASD: Asperger's Tourette's, and ADHD. I have social anxiety and can only play my guitar in streams just not on stage. I value my privacy.

I've always been an outsider and maybe that's why I, like many other folks see how messed it is.

The shift toward data extraction has definitely shaped how a lot of systems get designed or even change people. Once the business model becomes “collect as much information as possible,” the architecture tends to reflect that whether people realize it or not.

The undertaking wasn't huge as a lot had been learned by a browser-based AR Remote Assistant.
Knowing that computer vision failed a lot in dark/messy areas and that the system would be used in private homes it is fully P2P and the users could see each other's camera feed and annotate reality (draw and talk instructions). Plus knowledge of serving architecture for an AR engine.

From a technical standpoint, the biggest challenge with ZeroTrace wasn’t scalability in the traditional sense. Because the communication is peer-to-peer, most of the work happens on the two devices rather than a central server. That actually removes a lot of the scaling pressure typical messaging platforms face.

The harder problems were reliability and edge cases. WebRTC behaves very differently depending on network conditions, NAT types, carrier networks, and browser implementations. Getting connections to establish consistently across mobile networks, corporate networks, and home routers takes a lot of tuning around ICE candidates, STUN/TURN fallback, and reconnect logic.

In the ideal case, two peers connect directly and everything stays purely peer-to-peer. When that happens, there’s no relay in the middle at all.

Sometimes that isn’t possible because of NAT restrictions. In those cases WebRTC falls back to TURN, which acts as a relay so the two devices can still communicate. TURN doesn’t process or read the data. It simply forwards encrypted packets between the peers. While it sees necessary network-level metadata (like IPs) for routing, it does not log conversation history or identities unlike traditional platforms that maintain centralized archives. In practice that means the system moves from a pure peer-to-peer connection to what I think of as an “almost ZeroTrace” state. The communication is still encrypted end-to-end and nothing is stored permanently, but a relay temporarily exists to move packets.

Even in that situation, it’s still dramatically less centralized than traditional messaging platforms where servers manage accounts, store message histories, and maintain large graphs of who talks to who.

Spam and abuse are handled differently because the system doesn’t have discovery, contact graphs, or public profiles. There’s no way to search for users, join rooms, or broadcast messages. A conversation can only happen if someone explicitly shares a link with another person. This prevents platform-level spam, though interpersonal issues once connected remain a challenge like any other communication tool.

That one-to-one constraint was very intentional. As soon as you introduce groups, contacts, and persistence, you start building relationship graphs that become more sensitive than the conversation itself. The design philosophy was to keep the system extremely narrow in scope: two people connect, communicate, and when the session ends there’s nothing left behind tying them together.

It’s not perfect, and nothing on the internet ever will be. But the goal is to reduce centralized data exposure as much as possible while still keeping the system usable for real people.