Yaseen ynx0

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

Ames Push-Based Reconnect

As it stands, Ames re-sends packets to an offline peer forever, every two minutes. For a ship with, say, 2400 offline subscribers to five chat channels, this adds up to a hundred packets being sent per second to ships that aren't there. A lot of those packets will also go through a relay before being hurled into the void, forcing the relay to do essentially meaningless work.

This is a fair amount of wasted CPU, bandwidth, and disk usage (every retry is a new Arvo event on the sender, which must be written to disk). To make it worse, the retry rate trades off against reconnect latency. If my ship comes back online after a few minutes of downtime, it will take on average one minute -- half the retry interval -- before I hear retried packets from my peers. Lowering the retry interval to lessen the reconnect time would increase the bunk packet rate, which increases systemic load on the network.

A couple years ago, ~wicdev-wisryt proposed switching Ames to use push-based recon

Vagrant and VMWare Tech Preview 21H1 on Apple M1 Pro

UPDATE November 20, 2022: VMWare Fusion 13

VMWare Fusion 13 is now released. Read Vagrant and VMWare Fusion 13 Player on Apple M1 Pro for the latest.

Summary

This document summarizes notes taken while to make the VMWare Tech preview work on Apple M1 Pro, it originated

quick recap on complex numbers

Take a number, square it, the result is non-negative. Because positive * positive = positive and negative * negative is positive. Or $0^2 = 0^2$.

But someone wanted to take square roots of negative numbers, so they did, and called it 'i'. $\sqrt{-1} = i$. A lot of people were frustrated upon learning this "You can't do that!", "How do you know that it doesn't lead to contradictions".

The solution, to put imaginary and complex numbers on a solid foundation is something called a ring quotient. What you do is you start with the ring (meaning number system) of polynomials over the real numbers $R[i]$, which looks like this:

$1, 2 3.5, \pi$ etc.
$i, i^2, 0.3 + 9.5 i + 23 i^3$ and so on.

Mill Explained

Mill, or mill.hoon, is the execution engine for Uqbar. At a high level, it takes the current state of a town (a "shard" of our rollup) along with a set of transactions (referred to in code as eggs) and creates a state transition which can be applied to that town. Here, I will document the specifics of this process and explore implementation choices available to us.

It's important to note that our current implementation of the execution engine can be modified in some ways by Sequencers. The result of an individual transaction must be ZK-verified, that is, the sequencer must generate hints to prove the computation was performed correctly, but the overall state transition can be composed of these results in many ways. A Sequencer therefore has the ability to exclude or order transactions in ways they see fit (with the potential, here, for MEV extraction). The implementation choices made outside of the "must-prove" portion of mill.hoon are made for performance, not validity, and can

This is a proposal for a "lure service".

While this can serve as the foundation for countless features, the primary goal is to solve the "boot into an empty landscape" problem. In other words, it's trying to close the loop of "one person uses Urbit" -> "they invite another to their group on Urbit" -> "they get on Urbit and immediately know what to do with it" -> "they invite another".

Thus, we will first consider the case of inviting someone into an Urbit group who may not already use Urbit.

Invites should be regular links. These work on any device, can be transmitted over any transport (including publicly in a tweet or physically via qr code), and are very low-friction to click. When you click this link, you should expect to receive an invite to that group.

To make this happen, we must somehow establish an association between the person who clicked the link and their @p. We should make this work for as many cases as possible -- especially, it should work even if they don't yet have a @p.

New Mars storyboard

Elevator pitch

An Urbit runtime with near-machine execution speed and NAS-equivalent addressable storage enables most classes of personal applications to be built directly on Urbit.

Wins

Near-machine execution speed

Currently standard library functions which implement highly-iterated loops, such as turn, are jetted to remove arm invocation overhead arising from indirect jumps, dynamic jet matching, and allocation for parameters. The majority of overhead in hot codepaths (such as Ames) is in arm invocations themselves, not in the code for arms.

Notes on this tweet.

The screenshots were taken on different sessions.
The entire sessions are included on the screenshots.
I lost the original prompts, so I had to reconstruct them, and still managed to reproduce.
The "compressed" version is actually longer! Emojis and abbreviations use more tokens than common words.

"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.

	#!/usr/bin/env python3

	def cli():

	@command
	def hello(*args):
	cmd('echo', 'Hello', *args)