docs(147): id/type tags, origin forms, tags vs CI

[shruggr]

Summary

Draft proposal for additive clarifications to BRC-147 (Brandon’s basket profile), for discussion before merge.

• id: SHOULD on managed rows — wallet-unique opaque id (generation not standardized)
• type: SHOULD when known — full origin inscription MIME (params stripped); copy on self-keep
• Origin tag — bare origin (this out is origin) vs origin:<outpoint> (later tip) + self-keep promote/copy
• Tags vs customInstructions — tags for query keys; CI for display name, optional spend fields, provenance; name: tag MAY legacy

Intentionally does not change basket name, supersede 147, or pull in P1Sat permission-module machinery.

Open threads (also offline with Brandon):

• Duplicating origin/app across tags and CI
• CI origin underscore preference vs BRC-100/SDK dot form
• Provenance size vs wallet-toolbox CI column limits (150 omit-if-large / 156)

Test plan

• Review diff with Brandon
• Align on open threads above
• Merge when agreed

[shruggr]

@GenericCPU I would love to discuss the duplicated fields across custom instructions and tags.

The logic I've been using is based on the reference implementation of BRC-100 lowercasing tags. I put derivation information in customInstructions as well as fields where case is significant. Searchable fields and lowercase tolerable fields go in tags. Is there a specific reason to store these fields across both?

Are the aliased fields aliases for a reason?

[shruggr]

I've been moving the other direction on outpoint format to use the dotted form for most cases. In the 1sat-sdk, we are using origin:. I've been treating the reading side as supporting either format interchangeably, but trying to nail down to the use of dotted in all new api/overlays/etc. The one exception to this is BSV21 tokens which write the outpoints on-chain as a tokenId. The spec existed before the newer dotted format, but tokenId is a fundimentally different identifier than origin, so it's not a big deal there. Currently, I've updated the 1sat-sdk to use _ as defined in this spec, and I'm fine with that

[GenericCPU]

Agree with the tags vs CI direction here — mirroring the same constraints on BRC-163 (#217):

• Reference @bsv/sdk lowercases tags and caps each at 300 UTF-8 bytes
• internalizeAction rejects customInstructions over 1000 UTF-8 bytes (createAction is looser today, but import/re-file must stay lean)
• So display name / spend fields / anything case-sensitive belongs in CI; tags stay query keys in a lowercase-safe alphabet
• Your id: as wallet-local list key matches what we’re reserving on 163 (not BSV-21 token id)

One suggestion for this PR: spell those hard SDK limits in the Tags vs CI table so writers don’t recommend shapes that bounce off wallet-toolbox validation. We’ll wait on Brandon’s remaining id notes this evening before locking generation rules.

[GenericCPU]

Superseded for BRC-147 — please close this draft.

The 1sat-specific clarifications from this draft are now folded into #216 so we do not need a second 147 PR:

• origin forms (origin vs origin:<outpoint> + self-keep copy rules)
• type:
• tags vs customInstructions (prefer CI name)
• content for derivatives (already on 216)

id: does not belong in 147. That is the wallet-local list-key convention in #219 (BRC-164). 216 only points at 164 and says receivers must ignore counterparty-supplied id:.

Please close this draft; continue any id: discussion on #219 (prefix reservation / namespace).