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.
About Permissions, what an app is allowed to do with your wallet.
Reference for an AI
Everything an assistant needs to answer questions about BRC-98 accurately, including what it depends on.
Summary
- Why
- Future wallet permission schemes need a naming space that is guaranteed not to collide with protocol identifiers already in use by apps today.
- What
- BRC-98 reserves protocol identifiers that start with a lowercase "p" followed by a space, so wallets can recognize and support future permission schemes without breaking existing BRC-43 based apps.
- How
- A wallet checks if a requested protocol ID begins with "p ", and if so treats the next space-free token as a scheme ID, applying that scheme's own rules if it recognizes it, and rejecting the request otherwise.
What this lets you do
- Reserve a namespace for future permission schemes
- Reject protocol IDs that use the reserved prefix without a known scheme
- Define a new scheme ID and attach custom rules to it
- Extend wallet permissions beyond BRC-43 security levels or BRC-73 paradigms without breaking existing apps
- Parse protocol IDs unambiguously to detect alternative schemes
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
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 specification 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.