When a directory
becomes a gate.

A directory helps people find and understand a service. When losing access to that directory prevents an otherwise supported operation, the directory has acquired a second job. It has become a gate.

This can happen without a dramatic change to the underlying network. A wallet consults a helpful catalogue before displaying a permission request. The catalogue supplies a familiar name, an explanation and an icon. Then someone makes a successful lookup a condition of displaying the request at all. A convenience has become a dependency, and the catalogue operator now influences who can reach the user.

For BSV, that is a practical decentralisation question. Stable transaction rules leave room for competing applications and independent implementations. The freedom becomes less useful if a separate descriptive service can prevent customers from using those implementations. The relevant test is what happens when the description disappears.

1. Define what the listing means

BRC-184, Optional Metadata Registries and Their Stewardship, credited to Ty Everett, addresses this boundary. It describes ProtoMap, BasketMap and CertMap as sources of human-readable information about protocol identifiers, output baskets and certificate types. Its wallet consumption profile is proposed behaviour for implementations claiming to follow it. It is not evidence that every installed wallet already behaves that way.

A protocol description can explain a requested operation. A basket description can explain the intended use of a group of outputs. A certificate-type description can explain its fields. None of those descriptions supplies the user's permission to act. In particular, recognising a certificate's type does not establish trust in the issuer who signed a particular certificate.

The distinction should survive the interface. A friendly name belongs beside the exact identifier and relevant request details, rather than replacing them. Under the proposal, ProtoMap identifies a protocol using both its security level and protocol string. The network and publisher also matter when identifying a particular publisher's record. Two publishers describing the same protocol are making two attributable statements.

These details are easy to dismiss as implementation bookkeeping. They become important when a user sees the same familiar label attached to different requests, or when two publishers disagree about its meaning. A product cannot resolve that disagreement simply by removing the identity information that would let someone examine it.

2. Make the fallback a normal route

The BRC-184 profile requires an otherwise valid, supported operation to remain available when optional metadata is missing, withdrawn, disputed or unavailable. The ordinary permission process still applies. A user may refuse the operation; the wallet may reject an unsupported module or reserved administrative identifier. Those are independent reasons, rather than consequences of an absent description.

This is a precise engineering distinction. Continuing without a friendly description does not mean automatically approving a request. The fallback must preserve the user's choice and display enough of the actual request to make that choice possible. A registry outage must neither approve the operation nor become an additional veto.

I would begin the implementation from that fallback. Construct the permission request from its authenticated application context and exact operation. Allow a bounded descriptive lookup to enrich the display. If the lookup fails, retain the request. If metadata arrives late, do not silently change the counterparty, amount or permission scope the user was considering.

Consider a hypothetical wallet with a two-second lookup budget. A supplier could return a useful description in half a second, return no record, or fail to answer. The budget is an illustrative product choice, not a BRC requirement or a recommended universal timeout. The invariant is the important part: those three metadata outcomes must not turn one underlying request into three different grants of authority.

A useful review would include a delayed response arriving after the user has declined. It would also include a changed description arriving while the prompt is open. In neither case should presentation data reopen the decision or expand consent. These are proposed interface tests, not results from testing a named wallet.

3. Separate attribution from currentness

The payment-evidence article examined what a signed statement can establish. A similar issue appears in a directory. A valid signature can attribute a description to its publisher. It does not establish that the description is accurate, current or complete.

BRC-184's informative account of existing publication tooling describes registry updates as spending an earlier output and creating a replacement. Withdrawal spends the record without replacing it. That withdraws the publisher's current description; it does not revoke a certificate, change wallet grants or prohibit the identifier being described.

A cached signed record therefore presents two questions. Who published these bytes? Is this the current record the service claims to show? A correct answer to the first does not supply the second. A replica can preserve authentic history while still being out of date.

