OPL protocol corpus: Bitcom, B, AIP, MAP, Sigma, Addressing, 1Sat series, BAP, Bitcoin Schema (300-312)

README.md

@@ -229,6 +229,20 @@ BRC | Standard
 225  | [Animated-QR Air-Gap Transport for Arbitrary Payloads (TKQR1)](./peer-to-peer/0225.md)
 226  | [Miner-Enforced Resale-Royalty Covenant Tokens (OP_PUSH_TX)](./tokens/0226.md)
 227  | [Frictionless On-Chain Onboarding via Pre-Funded Claimable Tokens](./apps/0227.md)
+300  | [Bitcom — Universal Bitcoin Computer: Decentralized Protocol Registry and Composition](./scripts/0300.md)
+301  | [B — Bitcoin Data Protocol](./scripts/0301.md)
+302  | [AIP — Author Identity Protocol](./scripts/0302.md)
+303  | [MAP — Magic Attribute Protocol](./scripts/0303.md)
+304  | [Sigma — Transaction-Bound Script Signatures](./scripts/0304.md)
+305  | [Outpoint Content Addressing](./outpoints/0305.md)
+306  | [1Sat Ordinals — Single-Satoshi Tokens and Origin Tracking](./tokens/0306.md)
+307  | [1Sat Ordinals — Inscription Envelopes](./tokens/0307.md)
+308  | [1Sat Ordinal Collections](./tokens/0308.md)
+309  | [BSV-21 Fungible Tokens (JSON / Legacy)](./tokens/0309.md)
+310  | [BSV-21 Fungible Tokens (Binary)](./tokens/0310.md)
+311  | [BAP — Bitcoin Attestation Protocol](./peer-to-peer/0311.md)
+312  | [Bitcoin Schema — Social Data Types](./apps/0312.md)
+313  | [Encrypted Group Messaging over Type-42 Key Derivation](./peer-to-peer/0313.md)
 
 ## License
 

SUMMARY.md

@@ -19,6 +19,7 @@
 * [NotaryHash — Privacy-Preserving Signed-Hash Notarization with SPV-Verifiable Certificates](./apps/0220.md)
 * [Block Media Format (BMF) — Composable On-Chain Audio/Video](./apps/0224.md)
 * [Frictionless On-Chain Onboarding via Pre-Funded Claimable Tokens](./apps/0227.md)
+* [Bitcoin Schema — Social Data Types](./apps/0312.md)
 
 ## Wallet
 
@@ -101,6 +102,11 @@
 * [Bare Multi-Signature](./scripts/0047.md)
 * [Pay to Push Drop](./scripts/0048.md)
 * [Bitcoin Script ASM Format](./scripts/0106.md)
+* [Bitcom — Universal Bitcoin Computer: Decentralized Protocol Registry and Composition](./scripts/0300.md)
+* [B — Bitcoin Data Protocol](./scripts/0301.md)
+* [AIP — Author Identity Protocol](./scripts/0302.md)
+* [MAP — Magic Attribute Protocol](./scripts/0303.md)
+* [Sigma — Transaction-Bound Script Signatures](./scripts/0304.md)
 
 ## Tokens
 
@@ -117,6 +123,11 @@
 * [1Sat Provenance Remittance for Basket `1sat`](./tokens/0150.md)
 * [Latched 1Sat Provenance for Basket `1sat`](./tokens/0156.md)
 * [Miner-Enforced Resale-Royalty Covenant Tokens (OP_PUSH_TX)](./tokens/0226.md)
+* [1Sat Ordinals — Single-Satoshi Tokens and Origin Tracking](./tokens/0306.md)
+* [1Sat Ordinals — Inscription Envelopes](./tokens/0307.md)
+* [1Sat Ordinal Collections](./tokens/0308.md)
+* [BSV-21 Fungible Tokens (JSON / Legacy)](./tokens/0309.md)
+* [BSV-21 Fungible Tokens (Binary)](./tokens/0310.md)
 
 ## Overlays
 
