A server for the original client must answer the requests the client actually makes. The public hatena-server wiki documents PPM, TMB and UGO formats and an older connection workflow. The Flipnote Decompilation Project adds route, parser and UI evidence from the shipped application. Read both before treating a wiki field table as a complete protocol specification. [1][2]
Work from one screen outward
- Identify the client build and the screen to support.
- Record its request method, path, headers and body.
- Return the expected response type and verify parsing, navigation and errors.
- Test file downloads and actions independently of the listing page.
A reproduction of one successful server exchange does not imply that every original Hatena endpoint or failure path has been recovered. [1]
Build a route inventory
Choose one Studio build and one user flow, then record every requested path and response type. Start with a menu, a list, a TMB preview and a PPM download. Add posting, keyboard entry and metadata actions separately. The client itself makes route and cache decisions, so a server map assembled only from URLs in strings can omit important transitions. [1][2]
Match bytes and behaviour
For every endpoint, verify both network status and the resulting DSi screen. A response can carry a dialogue body even on an error; a successful HTTP status can still contain a malformed UGO or document. Keep responses within the client's size limits, validate their contents and test an empty page, one item and a full page. [1][2][3]
Check the client version and region
The original Japanese V1 transport differs from V2, and regional V2 builds can use different paths and UI resources. Record the build and region of every capture. The archived hatena-server wiki is useful historical implementation guidance, but it is incomplete and should be checked against the intended client. [1][2]
File authorship and account authentication
Do not equate an author label inside a PPM with an authenticated account. Keep network session handling, file acceptance, filename checks and user-facing attribution as separate decisions. This guide does not publish authentication details; authorised researchers can read the restricted NAS and authentication chapters. [1][3]