THRT x SecureLegion

PerkinsFund avatar
PCEF
@PerkinsFundDec 22, 2025

The Spaces explored the architecture, security model, and go-to-market of David’s decentralized secure messaging app, with Thomas probing assumptions and offering product and legal strategy. David outlined a dual-onion design with separate friend-request and messaging addresses, a three-phase handshake using a 10-digit PIN, Ed25519/X25519 keys, and ChaCha20-Poly1305 encryption, while storing encrypted contact cards locally and building a friends-only mesh to avoid centralized storage (e.g., IPFS pinning services). A long debate clarified Tor hidden service circuits (entry/middle/exit) and that David’s app runs client-only (never an exit node), still relaying via Tor for onion addressing. Operational topics included Android background limits and using VpnService to keep Tor alive, deferring iOS due to APNs, and shipping a Windows/Linux desktop app first. For hardware, David paused Samsung rooting and may base secure phones on GrapheneOS, later hardening to make a truly “own OS,” potentially bundling Thomas’s Cortex Agents to pre-scan APKs. Monetization ideas ranged from payments/swap fees to an “ads in the ping-pong protocol” overlay, with Thomas stressing legal structures (holding company owning token, nonprofit running utility) and avoiding dividend-like rev share. They covered IPFS pinning persistence, WiFi Pineapple traffic tests, a near-term Android beta (test pilot by weekend), and David’s trading platform (NinjaTrader-like for crypto perps), with Thomas offering a partner intro.

Recording Summary: Secure messaging app architecture, Tor hidden services debate, Android constraints, mesh contacts, IPFS pinning, phone strategy, monetization/legal, security testing, desktop plans, trading platform, and upcoming stream

Participants and Roles

  • Thomas: Builder of Cortex Agents and TraceX; provides security architecture critique, product/monetization ideas, and legal structuring guidance; urges pragmatic beta shipping and OS hardening; discusses IPFS pinning, token/legal compliance, and entity separation; offers introductions to potential partners; planning a Friday session and a short vacation.
  • David: Lead developer of the “Secure” app; designing Tor hidden-service-based, client-only messaging; implements dual onion addresses, a Ping-Pong protocol for reliable delivery, local encrypted contact cards, and a friends-only mesh for contact replication; navigating Android Play policy; planning phones (GrapheneOS-based) and Windows/Linux apps; explores IPFS alternatives; actively trading futures and building a C# platform for crypto perp trading; open-source codebase on GitHub.
  • UTC: Host planning a Friday stream; probes token utility and IPFS pinning implications; suggests token burn mechanics as utility.

Overview

This session centers on the architecture of a privacy messaging app (Secure), its reliance on Tor hidden services, the move away from IPFS pinning-based storage to device-local and mesh replication, Play Store constraints on background processes, and plans for secure phones using GrapheneOS. A prolonged technical debate clarifies Tor’s circuit model for hidden services. Additional topics include monetization (ads vs. commercial tier), token/legal structuring, security testing with WiFi Pineapple, desktop ports (Windows/Linux/Tails), and David’s separate futures trading platform. A Friday joint session is planned; introductions to potential partners are forthcoming.

App Architecture and Protocol Design

  • Local-first contacts and decentralization approach:

    • Initial approach used IPFS services (Pinata, then Crust). Both required paying to pin content; accounts/fees introduced central points of control.
    • Due to the cost/centralization of pinning, David pivoted to device-local storage: each device generates and stores an encrypted contact card (JSON) locally.
    • Contacts replicate through a friends-only mesh rather than a global DHT/IPFS network. Goal: remove centralized dependencies while keeping onboarding free.

  • Dual onion addressing and separation of concerns:

    • Upon account creation, the app derives a seed phrase (Solana-style) and onion addresses.
    • Two distinct onion endpoints:
      • Friend request endpoint (on one port).
      • Messaging endpoint (on a separate port).
    • Separation is intended to reduce exposure: the messaging onion is only revealed after multi-phase key exchange.

  • Multi-phase key exchange (Ping-Pong protocol):

    • Phase 1: Initiation with a basic encrypted request using a user-provided 10-digit PIN (to decrypt the initial payload and acknowledge a friend request).
    • Phase 2: Exchange of public keys and establishment of cryptographic materials.
    • Phase 3: Provision of the messaging onion address (kept undisclosed until keys are established), minimizing risk if the initial phase is observed.
    • Offline reliability: “Tap” mechanism caches ping/pong/message payloads locally when the peer is offline; when the peer appears, the sender broadcasts a silent “do I have mail?” check to resume delivery.

  • Cryptography used:

    • Message encryption: ChaCha20-Poly1305.
    • Signatures: Ed25519.
    • Key exchange: X25519.
    • Contact list replication between friends leverages HTTPS/TLS 1.3 (initial MVP scope), with end-to-end encryption layered on top for content.

