BRC-87

Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services

Independent implementations picking their own names for the same index or query will not interoperate. This proposes naming conventions so a name means the same thing wherever it appears.

Ty Everett7 Jun 20242 min read

Why: Overlay network nodes running BRC-22 topic managers and BRC-24 lookup services had no shared naming convention, making it hard to find equivalent services across different node operators.
What: BRC-87 is a naming convention that standardizes how BRC-22 topic manager names and BRC-24 lookup service names are written, so equivalent services share the same name across nodes.
How: A developer names a topic manager with a tm_ prefix and a lookup service with an ls_ prefix, followed by a short lowercase descriptor using only letters and underscores, keeping the whole name under 50 characters and avoiding leading, trailing, or doubled underscores.

What this lets you do

Name a BRC-22 topic manager with the tm_ prefix, like tm_uhrp_files
Name a BRC-24 lookup service with the ls_ prefix, like ls_uhrp_files
Coordinate with other node operators to agree on shared names for the same protocol
Rely on consistent names to find equivalent services if one node goes down
Check a proposed name against the master rules before deploying it

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

Reference for an AI

Everything an assistant needs to answer questions about BRC-87 accurately, including what it depends on.

The specification

Read the original

Abstract

This document proposes standardized naming conventions for topic managers in BRC-22 and lookup services in BRC-24 to ensure clarity, interoperability, and uniformity across different implementations. The goal is to provide consistent and easily understandable names that facilitate efficient communication and integration between overlay network nodes and services within the BSV ecosystem.

Motivation

Currently, there is no unified naming convention for topic managers and lookup services utilized in BRC-22 and BRC-24 standards. This absence can lead to confusion and errors in integration.

Specification

Naming Consistency Across Nodes

Network services that deal with the same transactions and protocols should negotiate to agree upon a common name for their topic managers and lookup services. This ensures resiliency, in that network users are able to access the same services at known locations across nodes, even if one node in an overlay network goes down. It also aids node operators in synchronizing relevant transactions with one another.

General Guidelines

Consistency: Names should be consistent across different implementations to avoid ambiguity.
Clarity: Names should be clear and descriptive enough for developers to understand their purpose.
Length: While names should be descriptive, they should also be concise to ensure ease of use in configurations and codebases.

Master Rules

Only lower-case letters and underscores.
Must not start or end with an underscore.
No consecutive underscores.
No longer than 50 characters.

Naming Conventions for BRC-22 Topic Managers

Prefix: Use the prefix tm_ to indicate a topic manager.
Topic Identifier: Follow the prefix with a short descriptor of the topic.
Example:
- tm_uhrp_files
- tm_tempo_songs

Naming Conventions for BRC-24 Lookup Services

Prefix: Use the prefix ls_ to denote a lookup service.
Service Identifier: Follow the prefix with a brief descriptor of the lookup service functionality.
Example:
- ls_uhrp_files
- ls_tempo_songs_search

Implementation

Each overlay network node and service provider must update their naming conventions to comply with the standardized guidelines described in this document. This update involves renaming existing topic managers and lookup services accordingly and ensuring that new implementations follow these standardized conventions.

By standardizing naming conventions for topic managers and lookup services, we can significantly enhance the clarity, consistency, and interoperability of overlay networks on the BSV blockchain.

Was this helpful?

Summary