Add inline management to the board for the connected viewer:
- On your own flyers: Edit (links to /?edit=1#<naddr>, which the main client
now honors by loading the flyer straight into the editor), Re-broadcast
(re-sends the already-signed event to all relays — no signing), and Delete
(replaceable tombstone + NIP-09, signed via the device key or NIP-07; a
pasted-nsec connection is pointed to the editor where the key is available).
- On flyers from others: Block — a per-device blocklist of author pubkeys
(voxvera_blocked_pubkeys) that always hides them, with a "Clear blocked"
control. This is roadmap #1's local blocklist direction.
The board hides tombstoned flyers (newest-version-wins so a delete can't be
undone by an older copy). New non-sortable actions column; a board delete-
confirm modal; 12 new strings × 14 languages. Adds e2e for block (hide/persist/
clear), own-vs-other actions, and board delete (tombstone + NIP-09 published),
plus a ?edit=1 deep link. 234 e2e across all six engines; docs updated.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Authors can now manage a published flyer from the editor when it's loaded from
an event (author-only — the active signing key must match the flyer's author):
- Edit: change fields and publish again; the same d-tag replaces in place.
- Re-publish (keep-alive): re-sign + re-broadcast the current content so relays
that prune app-data don't age the flyer out. Partially addresses roadmap #4.
- Delete: belt-and-suspenders across relay behaviors —
1) a replaceable TOMBSTONE (same kind+d, payload deleted:true + a ["deleted"]
tag) that overwrites the flyer's content, so the board/viewer hide it even
on relays that ignore deletions, and
2) a NIP-09 deletion request (kind 5) for the addressable a-tag + event id.
Confirmed via a modal; framed as best-effort, not a guarantee.
Tombstone recognition: the board's parseFlyers keeps the newest event per
(pubkey, d) and skips it when that newest version is a tombstone (so a delete
can't be reversed by an older copy arriving later); the viewer renders a
localized "This flyer was removed." state.
Adds the loaded-flyer actions UI + a delete-confirm modal, 11 new strings ×
14 languages, a Python schema test for the tombstone payload, and e2e for the
delete flow, board hiding, and the viewer removed state. 216 e2e across all six
engines; docs (spec/roadmap/README) updated.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Link a small inline SVG (site/favicon.svg, a red tile with a white "V") from
both index.html and board.html via a root-absolute href, so it resolves from
"/" and from "/board/" under Vercel cleanUrls. With an icon link present,
browsers stop auto-requesting (and 404ing on) /favicon.ico. No binary asset and
no external dependency, consistent with the self-contained client.
e2e asserts both pages declare the favicon and that /favicon.svg is served as
valid SVG. Closes the last code-finishable item in the roadmap's smaller list.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Add a "Shipped so far" summary (board login gate, web-of-trust filter, editor
publishing identity with PIN-encrypted nsec) and refresh the review footer:
the trust model is now implemented, so #3 (centralized client distribution) is
the highest-leverage untouched item.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Let authors publish a flyer under a stable, identifiable key when they want
one, while keeping anonymous-by-default. The editor now signs under one of
three identities, routed through activeIdentity()/signActiveEvent():
- Anonymous (default, unchanged): the per-device key, signed locally.
- NIP-07 extension: signs via window.nostr.signEvent; the secret never
enters the page.
- Imported nsec: decoded to a key used to sign. By default the secret lives
only in memory for the session. "Remember on this device" stores it
encrypted with a PIN (PBKDF2 SHA-256, 600k iterations, random salt ->
AES-GCM-256); the plaintext secret is never written to storage. On reload a
remembered key is locked until the PIN is entered; a session-only key falls
back to anonymous.
The signer pill, author npub, naddr, and poster URL all follow the active
identity. New identity controls are localized across all 14 languages.
Security note (also in docs): a short numeric PIN is brute-forceable offline
if the encrypted blob leaks, so it guards casual snooping, not a targeted
attacker — the NIP-07 path is stronger, and NIP-46 is a documented follow-up.
The minimum PIN is 4 digits but longer is allowed and encouraged.
Also updates README, the client spec (new "Publishing identity" section),
the roadmap (#1/#2 marked in progress with phases shipped), and the e2e
README. Covered by the cross-engine Playwright suite (default-anonymous,
NIP-07 connect + publish, session-only nsec without persistence, invalid
nsec, PIN encrypt -> lock on reload -> wrong/right PIN -> unlock, and forget).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Mark board moderation (#1) and authenticity (#2) as Planned and add a joint
"identity + web-of-trust on the board" direction:
- Login enables a trust-filtered view, not access control (you cannot gate
writes to public relays; you filter what the board displays).
- Keep anonymous creation + printing available; require identity only to
appear on the public board.
- Web-of-trust (NIP-02 follow graph) is the real spam defense, since keys are
free; login alone is just a soft deterrent.
- Support NIP-07 plus nsec import / NIP-46 / promoted anon key so mobile (the
scanned-QR audience) isn't locked out.
- Phased plan (identity → WoT filter → blocklist/report/NIP-05) and the two
open decisions: gate viewing or not, and which login methods at launch.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Add docs/roadmap.md capturing product/threat-model gaps that are not code
bugs, in priority order: (1) bulletin board has no moderation/abuse story,
(2) anonymous keys give no authenticity, (3) client distribution is
centralized on one domain, (4) relay permanence is overstated, (5) minimal
content-safety guardrails, plus smaller items. Each entry notes the problem,
current mitigation, why it matters, and possible directions.
Link it from the README and the spec's bulletin board section.
Co-Authored-By: Claude Opus 4.8 <[email protected]>