@@ -166,6 +177,8 @@
 * [Fountain-Coded Air-Gap Transport for Arbitrary Payloads](./peer-to-peer/0141.md)
 * [Universal Handle Addressing and Resolution for the Metanet](./peer-to-peer/0169.md)
 * [Animated-QR Air-Gap Transport for Arbitrary Payloads (TKQR1)](./peer-to-peer/0225.md)
+* [BAP — Bitcoin Attestation Protocol](./peer-to-peer/0311.md)
+* [Encrypted Group Messaging over Type-42 Key Derivation](./peer-to-peer/0313.md)
 
 ## Key Derivation
 
@@ -189,6 +202,7 @@
 * [User Wallet Data Format](./outpoints/0038.md)
 * [User Wallet Data Format Encryption Extension](./outpoints/0039.md)
 * [User Wallet Data Synchronization](./outpoints/0040.md)
+* [Outpoint Content Addressing](./outpoints/0305.md)
 
 ## Opinions
 

apps/0146.md

@@ -102,7 +102,7 @@ Where a manifest states at least one condition, admission is self-service: a rea
 | `ungateBurn`                                      | decimal string | conditional | satoshis to burn to ungate; required while any condition is on |
 | `successor`                                       | handle         | no          | who may assume custody after dormancy, per 8.3                 |
 | `dormantAfter`                                    | blocks         | no          | holder silence after which `successor` may sign, per 8.3       |
-| `token` `vouch` `renounce` `quorum` `fee` `roles` | object         | no          | conditions, per 2.3                                            |
+| `token` `vouch` `renounce` `quorum` `timelock` `fee` `roles` | object         | no          | conditions, per 2.3                                            |
 
 An absent condition and one present with `"on": false` evaluate identically; the distinction exists for an editor holding a half-configured condition and nowhere else.
 
@@ -372,7 +372,7 @@ A **member** reads the room and posts in it. A **mod** also deletes messages and
 
 Banning is strictly downward and never sideways: no role bans its own rank. An admin banning an admin is the one action that can empty a room's admin set in a single click. **Custody is not a rank** — the holder sits underneath the ladder rather than on top of it, may act on any participant, and cannot be acted on; without that, an ungated room where everybody is an admin has nobody able to act on anybody. Deleting a message leaves a record that a message was removed rather than silently closing the gap, since a transcript that rewrites itself is one nobody can reason about afterwards.
 
-A **ban** is recorded as a statement against the handle under BRC-169 section 10.7, scoped to the room — so it has an author, a time and a claim, which a row in a ban array does not. It is **attributed**, reversing BRC-169 section 10.7.1's default: that default protects somebody speaking against a peer at their own risk, and a moderator acting inside a room they moderate is in the opposite position. A room-scoped statement does not contribute to the subject's standing anywhere else and does not satisfy a renounce gate in another room; being unwelcome in one room is not a reputation, and a mechanism letting one moderator's decision follow somebody across the network would be worse than the list it replaced. The subject is told, and by whom, and any role that could impose the ban can lift it. How a ban is then read back as a condition — where the record lives, what scoping means at evaluation time, and what lifting is — is section 4.5.
+A **ban** is recorded as a statement against the handle under BRC-169 section 10.7, scoped to the room — so it has an author, a time and a claim, which a row in a ban array does not. It is **attributed**, reversing BRC-169 section 10.7.1's default: that default protects somebody speaking against a peer at their own risk, and a moderator acting inside a room they moderate is in the opposite position. A room-scoped statement does not contribute to the subject's standing anywhere else and does not satisfy a renounce gate in another room; being unwelcome in one room is not a reputation, and a mechanism letting one moderator's decision follow somebody across the network would be worse than the list it replaced. The subject is told, and by whom, and any role that could impose the ban can lift it. How a ban is then read back as a condition — where the record lives, what scoping means at evaluation time, and what lifting is — is section 4.6.
 
 Closing a room is a signed statement carrying who closed it and when; conforming clients stop accepting posts and render the room as closed. History remains readable, because section 9 is why nothing here can un-deliver a message, and a client presenting closure as deletion has promised something no client can perform.
 

