Logos Circle Los Angeles

Circles
21

Problem Statement

Local communities and neighborhoods are limited to coordinating on centralized tools like Nextdoor App and Facebook groups, which presents privacy and security concerns, limiting participation.

Proposed Solution

A a Logos and ZK powered Nextdoor app clone, with feature parity but with options for fully private and anonymous participation.

Incentives mechanisms can be explored to boost participation and increase adoption.

Target Users

Local area neighborhoods with boundary and perimeter conditions.

Winnable Issue

Lack of local level coordinated participation and communication. Currently limited completely to centralized solutions and lacking incentives or tangible community benefits.

Initial Thoughts on Feasibility

Proof of concept for user auth, proof of residency, and forum threads seems feasible.

Commented here: Build a Privacy-First Neighbourhood Engagement App (ZK Nextdoor) · Issue #22 · acid-info/contribute.logos.co · GitHub

22

Agenda for LA Work Group session Mon 12-Jan:

  1. Parallel Societies: https://ps.logos.co
  2. Review and discuss Snowflake Roles proposal from Dr. Goemon: https://forum.logos.co/t/circles-improvement-proposal-1-roles-snowflake-model/1477
  3. Review Circle PM Process Doc: https://docs.fileverse.io/0xebb75230dac435e5f8c4faaebe80e3eea910230d/5#key=WYVZmH0FUoz827a0G-kjQP9zS1xepxvMgulMOWFM6X0zOo4sElw7BG7eoEdVHugf
  4. Identifying New Winnable Issues
  5. Define FURPS specs for ZKNextdoor App:
  6. Set schedule for Winter ‘26

Notes:

https://docs.fileverse.io/0xebb75230dac435e5f8c4faaebe80e3eea910230d/15#key=xPSxCb1uBzThUE-1QGuFFR3c1XH1ErmSCSxKpcLnnHYKCzYv4I40iCEZmO69We4J

1 Like
23

Thanks for the write up! Curious to hear about the discussions around the snowflake model, what came up and how it was received :slight_smile:

1 Like
24

Work Group Recap: January 12th Session

We held our first work group of 2026 on Monday, January 12th. Attendance was light with just 3 of us, we need to do better here. That said, we made good progress on several fronts.

Snowflake Roles

We discussed the project management, technical lead, and growth roles based on @drgoemon’s snowflake roles framework Circles Improvement Proposal #1: Roles + Snowflake Model. No firm commitments yet, I want to open this up to a wider audience before we lock anything in. If you’re interested in stepping into one of these roles please reach out.

Coordination App (formerly ZK Nextdoor)

We’re moving away from the “ZK Nextdoor” framing. The more we dig into this, the more it feels like a coordination app rather than a neighborhood gossip platform. We locked in the basic FURPS requirements, I will follow up with the FURPS once I edit them a bit.

One thing we’re still thinking about: we’re not super comfortable with the “reporting on neighbors” angle. Want this to feel like a tool for community coordination, not surveillance tech.

PM Process

We reviewed the Circles PM requirements doc https://docs.fileverse.io/0xebb75230dac435e5f8c4faaebe80e3eea910230d/5#key=WYVZmH0FUoz827a0G-kjQP9zS1xepxvMgulMOWFM6X0zOo4sElw7BG7eoEdVHugf.

What’s Next

I’ll follow up with a separate post on exact dates, but the rough plan for winter 2026:

  • Networking event in early February
  • Work group session to follow

In the meantime, we push forward on the Coordination App.

25

Logos Circle [Los Angeles, February 2026]

Date: Tuesday, February 19, 2026
Location: Arts District Brewing Company, Downtown Los Angeles
Registered on Luma: 9
Attended: 8 (4 returning, 4 new)
Languages: English
Circle Steward: chair

Participants

8 attendees, a mix of developers, privacy advocates, and community builders. 4 returning members, 4 new.

Event Structure

Open-format group discussion over food and drinks at the brewery.

Topics Discussed

Homelessness in LA

  • Scale of red tape and funding required to make meaningful impact
  • Money gets absorbed by administrative overhead before reaching people in need
  • Institutions designed to help have become self-sustaining bureaucracies with incentives to manage the problem rather than solve it
  • Explored ideas around transparency tooling for tracking municipal spending and direct-aid frameworks with cryptographic auditability

