A sovereign social network
powered by Bitcoin

I totally agree. To better document these architectural trade-offs and ensure that both developers and end-users grasp the distinction between direct interaction and relay-based interaction, we must structure information in a way that makes the invisible—the path taken by the data—visible.
Below are the strategic pillars for formalizing this technical clarity, followed by a proposal to delve deeper into the most critical aspect.

1. An Architectural Transparency Matrix
   Vague terminology should be replaced with rigorous comparative documentation that evaluates each tool (such as BRC-100 or MessageBox) based on criteria of sovereignty:
   • Network Topology: Is the transaction Peer-to-Peer (direct between nodes/users) or Peer-to-Relay-to-Peer?
   • Trust Model: Can the relay censor, delay, or observe (compromising privacy) the message before it is recorded on the blockchain?
   • Infrastructure Dependency: If the relay (e.g., the Babbage project) shuts down its servers, does the application still function—even in a degraded state?
2. UI/UX Standardization: "Sovereignty Levels"
   Much like permission systems in mobile operating systems (iOS/Android), BSV wallets and applications should incorporate standardized visual indicators for the user:
   • Green / Direct: Transaction signed and sent directly to the network (via SPV, Merchant API, or ARC). Maximum sovereignty.
   • Orange / Hybrid: Utilizes a "Trust Anchor" or a Metanet handle resolver based on a third-party DNS.
   • Blue / Relay: Routed through an asynchronous messaging protocol (e.g., MessageBox). Offers high convenience, but relies on a third party for message delivery. 3. Documentation Focused on the "Minimum Mechanism Principle"
   Official documentation (notably that of the BSV Association) should be rewritten to shift the narrative burden. Direct use of the protocol—native Bitcoin scripts and direct transactions—should be presented as the "Zero Standard." Abstractions should not be framed as "the modern way to code," but rather as "convenience-oriented optimizations that come with trade-offs."
   A Topic Requiring Special Attention
   Among the elements you mentioned, the specification for addressing and resolving universal identifiers ("handles") for the Metanet—linked to the publication of details via a "trust anchor" or domain name—is the most critical point.
   A "handle" system is often the primary entry point for centralization: if the resolution of a peer-to-peer identity relies on traditional DNS (ICANN) or a third-party server that translates the handle into a public key or IP address, we end up recreating the very "gatekeeper" model that Bitcoin is designed to eliminate.
   Would you like us to outline the technical approach for this specific issue? More precisely, we could detail:
3. How to design a handle resolution system that is strictly local and based on SPV proofs (without querying a third-party API server).
4. How to link a "trust anchor" immutably on-chain, without depending on the long-term persistence of a traditional internet domain name.

Under these conditions, how is the user supposed to make a choice?

For a user to be able to make genuine choices within this ecosystem, the selection process must not require technical expertise in cryptography or network architecture. Instead, it should involve clear trade-offs regarding cost, speed, privacy, and long-term durability.
Here is how a user can make practical choices, facilitated by specific interface mechanisms and tailored economic models:

1. Choosing via the "Sovereignty Slider" (User Interface)
   When confirming an action—such as making a payment, sending a Metanet message, or publishing data—the wallet or application should not obscure the transmission method. It should offer an explicit choice, for instance, through three distinct modes:
   • Sovereign Mode (Direct):
   • How it works: The application generates the transaction, signs it, and sends it directly to the miners (via ARC/MAPI).
   • Why choose it: Complete privacy, immunity to censorship, and maximum resilience (even if the application developer disappears, the data remains permanently recorded).
   • Trade-off: The recipient must be online to receive any associated off-chain data, and network fees may be slightly higher.
   • Connected Mode (Hybrid / Trusted Anchor):
   • How it works: You use a simplified identifier (a "handle"), the validity of which is verified via a domain name or a shared registry.
   • Why choose it: Ease of use—it avoids the need to handle raw public keys—while still maintaining control over your own signing keys.
   • Convenience Mode (Relay / Asynchronous):
   • How it works: The transaction or message is routed through a third-party server (such as MessageBox), which stores it and delivers it to the recipient once they come online. • Why choose it: Ideal for everyday messaging, asynchronous interactions, or small, recurring payments.
   • Trade-off: The relay can see the metadata (who is talking to whom) and represents a single point of failure.
