P Protocols: Allowing future wallet protocol permission schemes
If applications are free to use any protocol name they like, a future standard cannot claim one without breaking somebody. This reserves a range of names so later permission schemes have room to exist.
Summary
- Why
- Wallet protocol permissions needed a way to add entirely new permission schemes later without risking naming collisions with existing protocols.
- What
- BRC-98 reserves protocol IDs that start with "p " (lowercase p, then a space) so future wallet permission schemes can use that space without colliding with anything that exists today.
- How
- A wallet checks whether a protocol ID begins with "p ", and if so treats the next space-free token as a scheme ID and rejects the request unless it recognizes and implements that specific scheme.
What this lets you do
- Reserve a namespace for a new permission scheme
- Reject protocol IDs from schemes the wallet does not support
- Define custom rules for counterparties, key IDs, and conditions under a scheme ID
- Extend BRC-43 security levels with new permission logic without breaking old apps
- Parse a 'p <scheme ID> <rest>' protocol ID unambiguously
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
Reference for an AI
Everything an assistant needs to answer questions about BRC-98 accurately, including what it depends on.
The specification
Abstract
The BRC-43 architecture for wallet protocol permissions enables a wide range of use cases. By reserving protocol identifiers and preventing their use by applications, we ensure compatibility with future standards, supporting the future development of new protocol permission schemes.
Motivation
The motivation for this proposal is to future-proof the BRC-43 architecture by enabling the seamless integration of new protocol permission schemes. By specifying reserved identifiers, we can ensure that new security and permission paradigms can be implemented without conflicts or unintended behavior.
Specification
To accommodate future protocol permission schemes, wallets must reject operation requests using protocol IDs beginning with p (a lowercase “p” followed by a space), regardless of security level.
Future Scheme Identifiers
Future permission schemes must define their ID formats as follows:
- Scheme IDs cannot contain spaces.
- Protocol IDs must start with
p, followed by the scheme ID, a space, and the rest of the protocol identifier.
Example Format
A protocol ID like p 222 xxxxx could represent a specific invoice number (e.g., 2-p 222 xxxxx-kkkkk), where:
2indicates the BRC-43 security level.pdesignates an alternative permission scheme.222identifies the permission scheme.xxxxxforms the remainder of the protocol ID under the alternative scheme.kkkkkdenotes the key ID.
Protocol Parsing and Rules
Wallets must differentiate between standard and alternative permission schemes by recognizing the p prefix followed by a distinct, space-free scheme ID. To ensure unambiguous parsing.
Upon recognizing a protocol ID structured as p <scheme ID> <rest of the ID>, wallets may apply the specific rules defined by the scheme associated with the scheme ID. These rules could define:
- Permitted protocols and key IDs.
- Conditions for operation execution.
- Counterparty requirements and customizable permission attributes.
Reserved Structure
To maintain clarity and prevent conflicts:
- Protocol IDs beginning with
pmust be reserved for future use. - Wallets must reject operations involving such IDs unless they explicitly support the scheme ID.
- A space must immediately follow the scheme ID to separate it from other elements.
Extensibility Beyond Current Paradigms
This specification allows future permission schemes to extend beyond current BRC-43 models (e.g., security levels or BRC-73 paradigms), enabling flexible and innovative wallet permissions that evolve with user and application needs.
Conclusion
By reserving protocol IDs starting with p and specifying rules for future permission schemes, this specification ensures forward compatibility and robust wallet permission functionalities. It enables seamless integration of new schemes without disrupting existing applications or introducing parsing ambiguities.