Whistleblowing App

  • Big breakthrough on architectural specs
  • Time and amount threshold requirements for supporting a specific claim, leading to an escrow amount that can be used for legal consultations, legal services, and/or support for the victim.
  • Look out for follow up post with expanded idea and specs

Outcomes

  • One member volunteered for Technical Lead role
  • Two members expressed interest in Growth roles
  • Follow-up meetings to be scheduled to define roles and next steps
  • Blockchain node running work group scheduled for Friday 20-Feb
  • Whistleblowing app moves forward with clearer spec direction

What We Learned / To Improve / New Ideas

  • Open discussion format continues to work well
  • Need better real-time documentation, will assign a notetaker next time
  • Growth roles need clear scope definitions before next Circle
2 Likes
26

Thx for the report!

FYI, a participant brought an AI note taking device to my circle, tiny device that was pretty impressive, also how it registered separate people correctly and really picked up on talk around the table. Maybe one to check out. :backhand_index_pointing_right: Plaud

Thinking that something like this could be a fun gift for long running circles getting things done

3 Likes
27

The next LA Circle meetup is locked in.

Monday, April 13th | 6:00 - 9:00 PM

Roxbury Park Community Center, Beverly Hills
471 S Roxbury Dr, Beverly Hills, CA 90212

two big focuses for this session

1. Community Outreach Channels

this session is about getting specific:

- what neighborhoods are we plugged into and where are the gaps?

- what channels (physical and digital) do we need to establish to hear directly from communities about what’s broken?

- how do we move from “we should do outreach” to actually having a repeatable process for identifying issues worth fighting for?

2. Whistleblower Application — Defining the Specs

We’re going to work on defining the full FURPS spec for the whistleblowing application

The timing is good because:

- Logos testnet v0.1 is live — actual testnet tokens are available now

- the Logos scaffold repo exists — modules and tutorials are being released consistently

- the tooling has reached the point where someone can realistically start building on this stack today

We’ve talked about this application for months and now the stack is ready. We need the spec tight enough that a builder can run with it.

see you there

28

Revised core problem statement for the Whistleblowing App initiative:

Los Angeles based 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 any LA entertainment worker 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 centralised server, without requiring the publisher to hold tokens, and without a single point of failure.

Related λ Prize: lambda-prize/prizes/LP-0017.md at master · logos-co/lambda-prize · GitHub

29

Logos Circle [Los Angeles, April]

Date: 2026-04-13
Location: Roxbury Park
Registered on Luma: 9
Attended: 5
Languages: English

Participants

  • Five attendees from the greater Los Angeles area
  • Backgrounds: developers, entertainment industry adjacent contributors, and crypto/privacy focused participants
  • Areas of interest and focus
    • Whistleblower protection tooling and anonymous evidence preservation
    • Community outreach, particularly children’s tech education in underserved LA neighborhoods
    • Logos ecosystem builder tracks (Lambda prizes, RFPs) and Basecamp app development

Topics Discussed

Whistleblowing App for LA Entertainment Workers

Designing an app purpose built for entertainment industry whistleblowers (actors, dancers, production staff, set designers, etc.), with strong anonymity guarantees. The project was prompted by friends of attendees whose creative work was co-opted without compensation.

Key Points & Insights:

  • Guiding design scenario throughout the session was a “Harvey Weinstein-level perpetrator”, a well-connected, resourced, and motivated to bury legitimate reports via bot-driven noise.
  • The app should feel like a familiar social feed: headline/hook → long-form post → attached evidence, with Reddit-style upvote/downvote, category filtering, severity-level filtering, and a “sort by controversial” mode.
  • Default landing view should show only endorsed/validated posts; secondary views expose unvetted content.
  • Evidence handling needs tiered privacy options: fully public, wallet/keycard gated, password protected, or a Dead Man Switch style timed/conditional release. The Enemy of the State (the movie, with Will Smith) scenario was used as a reference, a person holding incriminating footage they need preserved and routed to the right parties without traceability.
  • Anonymous private messaging and group coordination are needed so users who resonate with a report can collaborate on action.
  • A GoFundMe style private transaction layer should support reporters in dire financial situations, with refund logic if a funding threshold isn’t met.
  • Endorsement/staking mechanism (topic from the previous meeting) was revisited: tokens/funds endorse a report, and reaching escalation thresholds unlocks next tier actions (e.g., legal consultation hours), functioning as both anti-spam signal and funding mechanism.

