Urbit Documentation

website·Indexed 35 days ago

https://docs.urbit.org

Developer documentation for Urbit, a peer-to-peer network and personal server OS. Includes comprehensive guides on the Hoon functional programming language (Hoon School), the Arvo kernel, Gall agent development (App School), and the Azimuth public-key infrastructure for Urbit IDs.

Tokens: 146K
Snippets: 671
Records: 1K
Agent score: 64%

What's inside Urbit

Overview of Remote Scrying in Urbit
Remote scrying (introduced in kernel v413) allows a ship to perform a read from another ship's referentially transparent namespace. Because networking is asynchronous, remote scries do not use the synchronous .^ (dotket) operator directly. Instead, a requester asks Ames to perform the scry, which cooperates with Vere to retrieve the data. The result is returned asynchronously as a %tune gift.
https://docs.urbit.org/llms-full.txt?llms-doc=remote-scrywebsitellms
Introduction to Hoon and Urbit
Hoon is a functional programming language that compiles to Nock, the virtual machine powering Urbit OS (Arvo). Urbit consists of two primary components: Azimuth (Urbit ID), a PKI on the Ethereum blockchain for secure identities, and Arvo (Urbit OS), a deterministic, axiomatic operating system that runs on a peer-to-peer, end-to-end encrypted network.
https://docs.urbit.org/llms-full.txt?llms-doc=hoon-schoolwebsitellms
Overview of the Dill terminal driver vane
Dill is Urbit's terminal driver, responsible for constructing terminal sessions and coordinating input/output. While the vane handles the coordination, most of the terminal stack resides in userspace (instrumented by Gall).
Key characteristics:
- Functionality: Interfaces with keystrokes and terminal emulator sessions.
- Daemon Mode: Urbit can run in daemon mode without an active Dill terminal session.
- Compatibility: Due to emulator limitations, Dill sessions are currently only properly supported in the %webterm app.
```
|pass [%d %text "hello world"]
```
https://docs.urbit.org/llms-full.txt?llms-doc=8-vanes-i-behn-dill-kahn-lickwebsitellms

Overview of u3 C functions for jet development

The u3 system provides a set of C functions to extract data from Urbit types into C types and wrap C values back into Urbit nouns. These functions are categorized by their prefixes:

Prefix	Mnemonic	Source File	Example
`u3a_`	Allocation	`allocate.c`	`u3a_malloc`
`u3e_`	Event (persistence)	`events.c`	`u3e_foul`
`u3h_`	Hash table	`hashtable.c`	`u3h_put`
`u3i_`	Imprisonment (noun construction)	`imprison.c`	-
`u3j_`	Jet control	`jets.c`	`u3j_boot`
`u3k_`	Jets (transfer semantics, C args)	`[a-g]/*.c`	-
`u3l_`	Logging	`log.c`	`u3l_log`
`u3m_`	System management	`manage.c`	`u3m_bail`
`u3n_`	Nock computation	`nock.c`	`u3nc`
`u3q_`	Jets (retain semantics, C args)	`[a-g]/*.c`	-
`u3r_`	Retrieval (returns on error)	`retrieve.c`	`u3r_word`
`u3t_`	Profiling and tracing	`trace.c`	`u3t`
`u3v_`	Arvo operations	`vortex.c`	`u3v_reclaim`
`u3w_`	Jets (retain semantics, Nock core arg)	`[a-g]/*.c`	-
`u3x_`	Retrieval (crashes on error)	`xtract.c`	`u3x_cell`
`u3z_`	Memoize	`zave.c`	`u3z_uniq`

