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

sigilante

Butyl Captive Web Apps

In his dotpoast of ~2024.8.29 [1], Curtis Yarvin proposed a model for an Urbit application layer that temporarily decouples Azimuth-based logins from full decentralization on a fleet of Arvo ships. Such full or partial centralization allows apps to be polished with an anticipated later full decentralization to a mature Arvo release.

Yarvin's initial post laid out these possible apps by security factor:

• “Red-dot tiles are wallet apps which can can send your money to Burkina Faso where you can never get it back. You know. Crypto stuff. Be careful!

• “Gray-dot tiles are public feeds which show you public Web2 or Web3 data.

sigilante

Urbit: the future of private computing

By ~sorreg-namtyv · ~2024.8.29

Let's forget the gawky, warty, pimpled young Urbit of the present, and take a look at one possible fantastic user experience of the future.

Disclaimer: this is not a plan. This is just a dream. But everything in this dream (codename "Butyl") is real and possible and I think it's going to happen.

Onboarding

sigilante

Testing Mars

Software development theorist Michael Feathers, in his classic Working Effectively with Legacy Code, simply defined “legacy code” as “simply code without tests.” More specifically, Feathers referred to specific and auditable instantiations of tests as code. By this definition, much of Urbit's codebase is de facto legacy code. Our objective is to make Urbit demonstrably robust, capable of providing guarantees, and quantifiably amenable to reasoning. A robust testing framework and comprehensive test coverage are critical to providing such reliability and enabling enterprise-grade applications to be built on top of Urbit.

Current Urbit Testing

Unit testing is available on Urbit today for all parts of the system. No specialized kernel mode is necessary to audit gate behavior (altho Arvo and vane state information are not accessible from userspace). Urbit currently supplies the following tools:

-test Thread

sigilante

All serious Urbiters today are on a spectrum from pure builder to pure founder. This is not a problem—it's related to Riva Tez's remark that Urbit is a network of priests who need merchants. It's something like the employer/employee divide (at the extremes), but most of us are a bit more awkwardly in the middle of that span.

Becoming a founder means living in a world with an asymmetric payoff matrix. To found something means the opportunity to create massive value (rather than eke out minor value), and likewise to capture all or a significant portion of the created resources or streams.

Urbit seems to be trending towards a world wherein there is a slowly-growing pool of builder–founders that are perhaps housed in relatively fewer organizations. Urbit Foundation is growing in size and scope. Some other organizations have proven unable or unwilling to work within the constraints of building a hundred-year computer. The Aegean vision points towards a co

sigilante

%hush: Hoon Userspace Standard Hardware

The internal Urbit standard library, as contained in hoon.hoon and zuse.hoon, has largely been architected for building Hoon itself. This means that one of the highest-leverage software development efforts we can make is to produce a middleware userspace standard library that does everything a “normie” dev would want, with names such a dev would choose or guess. We can improve the non-core developer experience by defining and producing a set of standard libraries with intuitive names and interfaces. A userspace standard library will provide similar affordances to those available in common languages with larger user bases.

Several new libraries need to be defined. This will presumably be distributed via %yard.

• /lib/string, https://github.com/sigilante/string (ready)
• /lib/vector, C++ std::vector-style templating
• /lib/list, convenient list operations which are currently nonexistent (enumerate, zip, product, etc.)—maybe a general it

sigilante

%hob is a tiny %gall

As a stepping stone to composing full %gall apps, we propose %hob, a userspace framework for producing “toy” agent-like applications, called brownies.

Like %spider, %hob is itself a %gall agent that instruments other running processes. It wraps the %hob mini-agent, or brownie, with the standard Gall-scale boilerplate (including +dbug), allowing for straightforward interaction with the running brownie through the Dojo.

The brownie's state is defined in a $state block at the top of its file, e.g.:

+$  state

sigilante

Code accessibility cannot be an afterthought for Urbit development. Hoon has had a reputation for being a language of dense expressions, which we believe is now being cleared by sunshine. However, Hoon's extensive sugar syntax and irregular expressiveness can make it challenging for those relatively new to Hoon to decipher programs.

Code accessibility must be a priority for userspace Hoon. We can support developer learning and entry into the ecosystem by defining a subset of Hoon syntax that we adhere to in all of the appropriate guides and some of the userspace code.

Let's call this subset "Hoon Prime" (H´). Hoon Prime will be a code discipline within Hoon to promote a clear pathway for newer developers to understand the nature of Hoon programs before needing to grapple with the entire panoply of syntax and runes. Hoon Prime may not alway be the most concise Hoon code, and it will likely fail to maintain certain well-established preferences. (Even if there is a "better" way to write it, we should pre