P Labels: Allowing Future Wallet Action Label Permission Schemes

Ty Everett ([email protected])

Abstract

The BRC-65 and BRC-100 label system enables applications to organize and query actions. However, labels are also used in permission checks (e.g. for listActions), which limits extensibility for module-defined labeling and querying schemes. This proposal reserves a label prefix to allow wallets to delegate label permissioning and label-specific behavior to installed modules, while preserving the core principle that labels remain organizational metadata.

Motivation

Labels are intentionally non-behavioral and used for categorization and filtering. But in practice, permissions for creating actions with labels and querying actions by labels can be enforced by wallets. Modules that define their own labeling schemes need a way to:

• Distinguish module-specific labels from ordinary labels.

• Apply module-specific permission rules for label creation and querying.

• Optionally transform query results when a module label is used.

To enable this, we reserve a label namespace analogous to the reserved protocol and basket namespaces in BRC-98 and BRC-99.

Specification

Reserved Label Prefix

To accommodate future label permission schemes, wallets must reject any operation requests involving labels beginning with p (a lowercase "p" followed by a space), unless the wallet explicitly supports the corresponding module ID.

Future Module Identifiers

Module-defined label schemes must follow this format:

• Module IDs cannot contain spaces.

• Labels must start with p , followed by the module ID, a space, and the rest of the label.

Example Format

A label like p invoicing invoice 2026-02-02 could represent a module-specific label, where:

• p designates a module-defined label scheme.

• invoicing identifies the module.

• invoice 2026-02-02 is the module-defined label payload.

Parsing and Rules

Wallets must differentiate between standard and module-defined labels by recognizing the p prefix followed by a distinct, space-free module ID:

• The label must begin with exactly p .

• The module ID must be at least 1 character and contain no spaces.

• A single space must immediately follow the module ID to separate it from the module-defined label payload.

• The module-defined label payload must be at least 1 character.

• All labels must still comply with the general label constraints in BRC-100 (e.g. length limits).

Module Resolution and Permissions

There is no global registry. A wallet determines which modules it supports based on its installed or integrated modules and their declared module IDs.

When a label follows the p <moduleId> <label> structure:

• If the wallet does not support the module ID, it must reject the operation.

• If the wallet supports the module ID, it must defer to the module for permission checks involving that label.

Modules may implement custom permission rules for label usage that override or bypass the wallet's default label permission checks.

Module Influence on Queries

When a module-defined label is supplied to listActions or any other label-based query:

• The module may apply additional permission checks on the query inputs.

• The module may transform or filter the resulting action set before it is returned.

This behavior is optional per module and does not change the rule that labels remain organizational metadata; it only affects permissioning and query handling.

Reserved Structure

To maintain clarity and prevent conflicts:

• Labels beginning with p must be reserved for module-defined schemes.

• Wallets must reject operations involving such labels unless they explicitly support the module ID.

• A space must immediately follow the module ID to separate it from other elements.

Extensibility Beyond Current Paradigms

This specification allows modules to define new label permission schemes beyond current wallet permission systems, while preserving the fundamental categorization-only role of labels. It enables future label semantics to evolve without disrupting existing applications or introducing parsing ambiguities.

Conclusion

By reserving labels starting with p and delegating permissioning to installed modules, this specification ensures forward compatibility and extensibility for action labeling and querying within the BSV wallet ecosystem.