The proposal also separates the publisher from the host serving an index. Replicating available public records does not give the replica the publisher's private signing key. A new publisher can issue its own descriptions, but should not impersonate the former publisher. This preserves independent operation without pretending that provenance is interchangeable.

For a customer, these are different service promises. An archive may promise faithful historical retrieval. A live directory may promise timely updates under a stated synchronization process. A wallet may promise that stale metadata cannot enlarge a permission. Combining those promises into an unexplained badge makes responsibility harder to assign when something fails.

4. Test whether changing supplier changes authority

A choice of publishers is meaningful when changing that choice changes the descriptive service without unexpectedly changing the user's assets or existing grants. BRC-184 recommends a documented way to replace or disable metadata sources without disabling the underlying protocols or requiring funds to move. That is a recommendation within the proposed profile, not a claim that migration is already effortless in every product.

I would test the separation with a controlled substitution. Keep the application request, wallet policy and user decision fixed. Consult publisher A, then publisher B, then no publisher. Record the displayed descriptions and the resulting permission state separately. Differences in wording may be expected; an unexplained difference in the underlying permission requires investigation.

The comparison must also distinguish registry-publisher selection from certificate-issuer trust. Choosing a publisher to explain a certificate type should not quietly authorise that publisher, or every issuer using the type, to make trusted claims about the user. If an implementation couples those settings, the coupling needs to be visible rather than buried in a convenient shared configuration field.

The same restraint applies to security incident response. Rejecting an unsafe image or unauthenticated description is sensible. Treating its rejection as a ban on an otherwise supported protocol gives a descriptive channel more power than the profile assigns it. A separate, independently authorised application policy may impose restrictions, but it should identify its actual basis.

5. Count the operations hidden by an outage

Scaling the base network does not remove the bottleneck created by a compulsory lookup in an application. If every permission prompt waits for one catalogue, the catalogue's availability becomes part of the application's availability. Adding more transaction capacity elsewhere does not repair that dependency.

Here is an invented comparison, not a measurement. A test submits 1,000 otherwise supported requests while the metadata service answers 950 lookups and times out on 50. A design that suppresses those 50 prompts has made only 95 per cent of the submitted requests available for normal user consideration. A working fallback can present all 1,000, with 50 lacking the optional description. This says nothing about how many users approve, how many transactions are created, or how many are mined.

The denominator matters. Reporting response time only for the 950 successful lookups can describe that subset accurately while concealing the 50 excluded requests. A service comparison should retain unavailable descriptions, delayed prompts, abandoned decisions and user denials as distinct outcomes. Otherwise, a fast catalogue can appear to deliver a fast wallet merely by excluding the work it did not finish.

Multiple directory hosts can improve availability, but their count alone does not establish independence. Hosts may share an upstream index, network provider, publisher or synchronization defect. I would include a common-upstream outage in the proposed evaluation and record which service promise actually fails. This is an operational hypothesis to test, not a measured reliability claim about existing BSV services.

6. Stewardship needs a usable exit

The registry submission guide distinguishes BRC publication from publication by a particular registry operator. A merged proposal does not automatically create a registry record or distribute it to every operator. The guide describes an initial stewardship process, not an established universal accreditation body or guaranteed appeals timetable.

That modest scope is useful. Publishers can compete on clarity, maintenance, responsiveness and the quality of their evidence. They can publish reasons for corrections and preserve the history of disputes. Users and wallet implementers can choose different sources. The existence of a review process need not give that process authority over who may build.

There is still responsibility. A publisher should answer for misleading descriptions it signs. A host should describe the freshness and availability it actually supplies. A wallet implementer should preserve the boundary between display information and permission. An application supplier should explain its request accurately. Independent operation does not dissolve those duties into an anonymous network.

I favour fixed BSV base rules and competition above them because that arrangement leaves room for better implementations to displace weaker ones. A voluntary directory can support the competition by reducing the effort needed to understand a request. Its most important architectural safeguard is the ordinary path that continues to work when the directory is absent.