Updated Functionality and Usability specs (F+U of FURPS) per @fryorcraken’s feedback.
LA Circle Whistleblowing App FURPS v2
Functionality and Usability specs only.
Core Problem
LA entertainment workers face credible retaliation risk (blacklisting, loss of work, NDAs, lawsuits, harassment) when reporting abuse, unsafe working conditions, wage theft, harassment, discrimination, or other misconduct. Existing whistleblowing tools rely on centralized hosts that can be subpoenaed or de-platformed, force the publisher to pay fees (creating a paper trail), or give no long-term guarantee of discoverability.
The LA Circle Whistleblowing App allows anyone to upload a document (contract, email, video, audio, image, PDF, memo) and make it permanently discoverable, private at point of submission, and censorship-resistant, without running a centralized server, without requiring the publisher to hold tokens, and without a single point of failure.
Functionality (F)
Must-Have Features (MVP)
F1: Anonymous, content-addressed document upload. Submitter selects a file (contract, email, video, audio, image, PDF, memo) and uploads it to Logos Storage, receiving a content-addressed receipt code (CID). No account creation required, no identity binding, no uploader metadata stored or transmitted. [Satisfies LP-0017 “Upload”.]
F2: Metadata envelope capture and broadcast. Submission form captures title (used as the post’s headline/hook), long-form description, content_type (auto-detected), size_bytes (auto), timestamp (auto), and free-form tags. The envelope is published to a unique common Logos Delivery topic immediately after upload, making the document findable by any subscriber. The exact topic identifier is an implementation detail and will follow Logos Delivery content-topic conventions. [Satisfies LP-0017 “Broadcast”.]
F3: Optional on-chain anchoring, publisher-initiated. A distinct “anchor on-chain” action, separate from the upload flow, can be invoked by the publisher at any time after upload. Default is broadcast-only; allow third parties to anchor (F4). [Satisfies LP-0017 “On-chain anchoring”.]
F4: Benevolent indexer view (in-app) for batch anchoring with manual verification. The app exposes a reviewer-side view where an altruistic operator subscribes to the discovery topic, sees incoming (CID, metadata) a queue, manually reviews each for legitimacy, and selects verified entries to commit on-chain in a single batch transaction of ≥10 entries. Must be idempotent (re-submitting a registered CID does not fail a batch), must be resumable from the last successful batch after network interruption. [Satisfies LP-0017 “Batch anchor tool” plus idempotency and resumability reliability criteria; adds manual-verification]
F5: On-chain keyword-searchable metadata registry on LEZ devnet/testnet. Stores structured metadata per document (CID, keywords/tags, optional date and location fields, metadata_hash, anchor_timestamp) and is queryable by keyword, not by CID. A query such as “Harvey Weinstein” or tag-based filters return all matching CIDs with their metadata. This inverts the v1 design: the point of on-chain anchoring is to make documents discoverable, which requires keyword indexing on-chain rather than CID lookup. [Satisfies LP-0017 “On-chain registry”]
F6: Reusable document-indexing Logos Core Module. The upload → broadcast → anchor-with-keyword-metadata pipeline is extracted as a self-contained Logos Core Module with a documented API, consumable by other Logos apps independently of this Basecamp app. This is the durable engineering artifact. [Satisfies LP-0017 “Document-indexing module”.]
F7: Social-feed presentation layer (minimal MVP surface). Posts render as headline/hook → long-form description → attached evidence (downloadable). The app opens to a default “validated posts” feed and a secondary “all broadcast” view. “Validated post” is defined precisely as a post whose CID and metadata have been committed on-chain by a benevolent indexer via F4 — validation is the act of an indexer manually reviewing and anchoring the entry. The MVP feed supports basic recency and keyword filtering (the latter served by F5 queries). Submitting a new report is a primary action. Reddit-style upvote/downvote, severity filters, and “sort by controversial” mode are explicitly deferred to post-MVP (see F11). [Beyond LP-0017, but kept deliberately minimal for MVP per fryorcraken feedback.]
F8: Zero-crypto-knowledge submission path. A submitter must be able to complete a full submission without holding tokens, generating wallets, or understanding any blockchain concept. The submitter UX speaks in terms of “receipt code”, “published”, “anchored by an indexer”. Crypto-native flows surface only on the indexer/operator side (F4). [Extends LP-0017’s “no tokens required to publish” guarantee to the full submitter UX.]
F9: Upload retries with exponential back-off; delivery deduplication. Transient storage failures retry with back-off and surface a clear terminal error after retries exhaust. Re-broadcasting the same CID does not produce duplicate entries visible to subscribers. [Satisfies LP-0017 reliability requirements.]
F10: Anonymity safeguards and documented threat model. No IP, clipboard, filesystem path, crash report, or telemetry leaves the device. README documents what the app defends against (centralised host subpoena, document takedown, on-chain fee correlation, evidence tampering via content hashing) and what it does not defend against in v1 (network-layer deanonymisation, guidance points to Tor/Tails; local forensic recovery on the submitter’s machine). [Beyond LP-0017’s explicit success criteria but consistent with its “without identifying the uploader” intent.]
F11: Runs as a Logos Basecamp app with reproducible local build, downloadable assets, narrated demo. Packaged as a ui_qml Basecamp module per logos-ui-qml-builder. Standalone nix run mode supported for developer testing. Reproducible end-to-end demo script works against a real local sequencer with RISC0_DEV_MODE=0. Narrated video walkthrough shows terminal output confirming RISC0_DEV_MODE=0. [Satisfies LP-0017 Usability + Supportability deliverables.]
Usability (U)
U1: Three-click submission path for low-sophistication submitters. Pick file → optional title/description → submit. Minimal jargon; “CID” surfaced as “receipt code”. Success state unambiguous. The submitter must be able to complete a report under stress without reading documentation.
U2: Social-feed UI as the default surface. The app opens to the validated-posts feed (F7) with a keyword search box and a “submit a new report” primary action. Sort modes in MVP: recency and keyword relevance (served by F5). Controversial/upvote modes are for post-MVP.
U3: Desktop Basecamp on macOS and Linux for v1. Implemented as a ui_qml module per logos-ui-qml-builder. [Satisfies LP-0017 “Basecamp GUI” requirement.]
U4: Windows support when Basecamp supports it.
U5: Standalone nix run mode for power users and developer testing without Basecamp.
U6: Pre-submission warnings for irreversible actions. Before broadcast or anchor, the app shows a plain-language warning describing what becomes public, what stays private, and what cannot be retracted.
U7: Indexer-view UX targets technical operators. F4 assumes the operator can read CIDs, tags, and transaction hashes. Documented separately from the submitter-facing UI.
U8: English-only MVP; Spanish as near-term post-MVP priority. LA entertainment crew workforce (especially crafts, transport, production support) skews heavily Spanish-speaking. Centralised UI strings from day 1 so i18n is additive rather than a rewrite.
Open Questions & Decisions To Make
Q1: Keyword-registry schema. What fields are canonical (tags? free keywords extracted client-side? indexer-curated keywords?)? Where is extraction performed (submitter client, indexer at verification time, or both)? What is the on-chain representation? A simple inverted index, or richer structured metadata? Needs a concrete design doc before implementation.
Q2: Indexer operators on Day 1. Who runs F4 at launch? LA Circle members? Affects anchoring cadence, verification throughput, and cost coverage.
Q3: Staking slashing condition. A credible slashing rule and adjudication mechanism must be specified before staking as support/endorsement can be built.