Tor Hidden Services: Circuit Model and Client-Only Mode

  • Core disagreement and resolution:

    • David initially believed hidden services avoid exit nodes entirely. Thomas clarified Tor’s fundamental structure: circuits consist of an entry guard, middle relays, and an exit relay.
    • For onion service-to-client communication, both sides remain within the Tor network using separate circuits (commonly three hops for the client and three for the service), but the traffic doesn’t “exit to the clearnet.” The term “exit” still applies within Tor’s circuit model; it’s not synonymous with clearnet egress.
    • David’s code runs Tor in client-only mode (the app is never an exit or relay for others). Client-only mode means the app participates as a Tor client, relying on Tor relays; it does not make the app itself a relay or exit.

  • Practical implications:

    • Hidden service traffic “stays within Tor” (no clearnet exit), yet circuits still involve entry/middle/exit hops in Tor’s internal topology.
    • If an app uses Tor correctly (even for service-to-service), there are circuits on both sides and relays in the middle. Ensuring relay integrity is still relevant (e.g., referencing Tor’s node lists).

Android Constraints and Workarounds

  • Play Store policy change:
    • Previous design used a long-running foreground “wake” process for Tor; new policy penalizes processes running >2 hours continuously.
  • Solution:
    • Use Android’s VPNService permission/class to maintain a persistent network tunnel for Tor hidden-service connectivity, staying compliant with Play policies.

Friends-Only Mesh for Contact Replication

  • Rationale:
    • Avoid third-party pinning (cost/central control), limit blast radius, and uphold privacy by sharing only within circles the user trusts.
  • Operation:
    • Each device maintains an encrypted contact list containing friends’ public “friend-request” contact cards; lists can be imported via seed phrase to recover on new devices.
    • HTTPS/TLS is used to move encrypted contact data among friends; content remains encrypted, and future versions may expand protocol flexibility.

IPFS Pinning and Data Persistence

  • Observations:
    • Crust addresses disappeared after 3–4 days if unpinned. Pinning retains content availability by keeping it hosted/persisted by pinning services.
    • QuickNode is used by Thomas for IPFS publication with automated pinning via S3-style endpoints. If service fees lapse, providers can remove endpoints or unpin content, which impacts availability despite the peer-to-peer nature unless others keep pins.
  • On-chain storage impractical:
    • Publishing large app binaries directly on Solana is infeasible (per-message size limits and cost). IPFS remains the pragmatic peer-to-peer content layer, with on-chain proofs or references if needed.

Phone Strategy and OS Hardening

  • Current status:
    • Phones are paused until the next beta update ships (beta v7 underway; goal to finish by the weekend and push to Google Test Pilot).
    • Samsung devices (Knox) are heavily locked down; David attempted rooting via an OS vulnerability and reverse engineering but stalled after a boot issue.
  • Planned approach:
    • Prioritize Pixels and GrapheneOS as a base; add features like a “stress PIN” at the OS level to align with app behavior.
    • Ship phones with the Secure app and minimal bloat (remove ad/tracking components), focusing on delivering a usable beta and gathering feedback.
  • Open questions (Thomas’s prompts):
    • OS-level hardening specifics: Disable ADB/debug avenues, lock down build configs, and ensure recovery/support models acknowledge “true security” trade-offs (limited remote assistance).
    • Consider embedding scanning agents (e.g., Cortex Agents) to vet APKs pre-install; define policies on accepted cryptography/TLS versions, allowed OS services, and meaningful differentiation beyond vanilla GrapheneOS.

Security Testing and Traffic Analysis

  • WiFi Pineapple use cases:
    • Simulate rogue access points, test app behavior under network manipulation (e.g., loops, repeated reconnection attempts), and observe whether the hidden service listener emits traffic without inputs.
    • Validate the app’s timing-correlation mitigations by ensuring minimal unsolicited outbound activity.

Desktop and Alternative Form Factors

  • Windows app planned before iOS (constraints around Apple push-notification infrastructure).
  • Linux support considered; Tails or USB-based dual-boot scenarios discussed (pre-installed secure OS + app on USB). Note: auto-launch from USB is no longer supported, users must boot explicitly.
  • Idea: Offer secure laptops with pre-installed hardening and app; source refurbished hardware (e.g., via TechSoup) and tailor secure OS images.

