mirror of
https://github.com/PR0M3TH3AN/Artstr-Studio.git
synced 2026-10-30 10:10:39 +00:00
3237a69247c2398be2c8f5eb26bf71b52bae17ca
210
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 thePR0M3TH3AN
|
3237a69247 |
PPTX import Phase 3: image + chart / table / SmartArt placeholders
Every p:pic and every p:graphicFrame on a slide now becomes an Artstr image layer pointing at the shared placeholder URL (https://i.postimg.cc/9fY3n60q/example-image-replace-me.png). No binary media is ever decoded from the .pptx package — the user replaces each placeholder with their own URL after import, which keeps imported decks Nostr-publishable out of the box and honours Artstr's "remote URLs only" image model. Pictures (p:pic): - convertPicture reads spPr/xfrm for geometry, resolves the a:blip@r:embed relationship through the slide's _rels file, and uses the original media filename (basename of the relationship Target, URL-decoded) in the layer name: "Image: image3.png". - Missing embed relationship → MISSING_IMAGE_RELATIONSHIP warning; the placeholder still lands. GraphicFrames (p:graphicFrame): - convertGraphicFrame reads xfrm directly off graphicFrame (not spPr — that's a graphicFrame quirk), then dispatches on a:graphic/a:graphicData@uri: • chart → "Chart placeholder: <name>" + UNSUPPORTED_CHART_PLACEHOLDER + placeholders.charts++ • table → "Table placeholder: <name>" + UNSUPPORTED_TABLE_PLACEHOLDER + placeholders.tables++ • diagram → "SmartArt placeholder: <name>" + UNSUPPORTED_SMART_ART_PLACEHOLDER + placeholders.smartArt++ • else → "Unknown object placeholder" + UNSUPPORTED_UNKNOWN_PLACEHOLDER + placeholders.unknown++ walkSpTree now dispatches sp / pic / graphicFrame. readSlideRels loads the per-slide _rels file into a Map<rId, {target,type}> once per slide and passes it through ctx.slideRels. Smoke-tested: - gallery_template_layout_set.pptx: slide 10's chart now appears as 'Chart placeholder: Chart 0' (image layer, postimg URL, 9.3 x 5.85 inches at 1.2, 3.08) with an UNSUPPORTED_CHART_PLACEHOLDER warning in the report. - Synthetic multi-placeholder deck (1 picture + chart + table + SmartArt) exercises every branch: Image: image1.png from rels basename; chart / table / SmartArt placeholders with the right names and counters; positions and dimensions all correct in inches. |
||
|
thePR0M3TH3AN
|
49d6697660 |
PPTX import Phase 2: text shapes + speaker notes
Two paths land together because they share paragraph/run parsing. Text shapes (p:sp with p:txBody): - _readTxBody walks a:p paragraphs and a:r / a:fld runs, joining paragraph text with \n internally then escaping + converting to <br>-joined HTML on the way out. - _readRunStyle pulls the first run's a:rPr → fontSize (sz is hundredths-of-pt → pt), bold (b), italic (i), color (a:solidFill/a:srgbClr), and explicit font family (a:latin@typeface, but skip theme placeholders like '+mj-lt'). - a:pPr@algn → Artstr alignment via PPTX_ALIGN_TO_ARTSTR map (l/ctr/r/just). First paragraph's alignment wins for the whole box. - convertTextShape emits an Artstr text layer with the dominant style applied to the whole box; xfrm provides bounds. - Shapes without explicit xfrm (text inheriting placeholder geometry from a layout / master) warn TEXT_STYLE_APPROXIMATED and skip — proper placeholder resolution is Phase 6. - walkSpTree dispatches p:sp to convertTextShape if a p:txBody child is present, otherwise to convertPresetShape. Bumps report.imported.text or .shapes accordingly. Speaker notes: - readSlideNotes(files, slidePath, slideIndex, report) reads the slide's _rels/<name>.xml.rels, finds the .../notesSlide relationship, resolves the path, and walks the notesSlide's spTree concatenating every p:sp/p:txBody's plain text. - Filters out the slide-number stamp (PowerPoint embeds the current slide number as a "1" / "2" text on the notes-slide image placeholder; matching ^\d+$ drops it). - Result goes into slide.notes, which Presenter Mode already renders. report.imported.notes counts non-empty slides. Smoke-tested against gallery_template_layout_set.pptx (16 slides): - 156 text layers imported, zero warnings. - Slide 1 title 'Gallery\\nDeck System' lands as 'Gallery<br>Deck System' at 49pt Aptos Display bold #17202a. - Subtitle EDITORIAL TEMPLATE KIT lands at 8.5pt Aptos bold #b05a44 — exact source color. - 0 notes (this template-only deck doesn't ship with notes). Synthetic deck still produces an empty deck shell with no regressions. |
||
|
thePR0M3TH3AN
|
feace5e78c |
PPTX import: fix unit conversion — layer coords go to inches, not pixels
Phase 4 was emitting layer x/y/w/h in pixel units, but Artstr's canvas system (slide / customart / deck) treats layer coordinates as *inches* — it derives the on-screen canvas size by dividing slide.width by 96 (customArtCanvasInches() at line 6813). So a shape at x=1000, w=500 was being rendered as "1000 inches from the left, 500 inches wide" — about 96x bigger than intended. Fix: introduce TARGET_W_IN / TARGET_H_IN (20 / 11.25, i.e. 1920/96 and 1080/96) and rescale EMU through those instead of TARGET_W / TARGET_H. slide.width / slide.height stay at 1920 / 1080 because that's what the engine expects in slide.width. readStroke also assumed pixel units — Math.max(1, ...) clamped strokes to "at least 1 inch" after the scale flip, which would have produced impossibly thick lines once the rest of the fix landed. Now clamps to 1/96 inch (~1 pixel) minimum. After fix, the gallery_template_layout_set.pptx full-slide backing rectangle imports at exactly 20.00 x 11.25 inches with a 0.02 inch (~2 pt) stroke, which matches the source slide dimensions. |
||
|
thePR0M3TH3AN
|
3def41b184 |
PPTX import Phase 4: basic preset shapes with fills + strokes
Walks each slide's p:cSld/p:spTree and turns every non-text-bodied
p:sp with a:prstGeom into an Artstr shape layer. After Phase 1+1.5
slides imported as colored backgrounds with no layers; after this
they come in with most of their visible design.
What landed in src/pptx-importer.js:
- PPTX_PRST_TO_ARTSTR table mapping rect, roundRect, ellipse,
triangle, line, straightConnector1, star5, hexagon, pentagon
to Artstr shape kinds. Unknown prst values fall back to rect
with an UNSUPPORTED_SHAPE_APPROXIMATED warning.
- convertColor: a:srgbClr → '#rrggbb'. Scheme / preset / system
colors return null and trigger theme-resolution warnings later.
- readFill: walks spPr for a:solidFill / a:noFill, returns an
Artstr fill descriptor. Direct-child-only lookups so a fill
nested in a:ln doesn't leak through.
- readStroke: walks spPr/a:ln for solid color + width (EMU→px via
the slide scale) + dash style. Maps the OOXML dash family to
Artstr's three states (solid / dashed / dotted).
- readXfrm: a:xfrm/a:off + a:xfrm/a:ext → {x,y,w,h} in slide-pixel
coords; a:xfrm@rot (1/60000 deg) → degrees. Skips zero-area
shapes.
- convertPresetShape: pulls the above together, names the layer
with the source p:cNvPr@name for traceability, skips shapes that
carry a p:txBody (Phase 2 will handle text shapes).
- walkSpTree: top-level walk of spTree children. p:grpSp is Phase
5; p:pic / p:graphicFrame are Phase 3.
- importPptxFile wires the walk into the per-slide loop; layer ids
use a per-import counter prefix so two imports can't collide.
Smoke-tested against the user's gallery_template_layout_set.pptx
(16 design-template slides):
- 16 slides, 16 backgrounds, 64 shape layers, 0 warnings.
- Slide 1 imports the cream backing rect + green rect + gold and
terracotta ellipses + two cream rounded rectangles, with their
exact source colors (#5e735d, #c8a658, #b05a44, etc.).
- Editor loads in deck mode with the layers visible.
Synthetic 3-slide pptx still produces white slides + 0 layers, so
no regression on the Phase 1 baseline.
|
||
|
thePR0M3TH3AN
|
32af7f0e96 |
PPTX import P1.5: slide backgrounds (direct solid fills)
Quick win on top of Phase 1: pull each slide's direct background color out of p:bg/p:bgPr/a:solidFill/a:srgbClr and set it on the Artstr slide instead of always leaving the default white. Scoped narrowly: - Direct slide backgrounds only. p:bgRef (layout/master inheritance) emits LAYOUT_INHERITANCE_PARTIAL and stays white — Phase 6. - solidFill + srgbClr only. Gradient, picture, and scheme-color fills emit THEME_COLOR_UNRESOLVED and stay white — Phase 6. - Parse failures on a per-slide basis emit SLIDE_PARSE_FAILED and fall through to white; the deck shell still imports. Counts successful backgrounds in report.imported.backgrounds so the import report can show "16 backgrounds imported". readSlideBackground is exposed via _internals for future-phase tests. Verified end-to-end against the user's gallery_template_layout_set deck (16 slides, design-template set heavy on background colors): all 16 slides now import with their actual cream / themed colors (e.g. slide 1 = #fbf8f0) instead of plain white, with zero warnings. Synthetic-pptx smoke test (no p:bg) still produces white slides. |
||
|
thePR0M3TH3AN
|
2cc2b85883 |
PPTX import Phase 1: deck-shell parser
Replace the Phase 0 "not implemented" stub with a working deck-shell
import. A .pptx file in becomes a templateMode:'deck' payload out,
one empty Artstr slide per PowerPoint slide, with no layer extraction
yet (Phase 2+ adds text, notes, images, shapes).
What landed in src/pptx-importer.js:
- readPptxPackage(file): file -> ArrayBuffer -> fflate.unzipSync ->
{ [path]: Uint8Array }. Throws on missing fflate or invalid zip.
- parseXml(xmlText): DOMParser wrapper that detects <parsererror>
and re-throws so silent malformed-doc cases don't slip through.
- pptxTargetToZipPath(basePath, target): resolves OOXML relationship
Target values against the owning part's path. Handles relative,
absolute-in-package, and ./.. segments.
- readSlideSize(presDoc): reads p:sldSz cx/cy (EMU). Falls back to
16:9 widescreen default (12192000 x 6858000) when absent.
- readSlideRefsInOrder(presDoc, presRelsDoc): walks p:sldIdLst for
canonical order, resolves each r:id through the rels file to the
actual zip path of the slide XML. Handles both getAttributeNS for
the relationships namespace and the plain "r:id" attribute form.
- readPresentationInfo(files, report): bundles size + slide refs.
Adds a LARGE_DECK warning at >100 slides.
- importPptxFile(file, report): reads the package, parses
presentation info, emits one empty deck slide per ref at 1920x1080
with #ffffff bg + ignoreDeckTheme:true. Yields to RAF every 10
slides so a 50+ slide deck doesn't lock the UI. Returns a
templateMode:'deck' payload ready for loadProjectFromText.
Internals are exposed via window.ArtstrPptxImporter._internals for
future-phase tests and harnesses.
Smoke-tested via CDP against a synthetic .pptx built in-browser with
fflate.zipSync:
- 3-slide deck imports with correct count, dims, bg, ignoreDeckTheme.
- 5-slide deck round-trips through loadProjectFromText: editor
comes up with templateMode='deck', 5 slides, body has template-deck
class (Deck Builder live).
- Garbage bytes throw a clean "invalid zip data" error instead of
silently producing a zero-slide deck.
|
||
|
thePR0M3TH3AN
|
e8e96e2a3d |
Drop orphan vault-fix scaffolding left over from Phase 0 commit
The pptx-import branch's Phase 0 commit ( |
||
|
thePR0M3TH3AN
|
8f500f50af | Merge branch 'main' into pptx-import | ||
|
thePR0M3TH3AN
|
99d83e291a |
Make purchase vault durable across devices / domains
Fix three load-bearing gaps in the premium-templates vault that together made paid unlocks invisible on any session other than the one where the purchase happened (e.g. localhost vs. artstr.org with the same login). 1) Receipt fast-path now re-derives and decrypts the payload. The soft-gate KDF is deterministic from public material + the static client pepper, so a valid kind-9735 receipt is sufficient to recover the full decrypted payload locally — no surviving vault required. Previously the fast-path only set unlocked:true without the payload, so a card could appear unlocked but Use / Fork had nothing to fork. Now it runs Premium.decryptPayload on the envelope when a receipt matches by address (or event id), stores the full payload + preview in the local cache, AND opportunistically back-fills the vault so the next device doesn't have to redo the receipt scan. 2) Vault upsert is synchronous-to-success with visible failures. The unlock success path used to fire-and-forget upsert with .catch(console.warn). If the vault publish silently failed — relay rejection, narrowed relay list, etc. — the user still saw "Unlocked ✓" while no other device would ever see the purchase. Now the unlock awaits upsert, shows a "Syncing to your purchase vault…" interim toast, and on failure replaces the success toast with a clear error explaining the unlock is device-local only. upsertPurchaseVaultItem also stops swallowing publish errors so callers see them. 3) Vault traffic uses a wider relay union. New _vaultRelayUnion() returns the user's configured relays unioned with DEFAULT_NOSTR_RELAYS (deduped). _publishVaultEvent, loadPurchaseVault, and relayFastPathUnlockCheck all use it, so vault events stay reachable when a user narrows their relay list or runs the app on a different domain. NIP-65 write relays can be folded in later by editing one helper. Smoke-tested via CDP: - _vaultRelayUnion correctly merges + dedupes user + default relays. - Receipt fast-path now finds a synthetic kind-9735 receipt by `a`, decrypts the matching premium event end-to-end, and writes a cache entry with the full original payload (title, layers, etc). - upsertPurchaseVaultItem propagates publish failures instead of returning null — callers can now react to vault sync errors. Together these mean: an existing purchase will auto-recover the next time the Premium tab loads on any browser / domain that shares the same Nostr login, just from the receipts already on relays. No re-payment, no manual vault recovery. |
||
|
thePR0M3TH3AN
|
d710b84d19 |
PPTX import Phase 0: plumbing + lazy-load shell
Sets up the import-pipeline plumbing without doing any actual PPTX
parsing yet. Acceptance criteria from the spec's Phase 0:
- Vendor fflate (0.8.2 UMD) at src/vendor/fflate.min.js so the
importer can unzip .pptx packages without a build step. fflate
exposes window.fflate via the UMD shim.
- Add src/pptx-importer.js exposing window.ArtstrPptxImporter with
PPTX_IMAGE_PLACEHOLDER_URL, makePptxImportReport, and a stub
importPptxFile that throws "not implemented yet — Phase 1 lands
the deck-shell parser." Phase 1 will fill this out.
- Wire loadScriptOnce + ensurePptxImporterLoaded in index.html.
Both fflate and pptx-importer.js are lazy-loaded on the first
click of Import PPTX so the main bundle stays lean for users
who never use this path. Subsequent clicks are no-ops.
- Add an Import PowerPoint (.pptx) button + hidden file input to
the Deck Builder's Slides fieldset, next to the existing
Import slide buttons. Click flow:
button click -> ensurePptxImporterLoaded (with a "Loading…"
label on the button while scripts arrive) -> hidden file
input click -> change -> onPptxFileChosen -> import + report.
- Add the pptxImportReportModal shell with file name, summary
counts, placeholder note, and a collapsible warnings list.
Render is driven by the report data shape defined in spec
section 13. Close on background click or Close button.
Smoke-tested via CDP: first click lazy-loads fflate +
pptx-importer; subsequent calls reuse cached promises; file
picker triggers; Phase 0 stub returns the expected
not-implemented error which surfaces as a toast.
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
1c3160ca74 |
Mobile polish for the community browser, cards, and preview pane
Adam: "Take a pass at the site and improve the overall mobile
look. Focus on the template browser and the cards and the design
previews."
Mobile-before screenshots (iPhone-14 viewport) showed three real
problems:
1. Modal-tabs row overflowed the screen edge — Search and My
Designs cut off; users couldn't reach them.
2. Type-filter chips + category + language + trust selects all
wrapped to 3-4 rows, eating ~150px of vertical space before
a single card showed.
3. Preview-pane header layout squeezed the title into a tall
narrow column on the left because the action row insisted on
filling the right.
All of these stay desktop-first; the editor itself isn't optimised
for phones (Adam: "I don't expect users to use mobile to create
designs as much as just viewing what's been created"). The new
@media (max-width: 600px) block tightens only the community-
browsing surfaces:
Modal sizing
- Cards / inner content now use min(98vw, 640px) — 2vh margins
instead of 4vh, so the modal uses the screen rather than
floating in dead space.
- Padding reduced. Close button moves a few px tighter to the
corner.
- #nostrModal .modalHeader switches to flex-direction:column so
the title sits on its own row above the actions. Fixes the
"title squished into a narrow column" symptom.
Horizontal scroll instead of wrap
- .modalTabs and .feedTypeFilter both go flex-wrap:nowrap with
overflow-x:auto. Users swipe through the tabs / chips
horizontally, which is the standard mobile gesture for crowded
nav. Thin custom scrollbar tracks.
Cards
- One column. Tighter gaps (10px).
- Thumbs cap at height:260px / max-height:60vw — without this,
a 360px-wide phone gives a 360px-tall square thumb that fills
the entire viewport with one card.
- Card-actions row gets smaller font + tighter padding so the
four buttons (▲ Preview Use/Fork ⋯) stay on one row at common
titles.
Preview pane
- Tighter padding inside the gradient stroke (10px instead of
14px) so the preview content has more room.
- Ribbon slightly smaller font on mobile to match the new
proportions.
Verified visually at 390x844 (iPhone-14): tabs scroll cleanly,
chips scroll cleanly, the Premium card fills the column with its
watermarked JPEG + corner ribbon + Unlock CTA in the right
proportions, and the preview pane stacks title-above-actions
without crushing either. Regression smoke (existing editor) still
passes at desktop widths.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
92661a11a9 |
Preview pane: gradient stroke + PREMIUM ribbon to match the feed card
The preview pane (the larger view that opens when you click a feed
card's preview) already shows the watermarked JPEG + the Unlock
CTA for premium designs, but it lacked the visual cue that made
premium cards stand out on the wall.
CSS
- #nostrPreviewPanel.premiumPreviewPane reuses the same 2px
gradient-stroke trick as .feedCardPremium: two layered
background images (solid panel + 135° yellow→magenta→cyan)
with background-clip:padding-box,border-box on a transparent
2px border. Plus the same soft outer glow.
- Dark-mode variant swaps the inner panel colour.
- New .premiumPreviewRibbon — same gradient pill as
.feedCardPremiumRibbon but slightly larger to suit the bigger
surface; positioned top:10 left:10 inside the pane.
JS
- openDesignPreview adds class premiumPreviewPane and appends
the ribbon span when row.premium is set. Removes the class
on non-premium rows so styling doesn't stick from a previous
preview.
- Ribbon text mirrors the feed card: "⚡ PREMIUM" when locked,
"⚡ UNLOCKED" when the design has been paid for / decrypted.
Tested via CDP: preview pane opened on a synthetic premium event
has classes "premiumPreviewPane", ribbon text "⚡ PREMIUM", and a
linear-gradient in the computed background-image. Screenshot
confirms the same visual treatment as the feed card.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
1ea611b44e |
Feed cards: rebuild when the author's profile arrives (so the Tip button shows)
Adam reported the ⚡ Tip button was missing from cards in the template browser even though the author had a Lightning address. Root cause: diffWallCards reuses an existing card by event id and never rebuilds it. The author's profile is fetched AFTER the template events in fetchFeedAndReactions (the enrichment step), so the first card render runs when _feedCache.profiles[author] is still undefined. makeFeedCardTipButton returns null in that case (no lud16 → no tip button). When the profile arrived later, notifyFeedProgress kicked off a rerender, but diffWallCards reused the tip-less DOM card unchanged, and the button never appeared. Fix - buildFeedCardForRow now stamps each card with a small string encoding the row's mutable view-state: profile-has-LN flag, reaction count, zap-total bucket, premium decrypted/locked state, broken-preview flag. - diffWallCards reads the stamp on the existing card and the fresh stamp on the new row. If they differ, it rebuilds the card and replaceWith() into place. Cards built through paths that don't set a stamp (legacy code paths) are reused as before — backwards-compatible. Same mechanism naturally handles other "card refreshes when…" cases that previously didn't: when zap receipts stream in (zap bucket changes), when a reaction count ticks up (rx changes), when a premium row gets unlocked (pd/pg flip), when a previously- broken image gets retried and works (b flips). Tested via CDP: card built with empty profiles cache → no tip button, stamp ln=0. Profile pushed into the cache with lud16 → rerender → stamp ln=1, card rebuilt, "⚡ Tip" button now present. The same root cause was theoretically present in the preview pane and profile page, but in practice those open AFTER the user has been on the feed for a few seconds (profiles already loaded), so this card-side fix is the user-visible one. If the preview pane ever lands first, the openDesignPreview path already reads the latest _feedCache.profiles every time, so it picks up the LN address from the next render. Co-Authored-By: Claude Opus 4.7 <[email protected]> |
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
34d5918002 |
Profile menu + Settings modal + Logout
Restructures the post-login surface so Relays / Trust / Blocked
authors / Lightning wallet live in their own modal instead of
buried at the bottom of the Community Templates browser, and adds
a Logout action that was previously missing.
Profile button → dropdown menu
- Clicking the avatar pill toggles #nostrProfileMenu with three
items: 👤 View profile, ⚙ Settings, ↩ Logout. Menu is
position:absolute under the .nostrWidget (which is already
position:fixed, so it serves as the positioning context — no
new wrappers needed).
- openProfileMenu installs a document-level click-away handler
(deferred via setTimeout(0) so the opening click doesn't
immediately close it) and an Escape handler. closeProfileMenu
tears both down.
- 👤 View profile → existing openProfilePage(myPubkey).
- ⚙ Settings → opens the new Settings modal.
- ↩ Logout → clears local Nostr identity (see below).
Settings modal (#settingsModal)
- Standard modal shell with a close × button. Four <details>
sections moved verbatim from the Community-templates browser:
Relay settings, Web-of-trust soft moderation, Blocked authors,
⚡ Lightning wallet. Same IDs, so every existing handler (the
softModEnabledToggle, walletConnectBtn, walletSyncToggle,
relayList input, the whole walletUI module) keeps working
without changes.
- Backdrop click + Escape close the modal.
Logout (nostrLogout)
- Clears state.community.myPubkey + myProfile + myFollows +
myExtendedFollows + muteListSyncedAt.
- Drops the localStorage premium-unlock cache (it's per-identity)
and resets _vaultCache so the next sign-in pulls a fresh copy.
- persistAutosave + updateNostrWidget so the UI flips back to
"Sign in with Nostr."
- Does NOT disconnect the wallet (deliberate: the wallet is
reusable across identities, and Settings → Disconnect handles
that explicitly).
- Does NOT delete the synced-wallet record on relays (deliberate:
the whole point of NWC sync is to make the next sign-in pick
it back up). User can untick "Sync this wallet" in Settings
if they want a clean slate.
- Toasts "Signed out of Nostr."
Side fixes from the move
- Removed two dead nostrRelayDetails style.display toggles in
openDesignPreview / closeNostrPreview — that element used to
live inside the Community modal, so hiding it kept the layout
tight. Now it's in Settings; toggling its display from those
spots was a bug-in-waiting (the Settings modal would render
its relay section invisible the next time someone opened it
after closing a preview).
- openUnlockConfirm's "no wallet connected" path now opens the
Settings modal + expands the wallet panel, instead of the old
"open community modal" trick.
Tested via CDP:
- Signed-in: profile pill visible, login button hidden, menu
starts closed.
- Click pill → menu opens with three items in order.
- Click Settings → modal opens, menu closes; modal contains
nostrRelayDetails, blockListDetails, walletDetails sections.
- Close × → modal hides.
- Click pill → menu opens → Logout → state.community.myPubkey
cleared, profile pill hidden, login button visible.
- Regression smoke still passes.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
8c77e547dc |
Login picker modal — NIP-07 active, NIP-46 and nsec stubbed for later
Clicking the "Sign in with Nostr" button used to call window.nostr
directly. Now it opens a small picker so users see the three signer
options Artstr plans to support, with only NIP-07 actually wired up
today.
Picker modal (#loginPickerModal)
- Three option cards stacked: Browser extension (NIP-07), Remote
signer (NIP-46), Paste private key (nsec). Each card shows icon
+ name + a one-line description of the security model.
- NIP-46 + nsec cards rendered at .55 opacity with a "Coming soon"
pill, but still clickable so the toast fires and the user knows
we noticed they tried.
- "New to Nostr? Get started at nostr.how" link at the bottom for
onboarding.
JS wiring
- openLoginPicker / closeLoginPicker — standard show/hide. Backdrop
click closes (matches the publish-confirm modal pattern).
- loginOptNip07 → closes picker + runs the existing nostrLogin().
- loginOptNip46 / loginOptNsec → toast "Coming soon" explainer.
- $('nostrLoginBtn').addEventListener('click', ...) re-routes to
openLoginPicker; old direct-nostrLogin wiring removed.
When NIP-46 and nsec ship later, the picker options just need their
disabled styling dropped and new handlers wired — the modal markup
+ open/close plumbing stay.
Tested via CDP: picker hidden by default, opens on login-button
click, NIP-07 option closes picker and calls nostrLogin, NIP-46
option fires the "Coming soon" toast and leaves nostrLogin alone.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
be8c55afc8 |
NWC sync: store wallet credential as a NIP-44 encrypted Nostr event
Adam asked: "can we make the NWC link sync across logins via an
encrypted note?" Yes — common pattern in the Nostr ecosystem
(Alby's QR-shared wallet connect, Mutiny's wallet-pubkey export,
etc.) Mirrors the same NIP-44-self-encrypted kind-30078 shape we
already use for the purchase vault.
New module
- NWC_SYNC_D_TAG = 'artstr:nwc-connection:v1'
- NWC_SYNC_PREF_KEY = 'casewrap-nwc-sync-pref' — local preference
for whether to push/pull (default ON).
- publishNwcSync(uri) — NIP-44/04-encrypts the connection string
via the existing _selfEncrypt helper, publishes kind-30078 with
d=artstr:nwc-connection:v1 + encrypted tag. Fire-and-forget;
failures don't block the local connection.
- loadSyncedNwcUri() — queries the user's relays for their own
sync event, decrypts via _selfDecrypt, returns the URI string
or null. Validates the URI prefix before returning.
- deleteSyncedNwcUri() — publishes a replacement event with no
`uri` field so subsequent loads return null. Cleaner than a
kind-5 deletion for a replaceable parameterized event.
- hydrateNwcFromSync() — runs on Nostr login; restores the
connection only if the sync pref is on AND there's no local
connection AND a synced URI exists. Toasts "Lightning wallet
restored from your Nostr account ✓" on success.
UI
- Wallet connected-state panel gains a "Sync this wallet to my
Nostr account…" checkbox with an inline disclosure of the
security model: NIP-44 encrypted to your own pubkey, only
decryptable with your nsec. Hidden when not signed in to
Nostr / no encryption support.
- Toggle ON → re-publishes the current URI to the user's
identity. Toggle OFF → deletes the synced record and clears
the pref so the next sign-in elsewhere won't auto-restore.
- handleConnect: after a successful nwc.connect, if the sync
pref is on, publishes the URI in the background; toasts on
success.
- handleDisconnect: also clears the synced copy so a sign-in on
another device doesn't immediately reconnect a wallet the
user just intentionally disconnected.
- render() reflects the toggle's current state from the pref.
Hook into login
- loadCommunityIdentity now ALSO fires hydrateNwcFromSync after
the existing vault hydrate (both background, both
non-blocking). New device → sign in → wallet restored without
pasting the NWC URI again.
Security caveats surfaced in the UI copy:
- The connection string is a wallet-spending credential. Anyone
with the user's nsec can decrypt + spend up to the wallet's
NWC budget. Same trust model as the rest of the user's Nostr
identity, but worth being explicit since this is a hot wallet.
Tested via CDP with stubbed window.nostr.nip44 (base64 round-trip)
and stubbed publishCommunityEvent / queryRelays:
- Publish creates kind-30078 with the right d-tag + encrypted
marker.
- URI round-trips through encrypt → decrypt.
- hydrateNwcFromSync calls nwc.connect with the exact URI.
- Toggle off → delete event published, subsequent load returns
null.
- Pref defaults on, persists across get/set.
- Regression smoke still passes.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
39dee5157a |
New tab: sort by recency, not by trust tier
Adam reported the latest design (a premium one) was showing up about halfway down the New tab. The New-tab sort key was: (broken) || (trust tier weight) || (createdAt desc) So a recent post from someone you don't follow ranked BELOW older posts from people you do follow. That's the right behaviour for a "Following" tab, not a "New" tab — users expect newest-first when they click New. Trust tier removed from the New-tab sort. Recency wins, with broken-preview still as the only soft demotion so a wall of missing images doesn't lead. The existing Trust dropdown on the filter row is already there for users who want to scope to follows / extended-follows; this change just stops it from being silently the dominant sort. Other tabs are unchanged: Popular still uses zap-total → reactions → trust → createdAt, Zapped uses zap-total → trust → createdAt, Premium uses createdAt → unlock-min. Co-Authored-By: Claude Opus 4.7 <[email protected]> |
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
e6588017ed |
Premium: fix three issues from Adam's testing
1) Premium designs missing from the "New" tab
isPreviewBroken was flagging every premium cover / disc / jewel /
disc-design row as broken: those modes are in MODES_REQUIRE_IMAGE,
the stub payload has no slot/disc art, so row.preview was '' →
"broken". The New tab's sort puts broken rows last, so premium
rows sank past the 24-card pagination cutoff and disappeared.
Premium rows carry their own watermarked-JPEG preview inside the
envelope and always show it on the card, so they should never
count as "broken." isPreviewBroken now short-circuits on
row.premium and returns false unconditionally.
2) Upvote button felt unresponsive
The reaction handler awaited publishToRelays before changing the
button text — on slow relays that's a few seconds of no visible
feedback, so the click looked like it did nothing. Now it
optimistically swaps to "⋯" + disables the button as soon as you
click, then either commits to "▲ N" on success or rolls back to
the original text on failure. No more "did it work?"
3) My Designs → Purchased tab loaded inconsistently
Previously force-refetched the vault from relays every time the
tab opened, blocking the render on the slowest relay in the
pool. If the fetch failed, the whole wall went to an error
placeholder. Now:
- If we have an in-memory _vaultCache from the current
session, render those cards IMMEDIATELY (sync, before the
await), then re-fetch in the background and re-render with
the latest. Feels instant in the common case where the user
just unlocked something.
- Top-of-list refresh button so the user can force a relay
re-query on demand (useful after unlocking on another
device).
- Items missing their per-item event (the split-vault
_missing flag) render at .55 opacity with a click-to-toast
explanation instead of silently failing.
- On refresh failure, keep showing the cached cards — don't
blow them away just because relays timed out — and surface
a toastError with the actual reason.
Tested via CDP:
- Premium cover row → isPreviewBroken = false ✓
- Reaction button: click → text becomes "⋯", disabled = true.
On simulated failure response → rolls back to "▲", re-enabled.
- Existing vault round-trip + hydrate + Purchased-tab regression
still passes.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
b6b189848a |
Premium: parallel pay legs + address-tolerant unlock lookup + hydrate toast
Two fixes for issues Adam hit while testing.
Speed (~20s unlock → ~10s)
- payZapSplit was paying creator first, then platform, sequentially.
Each NWC pay_invoice round-trip is 3–8 s (LNURL fetch + wallet
settle + RPC response), so the two pays dominated wall time.
- Switched to Promise.allSettled — both legs fire concurrently
over the same NWC channel. The per-leg lookup_invoice + cached
preimage logic already protects against double-pay on retry,
so the original "creator first if half fails" ordering wasn't
actually load-bearing for correctness.
- On failure: surface the right `err.stage` so the UI's
targeted-retry button still works. If both legs fail we bubble
the creator error.
- Status line says "Paying creator + platform fee…" so the user
sees one combined step instead of two.
Cache-clear unlocks restored from vault (address-tolerant matching)
- Adam reported: "I clear cache and reload, the premium design I
just paid for becomes locked again." Two causes:
1. The hydrate runs silently — no visible feedback that
anything happened, so it's invisible whether it's broken
or working.
2. The lookup was by event-id only. If the creator edit-in-
places the design, the new event id won't match the
stored unlock entry → re-locked.
- isUnlockedLocally(eventId, addressCoord) now checks the event-
id first (fast path), then scans for an entry whose `address`
matches. New helper findUnlockedEntry returns the full entry
the same way.
- buildRowsFromEvents passes premiumAddressCoord(e) so an old
vault entry under the OLD event id still unlocks a NEW event
at the same address.
- hydrateUnlockedFromVault now skip-checks BOTH event id AND
address, returns { restored, total }, and surfaces a toast on
success: "Restored N premium unlock(s) from your vault ✓".
Failures surface a toastError so the user sees what went
wrong instead of guessing.
Tested via CDP:
- Address-tolerant lookup: pre-stamp an unlock for event v1 with
address coord A. Build rows from event v2 (same A, different
id) → v2 rendered as unlocked. Build rows from event v3 with
a different address → still locked. Lookup by event id vs by
address vs neither all return the right answers.
- Existing preview-refresh E2E (which exercises the full payZap
Split + unlock + decrypt path through the parallel-pay branch)
still passes — lock CTA → Use/Fork, watermark → real preview,
reveal flash applied.
- Regression smoke still green.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
f1a147baf9 |
Premium preview now supports pixel-art mode
Adam asked: "why is 'Premium preview not supported for mode pixelart'?"
— it's because I excluded pixelart and deck from the supported-modes
dispatcher when shipping the watermarked-preview pipeline. Pixel art
has its own renderer that operates on a tiny native canvas (32–128
px on a side), so the default JPEG-export path didn't apply.
renderPixelArtToExportCanvas()
- Renders the standalone pixel-art design (state.pixelArt frame 0)
through the existing renderPixelGridToCanvas helper.
- Scales up by the largest integer multiple that keeps the long
axis ≤ PREMIUM_PREVIEW.MAX_LONG_AXIS_PX (720 px). Integer scale
+ imageSmoothingEnabled = false → pixels stay crisp instead of
blurring; 32 px → 22× → 704 px, 64 px → 11× → 704 px, etc.
- Wired into _renderModeToExportCanvas so renderPremiumPreviewDataUrl
accepts pixelart alongside cover / disc / jewel / disc-design /
customart / slide.
Tested via CDP on a synthetic 32×32 frame:
- returns ok: true, 562×562 px, 45 KB. Reads as crisp pixel art
under the diagonal "ARTSTR PREMIUM · UNLOCK TO USE" watermark
in the saved JPEG.
Deck mode still throws ("Premium preview not supported for mode
'deck'") — the multi-page deck export is a different beast. A
deck-cover thumbnail would need the deck-builder code path; left
for a future commit if creators ask.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
1bb4471cc8 |
Fix: feed rerender silently dies when autosave restores myExtendedFollows as {}
Adam reported the "All" tab in the template browser was empty even
after the fingerprint dedup fix. Root cause: JSON cannot represent
a Set, so when autosave serialises state and the user reloads,
state.community.myExtendedFollows comes back as an empty object {}.
buildRowsFromEvents calls trustTierForPubkey on every event, which
calls state.community.myExtendedFollows?.has(...) — the ?. chain
DOES NOT short-circuit on a non-null object that just doesn't have
a `.has` method, so it throws TypeError. Inside the row builder
loop the throw bubbles up through dedupByFingerprint and the
rerender exits before any cards are drawn, leaving the wall empty
with no console error the user would notice. Compounded by my
recent additions writing autosave more often (after login,
hydrate, etc.), which made the bad shape much more likely to be
present on subsequent loads.
Three defensive fixes (any one would have sufficed; all three are
cheap):
1. restoreAutosave() re-initialises state.community.myExtendedFollows
to a real Set after the autosave merge if the restored value
isn't a Set. Same for myFollows → []. fetchHop2Follows refills
myExtendedFollows on next login.
2. trustTierForPubkey() now checks `ext instanceof Set` before
calling .has, and guards myFollows behind Array.isArray. Same
idea — refuse to throw on a shape that wasn't a Set / Array.
3. The feed-tab rerender wrapper try/catches the inner render
and console.warns instead of bubbling. Without this guard, a
single throw anywhere in the row builder / dedup / sort /
diff path silently kills the whole feed and the user has no
way to see what went wrong.
Tested via CDP: stuff autosave with state.community.myExtendedFollows: {},
reload, confirm state.community.myExtendedFollows is back to a Set
and buildRowsFromEvents on a synthetic event succeeds (trust
returned as 'unknown' since the test pubkey isn't followed). Pre-
fix this test threw the TypeError shown above.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
95a7130255 |
Fix: premium events were all collapsing into one row via fingerprint dedup
Adam reported the "All" filter in the template browser was empty. The
root cause: when buildRowsFromEvents synthesises a stub payload for a
still-locked premium row (we can't see the encrypted content), the
stub has no layers / slots / canvas data — so designFingerprint
returns essentially the same string for every premium row of the
same template mode. dedupByFingerprint then collapses them all into
a single row whose title happens to come from the earliest createdAt
event. With a feed full of premium designs and no plain ones, the
"All" view looked nearly empty.
Fix: designFingerprint short-circuits and returns '' (treated by
dedupByFingerprint as "skip dedup, always keep this row") for any
payload that has `premium: true` AND no content-bearing fields
(layers / coverTemplate / discTemplate / customArt / etc). That
matches exactly the stub shape produced by
_stubPayloadFromPremiumEvent — once the user unlocks and the cached
decrypted payload replaces the stub, the row has its real fields
back and normal content-based dedup resumes.
Tested via CDP:
- 5 premium events from different creators with different d-tags
and titles → all 5 rows survive the rerender → all 5 cards
visible. Previously this would have been 1 card.
- The earlier mixed test (1 plain + 1 premium + 1 legacy) keeps
the same 2-card result (plain + legacy DO have matching
fingerprints because their plaintext is identical) — exactly
what dedup is supposed to do for non-premium events.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
c87ec907ef |
Premium: honest soft-gate copy in unlock confirm + publish ack
PREMIUM_DESIGNS_FEATURE.md §9.1 + §13.5. Two surfaces where the
honest framing was missing:
Unlock confirm dialog (buyer side)
- Added a trailing line under the price breakdown:
"Soft-gate, not strong DRM — once unlocked you can save /
export / share the design like any other Artstr file."
- The buyer sees the limitation BEFORE paying so the
expectation is set up-front: the design will be theirs to
use, and there's no client-side trick that prevents them
from re-sharing afterwards.
Publish modal ack checkbox (creator side)
- New #publishConfirmSoftGateAck checkbox inside the premium-
details panel: "I understand this is a static soft-gate,
not strong DRM. A determined buyer can extract / re-share
the design after unlocking. Artstr protects against
drive-by scraping, not piracy."
- handlePublishConfirmPublish hard-blocks the publish when
state.publish.zapGate is on and the ack isn't ticked,
routing through the existing publishConfirmError surface.
- updatePublishConfirmZapGate resets the ack to unchecked on
every modal open so creators have to re-acknowledge each
time. Inheriting a tick across publishes would defeat the
point.
Tested via CDP: ack present, initial state unchecked, Publish
without tick produces the corrective error and does NOT call the
onConfirm callback. Tick + Publish succeeds (onConfirm fires).
Regression smoke still passes.
The remaining honest-copy surfaces (publish modal toggle label,
preview-pane locked note, Premium tab hint) were already in
place from earlier steps. The wallet panel itself doesn't get
the soft-gate copy — NWC is general-purpose for tips + zaps,
and the soft-gate framing belongs where the creator is
publishing or the buyer is paying.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
68b696459e |
Vault: auto-split into per-item events when over 40 KB
PREMIUM_DESIGNS_FEATURE.md §8.6 future-mitigation. Closes the
size cap on the single-event vault: once the encrypted blob would
exceed 40 KB (chosen to give comfortable margin under the ~64 KB
content limit on the most-common relays), publish each purchase
as its own kind-30078 event and reduce the canonical vault event
to a small manifest of stubs.
Implementation
- _vaultItemDTag(addr) — sha256(addr) → base64url, prefixed
`artstr:purchase:`. Stable per address coordinate, so a
re-publish of the same vault item over-writes its event in
place. Uses window.ArtstrNoble.sha256 (already bundled).
- _vaultItemStub(item) — drops payload + previewJpegDataUrl +
receipts, keeps only address coord + title/mode/amount/
timestamp so the index stays cheap. Stubs are enough to
populate the "My Purchases" tab even before the loader has
fetched per-item events.
- _publishVaultEvent(plaintext, dTag, extraTags) — extracted
helper that NIP-44-encrypts + publishes any vault-like event
(the canonical index OR a per-item entry). Returns
{ signed, encryptedSize } so the size probe doesn't require a
second encrypt.
- _publishVault now probes the single-event size FIRST. If
under threshold it publishes as before. Otherwise it loops
over items, publishing one per-item event each
(d=artstr:purchase:<sha>, t=casewrap-purchase tag for
discovery), then publishes a small canonical index event
with `split: true` + stubs only. Console.info logs the trip.
- loadPurchaseVault detects `parsed.split === true`, computes
the expected per-item d-tag for each stub, runs one bulk
queryRelays with #d=[...] to fetch them all in one shot, and
merges each per-item payload onto its stub. Stubs whose
per-item event can't be found come back with _missing: true
so the UI can render them as unavailable without crashing
the whole list.
- VAULT_SIZE_THRESHOLD constant: 40 * 1024. One place to tune.
Tested via CDP with a stubbed window.nostr.nip44 (predictable
base64 round-trip) and publishCommunityEvent / queryRelays:
- 1 small item (28 KB encrypted) → 1 event with the canonical
d-tag, content still inline. Reload restores the item.
- Add items until total would exceed threshold → console logs
"[vault] single-vault size ... > threshold ...". Subsequent
publishes emit per-item events (3 in this fixture) PLUS the
new index (1 KB, split=true, stubs only).
- Stubs in the index contain only a / eventId / creatorPubkey /
title / mode / unlockedAt / amountSats — no payload, no
preview.
- Loader reconstructs the full items list with payload +
receipts.
- Per-item event removed → reload still returns the stub but
flagged _missing: true.
- Regression: existing purchase-vault test (single-vault path
with NIP-44 round-trip + hydrate + Purchased tab render)
still passes unchanged.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
99b386db54 |
Premium unlock: refresh preview pane in place with a reveal flash
Previously, after clicking Unlock from the preview pane, the pane
kept showing the watermarked locked version until the user closed
and re-opened it. That made the "I just bought this" moment feel
inert, and could read as "did the payment work?" friction.
Now, on a successful unlock from openUnlockConfirm:
- Check if #nostrPreviewPanel is currently showing the row we
just unlocked (it stashes the row reference on the panel).
- If so, rebuild the row from _feedCache.events so it reflects
the freshly-decrypted payload (passes skipVersionFilter so the
cache stays fresh even for legacy version fields), and call
openDesignPreview(freshRow). The pane re-paints: the action
rail's "⚡ Unlock for N sats" swaps to "Use/Fork", the
watermarked JPEG body swaps to the real renderTemplate /
renderCustomArt etc. preview DOM, and Save JSON re-enables.
- Apply a new .premiumRevealFlash class to the panel right
after the swap. Defined as a 0.55 s premiumRevealFade
keyframe that fades from opacity 0 + 0.985 scale + slight
brightness boost to fully visible — reads as "the content
just appeared" without being garish.
Failure cases stay non-blocking: a try/catch around the preview
refresh logs to console without affecting the rest of the unlock
toast or the feed rerender.
Tested via CDP: synthetic premium event in the cache, open
preview pane (locked: watermarked image + Unlock CTA),
stub payZapSplit + upsertPurchaseVaultItem + native confirm so
openUnlockConfirm runs through. After the call returns the
preview pane has Use/Fork button, no JPEG image in the body, and
the premiumRevealFlash class set.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
191d216084 |
Premium tab in template browser + gradient stroke on premium cards
UI work to make premium designs more discoverable and visually distinct from free designs. New "⚡ Premium" tab in the Browse Community Templates modal - Sits between Zapped and Search in the tab row. - Reuses the existing feedTypeFilter / category / language / trust filter row shape. - panelPremium also carries an honest hint line under the filter row: "Premium encrypted designs — pay to unlock the full editable design. Soft-gate (not strong DRM); creators get 70%, Artstr gets 30%." - _feedState + _feedPagination extended with Premium. - switchModalTab + refreshNostrBrowser both recognise the new tab and route to loadFeedTab('Premium'). - loadFeedTab rerender filters out non-premium rows on this tab and sorts newest-first (cheap unlock-min as tie-break), so the tab reads like a marketplace listing rather than a chronology of mixed events. Gradient stroke + corner ribbon on premium cards - New .feedCardPremium CSS class. Uses the background-image double-layer trick (one solid bg + one gradient on border-box) to render a 2 px gradient ring through the standard border, plus a subtle outer glow. Dark-mode variant swaps the inner panel colour. - Gradient: 135° yellow (#ffd166) → magenta (#ef476f) → cyan (#06d6a0). Reads as Lightning-themed without screaming. - New .feedCardPremiumRibbon — small pill in the thumb's top -left corner. Shows "⚡ PREMIUM" when locked, "⚡ UNLOCKED" when the row's decrypted (purchase vault / fresh unlock). - buildFeedCard applies both class and ribbon whenever row.premium is set, so the visual treatment shows up on every tab (New, Popular, Zapped, Premium, Mine) — premium designs are easy to spot in the mixed feed too. Tested via CDP with one synthetic premium event + one plain event in the feed cache: - tabPremium / panelPremium / feedWallPremium all present. - Premium tab shows only the premium event (premiumOnly check on the synthesised event id). - Card class includes feedCardPremium; ribbon reads "⚡ PREMIUM". - On the New tab BOTH cards render, premium card has the styling + ribbon, plain card doesn't. - Pagination state.Premium populated correctly. - Regression smoke (existing editor) still works. Co-Authored-By: Claude Opus 4.7 <[email protected]> |
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
3346b06b57 |
Premium step 4 — NIP-44 purchase vault + Purchased tab
PREMIUM_DESIGNS_FEATURE.md §8 + §9.4. Adds a Nostr-synced encrypted
vault of every premium design the user has unlocked, so purchases
survive localStorage.clear() and sync to any other browser / device
where the same Nostr identity signs in.
Purchase vault (`nwc`-independent — only needs NIP-07 encryption):
- VAULT_D_TAG = 'artstr:purchase-vault:v1'
- _selfEncrypt / _selfDecrypt — wrappers over window.nostr.nip44
(preferred) / nip04 (fallback), using the user's own pubkey as
both sender and recipient. Mirrors the existing private-publish
capability detection so anything that publishes private also
supports the vault.
- loadPurchaseVault({ force }) — queries the user's relays for
their own kind-30078 with #d=artstr:purchase-vault:v1, picks
the most-recent event, NIP-44 decrypts, JSON parses, caches in
memory. Empty result for users with no vault yet.
- upsertPurchaseVaultItem(item) — fetches the latest vault first
(merge-by-address coord, last-write-wins for unlockedAt, set
union for receipts so we never drop a payment proof), then
re-publishes the encrypted vault as a single kind-30078 event.
Runs in the background after unlock; failures log and don't
block the toast.
- hydrateUnlockedFromVault() — on every Nostr login, pulls the
vault and writes each item into the local UNLOCK_CACHE_KEY so
the feed-card gate just works without a separate vault-vs-
cache check.
Wired into the unlock flow
- openUnlockConfirm: after a successful payZapSplit + decrypt,
calls upsertPurchaseVaultItem with a fully-populated item:
address coord, event id, creator pubkey, title, mode, unlock
timestamp, total + per-leg sat amounts, both preimages, the
cached watermarked preview JPEG, AND the decrypted payload.
Stored payload means the buyer can re-open the design even if
the original kind-30078 event later disappears from relays.
- Wired into loadCommunityIdentity (the post-login fan-out) so
a fresh browser instantly populates from the vault before the
user goes near the feed.
"⚡ Purchased" sub-filter in My Designs
- New feedTypeBtn with data-type='purchased' added to the Mine
panel's filter row. The existing click handler that calls
loadMyDesigns() picks it up.
- loadMyDesigns: branches to loadPurchasedDesignsIntoWall when
the filter is 'purchased' — skips the user-published-events
query entirely.
- loadPurchasedDesignsIntoWall: refreshes the vault, builds a
synthetic row per item via _rowFromVaultItem, renders through
the existing buildFeedCard pipeline so the cards look exactly
like the rest of the feed. Use/Fork on a vault row imports the
cached decrypted payload directly (no re-fetch, no re-derive).
- Friendly empty-state for users with no purchases; honest
error if the user's extension has no encryption support.
Tested via CDP with a stubbed window.nostr.nip44 (base64 sham for
predictable round-trip) and stubbed queryRelays / publishCommunityEvent:
- Empty initial vault returns { v:1, updatedAt:0, items:[] }.
- upsertPurchaseVaultItem publishes a kind-30078 with the right
d-tag and `encrypted` marker; the cipher round-trips back to
an item list with the title, payload, and BOTH receipts.
- Re-loading the vault from the cached published event
rebuilds the same item.
- Hydration writes the item's event id into
UNLOCK_CACHE_KEY so isUnlockedLocally returns true for it.
- loadPurchasedDesignsIntoWall renders one feed card from the
vault item.
- Regression: existing editor + premium publish + premium
consume E2E tests still pass.
Trade-off notes for future work
- The whole vault lives in one event today, so size scales
linearly with purchases. Each item includes the watermarked
preview JPEG (~20-30 KB) + the decrypted payload (typically
small). Once a vault approaches relay limits we'll switch to
per-purchase entries with d=artstr:purchase:<sha256(a)> per
§8.6 future-mitigation.
- The soft-gate key is derivable from public material, so we
don't bother storing the wrapped key per item — storing the
payload directly is both simpler and survives event deletion
on relays. Spec §8.3 calls for wrapped-key storage; that
becomes meaningful only when v2 secure-gate (creator-issued
keys) lands.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
2aed156912 |
Premium step 3 — encrypted publish + premium consume
PREMIUM_DESIGNS_FEATURE.md §19 item 3 + the consumer changes needed
to actually display, gate, and decrypt the new event shape. Closes
the architectural gap that Adam called out in testing: premium
templates were being published with the design payload in plaintext
on relays, with only a client-side tag asking nicely not to import.
Publish side
- _publishPremiumDesign(payload, mode, typeTag) — new helper that
runs when state.publish.zapGate && visibility === 'public'.
Steps: render the watermarked preview (bails with a precise
error if the design is too large or has CORS images), pick a
`premium:<mode>:<base>` d-tag (or reuse state.editingDTag on
edit-in-place), encrypt the payload via Premium.encryptPayload
with the event coordinate as AAD, embed the preview JPEG in
envelope.preview, then publish a single kind-30078 event with
the §5.1 tag set (premium / premium-mode=softgate-v1 /
softgate-epoch / encrypted / zap-gate / zap-min / zap-split /
two `zap` tags with weights from PLATFORM_FEE_BPS / discovery
tags / etc.).
- publishCurrentTemplateToNostr branches into the premium path
before the existing public path, after the private path. The
label in the publish toast says "Premium" so the user knows
which path ran.
- getTemplateTags no longer emits zap-gate / zap-min from
state.publish — that tag set is owned by the premium publish
helper now, so non-premium publishes don't accidentally tag.
Consume side
- isPremiumEvent(event), getPremiumEnvelope(event),
premiumEventDTag, premiumAddressCoord, premiumEventMode,
parsePremiumZapSplits — pure tag/content readers.
- _stubPayloadFromPremiumEvent — synthesises a payload shape from
public tags (title / category / language / mode) so the existing
feed-card readers don't choke on a locked row whose real
payload is encrypted.
- buildRowsFromEvents: detects premium events; if the user has
already unlocked (cached payload in UNLOCK_CACHE_KEY) we use
the real decrypted payload, otherwise the stub. Annotates the
row with row.premium = { envelope, previewJpegDataUrl,
decrypted, address, dTag } AND row.zapGate so the existing
lock-CTA logic keeps working.
- Older tag-only events (zap-gate=true with no `premium` tag) are
still surfaced as locked, but they're now a "delete + republish"
nag — their plaintext payload is already on relays.
- buildFeedCard miniPreviewWrap: for locked premium rows, renders
the watermarked JPEG from envelope.preview.dataUrl as an <img>
instead of trying to renderTemplatePreviewDOM on the stub
payload. fitMiniPreview is skipped (image fits via CSS).
- openDesignPreview (the preview pane): same gate. The preview
body shows the watermarked JPEG + an honest "Soft-gate, not
strong DRM" note. The Use/Fork button is replaced with a
"⚡ Unlock for N sats" CTA that runs the existing
openUnlockConfirm flow. The Save JSON button is disabled with a
"Locked — pay to unlock the design data" tooltip. (Previously
Save JSON downloaded the full payload — a flat bypass.)
Unlock decryption
- openUnlockConfirm: after payZapSplit succeeds, if the row is
premium, call Premium.decryptPayload with the row's envelope +
coord. Cache the decrypted payload in markUnlocked alongside
creator/platform preimages + the address coord. If decrypt
fails after a successful payment (epoch mismatch, corrupted
envelope), the payment proof is still cached so the user
doesn't re-pay; the message asks them to refresh.
- Once decrypted is in the cache, buildRowsFromEvents picks it
up on the next rerender and the row's Use/Fork / Save JSON
work normally (the existing import path reads row.payload).
Receipt fast-path by address
- relayFastPathUnlockCheck now takes full events (not just ids).
It runs two relay queries in parallel: kind-9735 with #a for
premium events (address-coord scope so edit-in-place doesn't
invalidate prior purchases — §13.2), and kind-9735 with #e for
legacy tag-only events. Marks unlocked off whichever matches.
- The call site in fetchFeedAndReactions now filters the
template events to (premium || zap-gated) and passes them in
full.
Copy
- Publish modal toggle: "Premium encrypted — viewers see a
watermarked preview and must zap to unlock the full design.
Soft-gate, not strong DRM — once unlocked, buyers can still
export or share." Reflects the spec's §13.5 honesty rule.
Tested via CDP with a stubbed publishCommunityEvent:
- All 17 spec §5.1 tags emitted in the right shapes including
the two `zap` split tags with weights pulled from
PLATFORM_FEE_BPS (70 / 30).
- Envelope has aes-256-gcm + IV + salt + ciphertext + softgate
metadata + embedded preview (~18 KB for a 1920x1080
customart).
- Direct string search against the serialized envelope for the
layer text "Locked!" and color hex "7c3aed" → not present.
Plaintext does NOT leak through the envelope.
- buildRowsFromEvents on the captured event produces a row with
row.premium.decrypted = false, full address coord, mode and
title derived from public tags.
- Premium.decryptPayload(envelope, coord) returns the exact
original payload via deep-equal JSON comparison.
- Regression smoke (existing editor + soft-gate self-test) still
passes.
Next step is the buyer-side purchase vault (§8) — NIP-44 self-
encrypted kind-30078 vault so unlocked keys sync across browsers /
devices, and the "My Purchases" tab in the Nostr modal.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
713ffefe83 |
Premium step 2 — watermarked preview pipeline
PREMIUM_DESIGNS_FEATURE.md §5.4 + §19 item 2. Renders the current
artboard as a low-res, watermarked JPEG suitable for embedding in
the premium publish event so buyers can see what they'd be paying
for. Budget-bounded so the event still fits in standard relay
limits after the encrypted blob is also added.
renderPremiumPreviewDataUrl()
- Picks an export DPI from the artboard's long-axis inches so the
initial render lands close to the 720 px cap (no wasted huge
rasterize for a 20-inch custom art canvas, no upscaling-from-
tiny for a 4.7-inch disc design).
- Re-uses the existing render*ToExportCanvas() helpers under a
new _renderModeToExportCanvas dispatcher so we don't duplicate
the per-mode draw logic.
- Downscales the result into a target-size canvas (max 720 px long
axis), draws the watermark, JPEG-encodes at quality 0.65.
- Budget loop: if the data URL exceeds 50 KB, shrinks long-axis by
22% and re-tiles + re-encodes (the same source canvas is reused;
no extra rasterize). Caps at 4 attempts down to a 360 px floor;
throws a precise "preview is too large" error otherwise so the
publish modal can tell the creator to simplify.
- Pre-checks _exportFailedImages so a CORS-tainted artboard fails
fast with a clear message instead of producing a broken preview.
_drawPremiumWatermark()
- Tiles "ARTSTR PREMIUM · UNLOCK TO USE" across the entire image
at -18°. Uses ctx.measureText so the horizontal step is the
actual rendered text width + a comfortable gap — adjacent
copies never overlap and the text is always readable. Rows
stagger by half a step so the pattern doesn't read as a strict
grid. White stroke at 45% opacity under a slate fill at 26%
so it reads on both light and dark designs.
PREMIUM_PREVIEW constants
- MAX_LONG_AXIS_PX = 720, QUALITY = 0.65, MAX_BYTES = 50*1024,
MIN_LONG_AXIS_PX = 360. Tunable in one place.
Restricted to modes the JPEG export already supports (cover, disc
sheet, jewel, disc design, customart, slide). Deck + standalone
pixel art remain out-of-scope for v1 premium publishing — they can
be added later when their own export paths grow a watermark hook.
Tested via CDP on three real artboards:
- Custom art 1920×1080 with color + rich text → 720×405 px,
20 KB. Watermark reads cleanly across the whole image.
- Cover (DVD presets, three colored slots + a title) → 718×488
px, 25 KB. Title still visible under the watermark.
- Disc design (small circular artboard) → 301×301 px, 12 KB.
Centre label readable.
- Stress: 4096×4096 custom art with 40 random color rects →
720×720 px, 40 KB. Under budget without needing a retry.
- Regression: soft-gate self-test and existing editor still work.
No publish/feed code touches this yet. Next step (§19 item 3) is
the premium publish event — encrypted envelope + new tag set +
embedded watermarked preview.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
a8c855fc5c |
Premium step 1 — soft-gate crypto primitive
First piece of PREMIUM_DESIGNS_FEATURE.md §6. Adds the static
client-side decryption layer for premium designs: HKDF-SHA256 over
an obfuscated per-epoch pepper + a per-design public salt, then
AES-256-GCM with the event coordinate as additional-authenticated-
data so ciphertext can't be copy-pasted to a different event.
noble bundle
- Add @noble/hashes/hkdf to the bundle entry; expose as
window.ArtstrNoble.hkdf and .hmac. Bundle size 14.0 KB → 16.5 KB.
Premium IIFE (new section in index.html)
- _softGatePepperParts — per-epoch lookup of 4x8-byte fragments
("palette seed I..IV"). For epoch 2026-05. Sub-strings don't
look like a "premium key"; reconstruction concats at use time.
Comment explicitly calls this obfuscation, not security, per
PREMIUM_DESIGNS_FEATURE.md §2 / §6.3.
- SUPPORTED_EPOCHS / CURRENT_EPOCH — adding a future epoch is
one entry in the parts table.
- pepperBytesForEpoch(epoch) — reconstructs the 32-byte pepper.
- deriveKey({ epoch, creatorPubkey, premiumAddress, schemaVersion,
publicDesignSalt, puzzleNonce }) -> 32 bytes via HKDF-SHA256
with the pepper as IKM, salt = publicDesignSalt, info =
"artstr-softgate-v1|<epoch>|<creator>|<addr>|v<schema>" (and an
optional "|p<nonce>" for the §6.7 CPU-puzzle hook).
- encodeAad(creatorPubkey, dTag) -> UTF-8 of
"30078:<creator>:<dTag>" so AES-GCM authenticates the
coordinate.
- encryptPayload(payloadObj, coord, { epoch? }) — random
32-byte salt + 12-byte IV; returns the spec §5.2 envelope
(base64 fields, softgate metadata, etc.).
- decryptPayload(envelope, coord) — reverses the above.
- Self-test runs on every load: round-trip a known payload AND
verify AAD/creator/schema mismatches all reject the decrypt
(event-coordinate binding). Single console.warn on failure.
Tested via CDP — all green:
- Round-trip with random keypair: ok
- AAD mismatch (different dTag) -> AES-GCM rejects: ok
- Creator pubkey mismatch -> KDF info changes -> rejects: ok
- Schema version mismatch -> KDF info changes -> rejects: ok
- KDF deterministic with identical inputs: ok
- Output length = 32 bytes (AES-256): ok
- Pepper reconstruction = 32 bytes: ok
- Envelope size for tiny payload = 577 bytes; ~63 KB headroom
under typical relay limits, plenty for an embedded preview
JPEG in step 2.
- Regression: NWC crypto self-test still passes; existing editor
still loads and renders layers.
Code only; nothing in the publish/feed flow uses this yet. Next
step (PREMIUM_DESIGNS_FEATURE.md §19 item 2) is the watermarked
preview pipeline.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
4e7ec76817 |
Lightning tips: pay in-app via NWC when a wallet is connected
Adam pointed out the tip flow still showed the bolt11 / QR view even when the user had a NIP-47 wallet set up. That re-introduces the exact wallet-handoff friction the NWC integration is meant to solve. Changes to the existing LNURL tip flow: - openTipModal sets the action button to "⚡ Send tip" when nwc.isConnected(), and to the original "Get invoice" otherwise. - getTipInvoiceFlow, after fetching the bolt11, tries nwc.payInvoice() FIRST when a wallet is connected. On success: toast "Sent N sats ⚡" + close modal. On failure (preimage missing, wallet error, budget exhausted, etc.): falls through to the existing showTipInvoiceView so the user can still pay the bolt11 externally with the visible error inline. - Button label restoration uses the same dynamic source so post- error retry shows the correct (state-appropriate) label. Pre-flight gates (amount validation, LNURL meta fetch, zap path construction) are unchanged — NIP-57 zap tagging still wraps the LNURL request so the recipient still sees a tracked kind-9735 receipt; the only difference is who pays the bolt11. Verified via CDP: button label flips between "Get invoice" and "⚡ Send tip" with nwc.isConnected() state. Co-Authored-By: Claude Opus 4.7 <[email protected]> |
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
c6955cd2ad |
Phase 3 — zap-gated templates UI
The publish flow now lets a creator tag a kind-30078 event as premium with a sat minimum, and the feed swaps the Use/Fork button for a "⚡ Unlock for N sats" CTA that drives the dual-zap split orchestrator from Phase 2. Publish side: - state.publish = { zapGate, zapMin } added to the editor state so autosave persists the user's last choice. - getTemplateTags() emits `zap-gate=true` + `zap-min=<sats>` tags when state.publish.zapGate is on. Encrypted (private) designs cannot be gated — they're not feed-listed, so the tags are deliberately suppressed. - publish-confirm modal grows a "Premium template" checkbox + a minimum-sats input. An inline note recomputes the creator/ platform split from the current input and the PLATFORM_FEE_BPS constant on every keystroke. Toggling Private hides the whole premium section. - Two blocking pre-publish checks: (a) creator's kind-0 must carry a lud16 or lud06 — corrective inline error + a hard stop in handlePublishConfirmPublish; (b) the chosen zap-min must split to ≥1 sat creator share. Consumer side: - isZapGated(event) / getZapMin(event) — pure tag readers. - buildRowsFromEvents annotates rows with `row.zapGate = { gated, min, unlocked }` so downstream code can branch cheaply. - buildFeedCard swaps "Use/Fork" for "⚡ Unlock for N sats" when `row.zapGate.gated && !row.zapGate.unlocked`, with a tooltip that names the platform-fee share. Preview button + whole-card click still open the design preview (the gate is on importing, not on looking). - openUnlockConfirm(row) — wallet/login checks, confirm() with the split shown, runs payZapSplit with a live status toast, marks unlocked, refreshes the feed. - localStorage cache UNLOCK_CACHE_KEY ('casewrap-unlocked-templates') with markUnlocked / isUnlockedLocally / getAllUnlocked. markUnlocked also drops any matching card DOM so diffWallCards rebuilds it on next rerender — without this, the optimistic same-id reuse kept the lock button on screen after payment. Relay fast-path: - relayFastPathUnlockCheck(gatedEventIds) — kind-9735 query with `#e=[gatedIds]` + `#P=[myPubkey]`. Any matching receipt = the user already paid, so we mark unlocked locally without a re-pay. Wired into fetchFeedAndReactions right after template fetch so a cache wipe / new device picks up existing unlocks for free. Tested via CDP (synthetic events; live e2e is Phase 4): - isZapGated tag detection (true/false/missing). - getZapMin parses the value. - markUnlocked / isUnlockedLocally round-trip. - getTemplateTags emits zap-gate + zap-min when on/public, omits when private. - Feed renders the gated event with "⚡ Unlock for 150 sats" button when locked; after markUnlocked + rerender, switches back to "Use/Fork". - Publish modal: Premium toggle expands the details panel; split note matches platform.splitZapAmount math; lud16-missing surfaces the corrective inline error. - Regression smoke: custom-art editor + render still work. Co-Authored-By: Claude Opus 4.7 <[email protected]> |
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
d22089c3e5 |
Phase 2 — platform-fee plumbing + dual-zap orchestrator
Adds the platform constants, the npub → lud16 lookup, the split math,
the partial-unlock localStorage cache, and payZapSplit — the
orchestrator that drives a creator/platform dual-zap through the NWC
client added in Phase 1.
`platform` IIFE:
- PLATFORM_NPUB hard-coded; PLATFORM_FEE_BPS = 3000 (30%). Single
constants so the fee is a one-line change later.
- getPubkeyHex() — decodes the npub once, caches the hex result.
- resolveLud16() — lazily fetches the platform's kind-0 from the
user's relays (with a 4.5s timeout), picks the most-recent profile
that has a Lightning address, caches for the session. Falls back
to lud06 → bech32-decoded lud16 string if lud16 is missing.
- resolveLnurlMeta() — pulls the LNURL payRequest metadata so we
can validate minSendable before fetching a real invoice.
- splitZapAmount(total, bps) — platform takes floor((total*bps)/
10000); creator gets the remainder so the legs always sum to
`total`. Defends against tiny amounts (negative, zero, 1-3 sats
where the platform share floors to zero).
Partial-unlock cache (PARTIAL_UNLOCK_KEY = 'casewrap-partial-unlocks'):
- Shape: { [eventId]: { creator?: { signedReq, bolt11, preimage? },
platform?: { ... }, startedAt } }
- Tiny helpers (getAll / get / save / clear) — Phase 4 will wire the
cross-session resume banner on top of this.
payZapSplit({ creatorPubkey, creatorMetadata, eventId, totalSats,
onStatus }) — the core orchestrator:
1. Resolve creator + platform LNURL metadata in parallel.
2. Validate minSendable on BOTH sides; refuse with a precise error
if either LSP won't accept the split share.
3. Build + sign both kind-9734 zap requests via Promise.all on
window.nostr.signEvent — the user sees two prompts back-to-back
rather than minutes apart.
4. Fetch both bolt11s in parallel.
5. Pay creator FIRST, then platform (sequential, so a half-failure
at least pays the creator and the user only retries the platform
leg).
6. Before each pay, run nwc.lookupInvoice(bolt11) — if the wallet
already settled it (idempotent retry across sessions), reuse the
preimage instead of double-paying.
7. Persist progress to PARTIAL_UNLOCK_KEY after every step; clear
only when both preimages are in hand.
8. Mark unlocked on preimage return — the preimage IS proof of
payment (it hashes to the bolt11's payment hash). Kind-9735
receipt arrival is async verification picked up via the existing
feed-load zap fetcher.
9. Throws with `err.stage = 'creator' | 'platform'` so the UI can
show a targeted retry button.
Tested via CDP:
- Constants + module shape ✓
- npub → hex pubkey: a4a6b5849b... (correct decode of PLATFORM_NPUB)
- Split math: 9 cases, including 100→70/30, 101→71/30 (rounding),
1-3 sats (creator wins ambiguity), and negative/zero edge cases.
- Partial-unlock cache round-trip ✓
- Live resolve against real relays: platform npub → adammalin@
strike.me → Strike LNURL endpoint, minSendable=1000 msats,
allowsNostr=true. So zaps to the platform will actually settle
AND issue kind-9735 receipts. (Receipt subscription continues to
happen via the existing feed-load fetchZapsForEvents path; no
new background sub needed for v1 auditability.)
The live `payZapSplit` end-to-end with a real CoinOS source wallet
runs in Phase 4 E2E.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
c3d280c0be |
Phase 1 — NWC client + wallet settings UI
The NIP-47 client (RPC over a relay-backed WebSocket) plus the
Settings-panel UX for pasting / managing a Lightning wallet
connection. Both required for the zap-gated unlock flow that lands
later in this arc.
NWC client (`nwc` IIFE):
- parseNwcUri: handles `nostr+walletconnect://` and the
`nostrwalletconnect://` alt scheme; multiple `relay` params;
URL-encoded secrets; optional `lud16` param. Returns null on
any malformed input.
- connect: opens a WS to the first relay, subscribes to
`{kinds:[23195], '#p':[clientPubkey]}` for responses and
`{kinds:[13194], authors:[servicePubkey]}` for the wallet's
capability info, then fires a `get_info` request to fetch the
alias / node pubkey. Persists creds + capabilities + last-test
timestamp under `casewrap-nwc-connection`.
- payInvoice / lookupInvoice / getInfoFresh: RPC helpers built on
a generic `_request(method, params, opts)` that NIP-04-encrypts
the JSON payload to the wallet service pubkey, signs the kind-
23194 event with the NWC secret (NOT the user's identity key),
publishes it, and resolves with the decrypted response via the
`e`-tag correlation. Default 25s timeout, configurable per call.
- Persistent listener registry (`nwc.on(fn)`) for UI re-renders on
any state transition (connect, disconnect, response decrypted,
capability list arrived, WS closed).
- Lazy reconnect: WS closed → next `_request` reopens; in-flight
promises are rejected so the caller can surface a real error.
Wallet settings UI (`walletUI` IIFE) — new <details> panel inside
the Nostr modal:
- Disconnected: CoinOS-led setup with three numbered steps + a
deep link to coinos.io/settings/connect; a generic paste field
that also accepts Alby Hub / Mutiny / Phoenix / Cashu.me URIs;
Connect + Paste-from-clipboard buttons; per-action status line.
- Connected: alias (from get_info, falling back to "Connected
wallet"), lud16 or short pubkey, relative "Tested X ago"; Test
and Disconnect actions; a capability warning that surfaces only
when the wallet doesn't advertise `pay_invoice`.
- Summary badge ("— PersistedWallet" / "— not connected") so the
state is visible without expanding the panel.
- Subscribes to `nwc.on()` so background reconnects and capability
discovery update the UI without manual refresh.
Tested via CDP (everything that doesn't need a real wallet):
- URI parser: real-shape (Alby-style URL-encoded relay + lud16),
multiple-relay, alt scheme, malformed scheme, short secret,
empty string. All produce the expected pass / null outcomes.
- Bad URI on Connect → parser error in status line; UI stays in
disconnected view.
- Valid-shape URI to a fake wallet → connects, switches to
connected view, persists to localStorage.
- localStorage round-trip: page reload restores the connected UI
with alias, lud16, relative timestamp, capability set.
- Disconnect: clears storage + returns to disconnected view.
- Regression check: existing custom-art editor still works.
The ship gate ("CoinOS-issued URI: get_info returns alias;
pay_invoice 10 sats settles") needs a real wallet, so the live
test moves to Phase 4 E2E.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
7eae78e909 |
Phase 0 — crypto bundle for NWC
Bundle @noble/secp256k1 v3.1.0 + @noble/hashes v2.2.0 as an IIFE
(noble-bundle.min.js, 15.8 KB) and load it before the main script.
The bundle exposes window.ArtstrNoble with schnorr, getPublicKey,
getSharedSecret, sha256, hex/randomBytes utils, plus secpUtils.
(noble v3 keeps hash functions external; the bundle wires
hashes.sha256 + hashes.hmacSha256 so schnorr.sign / verify work.)
On top of that, add an `NWC` IIFE in the main script with:
- sharedSecret(privHex, peerPubHex) — NIP-04 32-byte ECDH x-coord
(handles x-only 32-byte and full 33-byte pubkey hex).
- encrypt04 / decrypt04 — AES-256-CBC via crypto.subtle, 16-byte
random IV, `<base64ct>?iv=<base64iv>` wire format.
- getEventHash + signEventWithKey — NIP-01 event hashing + schnorr
signing using a *passed-in* hex privkey (the NWC connection's
secret, not the user's identity).
- verifyEvent — for kind-9735 receipt verification later.
- getPubkeyHex — schnorr x-only pubkey from a hex privkey.
Phase-0 self-test runs once at load: BIP-340 test vector #1 derives
the expected x-only pubkey AND verifies the published signature
through window.ArtstrNoble.schnorr; a NIP-04 round-trip encrypts
+ decrypts a known plaintext between two random keypairs; a
synthetic Nostr event is signed and verified through our helpers.
All checks pass silently; any failure logs a single console.warn
so the user sees "Crypto self-test failed — NWC features will not
work" if a bad bundle ever ships.
Verified via CDP:
- derivedPub matches BIP-340 vector 1: dff1d77f...502ba659
- sigVerify on the vector signature: true
- nip04Roundtrip: true
- eventSigned + eventVerify: true
- No console errors loading the app; existing custom-art editor
smoke test (add a color layer, render) still works.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
809e0f8fae |
Pixel editor: fix dropdown clipping when toolbar wraps near the sidebar
The pixel-art canvas-size dropdown (and the PNG-export dropdown that
shares the same class) used `position: absolute; right: 0` relative to
its toolbar wrap. The wrap lives inside `.pixelEditorBar`, which has
`flex-wrap: wrap`. When the bar wrapped and the trigger button landed
on the LEFT of its row, the menu's right-anchor pushed it 260px to the
LEFT — straight under the main sidebar.
Fix:
- Switched .pixelExportMenu to `position: fixed` (only when open).
- Added a `placeFlexMenu(menu, btn)` helper that anchors the menu's
right edge to the button's right edge by default, flips to the
button's left edge if anchoring right would push the menu past the
sidebar (using the aside's actual right edge as the safe-left
boundary, not just the viewport edge), and finally clamps to the
viewport on both sides.
- Added a fixed width (260px) + box-sizing border-box to keep the
menu from expanding to its natural content width once it's freed
from the previous absolute-positioning constraint.
- Window-resize handler auto-closes any open menu — the fixed coords
were computed against the previous layout, so resizing would
otherwise strand the menu away from its button.
Verified via CDP across 920px / 1000px / 1100px / 1440px viewports and
in both sidebar-open and sidebar-collapsed states. Also exercised the
specific failure scenario (button moved to the leftmost slot of the
bar, simulating the worst-case wrap layout) — menu now opens to the
right of the button, fully inside the canvas area.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
733d123edc |
Top-right action strip: pin undo/redo + canvas-size readouts under Nostr widget
The undo/redo pair and the trim/sheet canvas-size pills lived inside
.topbar's flex row, which wraps at narrow widths. Adam wanted them in a
permanent, predictable place so muscle memory works regardless of
editor mode or sidebar state.
Changes:
- .status is now `position: fixed; top: var(--top-strip-height);
right: 0; flex-wrap: nowrap` with the same panel/border styling as
the Nostr widget — a second strip directly below it.
- Reordered the markup so the canvas-size pills come first and the
undo/redo group last, so undo/redo end up hugging the viewport edge
and the pills sit to their left (matching the requested layout).
- Dropped the `body.app-designer .status` override (full-width
left-aligned), since the new positioning is universal across modes.
- updateNostrWidgetSpace() now measures the wider of the Nostr widget
or the new strip and reserves topbar right padding accordingly, so
the project title can't slide under the strip.
Verified via CDP at 1440px (cover, customart, pixelart modes) and at
900px narrow — strip stays pinned top-right with undo/redo on the
outside edge in every case.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
3c40951a8a |
Template browser: stop pinning rendered count to the first stream batch
Reported issues that all turn out to share one root cause:
1. "Open browser, keep it on All — nothing loads. Switch to Case Covers
or Disc Designs — they're all there."
2. "Still need to scroll down to see them all."
3. "Up-vote sorting and zap sorting seems not to work."
Symptom CDP confirmed: after opening Browse, `_feedPagination.New` ends
up with `rows: 72, rendered: 7`. Only 7 cards in the wall on the All
filter; 7 on Case Covers (out of 26); 7 again on All. So the wall is
clamped to the first batch size the streaming fetch happens to deliver.
Root cause: in loadFeedTab's rerender(), the reset for rendered was
`!rendered || rendered > rows.length`. As templates stream in via
notifyFeedProgress, the first rerender sees ~7 events and sets
rendered=7. Later rerenders with rows growing to 72 leave rendered
pinned: 7 is neither 0 nor `> 72`, so neither reset clause fires. The
auto-fill RAF check then short-circuits because 7 cards already
overflow the (short, modal) viewport, so it never tops up. And the
Popular / Zapped sorts re-sort all rows but only the first 7 ever
reach the DOM — so the visible order looks like the wrong top results.
Fix: change the reset to `rendered < chunkTarget`, where chunkTarget =
min(rows.length, chunk). That grows rendered up to a full chunk on
every rerender as long as enough rows exist, while still preserving
the user's scroll-loaded extra pages (rendered > chunk stays put).
Verified via CDP: All shows 24/72, Case Covers 24/26, All again 24/72.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
15ad4e93c3 |
Nostr login: persist to autosave on completion, not just on next render
Reported: "the nostr login doesnt persist after a refresh now."
Root cause: state.community.myPubkey is written by loadCommunityIdentity,
but the localStorage write only fires from inside render(). nostrLogin
calls loadCommunityIdentity → syncCommunityInputs + updateNostrWidget,
none of which call render(). A user who signs in and refreshes
immediately (without making any other interaction that triggers a
render — adding a layer, toggling a setting, etc.) loses the login,
because the autosave still reflects the pre-login state captured by an
earlier init-time render().
Fix: extract the autosave write into a `persistAutosave()` helper and
call it from both early-return paths of loadCommunityIdentity (logout /
no extension and successful sign-in). render() now calls the same
helper, so the on-disk format is identical to before.
Verified end-to-end via CDP:
- Stub window.nostr → call loadCommunityIdentity → no render → refresh
→ state.community.myPubkey restored, profile widget shows.
- Same flow but window.nostr throws (logout) → cleared pubkey
persisted as ''.
- render() autosave still captures layers correctly (regression check
on the helper extraction).
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
d6dcdfba11 |
Community browser: don't trash the welcome modal's pre-warmed cache
The previous "auto-refresh on Browse click" commit unconditionally called invalidateFeedCache() before opening the modal. That set _feedCache.events = null and forced a 6-second re-fetch on every Browse click — wiping the cache the welcome modal had populated seconds earlier. Symptom: cold reload → welcome loads instantly → exit → Browse shows "Loading..." for ~6s with nothing rendered, while changing the type filter (which only re-filters the cache) appears to "work" once the fetch finally lands. Smarter behaviour: - Add a `force` option to fetchFeedAndReactions that bypasses its 5-minute cache check. Use this from the Browse buttons. - Don't blow away the cache. Open the modal, switch to the New tab, which renders cached cards immediately via the existing `if (_feedCache.events && _feedCache.events.length) rerender()` path in loadFeedTab. Then trigger a force refresh only if the cache is staleish (>30s old). So: welcome just-loaded cache (age=2-5s) → Browse opens instantly with those cards, no extra fetch. Older cache (age=1m, 4m, etc.) → Browse renders cached cards instantly AND kicks off a background refresh whose progress streams in via notifyFeedProgress. The explicit Refresh button in the modal is still available for on-demand forced pulls. Co-Authored-By: Claude Opus 4.7 <[email protected]> |
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
e8c3115236 |
Community browser: auto-fill viewport on initial render
Symptom: after opening the browser, users had to scroll down a few pixels to see the rest of the initial card chunk. Cause: loadFeedTab's rerender() draws the first chunk (24 cards) via diffWallCards but skips the scroll-triggered auto-fill chain. appendFeedRows DOES have that chain (chained-RAF that keeps adding chunks until the modal scroller becomes scrollable), but it only runs when the user scrolls. Fix: after the initial diffWallCards, schedule a RAF that runs the same viewport-fullness check appendFeedRows uses — if the modal isn't yet scrollable AND there are unrendered rows, call appendFeedRows. The recursive RAF inside appendFeedRows then keeps adding chunks until the viewport is full or rows are exhausted. Co-Authored-By: Claude Opus 4.7 <[email protected]> |
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
fc8a89d2fa |
Community browser: auto-refresh on open + longer relay timeouts
Three reported issues:
1. "When I click the button it should auto-refresh." The two Browse-
Community buttons opened the modal and called switchModalTab('New'),
which routes to loadFeedTab. fetchFeedAndReactions honours a 5-minute
cache (line 16310), so a user reopening the browser within that
window saw stale results — including not seeing their own design
they just published. Add invalidateFeedCache() before opening the
modal so the 5-minute cache is bypassed on every Browse click.
Applied to both #browseCommunityBtn and #designerBrowseCommunityBtn.
2. "Sometimes it does not load everything in correctly each time."
The relay fetch timeouts were tight enough that slow relays would
miss reply windows. Bump:
- templates: 4500ms → 6000ms
- deletions: 3500ms → 5000ms
- reactions: 2500ms → 4000ms
- zap receipts: 4500ms → 6000ms
Streaming via onEvent is unaffected, so the first event still
appears the moment any relay responds; the longer ceiling just
means more events make the cut before the await resolves.
3. "Zap and up-vote ranking is not working reliably." The sort logic
in loadFeedTab is correct — Popular sorts by zap total, then
reactions, then trust, then date; Zapped sorts purely by zap
total. Reactions are fully fetched before the initial rerender;
zap receipts stream in asynchronously and trigger debounced
rerenders via scheduleZapStreamRerender → notifyFeedProgress,
which re-sorts using the now-current _zapCache. So unreliable
perception was mostly "I see initial sort, then it reorders."
The fix here is indirect — longer zap timeout + auto-refresh on
open mean more zaps arrive within the first rerender window, so
the user sees the correct order sooner instead of watching it
shuffle.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
88bd59bf12 |
JPEG export: DPI / quality selector
Small dropdown next to Export JPEG with three presets:
- 96 dpi / quality 0.85 — fast, screen-only
- 150 dpi / quality 0.92 — standard (default)
- 300 dpi / quality 0.95 — print-grade
The picker lives next to the existing Print/Save PDF + Export JPEG
buttons in the Print & Save panel. The click handler reads the
selected option and passes the right { dpi, quality } pair to
exportArtboardAsJpegBlob. No persisted state — defaults to standard
on each page load.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
0cf8d05c1e |
Resize: corner handles default to independent axes (Shift = lock aspect)
Corner handles used to lock the aspect ratio whenever the sidebar 🔒 toggle was on (the default). Result: dragging the corner horizontally a lot and vertically a little still scaled both axes by the horizontal-driven factor — width and height grew at the SAME rate regardless of the drag vector. Switch to the Figma / Photoshop / Keynote convention: - Corner handle drag → axes are independent. Each axis follows its own drag delta. Drag right-and-a-bit-down → width grows a lot, height grows a little, matching the cursor exactly. - Hold Shift while dragging the corner → lock the aspect ratio. Same math as before (the larger-magnitude axis sets the scale, both axes get it). The sidebar 🔒 toggle still governs typed W / H input cascades — so typing Width:5 with the lock on still updates Height proportionally. Only the visual corner-drag behaviour changed. Same fix applies to: - startLayerResize (single-layer corner handles). - startLayerSelectionResize (multi-select bounding-box corner handles). Edge handles (n/s/e/w) are unchanged — they're always single-axis. Co-Authored-By: Claude Opus 4.7 <[email protected]> |
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
54cf915b4f |
JPEG export: rich-text rendering (P2) via canvas run-layout
The plain-text fillText path (drawTextLayerPlainToCanvas) strips inline
marks via layerHtmlToPlainText. Add a rich-text path that preserves
inline bold / italic / underline / lists / links in the JPEG output.
First attempt was an SVG <foreignObject> wrapping the layer's HTML,
loaded via a Blob URL and drawImage'd onto the canvas — clean and
short. Chromium taints the canvas on every <foreignObject> SVG
regardless of origin, so toBlob('image/jpeg') threw SecurityError.
Confirmed via CDP: `kind:'taint', err:"Tainted canvases may not be
exported."`
Switched to a pure-canvas rich-text engine:
- _parseTextRunsFromHtml walks the layer's HTML into a flat list of
styled runs ({text, bold, italic, underline} or {br}). Handles
<b> / <strong>, <i> / <em>, <u>, <a> (visual underline only,
links don't survive into the canvas image), <br>, <p> / <div> /
<h1>-<h3> (block break before+after), <ul>/<ol>/<li> (bullets
for unordered, "1.", "2.", … prefixes for ordered, properly
nested via a list stack).
- _layoutTextRuns walks the runs with ctx.measureText, builds a line
list with word-wrap at the layer's inner width. Trailing whitespace
at a wrap point is discarded.
- drawTextLayerRichToCanvas applies the layer's clip, walks the lines
with proper left / center / right alignment using each line's total
width, fillText per item, and a tiny fillRect under each underlined
run (sat just below the baseline at ~95% line-height, ~6% thick).
The dispatcher drawTextLayerToCanvas calls the rich path when
_textHasInlineMarks(layer.html) — i.e. layer.html contains any of
b/strong/i/em/u/a/br/ul/ol/li/span/font — and the plain path
otherwise. drawLayerToCanvas now awaits drawTextLayerToCanvas (it
became async).
End-to-end verified via CDP on a Custom Art canvas:
layer 1: "<b>Bold</b>, <i>italic</i>, <u>underlined</u>,
<a href=…>link</a>."
layer 2: "<ul><li>Item one</li>… </ul>"
Resulting JPEG renders Bold as bold, italic as italic, both
underlined and link as underlined, and the list as bulleted lines.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
2d1ed1124d |
Custom Art: match canvas to imported image's natural dimensions
New "Match canvas to image size" button in the selected image layer's panel. Only visible in Custom Art mode (Slide is 16:9- locked; Cover/Disc/Jewel use sheet dimensions tied to physical media). Behaviour: - Loads the image via loadImageWithCors with a short timeout so a CORS-hostile or unreachable URL errors cleanly instead of hanging. - Updates state.customArt.width / height to the image's naturalWidth / naturalHeight, clamped to [CUSTOM_ART_MIN, CUSTOM_ART_MAX]. Marks preset as 'custom'. - Pushes one history entry so the resize is undoable. - Toasts the resulting canvas size (and notes if the image was clamped down because it exceeded CUSTOM_ART_MAX). The button visibility is computed in syncLayerInputs: image type + has src + templateMode === 'customart'. Hidden otherwise. Co-Authored-By: Claude Opus 4.7 <[email protected]> |
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
902befa189 |
Fix blank PDF print regression — split exporting / export-print classes
Recent commit
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
29dcdeea61 |
Canvas crop marks for Custom Art + Slide modes (toggleable)
Crop marks were a cover-only feature; Custom Art / Slide canvases exported with no corner registration marks at all. Add a corner crop-mark set for canvas modes with the existing showCrops / printCrops toggles wired up. Changes: - New <div class="cropMarks canvasCrops"> sits inside .sheet alongside the existing cover cropMarks. Eight corner marks, positioned outside the canvas edges via new .cc-* classes that are scoped under .canvasCrops so they don't collide with the bleed-anchored cover .cm-* positions. - CSS shows .canvasCrops only in body.template-customart and body.template-slide. It reuses the existing `--crop-display` / body.print-crops gating, so state.showCrops drives on-screen visibility and state.printCrops drives print visibility — the same toggles the cover mode has used all along. - Move showCrops and printCrops <label>s from `cover-toggle` to a new `crops-toggle` class. Cover-toggle still hides showGuides / showBleed / printGuides in non-cover modes (those are bleed/safe concepts that don't apply to canvas modes); crops-toggle shows in cover / customart / slide, hidden only in disc + jewel sheets. JPEG export was already unaffected — the direct canvas rasterizer doesn't touch the DOM, so canvasCrops never appears there. The PDF Print route does render the DOM, where printCrops now controls inclusion. Verified via CDP: in customart mode, both toggle labels render, .canvasCrops is visible by default with a valid corner-span bounding box, and `state.showCrops = false; render()` hides it. Co-Authored-By: Claude Opus 4.7 <[email protected]> |
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
119b14e1d3 |
Editor UX: click background to deselect + strip selection chrome in print
Three small editor-UX fixes:
1. Click in the canvas gutter → deselect. The existing #sheet click
handler only fired when the click landed inside .sheet; clicks in
the area between the sheet edge and the previewShell edge
("sheetWrap" parent) hit no handler and the selection stuck.
Added a #previewShell click handler that deselects when the
click isn't on a .freeLayer and isn't on #sheet (which the
existing handler still covers). Layer .freeLayer clicks already
stopPropagation, so they don't bubble through.
2. Selection chrome no longer bleeds into PDF / JPEG-fallback
output. The codebase had `body.exporting .freeLayer.selected
{ outline: none }` rules sitting dead — JS only ever toggles
`body.export-print`. Renamed the CSS to match. Also added rules
to hide .layerHandle (resize squares) and .layerSelectionBox
(multi-select dashed box) under the same class.
3. The regular Print / Save PDF button (printWithCurrentFilename)
wasn't adding any export class around window.print(), so
selection chrome bled into single-sheet prints too. Added
body.classList.add('export-print') before the print + the
matching remove on afterprint. The JPEG-PDF-fallback flow
(enterExportPrintMode) already added this class; now both flows
benefit from the same CSS.
Verified via CDP: clicking in the gutter outside the sheet now
deselects ({selId:'', isSel:false}).
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
||
|
thePR0M3TH3ANandClaude Opus 4.7
|
b890f78f1f |
JPEG export P1: one-click direct rasterizer, PDF fallback on CORS
Replace the click-Export-JPEG → print-to-PDF → save-to-disk → re-pick
flow with a single click. The canvas-rasterizer infrastructure was
already 90% built in this codebase — drawLayerToCanvas,
loadImageWithCors, setupExportCanvas, and rasterizers for cover /
disc-sheet / jewel / disc-design all existed but were never wired
into any user-facing entry point. This commit ties them together.
What changed:
- New renderCustomArtToExportCanvas(dpi) — the one missing rasterizer.
Handles customart / slide canvases: background colour fill + every
canvas-target layer drawn in z-order via the existing per-type
drawers.
- New exportArtboardAsJpegBlob({dpi, quality}) orchestrator. Branches
by current templateMode (and appMode for the disc-design designer):
cover → renderCoverToExportCanvas
disc → renderDiscSheetToExportCanvas
jewel → renderJewelSheetToExportCanvas
designer-disc → renderDiscDesignToExportCanvas
customart / slide → renderCustomArtToExportCanvas
pixelart / deck → {ok:false, kind:'unsupported'} (caller falls back)
Clears _exportFailedImages, renders, then:
- if any image failed to load (CORS-blocked, 404, timeout) →
{ok:false, kind:'cors', urls: [...]}
- if toBlob throws (canvas tainted, shouldn't happen but defensive) →
{ok:false, kind:'taint'}
- else {ok:true, blob}.
- exportArtboardAsJpeg(btn) rewritten as an async click handler:
disables the button + sets a "Rendering…" label, calls the
orchestrator, downloads the blob on success, or routes to the
existing openPdfJpegModal() with a toast on cors/unsupported/taint.
End-to-end verified via CDP against the running app:
- 4-layer Custom Art (color + shape circle + plain text + QR code) →
direct JPEG download, 1280×720 px, ~43 KB at dpi=96 quality=0.92.
All four layers render in the right positions (PNG preview attached
to the verification — color block top-left, red circle adjacent,
bold text below, scannable QR overlap with the text bounds).
- Single image layer with an unresolvable URL → {ok:false, kind:'cors',
urls:[...]}, which the click handler converts to a toast + the
existing print-to-PDF modal.
P1 scope ships customart / slide / cover / disc-sheet / jewel /
disc-design. Pixel-art standalone keeps its own PNG/GIF export, and
slide-deck keeps the multi-page PDF flow (both intentionally not
covered here).
Rich-text inline marks (bold / italic / underline / links / lists
applied to sub-spans) still render as plain text in the JPEG —
existing drawTextLayerToCanvas uses layerHtmlToPlainText. P2 adds
SVG-foreignObject rich-text rendering.
Co-Authored-By: Claude Opus 4.7 <[email protected]>
|