apps/0218.md

@@ -444,12 +444,12 @@ This document specifies what a command means, not how it looks, with three excep
 
 ### 11. Access Gates
 
-A room may condition **reading** it on facts about the reader — a token they hold, a vouch somebody signed, a statement written against them. That mechanism is specified in [BRC-190](./0190.md), which subsumes and replaces the sketch that previously stood in this section.
+A room may condition **reading** it on facts about the reader — a token they hold, a vouch somebody signed, a statement written against them. That mechanism is specified in [BRC-146](./0146.md), which subsumes and replaces the sketch that previously stood in this section.
 
 Two boundaries are worth restating here, because both are about this document.
 
-1. Access gates define no verbs and reserve none. Configuring a gate from a conversational interface is a matter for this document; what a gate *is* and how it evaluates is a matter for BRC-190.
-2. The `/gate` verb reserved in section 6 is a different thing and remains reserved. It is the **write** half — charging for entry, with custody, refunds, and a rule for what happens when the room ends. BRC-190 specifies the **read** half only.
+1. Access gates define no verbs and reserve none. Configuring a gate from a conversational interface is a matter for this document; what a gate *is* and how it evaluates is a matter for BRC-146.
+2. The `/gate` verb reserved in section 6 is a different thing and remains reserved. It is the **write** half — charging for entry, with custody, refunds, and a rule for what happens when the room ends. BRC-146 specifies the **read** half only.
 
 ## Security Considerations
 
@@ -478,6 +478,6 @@ Two boundaries are worth restating here, because both are about this document.
 ## References
 
 - [BRC-3: Digital Signature Creation and Verification](../wallet/0003.md)
