The online browser uses ugomemo:// URLs to open Studio's built-in screens. Other URL-like prefixes refer to local files and make no network request. Resolve these prefixes before attempting HTTP; passing every link to an HTTP client will not reproduce Studio's behaviour. [1]
| Scheme or path | Documented use |
|---|---|
ugomemo://drawface | Open comment drawing. |
ugomemo://postmemo | Open Flipnote posting. |
ugomemo://command | Open button-code search. |
ugomemo://keyboard/<URL> | Open text input and request the supplied destination after submission. |
ugomemo://createmail | Named in the wiki, but its request and screen behaviour remain undocumented. |
sdmc:/ | Address a file on removable media. |
dataPub:/ | Address data within the application's public save, including observed sample notes. |
nand:/ | Possible NAND namespace inferred from ROM strings; actual reachable paths were not established in the wiki. |
What each scheme actually does
The native ugomemo:// links belong to UGO records or the client's HTML action metadata. They are not normal HTTP destinations. A keyboard link can append a destination after the scheme, but the historical test observed a request without the client then navigating to the result. Command search instead performs a regional /jump request and uses a response header to decide whether the reply is a destination or an error dialogue. See Hatena action flows for the request and response sequence. [1]
A page may use upperlink to point at an SD file, for example a root-level PPM under sdmc:/. The wiki records five sample notes in a European public save, at these paths: [1]
dataPub:/ugo/005/0DD426_08F59C904C844_001.ppmdataPub:/ugo/006/TDD426_08F59C7FAD056_001.ppmdataPub:/ugo/011/3DD426_08F59C875A2A2_002.ppmdataPub:/ugo/012/17D1EE_087CBDF2EF4BD_000.ppmdataPub:/ugo/012/FDD426_08EB04AC8A0B3_000.ppm
These filenames were recorded for one set of sample notes; other regions or installations may differ. The source infers nand:/ from ARM9 strings but gives no working NAND path. Some local-file tests left the screens swapped and most controls unresponsive, so the tests do not establish a supported browser feature. A hosted page must not get unrestricted access to user media through an unchecked path. [1]
Opening native screens
The wiki documents native menu-action URLs in UGO items and HTML metadata buttons. It does not show that every ugomemo:// action works in an ordinary HTML link. For text input from a link, use the separately documented .kbd route. [1]
X-DSi-Dialog-Type | Body interpretation | Encoding |
|---|---|---|
0 | Destination URL to navigate to | UTF-8 |
1 | Error message to display | UTF-16LE |
Omitting that header from a command-search jump response caused a softlock in the wiki's test. Set the response type even when returning an empty result; an HTTP success status alone is insufficient. [1]
In an internal keyboard URL, the destination follows the action name, as in ugomemo://keyboard/http://ds.example.com/input.htm. Historical tests received the typed value in X-Email-Addr at that destination, but the previous page stayed on screen without re-rendering. Following another link was necessary to see the result. This limitation was seen with the internal URL; the ordinary .kbd route has its own forwarding behaviour. [1]
Local media URLs
The wiki's upperlink example uses sdmc:/F78DA8_14768882B56B8_030.ppm for a PPM at the SD card root. It is an example path, not a separately checked file from a card. The prefix refers to removable storage rather than an HTTP host. Read the wiki's broad SD-access claim alongside its instability reports: the tests did not establish a supported browser feature. [1]
The five dataPub:/ugo/... sample paths above were recorded for Europe. The wiki suggests the American version may use them too, but does not verify this and warns against assuming the same catalogue for Japan. Access to other dataPub:/ content was unresolved. The source found nand:/ in arm9.bin, but supplied no working NAND path. That string alone does not demonstrate arbitrary NAND access. [1]
Local-resource tests could swap the two screens and leave only touch controls responding. The wiki questions whether these paths were intended for production or development use. That is the authors' interpretation; the input failure itself is what they observed. [1]