Beersy

9 standards

Governance and stewardship

Standards need somebody to keep them. These cover who registers an identifier, who may reserve a namespace, what an operator promises to do, and how that responsibility is handed on.

Also searched as registry, stewardship, namespace, reserved, operating practices, administration, policy.

Filed under

9 standards, spread across 4 of the 12 topics.

Start with

BRC-184

Optional Metadata Registries and Their Stewardship

When an app asks a wallet to approve something, the wallet often shows a cryptic code, a raw protocol string, an unfamiliar basket name, or a block of certificate bytes. Users cannot tell what is actually being requested, and there has been no shared, trustworthy place to look up a human-readable name or description for these identifiers. This makes it possible to publish and consult optional, attributed descriptions, without letting those descriptions ever decide whether the underlying operation is allowed.

Filed under Wallet

Standards about this

Governance and stewardship is the main subject of these 2.

  • 184

    Optional Metadata Registries and Their Stewardship

    When an app asks a wallet to approve something, the wallet often shows a cryptic code, a raw protocol string, an unfamiliar basket name, or a block of certificate bytes. Users cannot tell what is actually being requested, and there has been no shared, trustworthy place to look up a human-readable name or description for these identifiers. This makes it possible to publish and consult optional, attributed descriptions, without letting those descriptions ever decide whether the underlying operation is allowed.

  • 187

    Thoughts on Declarative Stewardship

    Shared systems like a village granary or a blockchain network need someone to actually do the maintenance work, but whoever does that work can start to confuse running the thing with owning what it is for. Without a way to separate the rules of a system from whoever currently claims to enforce them, cooperation ends up depending on trusting one person or group forever, and the whole system becomes fragile the moment that keeper disagrees, retires, or goes bad.

Standards that touch it

These are about something else, and deal with governance and stewardship on the way.

  • 20

    There is no BRC-20

    Ethereum has a well-known token standard called ERC-20, and people arriving from that world assume there must be a BRC-20 to match. There is not, and this document exists to say so plainly and stop the confusion spreading further.

  • 92

    Mandala Token Protocol (Withdrawn)Withdrawn by the author.

    Token schemes tend to accumulate rules until they are hard to implement twice the same way. This keeps issuing, transferring, recovering and redeeming a token as small as it can reasonably be.

  • 156

    Latched 1Sat Provenance for Basket 1sat (Withdrawn)Withdrawn by the author. Do not implement.

    Sometimes a standards document gets written, then the people behind it change plans and stop building what it described. If nothing marks that document as dead, other developers can still find it, assume it works, and build against something that was never finished or safe to use. This document exists to stop that from happening by pointing everyone to the real, working approach instead.

  • 200

    Operating Practices for Identity Certifiers

    Anyone can sign a digital certificate claiming something about you, like "this email belongs to this person," but a valid signature by itself does not tell you whether the signer actually checked anything, how they handle mistakes, or what happens if the claim turns out to be wrong. Without shared ground rules, two issuers using the same certificate format could have wildly different (or nonexistent) verification practices, leaving anyone relying on the certificate with no way to judge it.

  • 234

    A Shared Schedule for Reducing Free Blockchain Index Coverage

    Free blockchain explorer lookups (finding a transaction or checking an address's history by typing its ID) feel like a permanent utility, but someone pays in storage, bandwidth and recovery costs for every address and transaction they index forever. Apps and wallets that rely entirely on a provider's free lookups have no warning if that provider decides to narrow what it indexes for free, and no shared playbook for what "narrower" would even mean. This proposal gives providers a common, predictable schedule for shrinking free coverage, so apps can plan ahead instead of being surprised.

Usually read alongside

Concepts that keep appearing on the same standards as this one.

Was this helpful?

Search Beersy

Search standards by number, title, author or topic