Future
duration
TBD
If code run inside the `+mink` metacircular evaluation function in the Hoon standard library, which runs all userspace code, errors out deterministically (i.e. hits a trivial infinite loop in the Nock spec), then `+mink` catches the error and returns a stack trace.
Future
duration
1 Month
Applications often have bugs when a peer breaches. Modifying the userspace/kernelspace API to give Gall agents clearer information about breaches should improve application reliability and developer experience.
Future
duration
TBD
There are a number of cases where Arvo can crash in a way where it gets into an inconsistent state (e.g. Clay does not always handle Ames crashes properly) or gets stuck on something and fails to continue to make progress.
Future
duration
TBD
Arvo updates itself over the air, but current Vere does not. We should let the binary update itself by downloading a new version and replacing itself with that, instead of forcing the user to run terminal commands to stay up to date.
Future
duration
TBD
If Vere hits a nondeterministic error on replay, it should retry instead of giving up and crashing.
Future
duration
TBD
Improving the Arvo/Vere version negotiation will increase release rate by reducing the amount of work it takes to release a new Kelvin version.
Future
duration
TBD
The filesystem I/O driver doesn't handle filesystem errors properly, which can cause desynchronization between Unix and Clay. Fixing this would improve developer experience and general reliability.
Future
duration
2 Months
Clay's filesystem querying API is cumbersome to use and difficult to implement properly. A cleaner API would support remote scry better, would be easier for developers to integrate with, and would be less bug-prone.
Future
duration
1-3 Months
Current Vere needs to run Nock on an event before it can write it to disk. This places a lower bound on event latency, defined as time between receiving an event and performing its effects, at `D + N`, i.e. disk write latency (`D`) plus nock execution time (`N`). Commit-before-compute has amortized latency `max(D, N)`, which is usually significantly better.
Future
duration
3 Months
A version of Hoon with a dependent type system could make the type system easier to understand, improving developer experience.
Future
duration
3-6 Months
Desk-based namespacing should improve reliability, maintenance, and developer experience.
Future
duration
TBD
According to the principle of least privilege, each Vere process should only have privileges from the host operating system that it needs for normal operation. This is easier to understand, and likely easier to implement well, with multiprocess I/O.
Future
duration
1 Month
Adding a scheme of Unix process exit codes to the Mars process, and handling them in the Urth process (sometimes by printing them with more detail), will make the system easier to debug and maintain.
Future
duration
3-6 Months
Ames has no forward secrecy other than manual on-chain key rotation. This means if an attacker finds the symmetric key between two ships or one of the private keys, they could decrypt the whole history of communication between those ships.
Future
duration
TBD
Arvo's Behn vane (kernel module) currently serves two purposes: setting timers, and deferring tasks to later events. Deferral could be split out into a separate feature, which could aid both in refactoring Behn to be easier to verify and optimize.
Future
duration
TBD
`libames` would aid in integrating Urbit with other systems, writing iOS clients, and allowing Urbit to be used in internet-of-things applications.
Future
duration
TBD
Adding a basic logging system to Urbit (probably logging to files as a first step, or maybe syslog) would reduce hosting costs, improve release cycle times, and reduce the amount of time it takes devs to debug live ships.
Future
duration
2-4 Months
Once there are 8GB or 16GB in the loom, it will be common for there to be more data in Urbit than fits in RAM. This presents several new problems, and demands solutions.
Future
Move event log management into the same Unix process that manages snapshots.
Future
duration
1-2 Months
A more memory-efficient implementation of `|meld` should reduce dangerous memory pressure. This would reduce maintenance burden.
Future
duration
2-3 Months
At some point, we want to stop using Git and use Clay instead. Most of what's missing from that is building more tools in Clay that replicate the various Git tools.
Future
duration
1 Month
Dill, in the Arvo kernel, supports multiple sessions, but the current Urbit terminal client only uses one session. To make the Urbit command-line more usable, the client should support multiple sessions too.
Future
duration
TBD
Similarly to breaking up the Urth process, we should split event log reading and writing into its own process, which will communicate with the Mars Nock runner process.
Future
duration
2-3 Months
We intend to split the Urth I/O process into multiple processes -- one dispatcher process and one process for each I/O driver.
Future
duration
3 Months
One of the main barriers to writing an Urbit app is that the standard way to present a user interface is by writing it in JavaScript that runs in a web browser. This has advantages, but it requires writing code in two languages, and it means you can't stay in Urbit entirely when writing an app. This phase of the work involves allowing hoon UI specifications to be rendered to a browser
Future
duration
TBD
A standard protection against DDoS attacks is to track and rate-limit IP addresses sending malicious packets. A basic version of this functionality could be added to Vere without too much trouble and give Urbit a modicum of DoS resilience.
Future
duration
1-3 Months
Ames packets need to be decrypted to be authenticated. Wrapping the packet in an HMAC would let the receiver discard unauthenticated packets faster, improving DoS resilience.
Future
The "quick boot" project aims to bring initial Urbit boot time down from ~10 minutes to well under a minute.
Future
duration
1 Month
Urth/Mars communication all happens within a single IPC connection. Separating communication that's unrelated to the event loop (such as logging, scry requests and responses, spinner status notifications, and snapshot notifications) into separate IPC streams should improve performance and increase flexibility for alternate Mars implementations.
Future
duration
2-3 Months
Vere's two processes, Urth (the I/O process) and Mars (the Nock worker process), communicate using a custom noun-based interprocess communication (IPC) protocol. This currently uses the Unix stdin and stdout, but using shared memory instead would make IPC significantly faster, reducing event processing latency and improving overall data throughput.
Future
duration
2 Months
As it stands, every Kelvin change breaks backward compatibility, requiring app devs to publish modified code so their users can keep the app running. This needs to happen less frequently over time, until eventually apps can be "write once, run forever."
Future
duration
TBD
Urbit's timer system could be better in several ways.
Future
duration
4-8 Months
A typed interface to solid-state publications should improve developer experience and performance (by avoiding runtime typechecks and type coercions).
Future
duration
1 Month
There are a number of places where Vere crashes where it should instead handle the error and continue.
Future
duration
4-8 Months
Standardizing application protocol versioning in the kernel should improve developer experience and lead to more applications behaving correctly across upgrades, thereby improving user experience too.
Future
duration
1 Month
Turning off the `!<` ("zapgal") rune in userspace will reduce the security attack surface of the kernel, reducing the kernel's vulnerability to attack by malicious applications.