Challenges & Open Questions:

  • Preventing coordinated bot floods from burying legitimate reports (the Weinstein scenario).
  • Balancing near zero barrier to entry for genuine whistleblowers (ideally no tokens or crypto knowledge required) against robust anti spam protections.
  • Moderating graphic or disturbing content without introducing centralized takedown power.
  • Determining who reviews uploaded evidence and how reviewers opt in/out of exposure.
  • Categorization (NSFW gating, severity tags) without enabling censorship.
  • ZK email proofs are strongly compelling for validating employment claims, but carry correlation risk. E.G. You can prove you work for HAPPYCORP because you have an @happycorp.comhappycorp.comhappycorp.comhappycorp.com email, but would submitting proof of possession of that email expose you?

Solutions, Ideas & Proposals:

  • Work in tandem with existing Lambda Prize Whistelblowing evidence upload issue: https://github.com/logos-co/lambda-prize/blob/master/prizes/LP-0017.md
  • Build the framework first and layer the staking/endorsement mechanism in a later.
  • Submitter-defined escalation thresholds and intended next steps (e.g., “$10K endorsement → legal consultation; 30-day lifespan”).

Action Items & Next Steps:

  • Chair to document the full whistleblowing-app spec/FURPS from this session and post it to the Logos forum.
  • Chair to query about turning the spec into a Lambda prize.

Community Outreach

Identifying a local community the LA circle can form a direct relationship with, modeled on the Lisbon circle’s partnership with Quinta do Mocho, and the Zanzibar after school program funding initiative.

Key Points & Insights:

  • Youth tech education: Reference model is the Zanzibar initiative, which raised funds for Raspberry Pis and rent for a physical location for the school.
  • One members prior experience with a public education initiative (free weekly piano teaching for underprivileged kids via public library grant funding) was cited as a model for what a vetted, durable children’s program looks like.
  • The angle for LA: teach kids skills to survive in an LLM driven world, targeting gentrification affected neighborhoods.
  • Fundraising capacity is not the bottleneck, the LA circle can certainly raise a few thousand dollars. The bottleneck is identifying the right recipient.

Challenges & Open Questions:

  • Vetting is critical, perpetrators gravitate toward roles that serve vulnerable populations (kids, elderly, sick, battered women’s shelters). Partners must have track records and independent endorsement.
  • Need to identify which specific LA neighborhood and which specific program to support.

Solutions, Ideas & Proposals:

  • Prioritize existing vetted underfunded youth tech/education programs over starting from scratch.
  • Look specifically at programs that applied for public library or municipal grants and either didn’t win or are funding constrained.
  • Require someone in the network who can personally vouch before partnering.

Action Items & Next Steps:

  • All participants to research existing underfunded LA kids’ tech/education programs, especially grant applicants, after-school programs, and library-linked initiatives.
  • All participants to help identify a geographic target area.
  • The circle to conduct its own due diligence before committing to any partner.

Logos Ecosystem Status Discussion

Key Points & Insights:

  • Testnet is up and tokens are claimable.
  • Basecamp app is live and running, modules can be built and loaded, and the app image is available for people to download and run locally.
  • Blockchain, storage, messaging, and anonymous-comms foundations are all shipping.
  • Two builder tracks are currently funded: Lambda prizes and RFPs.

Challenges & Open Questions:

  • Mac install friction: there is no clean DMG path for the latest Basecamp release. New users have to scroll through dozens of pre-release pages to locate v0.1, which is a significant onboarding obstacle.

Winnable issues update

Two concrete work streams are functioning as winnable issues for this circle, and both received meaningful progress:

1. Whistleblowing app specification → Lambda prize pipeline. The session produced a substantially more detailed spec than the circle had previously. Chair is taking ownership of documenting it, posting it to the forum, and either routing it into a Lambda prize or leaving it as a clear hook for developers to pick up.

2. LA community outreach target identification. The group coalesced strongly around the youth tech education direction and defined the vetting principle and the shortlist of research angles. Blocker here is informational, the circle needs to find the right recipient organization before any fundraising or partnership work can begin.

