| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
of it. "When I flick to scroll, it's not getting up to speed very quickly, and clicking around in the app feels a bit sluggish at times" (Adam, 2026-11-07). Measured on his Pixel 9 in the installed PWA: idle is quiet (0.16 s of script in 10 s), but three real flicks through Following spent 1.7 s of 9 on the main thread, frames up to 200 ms, and the work was the avatar thumbnailer finishing faces as they scrolled in: a synchronous canvas.toDataURL WebP encode per face (229 ms), the profile cache JSON.stringified twice per half-second flush (once just to measure it, up to ~2 MB with thumbnails), and a whole-page repaint per finished face that changes nothing on screen (feed rows keep the face they were admitted with). Now: the crop, resize and encode happen off the main thread (createImageBitmap with resizeWidth/Height, OffscreenCanvas.convertToBlob, FileReader), with the old canvas path as the fallback; a finished face is recorded once the page settles; scheduleRepaint holds while a finger is down or the page scrolled in the last 200 ms (at most 1.5 s), and the profile flush likewise (at most 5 s, forced on an account switch) and sizes the blob by summing rows instead of stringifying it. Tests: the create flow's heads-up / passphrase / check steps from earlier today broke every test that made a wallet by waiting for the words and clicking "Skip verification"; tools/puppeteer.js exports seedWords() and skipSeedCheck() and the 96 tests use them. room-faces and avatar-profile fail the same way on 8858591 (row.hover, scrollIntoView), before today's changes
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01VMan6Ts5Tktega8VbLg31q
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
missing
A reply under "Couldn't find that note on the relays" told nobody anything (Adam, 2026-10-20), so once every lookup comes back without its post it isn't shown in a feed's Conversations view (its thread, notifications and the replier's own Replies tab keep it; a lookup that later finds the post brings it back).
The lookups miss less:
- A NIP-22 comment (kind 1111) names its parent's author at e-tag [3], not NIP-10's [4], so every comment's parent lost its author and the author's outbox went unasked. fiatjaf's comment on Kieran's routstr post lives on relay.snort.social (its hint), Kieran's pyramid.fiatjaf.com and ditto: none of ours.
- A reply that names no author asks the outboxes of the people it's addressed to (its p tags, up to three).
- The relay the reference itself names is asked even when this device has marked it sick.
- A post read in Following (or the feed in use) is found in that feed's disk cache too, so a Conversations view opened right after a reload doesn't take its replies for orphans.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_013ZDf1cyCQLkfjftYhymZAg
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Videos and Articles — not a feed of its own.
Adam, 2026-10-16: "conversations [should] be one of the filter chips between
all and images and all should become notes". So the view row reads Notes ·
Conversations · Images · Videos · Articles, and Conversations shows the
current feed's people in reply — Following, Popular, a list, a topic, a pack,
anyone's timeline — each reply under the post it answers, as 885bc26 drew
them. The view is a feed state of its own under the feed's id (suffix
~replies: its own notes, clock, disk cache, fresh counter and live watch),
with a definition derived from the feed's (replies: true) so the merge,
seeding, borrowing, watch and kinds all go by it unasked; Notes ↔
Conversations is entered like a switch of feed, the feed chip unchanged, and
the chosen view persists across feeds and reloads like the others. A feed's
state is forgotten together with its view's (dropFeedState) when its query
or relays change or it is deleted. The built-in Conversations feed chip and
the editor's "Replies instead of posts" toggle from this morning are gone
with it (def.replies stays as the derived definition's mark).
tools/feed-conversations-test.js follows: the view chips in order, no feed
chip of its own, the view's cache under following~replies, the feed chip
staying on Following while the view is on, Back landing on the view, a new
list feed opening straight into the view with the replies borrowed from the
feeds in hand and Notes giving its posts, Following's view back at once, and
a reload opening on the view from its own cache. feed-media-views-test names
the chips; feed-custom-test is back as it was. feed-media-cache-test is
flaky either way (a stray first page in its request window, or its 8 s
timing, on clean HEAD too); feed-custom-test's "lands in Everything" fails on
clean HEAD; the other feed suites pass.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01J1Kon8bxJoHRpJdSzshCkp
|
|
|
the post it answers.
Amethyst's Conversations beside its New Threads (Adam, 2026-10-16: "a replies
mode or Conversations mode like Amethyst has"). The Following feed showed
their posts and dropped every reply, so what people were saying TO each other
only turned up by opening threads. Now a built-in Conversations chip sits
beside Following (id 'replies'; its own notes, clock, disk cache and relay
choice like the other built-ins): the same people, asked for notes and NIP-22
comments, keeping the replies — a reply as NIP-10 marks it, a comment, never a
quote or a repost (feedKinds/feedKeeps; the merge, seeding, borrowing, the
live watch and the media index all go by them). Each row shows what it
answers above it — "↩ Replying to" and the quote card of the parent (the e
tag marked reply, else root, else the last; a comment's e or E), tapping the
card opens that post, tapping the reply its thread at the reply — and the
header drops its "reply" tag there. The parent is usually in hand already
(the Following feed, a thread, someone's page: noteInHand, which quotedNote
checks before any relay — nostr:nevent quotes gain the same), and a thread
opened from such a row paints its root at once instead of fetching it. In a
conversations feed the parent counts as part of the row, so it arrives whole
with the first screen (noteReady's parent option, per feed); a profile's
Replies tab shows the same context and fills its cards in. Not a shareable
URL (it is nobody's timeline), so no Share in its menu. Any custom feed can
be one: "Replies instead of posts" in the editor (def.replies, synced with
the definition), named in its summary. The disk cache now keeps comments.
tools/feed-conversations-test.js: Following keeps posts only; the chip; the
replies newest first with the parent card from hand (no relay asked) and a
missing parent said so; the menu without Share; the reply's own tap opens
its thread at the reply, with the root painted from hand; the card's tap
opens the parent; Back lands on Conversations; the profile's Replies tab
shows the context, Posts none; a custom conversations feed via the editor
borrows the replies from the feeds in hand, not the posts. feed-custom-test
lists the new chip. Pre-existing failures not touched: feed-custom-test's
"a tagged post lands in it"/"lands in Everything" and feed-streaming-test's
pill position fail on clean HEAD the same way; feed-follow, feed-cache,
own-post-feeds, feed-list, feed-media-views, feed-switch-seed, profile-pager,
thread-pager, feed-repost, feed-live, feed-new-posts, feed-window,
feed-choice-per-wallet, feed-nav-destination, feed-wallet-back, moderation,
feed-mention-tap and feed-reboost pass.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01J1Kon8bxJoHRpJdSzshCkp
|
