The online UI can launch a Flipnote posting interface or a drawn-comment interface from a page control. Community documentation describes the posted body as a PPM in both cases; the comment path uses a one-page PPM. The original V2 research identifies request workers and posting dispatch, but not every historical server-side acceptance rule. [1][2]
Entry points
A page can advertise a post destination through metadata, while UGO menus can also carry actions. The post destination and the comment destination are distinct; one typically uses a .post style endpoint and the other a .reply style endpoint. A reader should not infer that both actions accept the same payload or have the same UI. [2]
Validate before accepting
At minimum, a receiving service should limit the body size, parse the PPM structure, check frame and sound section bounds, and verify that the result is associated with the intended action. A comment's one-page requirement should be checked independently of its filename. Authorship fields inside the PPM are file data, not proof of the submitting user. These are service design checks, not claims about the complete original Hatena backend. [1][2]
Responses
A POST can return a client dialogue or a navigation instruction. Test what the DSi displays after success and after validation failure. The public wiki leaves parts of historical POST responses unfinished, so check the response separately before using an example request to implement an endpoint. [1][2]