From 0a9075b0bfc1111a563761aaa619d7dc0b8a0dcd Mon Sep 17 00:00:00 2001 From: Luke Rohenaz Date: Fri, 4 Sep 2026 17:09:45 -0400 Subject: [PATCH] =?UTF-8?q?docs:=20propose=20BRC-187=20Bitcoin=20Schema=20?= =?UTF-8?q?=E2=80=94=20Social=20Data=20Types?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 1 + SUMMARY.md | 1 + apps/0187.md | 183 +++++++++++++++++++++++++++++++++++++++++++++++++ apps/README.md | 1 + 4 files changed, 186 insertions(+) create mode 100644 apps/0187.md diff --git a/README.md b/README.md index 100a9bbf..63a82fc6 100644 --- a/README.md +++ b/README.md @@ -238,6 +238,7 @@ BRC | Standard 174 | [Consensus-Unique Name Tokens — Identity Binding and Verified Resolution](./tokens/0174.md) 176 | [BSV-21 — Validity Proofs](./tokens/0176.md) 177 | [Wallet-Enforced Expiry for `noSend` Actions](./wallet/0177.md) +187 | [Bitcoin Schema — Social Data Types](./apps/0187.md) 190 | [Access Gates for Metanet Rooms](./apps/0190.md) 210 | [Derived Collectibles](./apps/0210.md) 218 | [Chat-Native Command Grammar for the Metanet](./apps/0218.md) diff --git a/SUMMARY.md b/SUMMARY.md index 11501cf9..fcb61963 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -15,6 +15,7 @@ * [Registry-Free Typed Content Anchor with On-Chain Code Provenance](./apps/0145.md) * [Verifiable Time Allocation](./apps/0168.md) * [Locked Content Header (LCH) — Licensed, Micropayment-Enabled Content](./apps/0170.md) +* [Bitcoin Schema — Social Data Types](./apps/0187.md) * [Access Gates for Metanet Rooms](./apps/0190.md) * [Derived Collectibles](./apps/0210.md) * [Chat-Native Command Grammar for the Metanet](./apps/0218.md) diff --git a/apps/0187.md b/apps/0187.md new file mode 100644 index 00000000..fa0e4285 --- /dev/null +++ b/apps/0187.md @@ -0,0 +1,183 @@ +# BRC-187: Bitcoin Schema — Social Data Types + +Open Protocol Labs (info@opl.dev) + +**Authors:** Luke Rohenaz (luke@opl.dev) + +**Contributors:** Austin Rappaport (MrZ), Kurt Wuckert Jr. (kurt@opl.dev), David Case (dcase@opl.dev), Michael Boyd (root@opl.dev), Dan Wagner (dan@opl.dev) + +## Abstract + +Bitcoin Schema is a community-driven collection of extensible data schemas that enable interoperable, data-based applications on Bitcoin SV — inspired by Schema.org's role on the web. This BRC specifies the **social core** of Bitcoin Schema: the composition model (content in B, attributes in MAP, authorship in AIP) and the on-chain record types for social applications — `post`, reply, `repost`, `like`, `unlike`, `follow`, `unfollow`, `friend`, `message`, tags, and attachments. Records written to these schemas can be indexed and queried to build full-featured social platforms whose data is shared across applications. + +Bitcoin Schema also defines further schema families (generic payments, on-chain functions, an on-chain package registry, token schemas); those are out of scope here and may become follow-on BRCs. + +## Motivation + +Interoperability between on-chain applications requires shared vocabulary, not just shared protocols. B ([BRC-180](https://github.com/opldotdev/BRCs/blob/codex/brc-180-b-protocol/scripts/0180.md)) says how to store content, MAP ([BRC-182](https://github.com/opldotdev/BRCs/blob/codex/brc-182-map/scripts/0182.md)) says how to attach attributes, and AIP ([BRC-181](https://github.com/opldotdev/BRCs/blob/codex/brc-181-aip/scripts/0181.md)) says how to sign — but none of them say that a post is `type post` or that a like names its target with a `tx` key. Bitcoin Schema supplies that layer: a common set of `type` values and key vocabularies so that a post written by one application renders in every other application that speaks the schema. + +The pioneering prior work for on-chain social data is the **Memo protocol** by Jason Chavannes, which first demonstrated posts, replies, likes, follows, topics, and profiles as OP_RETURN records, each action under its own fixed binary prefix. Bitcoin Schema generalizes that action vocabulary onto the composable B / MAP / AIP stack — extensible key/value attributes in a shared namespace instead of fixed per-action prefixes — and the original MAP specification documents this lineage directly, mapping Memo's operations to their MAP equivalents. + +## Specification + +The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. + +### 1. Composition Model + +Every Bitcoin Schema social record is a data-carrier output composed with the [BRC-179](https://github.com/opldotdev/BRCs/blob/codex/brc-179-bitcom/scripts/0179.md) pipeline: + +``` +[B ] | MAP SET app type [ ...] | AIP
+``` + +- **Content** (when the type carries content) is a B segment ([BRC-180](https://github.com/opldotdev/BRCs/blob/codex/brc-180-b-protocol/scripts/0180.md)). +- **Attributes** are a MAP `SET` segment ([BRC-182](https://github.com/opldotdev/BRCs/blob/codex/brc-182-map/scripts/0182.md)) carrying at minimum `app` (the producing application's name) and `type` (the schema type). +- **Authorship** is an AIP signature ([BRC-181](https://github.com/opldotdev/BRCs/blob/codex/brc-181-aip/scripts/0181.md)) covering the fields to its left. Records SHOULD be AIP-signed; unsigned records have no verifiable author. +- **Identity** references use BAP identity keys ([BRC-186](https://github.com/opldotdev/BRCs/blob/codex/brc-186-bap/peer-to-peer/0186.md)) under the key `bapID`. + +### Record interpretation and scope + +The examples below use protocol names as shorthand for their full identifiers, as specified in BRC-179 through BRC-182. Quoted text denotes UTF-8 push bytes, `|` denotes the pushed Bitcom separator, and angle brackets denote placeholders, not literal script bytes. Each content or action record occupies its own output. Tag and attachment outputs are supplemental and need not contain `app` or `type`. + +`app` labels the producing application; it is not an authenticated application identity. `bapID` in `follow`, `friend` or a recipient context names the target, not the author. Resolve the author from a valid covering AIP signature, and, when persistent identity is needed, the BAP history valid for that signing key. An AIP signature selecting only unrelated fields MUST NOT be presented as authentication of the full social record. An unverified signature or unavailable identity history must remain distinguishable from a verified author. + +A `tx` target is a displayed 64-hex-character transaction id, not an output index or an underscore/dot outpoint. It targets the transaction-level social object. A transaction containing multiple independent primary social records is ambiguous to these legacy `tx` references; this proposal does not reinterpret old identifiers to select one output. Applications requiring output-level targets need a separate extension. + +Readers MUST retain the distinction between absent and malformed required fields. A record lacking the required B segment or target key is not a valid instance of that type. Unknown types may be retained as extension records. Implementations should bound script, content and metadata parsing work; parser failure does not invalidate the underlying Bitcoin transaction. + +### 2. Type Vocabulary + +This document defines the following `type` values: + +| `type` | Content segment | Purpose | +|--------|-----------------|---------| +| `post` | B (required) | New content published to the network | +| `repost` | none | Amplify an existing post by txid | +| `like` | none | Positive sentiment about a target | +| `unlike` | none | Undo a like | +| `follow` | none | One-way relationship to an identity | +| `unfollow` | none | Remove a follow | +| `friend` | none | Two-way relationship request with key exchange | +| `message` | B (required) | Real-time chat content (separate namespace from `post`) | + +A reply is not a distinct type: it is a `post` with a transaction context (Section 4). + +### 3. Context and Subcontext + +Types MAY carry an optional context for categorization and threading, expressed with a consistent key pattern: the `context` key names **which key** serves as the context, and that named key carries the value. `subcontext` works identically: + +``` +context [subcontext ] +``` + +Examples of the pattern: + +- Reply threading: `context tx tx ` — the context is the `tx` key, whose value is the parent post's txid. +- Channel chat: `context channel channel my-chatroom` +- Private message: `context bapID bapID ` +- Platform integration: `context provider provider youtube subcontext videoID videoID ` — e.g. commenting on a YouTube video. +- Physical products: a UPC code as context for product reviews. + +Context determines rendering and view placement; tags (Section 6) are general-purpose metadata that do not. + +### 4. Content Types + +**Post:** + +``` +B | MAP SET app type post | AIP BITCOIN_ECDSA
+``` + +Content may be plain text, markdown, images, or any media B supports. + +**Reply** — a post whose context is the parent transaction: + +``` +B | MAP SET app type post context tx tx | AIP BITCOIN_ECDSA
+``` + +**Repost** — amplifies existing content without duplicating it; MAY add new context/subcontext, surfacing the original in additional contexts (for example reposting a UPC-context product comment with a `url` context so it appears in web-oriented apps): + +``` +MAP SET app type repost tx | AIP BITCOIN_ECDSA
+``` + +**Message** — like a post but in a separate namespace intended for real-time chat. Global, channel-scoped, and private forms: + +``` +B | MAP SET app type message | AIP ... +B | MAP SET app type message context channel channel | AIP ... +B | MAP SET app type message context bapID bapID | AIP ... +``` + +### 5. Action Types + +**Like / Unlike** — sentiment about a target named by a global identifier key (most commonly `tx`): + +``` +MAP SET app type like tx | AIP BITCOIN_ECDSA
+MAP SET app type unlike tx | AIP BITCOIN_ECDSA
+``` + +**Follow / Unfollow** — one-way relationships between identities: + +``` +MAP SET app type follow bapID | AIP BITCOIN_ECDSA
+MAP SET app type unfollow bapID | AIP BITCOIN_ECDSA
+``` + +**Friend** — a relationship request carrying a `publicKey` for potential future communication. A single record does not prove that the counterparty reciprocated. Historical documentation derives this key using the SHA-256 hash of the counterparty's BAP identity key and the BAP library's `getSigningPathFromHex`. This reference is informative: a library function name does not specify a portable key-agreement protocol. The record vocabulary below does not standardize derivation, encryption, key confirmation or secure messaging; applications need a separately specified, versioned agreement to use the key: + +``` +MAP SET app type friend bapID publicKey | AIP BITCOIN_ECDSA
+``` + +**Action state resolution:** these schemas describe action records. The canonical social-action documentation does not specify a consensus state-reduction algorithm. Applications that reduce `like`/`unlike` or `follow`/`unfollow` into current state MUST document identity resolution, duplicate/replay treatment, transaction and output tie-breaking, unconfirmed-event policy and reorganization rollback. Such policies are application behavior, not an existing universal “latest blockchain order” rule. Preserve the underlying records when exchanging data across applications. + +### 6. Tags + +Tags categorize content for search and filtering, carried as a MAP `ADD` (list semantics, [BRC-182](https://github.com/opldotdev/BRCs/blob/codex/brc-182-map/scripts/0182.md)) in an additional output of the same transaction: + +``` +MAP ADD tags ... | AIP BITCOIN_ECDSA
+``` + +### 7. Attachments + +Attachments carry rich media alongside a post or message, each as a separate B output ([BRC-180](https://github.com/opldotdev/BRCs/blob/codex/brc-180-b-protocol/scripts/0180.md)) in the same transaction, AIP-signed like any other output: + +``` +output n: B | AIP BITCOIN_ECDSA
+output n+1: B | AIP BITCOIN_ECDSA
+``` + +The legacy schema links supplemental outputs by transaction co-location, without an explicit primary-output pointer. Producers SHOULD use one primary post or message per transaction when relying on this convention. Readers MUST NOT infer that a signature on the primary output covers another output; verify supplemental output signatures independently. Multiple primary records leave attachment ownership ambiguous and require application policy, not an invented universal association rule. + +Any media type is supported: text formats (HTML, CSS, JavaScript, Markdown), images, audio, video, and binary documents. + +### 8. Extensibility + +The schema set is deliberately open: applications MAY define additional keys on any type, and readers MUST ignore keys they do not implement. New types and schema families are added through the community process at bitcoinschema.org. + +## Security Considerations + +- **Unsigned records** — anything can be written under any `app` name and `type`; only the AIP signature binds a record to an author, and only a BAP identity chain ([BRC-186](https://github.com/opldotdev/BRCs/blob/codex/brc-186-bap/peer-to-peer/0186.md)) binds that author to a persistent identity. Indexers SHOULD treat unsigned records as anonymous and unverifiable. +- **Private messages are not encrypted by this schema** — `context bapID` scopes delivery, not confidentiality. Confidential payloads require encryption at the content layer (under a separately specified encryption and authenticated key-agreement protocol). +- **Action replay** — AIP authenticates its signed fields; it does not make a record unique to one transaction. Re-publication can duplicate signed records. A reducer must define deduplication and reorganization handling without claiming this schema supplies a global ordering rule. + +## Implementations and interoperability status + +The primary schema documentation is [Social Actions](https://bitcoinschema.org/docs/schemas/social-actions), [Content Publishing](https://bitcoinschema.org/docs/schemas/content) and [Messaging](https://bitcoinschema.org/docs/schemas/messaging). The [documentation source](https://github.com/b-open-io/bitcoinschema) records the vocabulary and examples. The [1sat-stack BSocial module](https://github.com/b-open-io/1sat-stack/tree/master/pkg/bsocial) is an implementation reference for indexing. + +This proposal codifies the record vocabulary. It does not claim that existing applications share one action reducer, friendship key-agreement implementation or multi-primary attachment rule. Those boundaries require additional profiles and conformance fixtures before a stronger interoperability claim can be made. + +## References + +- Bitcoin Schema documentation (canonical): https://bitcoinschema.org/docs +- [BRC-179: Bitcom](https://github.com/opldotdev/BRCs/blob/codex/brc-179-bitcom/scripts/0179.md) — pipeline composition +- [BRC-180: B — Bitcoin Data Protocol](https://github.com/opldotdev/BRCs/blob/codex/brc-180-b-protocol/scripts/0180.md) — content and attachments +- [BRC-181: AIP — Author Identity Protocol](https://github.com/opldotdev/BRCs/blob/codex/brc-181-aip/scripts/0181.md) — authorship signatures +- [BRC-182: MAP — Magic Attribute Protocol](https://github.com/opldotdev/BRCs/blob/codex/brc-182-map/scripts/0182.md) — attribute layer (`SET`, `ADD`) +- [BRC-186: BAP — Bitcoin Attestation Protocol](https://github.com/opldotdev/BRCs/blob/codex/brc-186-bap/peer-to-peer/0186.md) — identity keys referenced by `bapID` +- Schema.org (inspiration): https://schema.org +- Memo protocol (Jason Chavannes) — pioneering prior work for on-chain social actions: https://memo.sv/protocol diff --git a/apps/README.md b/apps/README.md index dec752a1..984e9b53 100644 --- a/apps/README.md +++ b/apps/README.md @@ -9,6 +9,7 @@ BRC | Standard 145 | [Registry-Free Typed Content Anchor with On-Chain Code Provenance](./0145.md) 168 | [Verifiable Time Allocation](./0168.md) 170 | [Locked Content Header (LCH) — Licensed, Micropayment-Enabled Content](./0170.md) +187 | [Bitcoin Schema — Social Data Types](./0187.md) 190 | [Access Gates for Metanet Rooms](./0190.md) 210 | [Derived Collectibles](./0210.md) 218 | [Chat-Native Command Grammar for the Metanet](./0218.md)