# P Labels: Allowing Future Wallet Action Label Permission Schemes

Ty Everett (<ty@projectbabbage.com>)

## Abstract

The [BRC-65](/brc/wallet/0065.md) and [BRC-100](/brc/wallet/0100.md) 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](/brc/wallet/0098.md) and [BRC-99](/brc/wallet/0099.md).

## 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](/brc/wallet/0100.md) (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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hub.bsvblockchain.org/brc/wallet/0111.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.