1 pointby dkatsura2 hours ago1 comment
  • dkatsura2 hours ago
    I built TrueLock to share content that opens only under rules, without cloud dependency or a central service.

    A capsule is one .cfcaps file containing encrypted payload + an embedded unlock policy. The recipient gets one file, and the app checks rules locally before open.

    Current rules:

    time window

    geo radius

    password

    visual key (up to 5 images)

    AND/OR logic across rules

    Windows geo can be confirmed via a phone relay (QR challenge/proof flow).

    Capsules can contain text and attachments (including media). Current clients: Android + Windows.

    Crypto in current build: AEAD (AES-GCM / ChaCha20-Poly1305) + Argon2id for passwords. Format: cross-platform capsule container.

    Threat-model boundary: This is application-layer enforcement. A fully compromised endpoint/runtime can bypass local checks or exfiltrate plaintext after legitimate open. The goal is programmable disclosure in normal environments (reduce premature/accidental access).

    I’d value technical feedback on:

    threat-model clarity

    most compelling real use case

    which trust artifact is most useful next (format spec, vectors, reproducible builds, etc.)

    Quick test: set a time window (e.g., unlock in 2 minutes), share the .cfcaps, try open before/after.

    https://truelock.pro

    • dkatsura2 hours ago
      Maker here. I’m especially interested in criticism of the threat model.

      If you try it, I’d love feedback on:

      which rule is actually useful in practice (time/geo/visual key)

      what is confusing in setup

      what would increase trust fastest (spec, vectors, reproducible builds)

      • dkatsuraan hour ago
        If useful, I can post a minimal capsule format sketch (header + policy fields) and a compact threat-model table (what it protects vs. what it does not).