-- [BRC-190: Access Gates for Metanet Rooms](./0190.md)
+- [BRC-146: Access Gates for Metanet Rooms](./0146.md)
 - [BRC-169: Universal Handle Addressing and Resolution for the Metanet](../peer-to-peer/0169.md)
 - [RFC 2119: Key words for use in RFCs to Indicate Requirement Levels](https://www.rfc-editor.org/rfc/rfc2119)

apps/0312.md

@@ -0,0 +1,169 @@
+# BRC-312: 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-301](../scripts/0301.md)) says how to store content, MAP ([BRC-303](../scripts/0303.md)) says how to attach attributes, and AIP ([BRC-302](../scripts/0302.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-300](../scripts/0300.md) pipeline:
+
+```
+[B <content> <mediaType> <encoding>] | MAP SET app <appname> type <type> [<key> <value> ...] | AIP <algorithm> <address> <signature>
+```
+
+- **Content** (when the type carries content) is a B segment ([BRC-301](../scripts/0301.md)).
+- **Attributes** are a MAP `SET` segment ([BRC-303](../scripts/0303.md)) carrying at minimum `app` (the producing application's name) and `type` (the schema type).
+- **Authorship** is an AIP signature ([BRC-302](../scripts/0302.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-311](../peer-to-peer/0311.md)) under the key `bapID`.
+
+### 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 <contextKey> <contextKey> <contextValue> [subcontext <subKey> <subKey> <subValue>]
+```
+
+Examples of the pattern:
+
+- Reply threading: `context tx tx <txid>` — 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 <recipient identity key>`
+- Platform integration: `context provider provider youtube subcontext videoID videoID <id>` — 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 <content> <mediaType> <encoding> | MAP SET app <appname> type post | AIP BITCOIN_ECDSA <address> <signature>
+```
+
+Content may be plain text, markdown, images, or any media B supports.
+
+**Reply** — a post whose context is the parent transaction:
+
+```
+B <content> <mediaType> <encoding> | MAP SET app <appname> type post context tx tx <txid> | AIP BITCOIN_ECDSA <address> <signature>
+```
+
+**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 <appname> type repost tx <txid> | AIP BITCOIN_ECDSA <address> <signature>
+```
+
+**Message** — like a post but in a separate namespace intended for real-time chat. Global, channel-scoped, and private forms:
+
+```
+B <content> <mediaType> <encoding> | MAP SET app <appname> type message | AIP ...
+B <content> <mediaType> <encoding> | MAP SET app <appname> type message context channel channel <channel-name> | AIP ...
+B <content> <mediaType> <encoding> | MAP SET app <appname> type message context bapID bapID <recipient-bap-id> | AIP ...
+```
+
+### 5. Action Types
+
+**Like / Unlike** — sentiment about a target named by a global identifier key (most commonly `tx`):
+
+```
+MAP SET app <appname> type like tx <txid> | AIP BITCOIN_ECDSA <address> <signature>
+MAP SET app <appname> type unlike tx <txid> | AIP BITCOIN_ECDSA <address> <signature>
+```
+
+**Follow / Unfollow** — one-way relationships between identities:
+
+```
+MAP SET app <appname> type follow bapID <bapID> | AIP BITCOIN_ECDSA <address> <signature>
+MAP SET app <appname> type unfollow bapID <bapID> | AIP BITCOIN_ECDSA <address> <signature>
+```
+
+**Friend** — a two-way relationship enabling secured communications. The record carries a `publicKey` derived for the friendship: the deriving path is computed from the SHA-256 hash of the counterparty's BAP identity key (via the BAP library's `getSigningPathFromHex`), and the derived public key is published so the counterparty can construct a shared communication channel:
+
+```
+MAP SET app <appname> type friend bapID <bapID> publicKey <publicFriendKey> | AIP BITCOIN_ECDSA <address> <signature>
+```
+
+**Action state resolution:** for paired actions from the same identity on the same target (`like`/`unlike`, `follow`/`unfollow`), indexers MUST take the latest action in blockchain order as the current state.
+
+### 6. Tags
+
+Tags categorize content for search and filtering, carried as a MAP `ADD` (list semantics, [BRC-303](../scripts/0303.md)) in an additional output of the same transaction:
+
+```
+MAP ADD tags <tag1> <tag2> <tag3> ... | AIP BITCOIN_ECDSA <address> <signature>
+```
+
+### 7. Attachments
+
+Attachments carry rich media alongside a post or message, each as a separate B output ([BRC-301](../scripts/0301.md)) in the same transaction, AIP-signed like any other output:
+
+```
+output n:   B <attachment1Data> <mediaType> <encoding> | AIP BITCOIN_ECDSA <address> <signature>
+output n+1: B <attachment2Data> <mediaType> <encoding> | AIP BITCOIN_ECDSA <address> <signature>
+```
+
+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-311](../peer-to-peer/0311.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 (for example via keys established through the `friend` exchange).
+- **Action replay** — the latest-in-block-order rule (Section 5) assumes indexers process reorgs consistently.
+
+## Implementations
+
+Bitcoin Schema social types are produced and indexed by multiple production social applications, indexers, and parser libraries in TypeScript and Go. The canonical, community-maintained schema documentation lives at https://bitcoinschema.org.
+
+## References
+
+- Bitcoin Schema documentation (canonical): https://bitcoinschema.org/docs
+- [BRC-300: Bitcom](../scripts/0300.md) — pipeline composition
+- [BRC-301: B — Bitcoin Data Protocol](../scripts/0301.md) — content and attachments
+- [BRC-302: AIP — Author Identity Protocol](../scripts/0302.md) — authorship signatures
+- [BRC-303: MAP — Magic Attribute Protocol](../scripts/0303.md) — attribute layer (`SET`, `ADD`)
+- [BRC-311: BAP — Bitcoin Attestation Protocol](../peer-to-peer/0311.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

apps/README.md

@@ -13,3 +13,4 @@ BRC   | Standard
 220   | [NotaryHash — Privacy-Preserving Signed-Hash Notarization with SPV-Verifiable Certificates](./0220.md)
 224   | [Block Media Format (BMF) — Composable On-Chain Audio/Video](./0224.md)
 227   | [Frictionless On-Chain Onboarding via Pre-Funded Claimable Tokens](./0227.md)
+312   | [Bitcoin Schema — Social Data Types](./0312.md)