Open protocol · token-gated chat on BSV
Every token already has a room.
- room id = token id
- holding = membership
- invite = send a token
How it works
Three steps. No new prefix.
A room message is an ordinary Bitcoin Schema chat message whose channel is the token's id. Gating is a rule clients apply on top, not a new encoding.
Pick a token
Any BSV-21 token, BSV-20 tick or 1Sat collection. Its room id is bsv21:<txid>_<vout>, bsv20:<TICK> or coll:<txid>_<vout>. Sub-rooms add /<slug>.
Post a signed message
B + MAP + AIP, with type message, context channel and the room id as channel. It lands on chain like any other Bitcoin Schema message.
Holders are admitted
A message counts if its signer held at least min of the token when it was posted and isn't banned. Selling later never revokes past messages.
Invites need nothing extra: send someone min of the token and they're a member from the block the transfer is mined.
Creator controls
The room owner sets the terms.
The owner (the deploy, first-mint or collection signer) publishes a signed room-policy. Changes apply from the block they're mined in and are never retroactive.
How many tokens to enter
min is any amount, in raw units. It defaults to one whole token (or one collection item). Clients show it plainly: "Hold 10 $ROOM to enter".
Hold or spend
entry hold (default): holding is membership and nothing is spent. entry spend: pay spend units per entry, per message, or per second, minute, hour or day while you're in the room.
Burn or pay the owner
to burn (default) destroys spent tokens with a BSV-21 burn transfer. to owner sends them to the room owner, or to <address> to a treasury. The UI should say where they go.
Owners can appoint moderators and publish signed bans. Moderation is advisory: every client applies it, and the chain stays complete.
Built on what's already there
A thin layer on open work.
The bChat Protocol is a naming convention for channel plus a few optional MAP keys. Everything underneath already exists.
bSocial and Bitcoin Schema
Messages, likes and replies use the existing B + MAP + AIP formats. Reactions are ordinary Bitcoin Schema likes with the room keys added.
bmap indexing
Works today with no new indexer. bmap and the bsocial overlay already index MAP message and like, and bmap serves channels directly.
1Sat tokens
Rooms are 1Sat Ordinals BSV-21 tokens, BSV-20 ticks and collections. Balances and spend checks come from the 1Sat API.
BAP
Identity linking. Addresses attested in a BAP identity count toward a member's holding, alongside on-chain address-link proofs.
The message
This is the whole format.
A room message from the spec (§6.1). Clients must ignore MAP keys they don't know.
B "Scene 12 draft is up" text/markdown utf-8
| MAP SET app bchat.online type message context channel
channel bsv21:3f9a8e…c2_0 thread 7d1c…e9
| AIP BITCOIN_ECDSA 1Fc3…kq H+3v…==Roadmap
Draft for comment.
Encrypted rooms
Content encrypted per epoch with AES-256-GCM, keys wrapped to current holders with BRC-78 and delivered by BRC-33 MessageBox. Keys rotate when a holder leaves or is banned. Encryption protects against outsiders and indexers, not against members.
BRC submission
Planned: submit the spec as a BRC. The open questions are listed in §14, and comments and objections are welcome now.
Reference implementations
Where to use it.
bChat
Tokenised chat rooms at bitcoinchat.online. Its server rooms use the same gate keys, so a server room maps one-to-one to an on-chain room.
bWallet
The mobile wallet reference implementation, in progress. The plan (§15) is on-chain posting signed with your own identity key, merged with server messages.
Read it. Break it. Build on it.
The spec is short and open. Questions, objections and proposals go in issues; pull requests are welcome.