spec: fix logical inconsistencies, align with fmsgd behaviour (v0.5.0)

[markmnl]

Analysis of SPECIFICATION.md v0.4.1 found several logical inconsistencies; fmsgd was then audited to see why integration tests pass regardless, and the spec is updated to encode the working behaviour (per discussion). SPEC.md is re-distilled to match; a companion PR syncs it into fmsgd.

Major fixes

1. Verifying Message Stored excluded messages the host sent. The definition required a prior accept response (200/11), which a host never gives for messages it originated — a literal reading rejects every reply arriving at the originator's host with code 6, and makes the v0.4.0 add-to notification to the original sender's domain impossible. fmsgd already treats sent messages as stored (bare SELECT id FROM msg WHERE sha256 = $1 in store.go, hash populated by ensureSharedHash before first delivery; guarded by integration test 007-reply-to-own-sent.sh). The definition now includes messages the host sent.

2. Code 11 semantics. The code table, §Reject-or-Accept and the Sending step read "the additional recipients have been accepted" — a state no execution path produces: when any add-to recipient belongs to the receiving host it responds 65, and 11 only when none do. All three places now describe code 11 as acknowledging/recording an add-to batch by a domain hosting none of the added recipients (fmsgd: resolvePostChallengeCode, handleAddToPath).

3. Single header-response code. §3's steps could literally emit a REJECT 10 or a 64 after a 65 had been sent — bytes the sender state machine would mis-parse as per-recipient codes. §3 step 1 now states exactly one code is determined and sent, first matching rule wins (matching fmsgd's collapse in resolvePostChallengeCode).

4. add to / to overlap forbidden. NOTE II allowed an address in both lists, which created an unresolvable ambiguity: Terms defines "recipients" as a set (one per-recipient code) while §3 iterates occurrences (two codes) — desyncing the response stream if hosts disagree. fmsgd already rejects the overlap with code 1 (readAddToRecipients). Validation now requires add-to addresses to be distinct from to; NOTE II explains re-serving a recipient who lost the message via plain re-send.

5. Add-to "exact duplicate except…" list omitted topic. An add-to copy of a thread-starting message gains a pid, and topic is mutually exclusive with pid — so a conforming "exact duplicate" was structurally invalid. The exception list now includes the has-pid flag and topic omission (matching fmsgd's addToHeader).

Minor fixes

• MUST vs SHOULD conflict on creating the outgoing-message record before transmission → MUST in both places.
• Unsupported first byte: split by who listens on the other end (49585f7) — value ≤ 128 (unsupported message version) gets REJECT 2, since the sender's first read is always a response code; value > 128 (unsupported CHALLENGE version) TERMINATES without responding, since the challenger's next read is exactly the 32-byte CHALLENGE-RESPONSE hash and a code byte would be indistinguishable from hash bytes. fmsgd is brought in line by Terminate on unsupported challenge version instead of sending code 2 fmsgd#40.
• Code 10 description covers the add-to batch-duplicate use; §3 wording "none of the recipients" → "none of the add to recipients".
• "message hash" consistently defined via Computing Message Hash (Terms, Challenge Response).
• Numbering: Sending steps renumbered 1–10 (started at 2), Handling a Challenge 1–5 (skipped 4), 1.4.6.3.2 → 1.4.6.3.3 cross-ref; TOC gains "Notes on Adding Recipients" and "Computing Message Hash".

Bumped to v0.5.0 since the overlap prohibition is a behavioural change.

🤖 Generated with Claude Code