2. Choosing based on the true cost (Economic Model)
   The Bitcoin (BSV) protocol uses tiny but real transaction fees for every direct action on the ledger. Using a relay introduces a different economic model that the user can evaluate:
   • Pay-per-transaction (Direct): The user pays only the miners. This is the price for raw, immutable security.
   • Subscription or Ad-supported (Relay): The relay might offer free messaging in exchange for collecting metadata, or charge a flat fee to keep its servers running.
   The user can then choose their preferred model: paying a fraction of a cent for their freedom, or accepting a third party for the sake of convenience.
3. Reversibility: The ability to "take back one's assets"
   The ultimate criterion for a user should be the absence of vendor lock-in. If a user chooses the convenience of a relay (such as Babbage or a BRC-100 tool) to get started, they must be able to change their mind at any time.
   • Documentation and tools must ensure that private keys and historical data stored by the relay can be instantly exported for use in a "Direct / SPV" mode.
   If we want to empower users with this choice, the key lies in identity management.

Given that BRC100 will be coupled with the Teranode architecture, how can the element of choice be preserved?

The integration of BRC-100 into the Teranode architecture fundamentally changes the landscape. Teranode is designed to process massive transaction volumes—exceeding one million transactions per second—directly at the mining layer. If BRC-100 becomes the standard for indexing or routing—natively supported or optimized by these "super-nodes"—there is a risk that the "choice" to engage in raw, unmediated interaction could become economically or technically marginalized.
To ensure that users and developers retain a genuine choice in the face of Teranode’s immense power, action must be taken across three specific technical areas: direct access to node APIs, local validation (SPV), and open abstraction within wallet SDKs.
The following technical approach is required to preserve this sovereignty:

1. Guaranteeing "Raw Channels" on Teranode
   Teranode exposes ultra-fast interfaces—such as gRPC streams or high-throughput WebSockets—for the mass injection of transactions. To maintain freedom of choice, infrastructure specifications must mandate neutrality for these access points:
   • Script Non-Discrimination: A Teranode node must accept any native Bitcoin transaction (e.g., a complex multisig script or a direct peer-to-peer messaging transaction) with the same priority and pricing rules (fees per byte) as a transaction formatted according to BRC-100 standards.
   • Non-Indexed Public Endpoints: The ecosystem must maintain standardized access points (such as MAPI or ARC) that allow for the submission of "raw" Bitcoin transactions, without requiring the application to register with a BRC-100 indexer or relay. 2. Local SPV (Simplified Payment Verification) as a Countervailing Power
   If Teranode centralizes processing power and global indexing, the user's wallet must necessarily act as a countervailing power by validating its own data locally.
   • Systematic Merkle Proofs: Even if a transaction utilizes a BRC-100 abstraction optimized by Teranode, the wallet must require and store the Merkle proof directly on the user's device.
   • State Independence: Should a Teranode node’s BRC-100 indexer fail or impose censorship, the user must be able to reconstruct the state of their tokens or messages using only their local SPV proofs and block headers.
2. Implementing an "Architectural Fork" Mode in the Wallet SDK
   The user's choice is realized at the level of the wallet code (Wallet SDK). The SDK must be designed to "fork" its routing mode transparently:

To formalize this choice within the software architecture (at the Wallet SDK level), we must design a dynamic routing mechanism. The application prepares the user's intent, but it is the wallet's network and cryptographic layer that determines the final structure of the transaction.
Below is a detailed technical breakdown of this decision-making flow and the specifications for each option.

1. The Intent Data Structure (User Action)
   When a user clicks "Send," the application does not directly construct a Bitcoin transaction. Instead, it issues an abstract intent object, referred to as a UserAction. This object contains only the raw data and the destination, without making any assumptions about the transmission channel.