Planned follow-up responsibilities:

  • Chair: whistleblowing spec documentation and forum posts; Mac DMG file issues; next meeting logistics.
  • Circle member: reach out to personal contacts for public library based programs.
  • All: program research and geographic target identification for the community initiative.

What We Learned / To Improve / New Ideas

What worked well:

  • The Community Center produced a notably productive session.
  • The guiding scenario method “design against a Harvey Weinstein-level adversary”; “design for the Enemy of the State evidence-custody case” kept the whistleblowing app discussion concrete.

Areas for improvement:

  • Turnout was lower than usual.

  • Several significant design decisions (endorsement/staking in v1 vs. v2, moderation model, ZK identity approach) were flagged for follow-up but not assigned individual owners beyond Chair.

New ideas and experiments to try next time:

  • New location for higher turnout.
30

Ddocs mirror: dDocs | Privacy-enhancing Alternative to Google Docs

LA Circle Whistleblowing App FURPS (Functionality + Usability 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 centralised hosts that can be subpoenaed or deplatformed, force the publisher to pay fees (creating a paper trail), or give no long term guarantee of discoverability. They also offer no native way for fellow workers and allies to find, signal boost, financially support, or coordinate around a credible report.

The LA Circle Whistleblowing App lets any LA entertainment worker upload evidence and make it permanently discoverable, censorship-resistant, and (at the submitter’s option) tiered for privacy, while also providing the social feed presentation, endorsement/funding, and coordination layers that turn isolated reports into collective action, without requiring the submitter to hold tokens, and without a single point of failure.

The app’s guiding adversary scenario is a “Harvey-Weinstein-level perpetrator”: well-connected, well-resourced, and motivated to bury legitimate reports through bot-driven noise, legal pressure, and platform capture.

Scope of this document. This is a standalone specification for the LA Circle Whistleblowing App. It is written to be read on its own, no LP-0017 prerequisite, but every requirement is annotated with its relationship to LP-0017 (“Whistleblower — censorship-resistant document upload and indexing Basecamp app”) so the reader can see at a glance where this app reuses LP-0017 deliverables, where it extends them, and where it goes beyond LP-0017’s intentional out-of-scope boundaries.

Three relationship tags are used:

  • [Satisfies LP-0017] — the requirement directly fulfills a LP-0017 success criterion or hard requirement.
  • [Extends LP-0017] — the requirement starts from a LP-0017 criterion and adds capability or constraint on top.
  • [Beyond LP-0017] — the requirement is outside LP-0017’s scope. In several cases LP-0017 explicitly excludes the area (content moderation, access control, identity binding); those are flagged inside the item.

This document accounts only for Functionality (F) and Usability (U) deliverables. The intention is to define these items first, then update for Reliability (R), Performance (P), and Supportability (S) deliverables.

Functionality (F)

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. No account creation or identity binding. [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), size_bytes (auto), timestamp (auto), free-form tags, severity level, and category. The envelope is published to a versioned discovery topic (proposed la-circle.whistleblower.v1) immediately after upload, making the document findable by any subscriber. [Satisfies LP-0017 “Broadcast” for the base envelope; [Extends LP-0017] by adding severity and category fields needed by the social-feed layer (F8) and gating layer (F15).]

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 posture is broadcast-only and let third parties batch-anchor (F4). [Satisfies LP-0017 “On-chain anchoring”.]

F4 — Permissionless batch anchor CLI. Standalone tool that any altruistic third party (NGO, journalist collective, union, guardian org) can run to subscribe to the discovery topic, accumulate (CID, metadata_hash) tuples, and commit them to the on-chain registry in a single batch transaction of at least 10 entries. Permissionless (no coordination with publisher), idempotent (re-submitting a registered CID does not fail a batch), resumable from the last successful batch after network interruption. [Satisfies LP-0017 “Batch anchor tool” plus its idempotency and resumability reliability criteria.]

F5 — On-chain CID registry on LEZ devnet/testnet. Stores (CID, metadata_hash, anchor_timestamp) per document, queryable by CID, accepts batches of ≄10. Submitter chooses LEZ-program vs. zone-SDK direct submission and documents the trust-model justification (LP-0017 hard requirement; LA Circle recommendation: LEZ program, because decentralised zone sequencers are not yet shipped and the app’s purpose is censorship resistance). [Satisfies LP-0017 “On-chain registry”.]

F6 — Reusable document-indexing Logos Core Module. The upload → broadcast → anchor 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 that survives the app itself. [Satisfies LP-0017 “Document-indexing module” — the LP-0017 “side-effect” deliverable.]

F7 — Tiered evidence privacy at submission time. Per-document, the submitter chooses one of: fully public, wallet/keycard-gated, password-protected, or dead-man-switch (timed/conditional release). Reference scenario: the Enemy of the State case — a person holding incriminating footage who needs the evidence preserved and routed to specific parties without traceability, including conditional release if they go silent. [Beyond LP-0017. LP-0017 explicitly lists “content moderation, access control, or blocklists” as out of scope at the registry/delivery layer; this app introduces submitter-controlled access scoping at the app layer, leaving the underlying registry permissionless.]

F8 — Social-feed presentation layer. Posts render as headline/hook → long-form description → attached evidence (downloadable subject to F7 gating). Reddit-style upvote/downvote, category filter, severity filter, and a “sort by controversial” mode. Default landing view shows only endorsed/validated posts; secondary views expose unvetted content. Submitting a new report is a primary action. [Beyond LP-0017. LP-0017 produces a discovery topic but no social UI — this is the visible app the LA Circle persona uses.]

F9 — Endorsement / staking mechanism. Reviewers may stake tokens or funds against a post; reaching submitter-defined escalation thresholds unlocks next-tier outcomes. Dual-purpose: anti-spam signal and funding mechanism. [Beyond LP-0017. Permissionless storage and registry remain untouched; this is an opt-in app-layer overlay.]

F10 — Submitter-defined escalation thresholds and intended next steps. At submission, the publisher specifies what endorsement should fund (e.g., “$10K endorsement → fund a legal consultation; 30-day report lifespan”) and the explicit intended outcome. [Beyond LP-0017; pairs with F9.]

F11 — GoFundMe-style private contribution layer with refund logic. Reporters in dire financial circumstances may attach a funding goal to a post. Contributions are private; if the funding threshold is not met within the stated window, contributions automatically refund. Distinct from F9 staking — F11 is direct material support to the reporter, F9 is signal/escalation. [Beyond LP-0017.]

F12 — Anonymous private messaging and group coordination. Users who resonate with a report can message the submitter and form ad-hoc coordination groups without exposing identity. Targets the case where multiple workers experiencing the same misconduct need to organise a joint response. [Beyond LP-0017. LP-0017 excludes “end-user authentication or identity binding”; F12 honours that exclusion by being pseudonymous rather than identity-bound.]

F13 — Optional ZK identity / employment proof (with explicit correlation warning). Submitter may, at their option, attach a zero-knowledge proof of employment e.g., proof of possession of an @company.com email to lend the report credibility without revealing identity. Investigate adopting an existing Logos / ZK-ecosystem project rather than building from scratch. [Beyond LP-0017; deliberately optional to preserve LP-0017’s “no identity binding” default.]

F14 — Anti-bot-flood defense. (Not sure if this one is technically sound, need feedback for good solution here). Layered approach: rate limiting on the discovery topic, severity/category quarantining, the F8 default “endorsed-only” landing view, and the F9 staking signal collectively raise the cost of burying legitimate reports under coordinated noise. Designed against the Weinstein-level adversary. [Beyond LP-0017; LP-0017’s permissionless registry intentionally provides no spam defence — this app provides defence at the presentation/endorsement layer without compromising the underlying permissionlessness.]

F15 — Reviewer opt-in/opt-out gating for graphic content. NSFW and severity tags from F2 drive client-side content gating so reviewers can opt out of exposure to disturbing content without granting any party centralised takedown power. The gating is a personal filter, not a removal action. [Beyond LP-0017; explicitly designed to honour LP-0017’s “no blocklists” boundary while still solving the moderation problem at the client level.]

F16 — 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. Crypto-native flows surface only on the reviewer/endorser/contributor side (F9, F11) where the audience already has crypto familiarity. [Extends LP-0017. LP-0017 requires the upload not depend on the publisher holding tokens; this app extends the no-tokens guarantee to the entire submitter UX, including the social-feed and dead-man-switch paths.]

F17 — 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 (retry + dedup).]

