Skip to content

Instantly share code, notes, and snippets.

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.

@belisarius222
belisarius222 / remote-scry.md
Last active September 16, 2025 20:48
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

{ config, pkgs, ... }:
{
require = [
<nixos/modules/programs/virtualbox.nix>
./hardware.nix
./monitors.nix
# ./mailpile.nix
];