Monetization, Token Utility, and Legal Structuring

  • App monetization:

    • Secure app is free; potential commercial tier for businesses.
    • Thomas proposes an innovative “protocol-level” ad model: inject an ad payload alongside Ping-Pong replies; free tier shows ads, paid tier removes them.
    • David leans toward commercial version fees and small taxes on swaps; also exploring domain/payment partnerships (e.g., .sol SNS integration) and discounts when paying with the SECURE token.

  • Token utility and compliance:

    • UTC suggests fee-based token burns as a simple, transparent utility to reduce supply.
    • Thomas explains the regulatory constraints:
      • Direct revenue sharing/dividends to token holders can trigger securities treatment; to do revshare legally typically requires a formal ICO and compliance.
      • Safer alternatives: liquidity pool-based fee distributions, burns (accounted as losses), or discounts/utilities not tied to profit-sharing.
      • Entity separation: Keep speculative assets (token) in a holding LLC; have nonprofit or separate entity run utility. Maintain contracts and paper trails; treat burns/fees in proper accounting categories.

Trading Platform and Business Structure (David)

  • Trading background:

    • Trades NASDAQ futures (NQ) on 5-minute charts, opening range breakouts after 15 minutes post-open; targets 10 points per trade with ~35-point risk, emphasizing high win rate (90% over 4 months) and short holding periods (a few minutes).
    • Uses funded-account programs (e.g., Bullex, Apex, Take Profit). Typical payout cadence: ~$1,000 per 10 days per account after thresholds; scales with multiple accounts.
    • Teaching emphasizes consistency and measurable strategy; cautions against frequent strategy switching.

  • Platform development:

    • Rebuilding a proprietary C# trading platform (originally .NET 4.8 → 8.0) inspired by NinjaTrader; aiming at crypto perpetuals with no-KYC contexts via special residency programs.
    • Corporate structuring: separate entities for IP ownership, front-facing operations, and investors; Thomas advises LLC ownership with percent-based payouts rather than jumping to a C-corp unless needed.
    • Thomas will introduce David to a well-funded party pursuing a similar platform for potential collaboration.

Project Management and Collaboration

  • Roadmap:
    • David has a public roadmap but will update and deepen it; hackathon guidance led to branching; a dev branch is good practice.
    • Codebase is open source on GitHub (~45k LOC). David plans to ship the next beta, expand testing, and then return to phones.
  • Friday stream:
    • UTC will host; Thomas and David plan to join and continue technical and product discussions.

Key Takeaways and Decisions

  • Technical decisions:

    • Move away from IPFS pinning services to device-local + friends-only mesh for contacts.
    • Use dual onion addresses (friend-request vs. messaging) with multi-phase key exchange; keep messaging onion undisclosed until keys are set.
    • Tor client-only mode with hidden services; accept that circuits use entry/middle/exit hops even without clearnet exit.
    • Android compliance via VPNService to maintain persistent Tor.

  • Product strategy:

    • Focus on shipping the beta promptly to gather feedback; phones to follow with GrapheneOS base and app pre-installed.
    • Consider Windows app next; explore secure laptops/USB dual-boot offerings.

  • Monetization/legal:

    • Free app with potential ads in the Ping-Pong protocol or commercial no-ads tier.
    • Token utility via discounts, burns, or domain/payment integrations; avoid dividend-like distributions unless formally compliant (ICO/securities handling).
    • Maintain entity separation and proper accounting for crypto-related activities.

Open Questions and Risks

  • Tor specifics:
    • Further validation of hidden service relay behavior and terminology to ensure accurate threat modeling.
  • OS hardening:
    • Define concrete hardening measures (ADB/Debug restrictions, SELinux policies, app/OS whitelisting) and support implications of “no-backdoor” security.
  • Mesh robustness:
    • Ensure friends-only mesh scales and handles churn; define rekeying, revocation, and recovery flows.
  • Play Store and iOS:
    • Monitor policy changes; decide iOS strategy despite APNs/push constraints.
  • Token/monetization:
    • Decide on ads vs. commercial tier; finalize token utility offerings consistent with compliance.
  • IPFS pinning alternatives:
    • If future features need public content-addressability, evaluate pinning strategies (self-hosting pinning nodes, multi-provider redundancy).

Near-Term Actions

  • David:

    • Ship beta update (v7), push to Test Pilot; update roadmap with deeper milestones.
    • Run WiFi Pineapple tests for traffic analysis and timing-correlation mitigation.
    • Define OS hardening plan for GrapheneOS/Pixels; select initial hardware.
    • Continue work on Windows app prototype; plan Linux/Tails options.

  • Thomas:

    • Share Tor reference materials and node-list checking approaches.
    • Connect David with prospective trading platform partners; prep for Friday stream.
    • Advance Cortex Agents/TraceX, including APK model training for future phone integration.

  • UTC:

    • Prepare Friday stream agenda focusing on architecture, Tor model clarifications, beta goals, and token utility approaches.