F18 — Offline submission composition with deferred upload. (This might be out of scope for MVP.) File-selection and metadata-capture UI function fully offline — a submitter on an airgapped or flight-mode machine can prepare the submission, which queues locally and transmits automatically on reconnect. Local drafts autosave with a clear on-screen warning that drafts are unencrypted at rest unless the disk is encrypted. [Beyond LP-0017 but compatible — LP-0017 sets no offline requirement.]

F19 — Anonymity safeguards and documented threat model. No IP, clipboard, filesystem path, crash report, or telemetry leaves the device. README documents what the app does defend against (centralised host subpoena, document takedown, on-chain fee correlation, evidence tampering) and what it does not defend against in v1 (network-layer deanonymisation — guidance to use 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.]

F20 — 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. [Satisfies LP-0017 Usability + Supportability deliverables: Basecamp GUI, local build, downloadable assets, demo script, narrated video walkthrough showing RISC0_DEV_MODE=0 in terminal output.]

Usability (U)

U1 — Three-click submission path for low-sophistication submitters. Pick file → optional title/description → submit. Minimal jargon — “CID” surfaced as “receipt code” or similar. Success state unambiguous. The submitter must be able to complete a report under stress without reading documentation. [Beyond LP-0017 — LP-0017 sets no UX bar; this is the app’s own anti-friction commitment, motivated by the April-13 “near-zero barrier to entry” goal.]

