Logos Circle Los Angeles

[fryorcraken]

@chair

The envelope is published to a versioned discovery topic (proposed la-circle.whistleblower.v1)

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

@chair

F5 — On-chain CID registry on LEZ devnet/testnet. Stores (CID, metadata_hash, anchor_timestamp) per document, queryable by CID

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.

@chair

dead-man-switch (timed/conditional release)

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.

@chair

F7 — Tiered evidence privacy at submission time. Per-document, the submitter chooses one of: fully public, wallet/keycard-gated, password-protected,

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

@chair

only endorsed/validated posts

Define what it means.

@chair

Reddit-style upvote/downvote, category filter, severity filter, and a “sort by controversial” mode.

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

@chair

may stake tokens

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?

@chair

F10 — Submitter-defined escalation thresholds and intended next steps.

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

@chair

F13 — Optional ZK identity / employment proof (with explicit correlation warning).

I would say something for a later version.

@chair

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.]

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