interface UserAction {
type: 'PAYMENT' | 'MESSAGE' | 'DATA_ANCHOR';
destination: string; // Peut être une clé publique, un Paymail, ou un Handle Metanet
payload: Uint8Array; // Le message ou les métadonnées
amountSatoshis: number;
preference: 'SPEED' | 'SOVEREIGNTY' | 'BALANCED';
}

2. Specifications for Option A: The Teranode / BRC-100 Path
   This option is activated when the preference is set to SPEED, or for high-volume actions (e.g., recurring micro-payments in a video game or an IoT sensor data stream).
   Technical Mechanism
3. BRC-100 Serialization: The SDK encapsulates the payload into a standardized JSON or Protobuf structure, compliant with Teranode indexing schemas (e.g., token state protocols or application routing).
4. Envelope Script Creation: The data is typically embedded within a script containing an OP_FALSE OP_IF opcode (a data envelope) or an inscription-style format natively recognized by Teranode indexing modules.
5. Injection via Teranode gRPC/API: The signed transaction is sent directly to a specific Teranode endpoint (e.g., ARC or a supernode’s gRPC interface) capable of processing millions of requests per second. The node validates the BRC-100 state instantaneously within global RAM.
   Advantages & Limitations
   • Performance: Near real-time processing, ideal for distributed computing or mass-scale DeFi.
   • Visibility: The transaction is immediately indexed by the network, allowing third parties to query the global state via a simple API.
   • Risk: If Teranode changes its indexing rules or restricts API access to certified partners, the user experiences a loss of autonomy (a risk of "gatekeeping").
6. Specifications for Option B: The Direct Peer-to-Peer Path
   This option is activated when the preference is set to SOVEREIGNTY, or when an action requires absolute confidentiality. Technical Mechanism
7. Native Bitcoin Script Construction: The SDK bypasses any protocol overlays or indexing layers. It constructs a raw, standardized Bitcoin script (e.g., P2PKH for a payment, or a custom multi-script output to link data to a public key).
8. Isolated Local Signing: The transaction is signed offline on the device (via a secure enclave or a hardware wallet). No application metadata is exposed during this process.
9. Direct Routing (Out-of-Band SPV): If the action involves a human recipient, the SDK first attempts to send the transaction directly to the recipient’s wallet (via an IP-to-IP connection, WebRTC, or a peer-to-peer transport protocol). The recipient receives the raw transaction, verifies its validity locally using their own block headers, and then handles the broadcast.
10. Raw Broadcast: The transaction is injected into the mining network in an agnostic manner—for instance, by using the base Bitcoin P2P protocol (via listening nodes)—without relying on Teranode’s application-level indexing APIs.

Advantages & Limitations
• Absolute Sovereignty: No entity—not even the application publisher or the Teranode operator—can censor a transaction, provided that standard mining fees are paid. The ledger serves solely to validate timestamps and ensure that no double-spending occurs.
• Confidentiality: No application metadata is leaked to central indexers. Only the sender and the receiver are privy to the semantics of the transaction.
• Counterparty Requirements: Less suitable for large-scale asynchronous interactions if the recipient is not online to receive their off-chain data.
Fallback Mechanism within the Wallet SDK
To ensure the neutrality of the ecosystem, the SDK code must implement an automatic fallback logic:

async function processUserAction(action: UserAction): Promise {
if (action.preference === 'SPEED') {
try {
return await routeViaTeranodeBRC100(action);
} catch (error) {
console.warn("Échec du relais Teranode, repli sur le mode souverain direct...");
return await routeViaDirectP2P(action);
}
} else {
return await routeViaDirectP2P(action);
}
}

This architecture preserves choice: Teranode becomes an optional accelerator rather than a mandatory step.

To preserve this choice, the SDK must not logically link the user's address to a BRC-100 account. Private keys must remain strictly agnostic. The priority technical course of action
To anchor this architectural resistance in reality, the most immediate point of contention lies with wallets (Wallet SDK). If wallets capitulate and—for the sake of convenience—implement only the Teranode/BRC-100 path, the choice will vanish for the end user.