The online client is built into Flipnote Studio. Each screen chooses a route, sends a request and passes the reply to the relevant application and browser routines. The research follows route selection, POST workers, star requests, server text and keyboard input in the studied builds. Finding a route on one screen does not show which routes the rest of the service uses. [1]
Requests and results
Some interactions use structured UGO resources; others involve HTML-like content, previews, metadata actions or file transfers. The client can interpret numeric errors and returned text in ways that depend on the requesting page. A compatible server should reproduce the response type and status expected by a specific client path, then verify it on the intended build. [1][2]
The archived hatena-server wiki documents several formats and connection steps. It is incomplete, so check its descriptions against the ROM research and the client build you are using. [2]
Route selection is a state transition
The V2 client classifies a URL and the expected file type, decides whether its current archive can be reused, then dispatches to a menu, document, player, keyboard or posting mode. A PPM download is not an HTML navigation and a UGO is not just HTML with different styling. The exact V2 branches have been traced in the studied ROMs; Japanese V1's equivalent gateway remains less mapped. [1]
Transport generations differ
For the online action examined in Japanese V1, the client advances through socket and send states. V2 starts a request, polls it, closes it and handles the HTTP result in separate steps. A desktop script can check the server's response bytes, but reproducing that response alone will not reveal a timing or state-handling bug in the DSi client. [1]
Implementation map
Use requests for action bodies and headers, responses for results and errors, the browser for documents, and upload for submitted PPMs. The authentication and NAS guides are available only to authorised researchers. [1][2]