Overview of the Arvo II boot sequence
The Arvo boot process is the sequence of events that transforms an Arvo instance from a fresh start to a fully operational state. The formal state of an Arvo instance is an event history (a linked list of nouns). The boot process consists of five discrete stages:
1. Runtime startup: The initial execution of the runtime environment.
2. Boot sequence (pill): The loading and parsing of the 'pill', which delivers the Arvo kernel and source.
3. Arvo larval phase: The initial state where the kernel is established.
4. Arvo main sequence: The transition to the adult phase and the execution of core logic.
5. Userspace startup: The initialization of userspace vanes and the processing of associated slogs.
https://docs.urbit.org/llms-full.txt?llms-doc=5-arvo-ii-the-boot-sequencewebsitellms
Overview of Arvo Cryptographic Primitives
Arvo utilizes jetted cryptographic primitives for performance and to leverage standard C reference implementations. The primary primitives include Ed25519 for signatures and AES-SIV for encryption. All encryption-related jets are located in pkg/urbit/jets/e/.
https://docs.urbit.org/llms-full.txt?llms-doc=cryptographywebsitellms
Overview of Urbit ID
Urbit ID is a decentralized, secure, and human-meaningful identity standard for the Urbit network. It is based on a public-key infrastructure (PKI) implemented using NFTs on the Ethereum blockchain. An Urbit ID is required to join the Urbit network, as it allows an Urbit OS server to cryptographically sign all outgoing messages, ensuring the authenticity of network communications.
https://docs.urbit.org/llms-full.txt?llms-doc=what-is-urbit-idwebsitellms
Overview of the Urbit Runtime (Vere)
The Urbit runtime and Nock interpreter is known as Vere. It consists of several layers: the C3 layer (a specialized C environment for Urbit) and the U3 layer (the noun-wrangling part of the runtime). The runtime handles the execution of Nock and provides the infrastructure for 'jets' (optimized C implementations of Nock functions) and cryptography libraries.
https://docs.urbit.org/llms-full.txt?llms-doc=runtimewebsitellms
Overview of the u3 Nock runtime system
u3 is a C library that serves as the Nock runtime system for Urbit. It functions as a library for creating and storing 'nouns'. A noun is defined as either an atom (an unsigned integer of any size) or a cell (an ordered pair of any two nouns). u3 is designed as a 'solid-state interpreter,' utilizing a single-level store that supports transparent snapshotting and a specialized memory-management model.
https://docs.urbit.org/llms-full.txt?llms-doc=u3websitellms
Overview of Azimuth Data Flow components
Azimuth manages Urbit's PKI state using a naive rollup solution where the complete state is stored off-chain but derived from on-chain Ethereum data. The system consists of the following components:
- Bridge: The user interface for collecting and signing transactions, forwarding them to a roller via HTTP API.
- %azimuth: Gall agent that maintains the PKI state and exposes it via scries.
- %azimuth-rpc: JSON RPC-API providing access to point and DNS data from %azimuth.
- %eth-watcher: General-purpose Ethereum event log collector that feeds transactions to %azimuth.
- %roller: Gall agent that batches L2 transactions and submits them to Ethereum.
- %roller-rpc: JSON RPC-API that translates HTTP calls from Bridge into a format understood by %roller.
https://docs.urbit.org/llms-full.txt?llms-doc=azimuth-data-flowwebsitellms
Overview of Vere Runtime Architecture
Vere is the standard C-based runtime for Arvo. It implements the Nock specification to create a practical computer. The runtime spawns two primary processes that persist for the lifetime of the Urbit process: the king and the serf.
https://docs.urbit.org/llms-full.txt?llms-doc=6-vere-i-u3-and-the-serfwebsitellms
Overview of Eyre and Iris HTTP Vanes
Urbit uses two primary vanes for HTTP communication: Eyre and Iris. Eyre acts as the HTTP server, receiving messages from Unix and producing responses. Iris acts as the HTTP client for outbound operations. The system primarily supports GET, PUT, and POST methods, mapping them to Urbit's internal logic: GET is used for read-only information (similar to scry), while PUT and POST are used for state updates and data processing (similar to pokes).
https://docs.urbit.org/llms-full.txt?llms-doc=10-vanes-iii-eyre-iriswebsitellms