SPUDNET, retroactively backronymized into the Super PotatOS Update/Debug NETwork, is a [[PotatOS]] backend service (in the language of the [[PotatOS Privacy Policy]], a "PotatOS Service" or "PotatOS Thing"). Full comprehension of SPUDNET is not possible for 98.3% of [[humans]] and not recommended, but a brief summary of some features is safe and accessible:
== Features
=== Secured Communications
SPUDNET offers asymmetric authenticated communications services, originally designed for the [[PotatOS]] Remote Debugging Service. Communications can run over websocket or (recently) HTTP long-polling. In the original implementation, a PotatOS instance would connect to an unauthenticated "client" websocket, and send/receive textual messages to/from authenticated "admin" websockets on the same channel. While this was simple and easy to use, it had the disadvantage of not allowing automatic reconnection and being unsuited for more complex SPUDNET applications. "Comm" mode was rapidly added, which was a mechanism for authenticated clients to communicate with each other and nothing else over a SPUDNET channel, but it took some time for the "v4" protocol, based on JSON or msgpack structured data, to be included. v4 permits multiplexing several channels and modes on a single websocket connection, as well as extra features like subchannels (a way to partition messages more conveniently; not a security mechanism) and limited senderidentification.
=== Reporting
Called SPUDNET/PIR (PotatOS Incident Reports), this feature is used to report incidents from PotatOS systems on which incidents have occurred. This also functions as an automatic tracing system for detecting some buggy behaviour. Incidents are reported via a dedicated HTTP endpoint, and as well as the basic incident description PotatOS sends a code sample - generally the code most recently run by the relevant computer - and other metadata, such as a set of tags, reported computer ID and label, PotatOS build, stack trace, ComputerCraft version, adjacent peripherals, PotatOS UUID and logs, and other configuration. This is used to assist with debugging and to identify relevant computers.
Incidents were originally only accessible via direct interaction with the SPUDNET database, but are now accessible from the SPUDNET web UI. Incident reports are sent for a wide range of events, including but not limited to:
The first implementation of SPUDNET used a single, hardcoded key for each channel. Despite the obvious advantages of this, issues with an early SPUDNET-controlled [[orbital laser|Orbital laser]] system resulted in this being swapped for the HKI (Hierarchical Key Issuance) system. In HKI, keys can be created for different sets of channels (and with different permission levels, although this feature did not see much use for some time), but they exist in a tree, with each key able to issue equal- or lower-permissioned keys only. However, the interface for this, ''keyctl.py'', was widely considered somewhat unwieldy, so later versions simplified key handling and added web UI capabilities. Keys are used to sign into the web UI, connect to an admin or comm websocket, or authenticate a v4 websocket connection (only one key can be used per connection).
=== Web UI
The SPUDNET web UI allows monitoring some basic SPUDNET status, viewing reports (both a full overview and per-report metadata), and managing keys. All users can see metadata about keys, but of course not keys themselves, and incident reports are only available to those with permission level 5 or more.
