Skip to content
Antimatter

Testing Status

Antimatter Testing & Bug Documentation

Section titled “Antimatter Testing & Bug Documentation”

This document serves as a living record of critical bugs encountered, edge cases identified, and the workarounds/solutions implemented. This ensures historical knowledge is preserved as the architecture evolves.

1. Infinite Reconnect Loop on QR Scan (PR #12)

Section titled “1. Infinite Reconnect Loop on QR Scan (PR #12)”

Issue: The Android app would enter an infinite reconnection loop immediately after scanning a pairing QR code generated by antimatter-gateway pair. The UI would continuously show “Connecting…” but the handshake would never successfully complete.

Root Cause Analysis: The problem was caused by a combination of two separate bugs in the E2EE (End-to-End Encryption) handshake protocol between the Python Gateway and the Android app:

  1. Python Gateway Missing Parameter (server.py): When the server received the AUTH_CHALLENGE from Android, it attempted to instantiate E2EESession(). However, the Python E2EESession constructor requires a role: str parameter (either "gateway" or "client"). Because it was omitted, a TypeError was raised. The handler loop caught the exception, logged it, and subsequently dropped the WebSocket connection before the handshake could finish.

  2. Android App Premature State Reset (BridgeWebSocket.kt): In BridgeWebSocket.kt, the reconnectAttempt counter was being reset to 0 inside the onOpen callback. This meant that the moment a raw TCP/WebSocket connection was established, the app considered it a success and reset the backoff counter. When the Python server immediately dropped the connection due to the TypeError described above, the Android app triggered onClosed. Since reconnectAttempt was back at 0, it tried to reconnect immediately, leading to a perpetual, infinite connection loop with no backoff limit reached.

Resolution:

  • Gateway Fix: Updated server.py to explicitly pass the required role parameter: session_e2ee = E2EESession("gateway").
  • Android Fix: Moved the reconnectAttempt = 0 reset in BridgeWebSocket.kt out of onOpen. The counter is now only reset after the E2EE AUTH_RESPONSE is successfully received and verified, ensuring that dropped connections during the handshake properly increment the exponential backoff counter and eventually timeout after 5 attempts.

2. Global Username Engineering Notes

Section titled “2. Global Username Engineering Notes”

Currently a known architectural challenge (solving Zooko’s Triangle for P2P).

The Problem: We want to allow users to connect to each other using human-readable names (e.g., connect@saif) rather than scanning QR codes or pasting long Cloudflare URLs/Public Keys. However, using a centralized registry (Web2) introduces a “supervisor” with unilateral control, while a decentralized blockchain approach (Web3/ENS) forces users to pay financial fees (gas) to register names.

Current Workarounds & Brainstorming:

  • We avoid a centralized registry to maintain the ethos of “own your keys, own your software.”
  • If we introduced a centralized mapping server, it would be vulnerable to domain squatting and would act as a central point of failure/censorship.
  • Future Directions: Exploring alternative DHT (Distributed Hash Table) mechanisms like Hyperswarm, Tor Hidden Services, or Web-of-Trust (WoT) systems that might allow mapping human-readable names to cryptographic keys natively, without financial cost.