U2 — Social-feed UI as the default surface. The app opens to an “endorsed posts” feed with category filter, severity filter, and a search box. “Submit a new report” is a primary action button. Sort modes include relevance, recency, and “controversial” (F8). [Beyond LP-0017; the LP-0017 baseline is a Basecamp GUI for the upload flow only.]

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 if and when Basecamp supports it; otherwise deferred. [Compatible with LP-0017 — no Windows mandate either way.]

U5 — Standalone nix run mode for power users and developer testing without Basecamp. [Compatible with LP-0017.]

U6 — Pre-submission warning surfaces for irreversible actions. Before any irreversible step (broadcast, anchor, ZK-proof generation, dead-man-switch arming) the app shows a plain-language warning describing what becomes public, what stays private, and what cannot be retracted. The ZK-identity-proof warning (F13) must explicitly call out correlation risk. [Beyond LP-0017 but consistent with its anonymity intent; particularly important given F13’s correlation-risk concern raised in the April-13 session.]

Open Questions Carried Over From the April-13 Session

The following decisions remain open and are flagged here to keep them out of the requirements proper:

  • Q1. ZK identity / employment proof (F13) can we adopt an existing Logos / ZK-ecosystem project?
  • Q2. Needs economic design for Endorsement/staking (F9)

User Personas

Primary user persona: LA entertainment worker. Actors, stunt performers, background performers, musicians, composers, session players, dancers, choreographers, writers (film/TV/commercial/staff/freelance), directors, ADs, producers, line producers, UPMs, A/V crew (DPs, camera ops, sound mixers, boom ops, editors, colourists), PAs, coordinators, set designers, art department, wardrobe, hair/makeup, VFX, grip/electric, and adjacent roles (agents, managers, publicists, entertainment lawyers). Reporting motivations: harassment, wage theft, unsafe working conditions, discrimination, NDA abuse, retaliation, union-contract violations, child-safety on set.

Secondary user persona: reviewers and subscribers. LA adjacent journalists, union reps (SAG-AFTRA, WGA, IATSE, DGA, Teamsters Local 399), legal aid organisations, advocacy NGOs. Subscribe to the discovery topic, run batch anchor tooling, and operate endorsement/staking flows.

Tertiary persona: endorsers and contributors. Allies, fellow workers, advocacy orgs, the donor public, who stake tokens or contribute funds toward escalation thresholds (F9–F11). Likely have crypto familiarity.

31

I would just say “unique common topic”. This is implementation detail + wrong format for logos delivery content topics.

The point of putting the CID on chain is to discover the CID. So I don’t think makes sense to have the CID queryable from the chain.
Instead, you should have metadata on the chain (keywords, date, location). So that the data onchain can be queryable by keywords, eg “Harvey Weinstein”, and return all the CIDs (and metadata) of related documents.

