PRD §240: record the NFT-folder shape and the eager owned-NFT read - #81
Draft
alexanderchopan wants to merge 1 commit into
Draft
PRD §240: record the NFT-folder shape and the eager owned-NFT read#81alexanderchopan wants to merge 1 commit into
alexanderchopan wants to merge 1 commit into
Conversation
Two deferrals from one conversation, written down rather than left to be rediscovered. NFTs in folders: the display half is a revival (§72/§124's strip shipped once, GenMediaShelf is still in the tree), but check-and-file is the surface §178/§229 retired. Records the shape — collection-as-folder if it ever returns, manual folders only as a deliberate §178 reversal. The cost finding underneath it: ownedNFTContracts fires eagerly on every wallet refresh (5 networks x every EVM address, paging) to build a spam allowlist whose two consumers only fire when something NFT-shaped lands. Lazy beats a §216-style window here. Not built on purpose — no measured number backs it, unlike §216's Zerion math, so the entry names the two signals that would revive it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XrmnGXbYAwC3Sh9ApBYFa8
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Docs only — one PRD entry, no code touched.
Two deferrals from one conversation, written down so neither gets rediscovered from scratch.
NFTs in folders. Asked whether the app could display a wallet's NFTs and let someone check them into folders. The display half is a revival, not new work (§72/§124's NFT strip shipped once, and
GenMediaShelfis still in the tree), but the folder half is exactly the surface §178 and §229 retired — the person never files. Dropped before a ruling was needed, so the entry records the shape: collection-as-folder if NFTs ever return, and a manual folder only as a deliberate §178 reversal rather than a side effect of adding a picture grid.The cost finding underneath it.
WalletIngest.ownedNFTContractsfires eagerly on every wallet refresh — 5 networks × every watched EVM address, paging — to build a spam allowlist whose only two consumers (the received-ERC-721/1155 check, andWalletApprovals'ApprovalForAllcheck) fire only when something NFT-shaped actually lands. Lazy beats a §216-style window here, and preserves both fail directions untouched.Not built on purpose, and that reason is the entry. No measured number backs it — unlike §216, whose window was earned by real Zerion math. So the entry names the two signals that would revive it (Alchemy dashboard burn, or a slow-wallet-refresh complaint) instead of pre-empting them.
Nothing to verify: no Swift changed, no build or probe involved.
Generated by Claude Code