BRC-230: Wallet Index Expansion Packs

[GenericCPU]

Summary

Proposes BRC-230 — a wallet standard for Index Expansion Packs: user-approved, locally cached mirrors of public overlay lookup indexes (large NFT catalogs, feeds, curated discovery).

The spec composes existing BRCs without redefining custody or overlay admission:

• Manifest — pack id, BRC-87 topic/lookup service, scope query, storage budgets, optional BEEF preview
• Local profile — basket index with pack:<packId> / entry:<key> tags and grade-C display metadata in customInstructions
• Permissions — BRC-99 scheme index (p index install|read|sync <packId>) gated by BRC-116
• BRC-100 extensions — installIndexExpansion, listIndexExpansions, removeIndexExpansion, syncIndexExpansion, listIndexExpansionEntries
• Trust — pack rows are convenience/oracle only; held inventory and BRC-150 authenticity are unchanged

Includes an informative reference profile for the HandCash Market 1Sat catalog (handcash.market.catalog).

Author: Brandon Cryderman / HandCash (brandongcryderman@gmail.com)

Motivation

BRC-35 local KV and BRC-165 P1Sat permissions do not cover “install this overlay slice for offline browsing.” Apps today re-fetch full remote indexes on every navigation. This BRC gives wallets a standard install → sync → query → uninstall path with explicit user consent and budget caps.

Test plan

• Maintainer review of BRC number assignment (230 follows wallet 229)
• Cross-reference links resolve in wallet/0230.md
• README.md, SUMMARY.md, and wallet/README.md index entries match
• Overlay/wallet/token references align with merged BRC-22/24/87/88/99/100/116/147/150/165 text

Made with Cursor

[GenericCPU]

Hey @ty-everett can you give me feedback on this?

[ty-everett]

Thanks Brandon. I think the underlying offline/discovery goal is useful, but the current draft combines two different concerns: an internal wallet pack manager and an application-facing cache service.

As written, applications control pack installation, synchronization, removal, enumeration, and reads through five new wallet methods. That is substantially different from the existing separation, where applications query BRC-24 overlays and own their UI/cache policy, while the wallet owns custody, cryptographic operations, and permissions.

I think we should first establish the requirement that cannot be met by application storage. If the requirement is simply faster navigation or offline browsing, web and native applications already have appropriate caching systems and should control their own freshness and eviction policies. No wallet or BRC-100 change is needed.

If the intended feature is wallet-native—for example, a wallet vendor wants to install public catalogs for its own UX—then install/sync/remove and storage budgets should remain internal wallet operations. Applications should not control that lifecycle.

If there is a real cross-application requirement to expose a wallet-installed pack, I would prefer one read-only P-basket surface using existing listOutputs, modeled after BRC-165: something like basket p index entries, with pack: supplied as a tag. Installation, synchronization, and removal would remain wallet-internal.

Before using listOutputs, though, the draft needs to resolve a fundamental type issue: BRC-100 baskets contain tracked spendable outputs, while this proposal describes grade-C cache rows that are not custody. Are the returned entries the actual BEEF-backed overlay UTXOs, or arbitrary cached cards pointing at those UTXOs? If they are arbitrary records, customInstructions does not make them BRC-100 outputs and a separate lookup surface would be cleaner.

There are also some concrete specification gaps:

• p index … is shown as a standalone wire value, but P-modules are activated through an existing basket, protocol, or label argument.
• The proposed groupPermissions shape does not match BRC-116, and P-module authorization must be defined by the module.
• The five vendor methods have no BRC-100 WalletWire call codes or serialization.
• Pack state appears wallet-global while permissions are per originator; read/remove/sync ownership across apps is unclear.
• Incremental synchronization, removals, pagination, manifest signatures, and BRC-123 scheme registration are not yet specified.

My preference would therefore be: keep app caching in apps; keep wallet pack lifecycle internal; and only standardize a minimal read-only wallet surface if shared cross-app access is the actual requirement. That preserves the separation of concerns and avoids expanding BRC-100 unless the use case truly requires it.

[GenericCPU]

Thanks Ty, very helpful insight, I was concerned I might not be scoping this accurately.

The main use-case is for 1sat collections atm, but I could see this being useful for many other scenarios where content is stored in beefs, that you may want cached access to for speeding up the experience.

Particularly in our example we want to be able to trade, import, receive, or move thousands of pixelfoxes quickly including the ability to quickly verify.

The idea is, If users have the full index already then this will speed up effective validation time and introduce more durable overlay data distribution practices.

Just need to find the right structure for it.