Skip to content

Instantly share code, notes, and snippets.

View liam-fitzgerald's full-sized avatar

Liam Fitzgerald liam-fitzgerald

View GitHub Profile

The future of shrubbery:

Shrubbery is back! After much navel gazing, ketamine, and other forms of introspection that are under NDA, a decision has been reached. I have decided to push my code to the public (go look at lf/persist[1]). I apologize to everyone I left in the lurch.

So what’s next?

There are a handful of minor tasks that I need to finish in order for new shrubbery to work. These will be completed and released with groundwire. This release will be the last release of shrubbery-as-agent as well as the first with the new root shrub design. What was formerly app/neo.hoon is now app/lain.hoon, as well as a “root shrub” named neo. I consider %lain to be more or less the property of the community. All PRs welcome and considered. Neo will continue to be developed in public, however it should be considered a product, rather than infrastructure. Think of %lain as the filesystem and %neo like OS X.

https://github.com/liam-fitzgerald/urbit/tree/lf/persist

Urbit, as it lives and breathes
Segment 1: Bootstrapping
Urbit should be the easiest place to write any application. Excluding applications that require high performance, shrubbery already makes this very close to true. It needs a little more love and sanding down rough edges, but it’s extremely close
Result: The namespace is alive
Segment 2a: The “maximalism” in namespace maximalism
The most annoying part of working with Urbit is getting data in and out of the system. The solution to this is simple: Put everything inside the system. If all the data you could possibly want is bound somewhere, then a significant number of things we currently consider “applications” simply become transformations over the namespace. Moreover, this opens up the possibility of no-code shrubs because if the data already exists, then the necessity of marshaling shenanigans is a lot lower. We should leverage the network topology and provide stars incentives to republish data from the outside into their namespace.
Metabolized: Zapi
@liam-fitzgerald
liam-fitzgerald / remote-scry.md
Created January 11, 2022 21:08 — forked from belisarius222/remote-scry.md
Remote Scry Protocol Proposal

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

@liam-fitzgerald
liam-fitzgerald / lone-gall.hoon
Created October 18, 2020 23:14
gall-isolation.hoon
:: %lone: gall agent isolation subsystem
::
:: Unincluded in this sketch, but potentially necessary:
:: - Optional permissions
:: - Scrying an agents permissions out of gall
:: - Dynamic permissions
:: Open questions:
:: - Is allowing pokes based on mark specific enough? Maybe not,
:: given %graph-store. Maybe poke-marks should be
:: $@(mark [=mark $-(vase ?)])
//
// @urbit/groups
//
// import Airlock, { Poke, Watch, scry } from '@urbit/airlock'
// declare types
//
interface Group {}
type Groups = Record<string, Group>;
export type GroupUpdate = GroupUpdateAddMembers | GroupUpdateRemoveMembers;

Sadly due to the nature of the migration from links to graph store, it was not technically feasible to do a seamless migration. Instead, the latest OTA has moved all the link collections into graph-store, as archived graphs. As links now uses a client-server topology, groups should decide amongst themselves who should host the link collections, in order to prevent everybody hosting a different copy. If you would like to host a publically accessible link collection that you were in prior to the OTA, then you must do the following.

Work out what your resource identifier is

In the dojo, run

:graph-store +dbug [%state '~(key by archive)']
> {[entity=~nus name=%posts-853] [entity=~nus name=%music-384]}
/- spider
/+ strandio
/+ resource
=, strand=strand:spider
^- thread:spider
|= arg=vase
=/ m (strand ,vase)
^- form:m
;< =bowl:spider bind:m get-bowl:strandio
=/ groups=(list resource)
/+ auto=language-server-complete,
easy-print=language-server-easy-print
:- %say
|= [* [query=cord ~] ~]
:- %tang
=/ lib=type
-:!>(..zuse)
|^
=/ specs
%+ sear
/+ *chat-json
:- %say
|= [[now=@da eny=@uvJ bec=beak] ~ ~]
:- %json
(inbox-to-json .^(inbox %gx /(scot %p p.bec)/chat-store/(scot %da now)/all/noun))