sigilante

ἈΘΗ͂ΝΑΙ: A VISION

The Athens project epitomizes several longstanding threads in Urbit's vision of a social Internet. Athens lays the groundwork for a transition from a set of centralized apps to a fully decentralized Urbit peer-to-peer network. Communities will be able to start in a captive state and roll over to become fully decentralized as they mature.

Athens therefore begins by defining a field of “captive” apps, or apps that are brokered through a centralized server. It implements the groundwork for the dotpoast vision by identifying security modalities and presenting a single access layout to the various modal apps. It includes a roadmap for transitioning all or part of the network to utilize not only Azimuth but also Arvo.

Software Suite

The initial release of Athens for the general public will include a number of integrated services. “Integration” means that links or references between apps are legible; for instanc

joemfb

The strategy of Urbit

Urbit is a new decentralized global computing infrastructure. Urbit is three layers: a continent (Azimuth), a computer (Arvo), and a civilization (Casbah).

To oversimplify: Casbah is a decentralized social network between Arvo servers with Azimuth addresses.

What is the actual status of these things?

dozreg-toplud

Mass update report

Introduction

A few months ago I started working on mass modernization project to learn about Arvo and Vere and to contribute to the core development. Since then I had some success working on WebAssembly interpreter, and I decided that it would be wise to focus my attention on that project instead.

I managed to achieve the first milestone outlined in the grant proposal. To ensure my efforts don't go in vain I will describe what I achieved and learned while working on that milestone.

Target audience

philipcmonk

"Stepwisdom" and "step nomadism" are two competing philosophies of how to sequence code upgrades, and they have a very long history in Urbit.

Stepwisdom is the idea that the system should guarantee that every update to a piece of code is run stepwise, in order. That is, you only ever upgrade from version n to n+1. This is very nice for developers -- instead of considering n different possible upgrade scenarios, you can consider only one. This sounds so nice that we've always planned to do it, though somehow we've never quite got there.

tiller-tolbus

%fleet specification

%fleet is an Urbit application for monitoring a set of sponsored ships. It is intended to be run on a ship that is providing value-added sponsor services to other running ships. The primary target audience is stars performing planet services, although it should in principle be useful for galaxies performing star services, as well as planets performing moon services.

%fleet initializes by collecting a set of residents on the host ship from Ethereum and Jael. Periodically, it checks to ensure that the set is up to date. Upon each refresh, new residents are added, and former residents are removed from this set. This “refresh” should occur at least once per hour, and even more frequently if performance allows.

%fleet will automatically monitor the uptime of each ship in its set. Similar to ~midden-fabler/ahoy, it will track the amount of time since the last heartbeat from each ship. If the time since last heartbeat exceeds a specified “heartbeat threshold”, %fleet will comman

belisarius222

• yes to epoch system
• each epoch has a version file, an initial snapshot, and an event log database file
• we will need to add code to vere to find the latest epoch folder before loading snapshot and event log
• there are two separable operations involved in truncation:

1. create new epoch, by copying snapshot into a new epoch folder, creating a new version file in that folder, and creating a new event log database file in that folder whose events db is empty and whose metadata db contains entries copied from the previous epoch's metadata db
2. a "keep only N recent epochs" command, which removes all epoch folders older than that

belisarius222

The best idea we have so far for parallel processing comes from ~master-morzod, and it's this:

You want to kick a long-running Nock computation (e.g. a call to the hoon compiler) out of the main event loop and run it in another thread so it doesn't block normal Arvo event processing while it's running. To do this, have Arvo store a $trap (a thunk, or unevaluated Nock expression), representing this computation, give it a number, and emit an effect to the runtime asking the runtime "please wake me up to run trap 37".

A naive runtime, upon seeing this effect, will just immediately enqueue an Arvo event asking Arvo "please run trap 37". This will defer execution of the trap until later, but it will still block the main loop.

A smart runtime doesn't immediately enqueue an Arvo event. Instead, it scrys into Arvo asking it for trap 37, and obtains the trap. It runs the trap in another thread (note that this requires adding basic multithreading support to the Nock interpreter). Once the computation completes,

mcrumm

Deploying to Fly.io with SQLite

Deploying a Phoenix app to Fly.io is a breeze...is what everyone kept telling me. In fairness, I imagine the process would have been breezier had I just used postgres, but all the sqlite and litestream talk has been far too intriguing to ignore. "Wait", you say. "It is just a flat file. How much harder can it be?"

It is easy to make something harder than it should be. It is hard to take something complex and make it truly simple. flyctl launch does an amazing job at providing a simple interface to the utterly complex task of generating deployment resources, especially now that we are living in a containerd (erm, firecracker) world.

This gist is for anyone who, like me, thinks they know better than to read all of the documentation and therefore necessari

belisarius222

Remote Scry Protocol Proposal

Overview

Despite Urbit's "scry" namespace being global (every request path contains the host ship), there is no way to query other ships. This proposal adds a second Urbit-to-Urbit network protocol that implements remote scrying. This will allow for ships to field read requests without incurring disk writes, and since the namespace is immutable, caching responses will be simple and worthwhile.

To "scry" in Urbit means to query the Urbit namespace. Conceptually, if a query resolves, it can produce either a piece of marked data (meaning tagged with a system-recognized type) or an empty result indicating that this path will never contain data. Not all requests resolve; some "block", which represents a refusal or inability to answer the question (such as a local query for a file at a future date). The namespace is immutable in the sense that all nonblocking results to the same query must be identical. Whether a query resolves is not specified; a query could succeed, the