Extremely hard, you probably would need some sort of network like TaCo threshold that would provide the decryption key after a timeline. I’d drop that.

I am not convinced this is useful. I’d refine the use case.

Define what it means.

Would definitely put this in a later version (eg, not part of MVP).

how do you loose your stake?

Note that only doc that are pushed onchain (pay gas) get referenced for later. So the CLI that does batch may want to only commit verified docs?

So maybe instead of a CLI, it’s a view in the app where someone can benevolently index to the blockchain, after they checked manually the legitimacy?

I would say this is a new, separate, app. Same for F11.

I would say something for a later version.

I think it’s important to realize the moderation can be done at indexing level. I don’t have a clear solution right now. Discovery via delivery will be rate limited using RLN.
Not sure about how to prevent an onchain flood yes, this will depend on the cost of going onchain

Again, would keep out of scope for MVP

2 Likes
32

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.

33

Date: 2026-05-19
Location: Arts District Brew Company DTLA
Registered on Luma: 6
Attended: 6
Languages: English

Participants

Six attendees joined this month’s Circle, all returning members from prior sessions. The group skewed strongly technical, with developers and builders dominating the table and three members arriving with laptops ready to work. Shared interests centered on hands-on engagement with the Logos stack, partnership building for the LA Circle, and exploring civic pathways for grassroots privacy and parallel-institution work in the city.

Topics Discussed

Logos Basecamp hands-on session

Partnership opportunities in LA

  • Key points & insights:

    • The group identified six LA based organizations as priority targets for partnership outreach.

      • URBAN TXT
      • 9 Dots
      • LA-Tech.org
      • A Place Called Home
      • LA Makerspace
      • TUMO Los Angeles

    • Discussion centered on framing the LA Circle’s value proposition for each organization type, and on how to keep the outreach grounded in concrete collaboration rather than abstract pitching.

    • One member volunteered to assist with making initial contact with representatives from those organizations.

  • Action items / next steps: Volunteer member to begin reaching out to representatives at the six identified organizations, will report back to the Circle on responses and next steps at the following session.

Burbank Library maker space

  • Key points & insights:

    • One member is planning to attend the upcoming Burbank city council meeting to lobby for a maker space at the new Burbank library.

    • The LA Circle is tracking the progress of this initiative to evaluate whether the Circle can play a stewarding role in the maker space once it is established.

    • The opportunity aligns with the Circle’s broader interest in grassroots civic infrastructure and parallel institutions.

  • Action items / next steps: Member to attend the Burbank city council meeting and report back; Circle to assess stewardship involvement.

What We Learned / To Improve / New Ideas

  • What worked well: The returning group created strong cohesion and made a deeper technical session viable, hands-on Basecamp format produced more concrete progress than a discussion only meetup.

  • Areas for improvement: No new attendees this session. The Circle needs to improve top-of-funnel outreach.

34

Next LA Circle event is scheduled for 23-June at a new location in Burbank!

35

Logos Circle Los Angeles, June 2026

Date: Tuesday 23-June 2026
Location: Burbank, CA
Registered on Luma: 10
Attended: 8
Languages: English

Participants

8 attendees from USA
Backgrounds: developers, system admins, artists, wholesale fruit vendor
Interests: Whistleblowing app development, Developing apps on Logos, Running Logos Nodes

Topics Discussed

  • Whistleblowing App Winnable Issue
  • RFPs and λ Prizes
    • Highlighted the RFP and λ Prize programs
  • Origins of Logos
    • Discussed the inception of Logos and its roots in the Status app
    • Gave wider context for new attendees
  • Logos Tech Stack Diagram Walkthrough
  • Node Running and the Global Uptime Leaderboard
  • Running Basecamp Modules (DOOM)

Winnable issues update

  1. Whistleblowing app: As of this posting one submission has been submitted and rejected for the #17 λ Prize issue, and one proposal has been submitted from a logos community member.

What We Learned / To Improve / New Ideas

  1. We will continue to utilize the new Burbank location for the July session.
  2. The circle must expand and grow new member attendance for the next session
  3. Looking for opportunities to present the Logos tech stack and Logos Circle to aligned local communities and meetup groups leading into the July session.
  4. Local Outreach: Need to do better here, no meaningful progress made with local organizers and communities.