git.iko.soy/urbit.org

on f7df2db help sign in

from2bb1b20

swap

to0 ahead, 3616 behind

compare

.gitignore+1−9

since splitsnapshots

unifiedsplit

@@ -11,7 +11,6 @@

11# next.js

11# next.js

12/.next/

12/.next/

13/out/

13/out/

14−.next

15

14

16# production

15# production

17/build

16/build

@@ -27,7 +26,6 @@ yarn-debug.log*

27yarn-error.log*

26yarn-error.log*

28

27

29# local env files

28# local env files

30−.env

31.env.local

29.env.local

32.env.development.local

30.env.development.local

33.env.test.local

31.env.test.local

@@ -37,10 +35,4 @@ yarn-error.log*

37.vercel

35.vercel

38

36

39# editors

37# editors

40−/.nova/

38+.nova

41−

42−# rss

43−public/rss.xml

44−

45−yarn.lock

46−

.husky/.gitignorenew file+1

@@ -0,0 +1 @@

1+_

.husky/pre-commitnew file+4

@@ -0,0 +1,4 @@

1+#!/bin/sh

2+. "$(dirname "$0")/_/husky.sh"

3+

4+npx pretty-quick --staged

.nova/Configuration.jsonnew file+3

@@ -0,0 +1,3 @@

1+{

2+ "workspace.name": "urbit.org"

3+}

.npmrcdeleted−1

@@ -1 +0,0 @@

1−unsafe-perm = true

.nvmrcdeleted−1

@@ -1 +0,0 @@

1−14

.prettierrcdeleted−5

@@ -1,5 +0,0 @@

1−{

2− "tabWidth": 2,

3− "useTabs": false,

4− "printWidth": 80

5−}

README.md+12−38

@@ -1,42 +1,20 @@

1−The website for Urbit is maintained by the Urbit Foundation and the Urbit community. Issues and contributions are welcome.

1+The website for Urbit.

2

2

3## Getting Started

3## Getting Started

4

4

5−1. Fork the [Urbit site repository](https://github.com/urbit/urbit.org).

5+```bash

6+npm install

7+```

6

8

7−2. [Create a local clone](https://help.github.com/articles/cloning-a-repository/) of your fork.

9+Run the development server:

8

10

9−3. Navigate to the `urbit.org` directory and install Node 14 using [nvm](https://github.com/nvm-sh/nvm):

11+```bash

12+npm run dev

13+# or

14+yarn dev

15+```

10

16

11− ```shell

12− cd urbit.org

13− nvm install 14

14− ```

15− You can then run `nvm use` whenever in the repository (or automate it with a script - see [here](https://github.com/nvm-sh/nvm#deeper-shell-integration)).

16−

17−4. Install our dependencies:

18−

19− ```shell

20− npm install

21− ```

22−

23− If running an arm64 Mac (M1 or later), you may need to install some dependencies to compile canvas, one of our dependencies. Assuming you have [Homebrew](https://brew.sh):

24−

25− ```shell

26− arch -arm64 brew install pkg-config cairo pango libpng jpeg giflib librsvg

27− ```

28−

29−5. Run the development server:

30−

31− ```shell

32− npm run dev

33− # or

34− yarn dev

35− ```

36−

37− Open [http://localhost:3000](http://localhost:3000) with your browser to see the result.

17+Finally, open [http://localhost:3000](http://localhost:3000) with your browser to see the result.

38−

39−To learn more about contributing, see GitHub's [documentation](https://docs.github.com/en/get-started/quickstart/contributing-to-projects).

40

18

41## Framework and Library Documentation

19## Framework and Library Documentation

42

20

@@ -51,8 +29,4 @@ To learn more about Tailwind CSS, take a look at the docs:

51

29

52## Deployment

30## Deployment

53

31

54−We deploy using Vercel. All pull requests will show a deployment preview via the same.

32+WIP

55−

56−## Upgrades

57−

58−The `/scripts` contains scripts used to programmatically upgrade site content data.

components/BasicPage.js+12−22

@@ -1,20 +1,15 @@

1import { useRouter } from "next/router";

1import { useRouter } from "next/router";

2import Head from "next/head";

2import Head from "next/head";

3−import Meta from "../components/Meta";

4import ErrorPage from "../pages/404";

3import ErrorPage from "../pages/404";

5−import {

6− Container,

4+import Container from "./Container";

7− SingleColumn,

8− Section,

9− Markdown,

10− IntraNav,

11− TableOfContents,

12−} from "@urbit/foundation-design-system";

13import Header from "./Header";

5import Header from "./Header";

14import Footer from "./Footer";

6import Footer from "./Footer";

15−import classNames from "classnames";

7+import SingleColumn from "./SingleColumn";

8+import Section from "./Section";

9+import markdownStyles from "../styles/markdown.module.css";

10+import { decode } from "html-entities";

16

11

17−export default function BasicPage({ post, markdown, search, index = false }) {

12+export default function BasicPage({ post, markdown, search }) {

18 const router = useRouter();

13 const router = useRouter();

19 if (!router.isFallback && !post?.slug) {

14 if (!router.isFallback && !post?.slug) {

20 return <ErrorPage />;

15 return <ErrorPage />;

@@ -22,22 +17,17 @@ export default function BasicPage({ post, markdown, search, index = false }) {

22 return (

17 return (

23 <Container>

18 <Container>

24 <Head>

19 <Head>

25− <title>{post.title}</title>

20+ <title>Urbit • {post.title}</title>

26− {Meta(post)}

27 </Head>

21 </Head>

28− <IntraNav ourSite="https://urbit.org" search={search} />

29 <SingleColumn>

22 <SingleColumn>

30 <Header search={search} />

23 <Header search={search} />

31− <Section>

24+ <Section narrow>

32 <h1>{post.title}</h1>

25 <h1>{post.title}</h1>

33 </Section>

26 </Section>

34− <Section>

27+ <Section narrow className={markdownStyles["markdown"]}>

35− <div className={classNames("flex", { sidebar: index })}>

28+ <article

36− <div className={classNames("markdown", { "max-w-prose": index })}>

29+ dangerouslySetInnerHTML={{ __html: decode(markdown) }}

37− <Markdown.render content={JSON.parse(markdown)} />

30+ ></article>

38− </div>

39− {index && <TableOfContents />}

40− </div>

41 </Section>

31 </Section>

42 </SingleColumn>

32 </SingleColumn>

43 <Footer />

33 <Footer />

components/Contact.jsdeleted−16

@@ -1,16 +0,0 @@

1−import NewsletterSignup from "./NewsletterSignup";

2−

3−export default function Contact({

4− emphasize,

5− ecosystem = false,

6− className = "",

7−}) {

8− const linkText = emphasize ? "text-green-400" : "text-wall-600";

9− const border = emphasize ? "border-green-400" : "border-wall-600";

10−

11− return (

12− <div className={className}>

13− <NewsletterSignup color={border} />

14− </div>

15− );

16−}

components/ContactSection.jsnew file+38

@@ -0,0 +1,38 @@

1+import NewsletterSignup from "../../components/NewletterSignup";

2+import { name, contact } from "../../lib/constants";

3+

4+export default function () {

5+ return (

6+ <Section narrow>

7+ <div className="measure">

8+ <h4 className="pb-6">

9+ If you’d like to follow our progress, we send monthly updates via

10+ email:

11+ </h4>

12+ </div>

13+ <NewsletterSignup color="black" />

14+ <h4 className="mt-12 text-gray">

15+ Follow us on{" "}

16+ <a className="text-black" href={contact.twitter}>

17+ Twitter

18+ </a>

19+ </h4>

20+ <h4 className="mt-6 text-gray">

21+ Explore code on{" "}

22+ <a className="text-black" href={contact.github}>

23+ Github

24+ </a>

25+ </h4>

26+ <h4 className="mt-6 text-gray">

27+ Ask questions in our{" "}

28+ <a className="text-black" href={contact.discord}>

29+ Discord

30+ </a>

31+ </h4>

32+ <h4 className="mt-6 text-gray">

33+ Boot Urbit and join{" "}

34+ <code className="bg-wall p-2 rounded-lg">{contact.urbitCommunity}</code>

35+ </h4>

36+ </Section>

37+ );

38+}

components/Container.jsnew file+8

@@ -0,0 +1,8 @@

1+// Ensures the root container is always 100vw, min 100vh, and centers all children along the y-axis

2+export default function Container({ children }) {

3+ return (

4+ <div className="flex flex-col min-h-screen w-screen items-center">

5+ {children}

6+ </div>

7+ );

8+}

components/ContentArea.js+20−80

@@ -1,85 +1,25 @@

1−import { useState, useEffect, useRef } from "react";

2−import { useRouter } from "next/router";

3−import { TableOfContents } from "@urbit/foundation-design-system";

4−

5export default function ContentArea(props) {

1export default function ContentArea(props) {

6− const [shortcut, setShortcut] = useState("");

7−

8− const detectOS = () => {

9− const agent = window.navigator.appVersion;

10− if (agent.includes("Win")) {

11− return "Ctrl+K";

12− } else if (agent.includes("Mac")) {

13− return "⌘K";

14− } else if (agent.includes("Linux")) {

15− return "Ctrl+K";

16− }

17− };

18−

19− useEffect(() => {

20− setShortcut(detectOS());

21− }, []);

22−

23− const scrollBox = useRef();

24−

25− const router = useRouter();

26−

27− useEffect(() => {

28− const handleRouteChange = () => {

29− if (scrollBox.current === null) return;

30− scrollBox.current.scrollTop = 0;

31− };

32−

33− router.events.on("routeChangeComplete", handleRouteChange);

34−

35− // If the component is unmounted, unsubscribe

36− // from the event with the `off` method:

37− return () => {

38− router.events.off("routeChangeStart", handleRouteChange);

39− };

40− }, []);

41−

42 return (

2 return (

43− <div className="w-full min-w-0 flex flex-col items-center bg-white">

3+ <div className="w-full min-w-0 flex flex-col">

44− <div

4+ <header className="w-full px-4 md:px-8 md:w-10/12 flex flex-row justify-between items-center pt-8 md:pt-10 lg:pt-12 pb-10 md:pb-12 lg:pb-24">

45− ref={scrollBox}

5+ <div className="type-ui">{props.section}</div>

46− className="px-4 md:px-12 lg:px-24 pt-8 md:pt-10 lg:pt-16 flex flex-col w-full max-w-screen-xl max-h-screen h-screen overflow-y-scroll"

6+ {

47− >

48− <div className="flex justify-between w-full items-center shrink-0">

49− <div className="font-semibold antialiased text-lg text-black">

50− {props.breadcrumbs}

51− </div>

52− <div className="hidden md:block">

53− <button

7+ // <button

54− onClick={(e) => {

8+ // onClick={(e) => {

55− e.stopPropagation();

9+ // e.stopPropagation();

56− props.search.toggleSearch();

10+ // props.search.toggleSearch();

57− }}

11+ // }}

58− className="bg-wall-100 text-wall-500 flex px-4 py-1 rounded-lg type-ui"

12+ // className="button-sm bg-wall text-gray"

59− >

13+ // >

60− Search<div className="ml-4 text-wall-400">{shortcut}</div>

14+ // Search<div className="ml-4 text-lightGray">⌘K</div>

61− </button>

15+ // </button>

62− </div>

16+ }

63− </div>

17+ </header>

64− <div className="flex justify-between">

18+ <div className="px-4 md:px-12 lg:px-24 pb-24 pt-16 flex flex-col w-full max-h-screen h-screen overflow-y-scroll">

65− <div className="min-w-0 max-w-screen-md">

19+ <div className="type-ui text-lightGray">{props.breadcrumbs}</div>

66− <div className="mb-16">

20+ <h2 className="mb-16 mt-4">{props.title}</h2>

67− <h2 className="mt-24">{props.title}</h2>

68− {props?.description && (

69− <p className="text-wall-400 font-regular mt-2 text-xl">

70− {props.description}

71− </p>

72− )}

73− </div>

74− {props.children}

21+ {props.children}

75− <div className="pb-24" />

22+ <div className="pb-32" />

76− </div>

77− {!props?.disableToC && (

78− <TableOfContents

79− key={props.params.slug?.join("/") || Math.random()}

80− />

81− )}

82− </div>

83 </div>

23 </div>

84 </div>

24 </div>

85 );

25 );

components/CopyLink.jsdeleted−61

@@ -1,61 +0,0 @@

1−import { useCopyToClipboard } from "../lib/hooks";

2−

3−export default function CopyLink({ content, className }) {

4− const [copyStatus, copy] = useCopyToClipboard(content);

5−

6− const buttonIcon =

7− copyStatus === "inactive" ? (

8− <svg

9− width="16"

10− height="16"

11− viewBox="0 0 16 16"

12− className="fill-white"

13− xmlns="http://www.w3.org/2000/svg"

14− >

15− <path

16− fillRule="evenodd"

17− clipRule="evenodd"

18− d="M3.2 1.6C3.2 0.716344 3.91634 0 4.8 0H11.3615L14.9333 2.38124V12.2667C14.9333 13.1503 14.217 13.8667 13.3333 13.8667H12.8V14.4C12.8 15.2837 12.0837 16 11.2 16H2.66667C1.78301 16 1.06667 15.2837 1.06667 14.4V3.73333C1.06667 2.84968 1.78301 2.13333 2.66667 2.13333H3.2V1.6ZM3.2 3.2H2.66667C2.37211 3.2 2.13333 3.43878 2.13333 3.73333V14.4C2.13333 14.6946 2.37211 14.9333 2.66667 14.9333H11.2C11.4946 14.9333 11.7333 14.6946 11.7333 14.4V13.8667H4.8C3.91634 13.8667 3.2 13.1503 3.2 12.2667V3.2Z"

19− />

20− </svg>

21− ) : copyStatus === "copied" ? (

22− <svg

23− width="16"

24− height="16"

25− viewBox="0 0 16 16"

26− xmlns="http://www.w3.org/2000/svg"

27− >

28− <path

29− fillRule="evenodd"

30− clipRule="evenodd"

31− d="M0 8C0 3.58172 3.58172 0 8 0C12.4183 0 16 3.58172 16 8C16 12.4183 12.4183 16 8 16C3.58172 16 0 12.4183 0 8ZM7.54325 11.4247L12.1498 5.66647L11.3169 5.00013L7.39013 9.90859L4.60812 7.59025L3.92526 8.40969L7.54325 11.4247Z"

32− />

33− </svg>

34− ) : (

35− <svg

36− width="16"

37− height="16"

38− viewBox="0 0 16 16"

39− className="fill-white"

40− xmlns="http://www.w3.org/2000/svg"

41− >

42− <path

43− fillRule="evenodd"

44− clipRule="evenodd"

45− d="M0 8C0 3.58172 3.58172 0 8 0C12.4183 0 16 3.58172 16 8C16 12.4183 12.4183 16 8 16C3.58172 16 0 12.4183 0 8ZM10.8229 11.5772L8.00004 8.75429L5.17716 11.5772L4.42292 10.8229L7.24579 8.00004L4.42292 5.17716L5.17716 4.42292L8.00004 7.24579L10.8229 4.42292L11.5772 5.17716L8.75429 8.00004L11.5772 10.8229L10.8229 11.5772Z"

46− />

47− </svg>

48− );

49−

50− return (

51− <button

52− className={`bg-wall-600 p-4 rounded-xl button-sm text-white flex items-center justify-center space-x-2 ${className}`}

53− onClick={() => copy()}

54− >

55− <p className="leading-5">

56− {copyStatus === "copied" ? "Copied" : "Shortcode"}

57− </p>

58− {buttonIcon}

59− </button>

60− );

61−}

components/DocsSidebar.jsdeleted−32

@@ -1,32 +0,0 @@

1−import Link from "next/link";

2−import { useState } from "react";

3−import { MenuTray } from '@urbit/foundation-design-system'

4−

5−export default function Sidebar(props) {

6− const [isOpen, setTray] = useState(false);

7− return (

8− <>

9− <div className="hidden md:flex flex-col w-96 bg-wall-100 max-h-screen h-screen">

10− <header className="flex shrink-0 justify-between items-center pl-6 pt-12 mt-5 pb-8">

11− <Link href="/" passHref>

12− <a className="font-semibold antialiased text-lg text-wall-500">Urbit</a>

13− </Link>

14− </header>

15− <div className="overflow-y-auto p-6 pt-16">

16− {props.children}

17− <div className="pb-32" />

18− </div>

19− </div>

20−

21− <MenuTray isOpen={isOpen} setTray={setTray} search={props.search}>

22− <header className="flex shrink-0 justify-between items-center pb-8">

23− <Link href="/" passHref>

24− <a className="type-ui text-wall-500">Urbit</a>

25− </Link>

26− </header>

27− {props.children}

28− <div className="pt-64" />

29− </MenuTray>

30− </>

31− );

32−}

components/EventPreview.js+16−75

@@ -1,88 +1,29 @@

1import Link from "next/link";

1import Link from "next/link";

2−import { DateTime } from "luxon";

3−import { DateRange } from "../components/Snippets";

4−import {

5− generateDisplayDate,

6− generateRealtimeDate,

7−} from "@urbit/foundation-design-system";

8−import classNames from "classnames";

9

2

10−export default function EventPreview({ event, className, big }) {

3+export default function EventPreview({ event, className, title }) {

11 // Event tiles have a 'dark mode' used when their background images are dark and white text is needed for legibility.

4 // Event tiles have a 'dark mode' used when their background images are dark and white text is needed for legibility.

12− const grayText = event?.dark ? "text-white dark:text-black" : "text-wall-400";

5+ const grayText = event.extra?.dark ? "text-midWhite" : "text-gray";

13− const blackText = event?.dark

6+ const blackText = event.extra?.dark ? "text-white" : "text-black";

14− ? "text-white dark:text-black"

15− : "text-wall-600";

16−

17− const starts = generateDisplayDate(event.starts, event.timezone);

18− const ends = generateDisplayDate(event.ends, event.timezone);

19−

20− const inFuture = generateRealtimeDate(starts) > DateTime.now();

21−

22− const happeningNow =

23− generateRealtimeDate(event.starts) > DateTime.now() && !inFuture;

24

7

25 return (

8 return (

26− <div className={`cursor-pointer h-full ${className}`}>

9+ <div className={`cursor-pointer ${className}`}>

10+ {title ? <h3 className="mb-2">{title}</h3> : null}

27 <div

11 <div

28 key={event.slug}

12 key={event.slug}

29− className={`bg-wall-100 min-h-[320px] h-full flex flex-col rounded-xl bg-cover bg-center bg-no-repeat `}

13+ className={`bg-wall rounded-xl h-96 bg-cover bg-center bg-no-repeat`}

30− style={{ backgroundImage: `url(${event.image})` || "" }}

14+ style={{ backgroundImage: `url(${event.extra?.image})` || "" }}

31 >

15 >

32 <Link href={`/events/${event.slug}`}>

16 <Link href={`/events/${event.slug}`}>

33− <div

34− className={classNames(

35− "flex flex-col p-6 min-h-[320px] justify-between items-between h-full relative",

17+ <div className="flex flex-col p-4 justify-between items-between h-full relative">

36− {

37− "backdrop-brightness-50 rounded-xl": Boolean(

38− event?.darken_image

39− ),

40− }

41− )}

42− >

43− <div

44− className={`grow-1 flex ${big ? "justify-center" : ""

18+ <div className="flex-grow-1 flex flex-col justify-center h-full">

45− } flex-col h-full`}

46− >

47− <h3 className={`${blackText} mb-2`} id={event.title}>{event.title}</h3>

19+ <h4 className={`mb-4 ${blackText}`}>{event.title}</h4>

48− <p className={blackText + " truncate text-sm"}>

20+ <p className={grayText}>{event?.type}</p>

49− {event.description}

50− </p>

51 </div>

21 </div>

52−

22+ <div className="absolute p-4 left-0 bottom-0 w-full">

53− <div className="flex justify-between items-end">

54− <div className="">

55− <p className={`${blackText} type-sub mb-1`}>{event.location}</p>

23+ <p className={`${grayText} type-ui-small`}>{event.extra.host}</p>

56− <DateRange

57− starts={starts}

58− ends={ends}

59− className={`${grayText} type-sub`}

24+ <p className={`${grayText} type-ui-small`}>

60− />

25+ {event.extra.guests}

61− </div>

26+ </p>

62−

63− {inFuture && event.registration_url ? (

64− <div>

65− <a

66− className="button-sm bg-green-400 text-white"

67− href={event.registration_url}

68− onClick={(e) => e.stopPropagation()}

69− target="_blank"

70− >

71− RSVP

72− </a>

73− </div>

74− ) : event.youtube ? (

75− <div className="shrink-0">

76− <a

77− className="button-sm bg-wall-600 text-white shrink-0"

78− href={`https://www.youtube.com/watch?v=${event.youtube}`}

79− onClick={(e) => e.stopPropagation()}

80− target="_blank"

81− >

82− ▶ Watch

83− </a>

84− </div>

85− ) : null}

86 </div>

27 </div>

87 </div>

28 </div>

88 </Link>

29 </Link>

components/Footer.js+155−3

@@ -1,6 +1,158 @@

1−import { Footer as FooterComponent } from "@urbit/foundation-design-system";

1+import Link from "next/link";

2+import SingleColumn from "./SingleColumn";

3+import Section from "./Section";

2−import { footerData } from "../lib/constants";

4+import { contact } from "../lib/constants";

3

5

4export default function Footer() {

6export default function Footer() {

5− return <FooterComponent data={footerData} />;

7+ return (

8+ <footer className="bg-wall w-full mt-48 flex justify-center">

9+ <SingleColumn>

10+ <Section short className="flex flex-row flex-wrap">

11+ <div className="w-1/2 md:w-1/3 flex flex-col flex-shrink">

12+ <h4 className="mt-16 mb-8">Use Urbit</h4>

13+ <Link href="https://github.com/urbit/port/releases">

14+ <div>

15+ <a className="type-sub text-gray">Urbit Client</a>

16+ </div>

17+ </Link>

18+ <Link href="https://github.com/urbit/urbit/releases">

19+ <div>

20+ <a className="mt-2 type-sub text-gray">Urbit Binaries</a>

21+ </div>

22+ </Link>

23+ {

24+ // <Link href="">

25+ // <div>

26+ // <a className="mt-2 type-sub text-gray">Urbit Apps</a>

27+ // </div>

28+ // </Link>

29+ }

30+ <Link href="/getting-started/planet/#hosting-providers">

31+ <div>

32+ <a className="mt-2 type-sub text-gray">Hosting Providers</a>

33+ </div>

34+ </Link>

35+ </div>

36+ <div className="w-1/2 md:w-1/3 flex flex-col flex-shrink">

37+ <h4 className="mt-16 mb-8">About</h4>

38+ <Link href="/understanding-urbit">

39+ <div>

40+ <a className="type-sub text-gray">What's Urbit?</a>

41+ </div>

42+ </Link>

43+ <Link href="/understanding-urbit/urbit-id">

44+ <div>

45+ <a className="mt-2 type-sub text-gray">Urbit ID</a>

46+ </div>

47+ </Link>

48+ <Link href="/understanding-urbit/urbit-os">

49+ <div>

50+ <a className="mt-2 type-sub text-gray">Urbit OS</a>

51+ </div>

52+ </Link>

53+ <Link href="/faq">

54+ <div>

55+ <a className="mt-2 type-sub text-gray">FAQ</a>

56+ </div>

57+ </Link>

58+ </div>

59+ <div className="w-1/2 md:w-1/3 flex flex-col flex-shrink">

60+ <h4 className="mt-16 mb-8">News</h4>

61+ <Link href="/blog">

62+ <div>

63+ <a className="type-sub text-gray">Blog</a>

64+ </div>

65+ </Link>

66+ <Link href="/events">

67+ <div>

68+ <a className="mt-2 type-sub text-gray">Events</a>

69+ </div>

70+ </Link>

71+ </div>

72+

73+ <div className="w-1/2 md:w-1/3 flex flex-col">

74+ <h4 className="mt-16 mb-8">Develop</h4>

75+ <Link href="/docs">

76+ <div>

77+ <a className="type-sub text-gray">Documentation</a>

78+ </div>

79+ </Link>

80+ <Link href="https://github.com/urbit">

81+ <div>

82+ <a className="mt-2 type-sub text-gray">Github</a>

83+ </div>

84+ </Link>

85+ <Link href="https://github.com/urbit/awesome-urbit#http-apis-airlock">

86+ <div>

87+ <a className="mt-2 type-sub text-gray">Airlock APIs</a>

88+ </div>

89+ </Link>

90+ </div>

91+ <div className="w-1/2 md:w-1/3 flex flex-col">

92+ <h4 className="mt-16 mb-8">Contribute</h4>

93+ <Link href="https://github.com/urbit/urbit/issues">

94+ <div>

95+ <a className="type-sub text-gray">Issue Tracker</a>

96+ </div>

97+ </Link>

98+ <Link href="/grants">

99+ <div>

100+ <a className="mt-2 type-sub text-gray">Urbit Grants</a>

101+ </div>

102+ </Link>

103+ </div>

104+

105+ <div className="w-1/2 md:w-1/3 flex flex-col">

106+ <h4 className="mt-16 mb-8">Community</h4>

107+ <Link href="https://groups.google.com/a/urbit.org/g/dev?pli=1">

108+ <div>

109+ <a className="type-sub text-gray">Dev Mailing List</a>

110+ </div>

111+ </Link>

112+ <Link href="https://discord.gg/CfSKKaB2ep">

113+ <div>

114+ <a className="mt-2 type-sub text-gray">Support Discord</a>

115+ </div>

116+ </Link>

117+ <Link href="https://github.com/urbit/azimuth">

118+ <div>

119+ <a className="mt-2 type-sub text-gray">Governance</a>

120+ </div>

121+ </Link>

122+ <Link href="https://twitter.com/urbit">

123+ <div>

124+ <a className="mt-2 type-sub text-gray">Twitter</a>

125+ </div>

126+ </Link>

127+ </div>

128+ </Section>

129+ <Section className="flex flex-col md:flex-row">

130+ <div className="md:w-1/3">

131+ <Link href="/privacy">

132+ <div>

133+ <a className="type-sub text-gray">Privacy Policy</a>

134+ </div>

135+ </Link>

136+ </div>

137+ <div className="md:w-1/3">

138+ <Link href="/terms-of-service">

139+ <div>

140+ <a className="type-sub text-gray">Terms of Service</a>

141+ </div>

142+ </Link>

143+ </div>

144+ <div className="md:w-1/3">

145+ <div>

146+ <a

147+ href={"mailto:" + contact.email}

148+ className="type-sub text-gray"

149+ >

150+ {contact.email}

151+ </a>

152+ </div>

153+ </div>

154+ </Section>

155+ </SingleColumn>

156+ </footer>

157+ );

6}

158}

components/GrantPreview.js+28−50

@@ -2,61 +2,39 @@ import classnames from "classnames";

2import Link from "next/link";

2import Link from "next/link";

3

3

4export default function GrantPreview({ grant }) {

4export default function GrantPreview({ grant }) {

5− const isCompleted = grant.extra.completed;

6− const isOpen = !isCompleted && grant.extra.assignee?.[0] === "";

7− const type = grant.taxonomies.grant_type;

8−

9− const className = classnames({

10− "bg-lightBlue": type.includes("Proposal") && isOpen,

11− "bg-purple-200": type.includes("RFP") && isOpen,

12− "bg-yellow-100": type.includes("Bounty") && isOpen,

13− });

14−

15 return (

5 return (

16− <div

17− key={grant.slug}

18− className={`mb-4 cursor-pointer bg-wall-100 rounded-lg ${className}`}

6+ <div key={grant.slug} className="mb-4 cursor-pointer bg-wall rounded-lg">

19− >

20− <Link href={`/grants/${grant.slug}`} passHref>

7+ <Link href={`/grants/${grant.slug}`}>

21− <a>

22− <div className="p-8">

8+ <div className="p-8">

23− <div className="flex items-center mb-4">

24− <h3 className="type-ui" id={grant.slug}>

9+ <h3 className="type-ui mb-4">{grant.title}</h3>

25− {grant.title}

26− </h3>

27− <div className={`bg-wall-500 text-wall-100 badge-sm ml-2`}>

28− {!isCompleted ? (isOpen ? "Open" : "In Progress") : "Completed"}

29− </div>

30− </div>

31− <p className="mb-4">{grant.extra.description}</p>

10+ <p className="mb-4">{grant.extra.description}</p>

32− <div className="flex w-full flex-col md:flex-row md:items-center justify-between">

11+ <div className="flex w-full flex-col md:flex-row md:items-center justify-between">

33− <p className="text-wall-500">

12+ <p className="text-gray">

34− <strong>Reward: </strong>

13+ <strong>Reward: </strong>

35− {grant.extra.reward}

14+ {grant.extra.reward} star

15+ {grant.extra.reward === 1 ? "" : "s"}

36− </p>

16+ </p>

37− <div className="flex items-center flex-wrap md:mt-0 mt-4">

17+ <div className="flex items-center flex-wrap md:mt-0 mt-4">

38− {grant.taxonomies.grant_type.map((category) => {

18+ {grant.taxonomies.grant_type.map((category) => {

39− const className = classnames({

19+ const className = classnames({

40− "bg-blue-400 text-white": category === "Proposal",

20+ "bg-blue text-white": category === "Proposal",

41− "bg-purple text-white": category === "RFP",

42− "bg-green-400 text-white": category === "Apprenticeship",

21+ "bg-green text-white": category === "Apprenticeship",

43− "bg-yellow-300": category === "Bounty",

22+ "bg-yellow": category === "Bounty",

44− });

23+ });

45− return (

24+ return (

46− <div className={`${className} badge-sm mr-1 my-1`}>

25+ <div className={`${className} badge-sm mr-1 my-1`}>

47− {category}

48− </div>

49− );

50− })}

51− {grant.taxonomies.grant_category.map((category) => (

52− <div className="bg-wall-500 text-wall-100 badge-sm mr-1 my-1">

53 {category}

26 {category}

54 </div>

27 </div>

28+ );

55− ))}

29+ })}

30+ {grant.taxonomies.grant_category.map((category) => (

31+ <div className="bg-gray text-wall badge-sm mr-1 my-1">

32+ {category}

56− </div>

33+ </div>

34+ ))}

57 </div>

35 </div>

58 </div>

36 </div>

59− </a>

37+ </div>

60 </Link>

38 </Link>

61 </div>

39 </div>

62 );

40 );

components/GrantProgramOverview.jsdeleted−59

@@ -1,59 +0,0 @@

1−import { useRouter } from "next/router";

2−import Link from "next/link";

3−import Head from "next/head";

4−import Meta from "../components/Meta";

5−import ErrorPage from "../pages/404";

6−import {

7− Container,

8− Section,

9− SingleColumn,

10− Markdown,

11− IntraNav,

12− formatDate,

13−} from "@urbit/foundation-design-system";

14−import Header from "./Header";

15−import Footer from "./Footer";

16−import { DateTime } from "luxon";

17−

18−export default function GrantProgramOverview({

19− post,

20− markdown,

21− search,

22− program,

23− actionLink,

24− actionText,

25−}) {

26− const router = useRouter();

27− if (!router.isFallback && !post?.slug) {

28− return <ErrorPage />;

29− }

30−

31− const title = program.charAt(0).toUpperCase() + program.slice(1);

32− return (

33− <Container>

34− <Head>

35− <title>{title} • Grants</title>

36− {Meta(post)}

37− </Head>

38− <IntraNav ourSite="https://urbit.org" search={search} />

39− <SingleColumn>

40− <Header search={search} />

41− <Section narrow short>

42− <h1>{post.title}</h1>

43− <div className="type-ui text-wall-500 mt-4 md:mt-8 lg:mt-10">

44− Last Revision: {formatDate(DateTime.fromISO(post.date))}

45− </div>

46− <Link href={actionLink} passHref>

47− <a className="button-sm bg-green-400 text-white mt-8 max-w-fit">

48− {actionText}

49− </a>

50− </Link>

51− </Section>

52− <Section narrow short className="markdown">

53− <Markdown.render content={JSON.parse(markdown)} />

54− </Section>

55− </SingleColumn>

56− <Footer />

57− </Container>

58− );

59−}

components/Header.js+90−80

@@ -2,25 +2,28 @@ import Link from "next/link";

2import { useRouter } from "next/router";

2import { useRouter } from "next/router";

3import { useState } from "react";

3import { useState } from "react";

4import classnames from "classnames";

4import classnames from "classnames";

5−import { capitalize, MenuTray } from "@urbit/foundation-design-system";

5+import path from "path";

6+import MenuTray from "../components/MenuTray";

7+import Section from "../components/Section";

8+import { capitalize } from "../lib/lib";

6

9

7function ActiveLink({ children, href, className, currentPath }) {

10function ActiveLink({ children, href, className, currentPath }) {

8 const firstCrumb = currentPath.split("/")[1];

11 const firstCrumb = currentPath.split("/")[1];

9

12

10 const activeClassName = classnames({

13 const activeClassName = classnames({

11− "text-wall-900": "/" + firstCrumb === href,

14+ "text-black": "/" + firstCrumb === href,

12− "text-wall-500": "/" + firstCrumb !== href,

15+ "text-gray": "/" + firstCrumb !== href,

13 });

16 });

14

17

15 return (

18 return (

16− <Link href={href} passHref>

19+ <Link href={href}>

17 <a className={`${className} ${activeClassName}`}>{children}</a>

20 <a className={`${className} ${activeClassName}`}>{children}</a>

18 </Link>

21 </Link>

19 );

22 );

20}

23}

21

24

22export default function Header(props) {

25export default function Header(props) {

23− const [isOpen, setTray] = useState(false);

26+ const [isOpen, toggleTray] = useState(false);

24

27

25 const currentPath = useRouter().asPath;

28 const currentPath = useRouter().asPath;

26

29

@@ -29,14 +32,14 @@ export default function Header(props) {

29 const firstCrumb = currentPath.split("/")[1];

32 const firstCrumb = currentPath.split("/")[1];

30

33

31 return (

34 return (

32− <header className="layout px-4 md:px-8 flex justify-between items-center pt-8 md:pt-10 lg:pt-12 pb-10 md:pb-12 lg:pb-24">

35+ <header className="w-full px-4 md:px-8 md:w-10/12 flex flex-row justify-between items-center pt-8 md:pt-10 lg:pt-12 pb-10 md:pb-12 lg:pb-24">

33 <div>

36 <div>

34− <Link href="/" passHref>

37+ <Link href="/">

35− <a className="font-semibold text-lg">Urbit</a>

38+ <a className="type-ui">Urbit</a>

36 </Link>

39 </Link>

37 {routeDepth > 2 ? (

40 {routeDepth > 2 ? (

38− <Link href={`/${firstCrumb}`} passHref>

41+ <Link href={`/${firstCrumb}`}>

39− <a className="inline md:hidden type-ui text-wall-500 ml-2">

42+ <a className="inline md:hidden type-ui text-gray ml-2">

40 {capitalize(firstCrumb)}

43 {capitalize(firstCrumb)}

41 </a>

44 </a>

42 </Link>

45 </Link>

@@ -49,35 +52,17 @@ export default function Header(props) {

49 <ActiveLink

52 <ActiveLink

50 currentPath={currentPath}

53 currentPath={currentPath}

51 className="mr-5 type-ui"

54 className="mr-5 type-ui"

52− href="/getting-started"

55+ href="/docs"

53− >

54− Get Started

55− </ActiveLink>

56−

57− <ActiveLink

58− currentPath={currentPath}

59− className="mr-5 type-ui"

60− href="/overview"

61 >

56 >

62− Overview

57+ Docs

63 </ActiveLink>

58 </ActiveLink>

64−

65− <ActiveLink

66− currentPath={currentPath}

67− className="mr-5 type-ui"

68− href="/ecosystem"

69− >

70− Ecosystem

71− </ActiveLink>

72−

73 <ActiveLink

59 <ActiveLink

74 currentPath={currentPath}

60 currentPath={currentPath}

75 className="mr-5 type-ui"

61 className="mr-5 type-ui"

76− href="/grants"

62+ href="/blog"

77 >

63 >

78− Grants

64+ Blog

79 </ActiveLink>

65 </ActiveLink>

80−

81 <ActiveLink

66 <ActiveLink

82 currentPath={currentPath}

67 currentPath={currentPath}

83 className="mr-5 type-ui"

68 className="mr-5 type-ui"

@@ -85,85 +70,110 @@ export default function Header(props) {

85 >

70 >

86 Events

71 Events

87 </ActiveLink>

72 </ActiveLink>

88−

89 <ActiveLink

73 <ActiveLink

90 currentPath={currentPath}

74 currentPath={currentPath}

91− className="mr-5 type-ui"

75+ className="mr-5 text-green type-ui button-text"

92− href="/blog"

76+ href="/getting-started"

93 >

77 >

94− Blog

78+ Download Port

95 </ActiveLink>

79 </ActiveLink>

80+ <button

81+ onClick={(e) => {

82+ e.stopPropagation();

83+ props.search.toggleSearch(e);

84+ }}

85+ className="button-sm bg-wall text-gray"

86+ >

87+ Search<div className="ml-4 text-lightGray">⌘K</div>

88+ </button>

96 </nav>

89 </nav>

97

90

98 {

91 {

99 // Small screen header

92 // Small screen header

100 }

93 }

101− <MenuTray isOpen={isOpen} setTray={setTray} search={props.search}>

94+ <MenuTray isOpen={isOpen} toggleTray={toggleTray}>

102− <Link href="/" passHref>

95+ <Link href="/">

103− <a className="font-semibold mb-4">Urbit</a>

96+ <a className="type-ui mb-12">Urbit</a>

104− </Link>

105− <Link href="https://urbit.org" passHref>

106− <a className="font-semibold mt-2">Urbit.org</a>

107− </Link>

108− <Link href="https://operators.urbit.org" passHref>

109− <a className="mt-2">Operators</a>

110 </Link>

97 </Link>

111− <Link href="https://developers.urbit.org" passHref>

112− <a className="mt-2">Developers</a>

113− </Link>

114− <Link href="https://roadmap.urbit.org" passHref>

115− <a className="mt-2 mb-4">Roadmap</a>

116− </Link>

117− <hr className="border-wall-200" />

118−

119 <ActiveLink

98 <ActiveLink

120 currentPath={currentPath}

99 currentPath={currentPath}

121− className="mr-5 mt-4 mb-4 text-green-400"

100+ className="mr-5 mb-4 type-h3"

122− href="/getting-started"

101+ href="/docs"

123 >

102 >

124− Get Started

103+ Docs

125 </ActiveLink>

104 </ActiveLink>

126−

127 <ActiveLink

105 <ActiveLink

128 currentPath={currentPath}

106 currentPath={currentPath}

129− className="mr-5 mb-4"

107+ className="mr-5 mb-4 type-h3"

130− href="/overview"

108+ href="/blog"

131 >

109 >

132− Overview

110+ Blog

133 </ActiveLink>

111 </ActiveLink>

134−

135 <ActiveLink

112 <ActiveLink

136 currentPath={currentPath}

113 currentPath={currentPath}

137− className="mr-5 mb-4"

114+ className="mr-5 mb-4 type-h3"

138− href="/ecosystem"

115+ href="/events"

139 >

116 >

140− Ecosystem

117+ Events

141 </ActiveLink>

118 </ActiveLink>

142−

143 <ActiveLink

119 <ActiveLink

144 currentPath={currentPath}

120 currentPath={currentPath}

145− className="mr-5 mb-4"

121+ className="mr-5 mb-4 type-h3"

146 href="/grants"

122 href="/grants"

147 >

123 >

148 Grants

124 Grants

149 </ActiveLink>

125 </ActiveLink>

126+ </MenuTray>

150

127

151− <ActiveLink

128+ {

152− currentPath={currentPath}

129+ // Mobile menu button and search button

153− className="mr-5 mb-4"

130+ }

154− href="/events"

131+ <div className="block md:hidden">

132+ <button

133+ onClick={(e) => {

134+ e.stopPropagation();

135+ props.search.toggleSearch(e);

136+ }}

137+ className={`z-10 fixed px-4 items-center justify-center type-ui rounded-xl h-16 bg-white text-gray left-4 right-4 bottom-4 mobile-search-button-width ${

138+ isOpen ? "flex" : "hidden"

139+ }`}

155 >

140 >

156− Events

141+ Search

157− </ActiveLink>

142+ </button>

158−

143+ <button

159− <ActiveLink

144+ onClick={() => toggleTray(!isOpen)}

160− currentPath={currentPath}

145+ className="z-10 fixed bottom-4 right-4 w-16 h-16 bg-ultraDeepWall flex items-center justify-center rounded-full"

161− className="mr-5 mb-4"

162− href="/blog"

163 >

146 >

164− Blog

147+ {isOpen ? (

165− </ActiveLink>

148+ <svg

166− </MenuTray>

149+ width="16"

150+ height="16"

151+ viewBox="0 0 16 16"

152+ fill="none"

153+ xmlns="http://www.w3.org/2000/svg"

154+ >

155+ <path

156+ fill-rule="evenodd"

157+ clip-rule="evenodd"

158+ d="M0.39382 13.7045C-0.131273 14.2296 -0.131274 15.081 0.39382 15.6061C0.918913 16.1312 1.77026 16.1312 2.29535 15.6061L7.99999 9.90142L13.7047 15.6061C14.2297 16.1312 15.0811 16.1312 15.6062 15.6061C16.1313 15.081 16.1313 14.2296 15.6062 13.7046L9.90152 7.99989L15.6061 2.29535C16.1312 1.77026 16.1312 0.918913 15.6061 0.39382C15.081 -0.131273 14.2296 -0.131273 13.7045 0.39382L7.99999 6.09836L2.29548 0.393844C1.77038 -0.131249 0.919038 -0.13125 0.393945 0.393844C-0.131148 0.918937 -0.131148 1.77028 0.393945 2.29537L6.09846 7.99989L0.39382 13.7045Z"

159+ fill="white"

160+ />

161+ </svg>

162+ ) : (

163+ <svg

164+ width="16"

165+ height="16"

166+ viewBox="0 0 16 17"

167+ fill="none"

168+ xmlns="http://www.w3.org/2000/svg"

169+ >

170+ <rect width="16" height="3" rx="1.5" fill="white" />

171+ <rect y="7" width="16" height="3" rx="1.5" fill="white" />

172+ <rect y="14" width="16" height="3" rx="1.5" fill="white" />

173+ </svg>

174+ )}

175+ </button>

176+ </div>

167 </header>

177 </header>

168 );

178 );

169}

179}

components/HighlightCard.jsdeleted−22

@@ -1,22 +0,0 @@

1−import Link from "next/link";

2−export default function HighlightCard({ slug, highlight }) {

3− return (

4− <Link href={highlight.url}>

5− <div className="cursor-pointer bg-wall-100 rounded-xl min-h-0 flex-1">

6− <div className="flex flex-col p-4 h-full relative">

7− {highlight.image ? (

8− <div className="w-64 md:w-full rounded-xl object-cover overflow-hidden basis-3/5">

9− <img className="h-full w-64 md:w-full object-cover" src={highlight.image} />

10− </div>

11− ) : (

12− <div className="rounded-xl w-full"/>

13− )}

14− <div className="pt-4">

15− <p className="mb-2 font-semibold leading-5">{highlight.title}</p>

16− <p className="text-sm leading-5">{highlight?.description}</p>

17− </div>

18− </div>

19− </div>

20− </Link>

21− );

22−}

components/JoinGroup.jsdeleted−79

@@ -1,79 +0,0 @@

1−import { useCopyToClipboard } from "../lib/hooks";

2−

3−export default function Contact({ emphasize, groupName, label, className }) {

4− const [copyStatus, copy] = useCopyToClipboard(groupName);

5−

6− const linkText = emphasize ? "text-green-400" : "text-wall-600";

7− const border = emphasize ? "border-green-400" : "border-wall-600";

8− const washedBg = emphasize ? "bg-green-100" : "bg-wall-100";

9− const iconColor = emphasize ? "#00B171" : "#24221E";

10−

11− const buttonIcon =

12− copyStatus === "inactive" ? (

13− <svg

14− width="16"

15− height="16"

16− viewBox="0 0 16 16"

17− fill="none"

18− xmlns="http://www.w3.org/2000/svg"

19− >

20− <path

21− fillRule="evenodd"

22− clipRule="evenodd"

23− d="M3.2 1.6C3.2 0.716344 3.91634 0 4.8 0H11.3615L14.9333 2.38124V12.2667C14.9333 13.1503 14.217 13.8667 13.3333 13.8667H12.8V14.4C12.8 15.2837 12.0837 16 11.2 16H2.66667C1.78301 16 1.06667 15.2837 1.06667 14.4V3.73333C1.06667 2.84968 1.78301 2.13333 2.66667 2.13333H3.2V1.6ZM3.2 3.2H2.66667C2.37211 3.2 2.13333 3.43878 2.13333 3.73333V14.4C2.13333 14.6946 2.37211 14.9333 2.66667 14.9333H11.2C11.4946 14.9333 11.7333 14.6946 11.7333 14.4V13.8667H4.8C3.91634 13.8667 3.2 13.1503 3.2 12.2667V3.2Z"

24− fill={iconColor}

25− />

26− </svg>

27− ) : copyStatus === "copied" ? (

28− <svg

29− width="16"

30− height="16"

31− viewBox="0 0 16 16"

32− fill="none"

33− xmlns="http://www.w3.org/2000/svg"

34− >

35− <path

36− fillRule="evenodd"

37− clipRule="evenodd"

38− d="M0 8C0 3.58172 3.58172 0 8 0C12.4183 0 16 3.58172 16 8C16 12.4183 12.4183 16 8 16C3.58172 16 0 12.4183 0 8ZM7.54325 11.4247L12.1498 5.66647L11.3169 5.00013L7.39013 9.90859L4.60812 7.59025L3.92526 8.40969L7.54325 11.4247Z"

39− fill={iconColor}

40− />

41− </svg>

42− ) : (

43− <svg

44− width="16"

45− height="16"

46− viewBox="0 0 16 16"

47− fill="none"

48− xmlns="http://www.w3.org/2000/svg"

49− >

50− <path

51− fillRule="evenodd"

52− clipRule="evenodd"

53− d="M0 8C0 3.58172 3.58172 0 8 0C12.4183 0 16 3.58172 16 8C16 12.4183 12.4183 16 8 16C3.58172 16 0 12.4183 0 8ZM10.8229 11.5772L8.00004 8.75429L5.17716 11.5772L4.42292 10.8229L7.24579 8.00004L4.42292 5.17716L5.17716 4.42292L8.00004 7.24579L10.8229 4.42292L11.5772 5.17716L8.75429 8.00004L11.5772 10.8229L10.8229 11.5772Z"

54− fill={iconColor}

55− />

56− </svg>

57− );

58−

59− return (

60− <div className={className}>

61− <h4 className="text-wall-500 flex items-baseline flex-wrap">

62− {label ? label + " " : ""}

63− <div className="rounded-lg flex items-stretch">

64− <code

65− className={`rounded-l-lg px-2 md:px-4 py-2 ${washedBg} flex items-center h-full ${linkText}`}

66− >

67− {groupName}

68− </code>

69− <button

70− className={`rounded-r-lg px-4 ml-0.5 flex-1 flex justify-center items-center ${washedBg}`}

71− onClick={() => copy()}

72− >

73− {buttonIcon}

74− </button>

75− </div>

76− </h4>

77− </div>

78− );

79−}

components/Lorem.jsnew file+106

@@ -0,0 +1,106 @@

1+// Giant lorem ipsum for tests

2+export default function Lorem(props) {

3+ return (

4+ <div className={props.className || ''}>

5+ Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus sagittis posuere purus vitae auctor. Duis consequat commodo metus vel pellentesque. Nulla massa neque, commodo sed placerat vel, mattis sed felis. Proin et felis auctor, tristique ante at, mollis nisi. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; In tempus blandit volutpat. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

6+

7+ Praesent egestas at metus ac pharetra. Pellentesque tempus elit ex, vel scelerisque magna ornare ac. Vestibulum vitae est nibh. Nullam posuere, libero ac aliquet congue, urna tortor faucibus leo, eu bibendum quam nulla id metus. Vivamus eget feugiat ex. Sed purus nulla, ultricies eget dui fermentum, pellentesque posuere lectus. Maecenas vel orci dignissim ligula luctus varius. Quisque convallis massa in lectus aliquet, varius varius risus scelerisque. Suspendisse et interdum turpis. Sed ac fermentum nulla. Donec nunc est, tincidunt ac fermentum luctus, auctor vel dui. Vivamus hendrerit, libero sed pellentesque viverra, est massa pretium tellus, vel ultrices turpis ante at orci.

8+

9+ Interdum et malesuada fames ac ante ipsum primis in faucibus. Integer sit amet dui sed purus accumsan tempor. Aenean posuere lacus mollis mattis maximus. Integer hendrerit pulvinar tempus. Nam aliquet ipsum et arcu convallis placerat. Donec facilisis odio sed dolor ultricies, nec rhoncus lacus fringilla. Cras luctus odio ipsum, in pretium eros volutpat sit amet. Integer fringilla ipsum at bibendum imperdiet. Maecenas auctor magna non arcu varius rhoncus. Nunc dictum elementum suscipit. Proin rhoncus lacus in massa eleifend blandit.

10+

11+ Maecenas eu tellus dignissim, venenatis turpis eu, tempus odio. Praesent viverra vitae neque in dapibus. Donec fermentum neque at augue volutpat bibendum. Integer blandit tristique sodales. Vestibulum ultrices nulla ac est vulputate imperdiet. Vivamus venenatis cursus tellus quis faucibus. Curabitur non fringilla felis. Sed blandit tellus quis dictum cursus. In quam ex, euismod at ipsum quis, porta tempor nisl. In id scelerisque diam, quis gravida mi.

12+

13+ Nullam lacinia quis nibh vitae fermentum. Sed in libero vitae massa pulvinar feugiat nec non sem. Donec tristique ac felis vel feugiat. Suspendisse tempus ante metus, non porttitor arcu tincidunt nec. Vestibulum iaculis dolor ut quam lobortis, quis mollis purus imperdiet. Vivamus faucibus interdum nibh vel lacinia. Pellentesque at tempus mi. In hac habitasse platea dictumst. Phasellus ultricies tincidunt elementum. Mauris mollis mollis auctor.

14+

15+ Suspendisse potenti. Pellentesque egestas leo ut arcu imperdiet vehicula. Fusce dapibus volutpat leo, tempus sodales risus ultricies et. Nullam gravida massa ac aliquam egestas. In facilisis vitae eros vitae posuere. Duis enim enim, commodo vel dapibus et, consequat sed purus. Morbi ornare vitae tellus nec ultricies. Curabitur egestas lacus ut dictum laoreet. Praesent bibendum cursus pellentesque. Maecenas fringilla tempor lacus id feugiat. Praesent non imperdiet velit. Nulla facilisi. Vestibulum elementum, velit sed ultricies porta, odio eros porta libero, a tempor turpis arcu malesuada ipsum. Phasellus eu mauris elit.

16+

17+ Curabitur id justo a eros tristique semper sodales non ipsum. Mauris aliquam felis sed orci pretium, at placerat urna posuere. Suspendisse potenti. In ac ipsum lorem. Maecenas in semper tortor, ac consectetur enim. Nullam sit amet nulla ante. Aliquam viverra risus et mauris suscipit, at gravida risus dignissim. Proin tincidunt metus eros. Donec tempus finibus nulla quis ullamcorper. Etiam ut nulla nisl. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Vivamus lacinia ornare mauris ac fringilla. Maecenas ac faucibus ipsum.

18+

19+ Nulla finibus fringilla lacus, id venenatis dolor pulvinar vitae. Vestibulum vulputate luctus eros, sed commodo justo consectetur fermentum. Suspendisse potenti. Morbi ex diam, dapibus vel faucibus id, mattis et felis. Ut a interdum augue, euismod fringilla ex. Nullam fermentum, eros sed congue vestibulum, tortor neque tempus sapien, in ultricies erat nulla in eros. Aliquam non velit semper, ullamcorper augue nec, auctor purus. Duis enim felis, viverra nec nisi vel, sodales bibendum ante. Etiam sollicitudin ornare cursus.

20+

21+ Donec iaculis bibendum viverra. Mauris mattis consectetur suscipit. Proin at cursus risus. Vivamus eu felis condimentum, tempus enim id, vestibulum odio. Praesent pretium massa vitae turpis aliquet posuere. Nunc egestas, libero eu vestibulum iaculis, leo sapien consequat dolor, ut feugiat nisl metus vel eros. Suspendisse faucibus felis a est porta tincidunt. Sed diam orci, sodales non orci nec, pharetra dapibus ipsum.

22+

23+ Quisque rutrum, urna non vehicula porta, tellus dolor maximus quam, et pharetra justo diam quis neque. Suspendisse at lorem rhoncus, maximus tortor nec, sodales leo. Vivamus eu condimentum mauris. Pellentesque varius, velit nec maximus volutpat, dui purus porta lorem, eu dapibus metus risus non sem. Vestibulum id libero tellus. Quisque tortor turpis, laoreet eu est et, mollis volutpat elit. Nunc posuere enim sit amet vulputate fringilla. Curabitur pretium arcu in sem mattis pellentesque. Quisque vulputate ex leo, at accumsan tellus fermentum sit amet. Fusce ac velit vel dolor lacinia gravida. Proin ac faucibus felis.

24+

25+ Aliquam semper massa et cursus laoreet. Praesent nec ante auctor, dapibus sem id, pellentesque justo. Maecenas iaculis ex sapien, in tempor erat dapibus a. Vivamus varius ut turpis eget vehicula. Sed condimentum enim non consectetur sagittis. Donec eu ipsum eros. Pellentesque convallis tellus id finibus rutrum. Fusce et facilisis metus. Proin quis orci iaculis enim iaculis ultrices a et ipsum. Vivamus blandit a diam at condimentum.

26+

27+ Donec et vestibulum purus. Ut at est pulvinar mauris ultrices facilisis. Duis lacus quam, euismod maximus venenatis at, consectetur id nunc. Suspendisse elementum risus vitae eros laoreet gravida. Fusce aliquam, justo eu auctor iaculis, purus justo molestie metus, in tincidunt metus magna nec orci. Proin lacus libero, maximus eu laoreet nec, egestas et lorem. Nunc condimentum, arcu ac elementum facilisis, purus ligula maximus est, sit amet hendrerit dui ante eu elit. Aenean tempor rutrum massa eget efficitur. Donec tempor metus diam, in gravida nunc lobortis at. Nam elementum sollicitudin aliquam. Proin sit amet quam eros. Vivamus ut ante nisi. Pellentesque vitae felis consectetur erat ultrices ultrices ut a ante. Duis interdum, ante id accumsan maximus, nisi sem euismod sem, vitae facilisis ex nunc a quam. Pellentesque libero sem, tempus sit amet blandit sed, interdum sed ante. Maecenas vitae rhoncus augue, eu molestie erat.

28+

29+ Nullam bibendum, lacus vel tincidunt tristique, ligula sapien interdum velit, non pretium dolor tortor sollicitudin leo. Aliquam vel lorem ut ligula mattis auctor. Proin ullamcorper molestie augue, eget pulvinar justo placerat eu. Sed euismod vehicula enim. In semper faucibus consectetur. Pellentesque interdum varius varius. Cras laoreet felis vitae eros iaculis sollicitudin. Aenean eu mattis felis. Proin mattis nunc sodales hendrerit fringilla. Aliquam velit mauris, feugiat eu felis a, ullamcorper tempus velit. Fusce non pulvinar quam, commodo imperdiet mi. Nam rhoncus turpis neque, in eleifend purus cursus vel. Quisque lobortis, nulla ut auctor finibus, ex nunc tristique nisl, in tincidunt est massa ut sem.

30+

31+ Vestibulum eu urna elit. Aliquam tempor cursus faucibus. Praesent scelerisque dui eu lorem auctor, eu lacinia nibh porttitor. Ut et eros eget felis tristique volutpat a ac tortor. Praesent quis lorem a mauris ultrices imperdiet quis a odio. In cursus maximus orci sed dignissim. Donec semper, orci id consectetur pulvinar, turpis lorem eleifend quam, eu fringilla libero mauris vel ante. Nunc id tellus elit. Etiam facilisis vitae lorem vel fermentum.

32+

33+ Sed bibendum maximus nulla a egestas. Cras commodo ipsum quis magna viverra, quis tempus eros gravida. Donec et dictum dui. Etiam vel orci quis mi molestie eleifend. Vivamus vel tincidunt augue. Fusce vel tortor sagittis, viverra velit nec, consequat elit. Maecenas sem metus, dignissim non mauris ac, elementum tempor lectus. Suspendisse vel sapien tincidunt elit posuere mattis vel id mauris. Nam vitae imperdiet orci. Sed bibendum justo eu bibendum consequat. Mauris mauris sapien, blandit eget semper nec, pulvinar at lorem.

34+

35+ Pellentesque vitae nunc sed nibh condimentum tempor eget sed est. Quisque bibendum eu odio vitae pharetra. Cras ut condimentum purus. Nullam ipsum dui, efficitur tempus tincidunt et, condimentum a ipsum. Curabitur malesuada nibh id massa imperdiet porttitor. Duis quis lobortis dui. Mauris aliquam lectus arcu, vel euismod ante dignissim quis.

36+

37+ In ut vulputate nisi. Vivamus felis est, vestibulum vitae scelerisque non, blandit sit amet purus. Nullam dictum, turpis sed rutrum lacinia, sapien enim dictum lectus, ut molestie lorem enim id mi. Donec vestibulum dui urna, ut viverra purus mattis sit amet. In maximus metus ipsum. Sed bibendum scelerisque mattis. Nunc sed dolor at metus euismod semper. Cras libero purus, porttitor nec sapien eu, pellentesque malesuada magna. Etiam euismod purus ut leo pharetra, sollicitudin hendrerit nibh dignissim. Nam accumsan lacus in velit commodo, non mollis urna ornare. Vivamus ligula metus, ultrices a iaculis quis, venenatis pellentesque nisl. Proin vestibulum pellentesque tortor vel tempor.

38+

39+ Pellentesque id orci tincidunt, egestas erat eu, fermentum ipsum. Nunc efficitur nulla vitae nunc feugiat porttitor. Fusce risus est, dignissim in fermentum vel, finibus eu sapien. Maecenas mollis lorem nec dolor ornare, vel vestibulum nunc fringilla. Quisque at ante nunc. Nam blandit nisi quis blandit auctor. Cras ac sem lorem. Interdum et malesuada fames ac ante ipsum primis in faucibus. Fusce nulla tellus, porttitor id aliquet iaculis, auctor a quam. Aenean sodales pulvinar vehicula.

40+

41+ Etiam non diam tortor. Ut posuere dolor id placerat posuere. Aliquam erat volutpat. Morbi tempor volutpat venenatis. Sed id iaculis mi, in commodo dui. Aliquam eleifend urna sagittis lorem porta malesuada. Praesent placerat justo sed luctus finibus. Vivamus commodo porttitor metus, vulputate sagittis ipsum finibus non. Vestibulum porttitor varius metus eu fermentum. Morbi eleifend augue sit amet velit aliquam facilisis.

42+

43+ Donec et lorem lectus. Integer ex neque, lobortis vitae posuere eu, tincidunt id enim. Vivamus consectetur elit porttitor mi viverra, in sodales velit finibus. Fusce auctor felis a ipsum mollis, nec ornare metus tempus. Fusce nulla felis, semper vitae lorem non, tincidunt feugiat tellus. Vivamus eu pulvinar elit. Proin leo odio, laoreet eu purus ut, luctus laoreet ante. Ut commodo lacus odio, in scelerisque tortor pharetra in. Aenean rhoncus augue non egestas condimentum. Donec maximus placerat facilisis. Praesent aliquam augue non purus volutpat blandit. Pellentesque id mollis enim.

44+

45+ In ut eros posuere, imperdiet sapien a, dapibus velit. Nam at blandit neque. Nam euismod leo et venenatis mattis. Praesent consectetur, risus consequat condimentum tincidunt, ante nibh aliquam ligula, condimentum egestas augue tortor non risus. Nulla accumsan diam a sapien tempus hendrerit. Fusce fringilla mi quis blandit sodales. Quisque finibus mi vel nisi efficitur imperdiet. Cras luctus dapibus mauris non feugiat. Aliquam eu rutrum ipsum. Aliquam elementum luctus molestie. Maecenas molestie nisi molestie, sollicitudin arcu vel, condimentum diam. Mauris eu quam ac lacus accumsan vestibulum. Etiam et mi imperdiet sem convallis dapibus vel eget nisl. In vel faucibus risus. Curabitur luctus pellentesque eros, ac condimentum tellus placerat nec. Nam gravida consequat tincidunt.

46+

47+ Vestibulum consectetur vitae erat non ultrices. Nullam eu diam dictum ante vehicula tempor sit amet et est. Donec ipsum justo, facilisis lobortis vehicula eleifend, viverra a leo. Donec hendrerit, lorem et congue dictum, ipsum nunc facilisis nunc, non ornare nulla augue eu nibh. Ut condimentum in mauris eget blandit. Donec sed est mi. Nunc gravida sodales vestibulum. In hac habitasse platea dictumst.

48+

49+ Aliquam interdum mauris turpis, a efficitur eros molestie suscipit. Donec elementum ultrices augue, in facilisis sapien vestibulum ac. Sed sit amet dictum augue. Nullam posuere ante sit amet cursus molestie. Praesent odio dolor, molestie ac eleifend vitae, tempor quis ligula. Cras a volutpat sem, a varius sapien. Curabitur finibus nisl quis porttitor luctus. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Pellentesque dignissim lacus a neque ultricies blandit. Donec a imperdiet est. Phasellus a tristique lectus. Mauris in augue in metus euismod fringilla.

50+

51+ Praesent congue tincidunt hendrerit. Vivamus efficitur neque est, vel ultricies lectus tempor et. Fusce sit amet lorem sit amet enim eleifend faucibus. Pellentesque mattis malesuada scelerisque. Aliquam quam elit, commodo a commodo nec, vestibulum eget neque. Suspendisse et nibh vestibulum massa placerat maximus rutrum non felis. Donec non nisi rhoncus ipsum luctus ultrices sit amet vel ligula.

52+

53+ In dictum vitae neque vehicula faucibus. Curabitur elementum nibh turpis, a pellentesque nunc viverra eu. Morbi dapibus justo dolor, nec fringilla turpis condimentum eu. Donec nec nibh eu erat tincidunt semper a ut erat. Duis accumsan mattis convallis. Aenean lacus elit, ultrices vitae nibh sit amet, consectetur vulputate risus. Morbi blandit lacus et condimentum mollis. Maecenas id massa ut massa interdum viverra a nec nisl. Pellentesque ullamcorper fringilla eros et volutpat.

54+

55+ Suspendisse egestas, purus sit amet condimentum tincidunt, nunc nibh pulvinar turpis, vel eleifend lacus elit nec ligula. In viverra et ipsum a faucibus. In dictum turpis nec lectus hendrerit, vitae imperdiet orci tincidunt. Aliquam felis risus, aliquam vel ornare vel, molestie vehicula tortor. Etiam ullamcorper sit amet tellus in mollis. Proin ut rhoncus enim. In sit amet blandit est. Quisque ultricies tortor a felis ultricies, in auctor ex feugiat. Integer tempus auctor nunc id molestie. Praesent eget placerat odio. Maecenas feugiat justo a odio blandit venenatis.

56+

57+ Nunc sit amet justo eu sapien efficitur porta. Pellentesque aliquet elementum odio. Donec est diam, vehicula quis scelerisque eget, gravida non arcu. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; Ut vehicula vestibulum commodo. Integer sed nunc sit amet augue hendrerit aliquam id quis elit. Donec congue risus non mauris condimentum luctus.

58+

59+ Sed dapibus nulla id feugiat eleifend. Vestibulum cursus malesuada nunc quis porta. Curabitur sodales justo augue, ac semper arcu gravida in. Nunc eu ex rutrum, viverra ipsum in, interdum leo. Nunc erat leo, consectetur vitae magna eget, lacinia auctor dolor. Etiam consequat eros sit amet lorem mollis malesuada. Suspendisse sit amet aliquet libero. Cras ut nisl aliquet, pulvinar odio nec, porttitor nisl. Aenean feugiat diam eget sapien rhoncus placerat. Etiam tincidunt blandit dui at venenatis. Nullam viverra tincidunt diam eget lacinia. Fusce hendrerit arcu nisi, euismod tincidunt eros blandit non. Fusce vehicula est a lorem ornare, id ultrices metus tempor. Aenean in sollicitudin felis.

60+

61+ Nunc euismod dolor erat, sit amet maximus quam blandit nec. Sed mollis placerat facilisis. Donec placerat eget lectus non egestas. In hac habitasse platea dictumst. Nullam vitae molestie justo, vitae convallis massa. Pellentesque quis magna sit amet est consequat vestibulum sed vestibulum tellus. Cras pharetra mi efficitur libero rutrum blandit. Vivamus eu orci ut diam pellentesque scelerisque. In dignissim malesuada risus. Phasellus eu scelerisque justo. Morbi nunc mi, tempus eu tempor sit amet, feugiat quis elit.

62+

63+ Nunc iaculis consectetur lectus, non placerat eros. Praesent sed tellus magna. Fusce in dui mattis, auctor turpis ut, condimentum metus. Duis nibh elit, euismod nec tellus quis, pulvinar consectetur nisl. Quisque laoreet, urna ut pharetra vehicula, erat dolor molestie lorem, ornare porta enim lacus ac massa. Donec volutpat dignissim mi. Nam in imperdiet lectus. Morbi quis varius risus. In ut fermentum elit. In hac habitasse platea dictumst. Duis gravida, nisl at consectetur hendrerit, risus diam porta nisi, dignissim gravida libero urna sit amet diam. Nunc orci felis, tincidunt in turpis quis, varius molestie ex. Praesent dapibus ipsum quis velit cursus, a vehicula orci mattis. In bibendum convallis lorem nec maximus. Praesent erat libero, accumsan vitae semper at, ultrices ornare urna. Sed interdum ex vitae lectus tempus, sit amet imperdiet elit blandit.

64+

65+ Nulla rhoncus dolor in ex porttitor, sit amet scelerisque risus sollicitudin. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Sed a orci quis diam vehicula pellentesque at molestie risus. Vivamus sollicitudin urna ex, at porta elit blandit sed. Pellentesque malesuada hendrerit diam porttitor ultricies. Suspendisse lobortis, diam non dapibus pulvinar, dui mi sodales quam, in vulputate nibh urna sit amet felis. Mauris sit amet tempor tortor. Ut viverra varius erat, pretium efficitur enim tempor vel.

66+

67+ Sed et mi at neque ornare aliquet ac id risus. Pellentesque auctor varius hendrerit. Vestibulum rhoncus, magna id dapibus dapibus, eros nisl blandit lacus, id suscipit odio leo eget lorem. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas mauris mi, volutpat id felis sit amet, condimentum venenatis ligula. Vivamus vitae ligula aliquet diam viverra dignissim eget vitae dolor. Fusce gravida tincidunt volutpat. Nulla hendrerit lectus in justo tincidunt, ac scelerisque lorem ultricies. Sed varius iaculis ipsum at maximus.

68+

69+ Nulla facilisi. Curabitur et ullamcorper turpis, vitae venenatis tortor. Fusce elementum in nulla vitae tempus. Nam malesuada, nulla quis molestie fermentum, quam sapien vestibulum neque, nec posuere metus nisl semper turpis. Vestibulum semper euismod pretium. Aenean mattis scelerisque pulvinar. Duis pharetra ex ut sem pretium, ut tempus ipsum bibendum. Ut id ligula eu neque suscipit accumsan et non libero. Nulla non ante ligula. Vivamus a posuere justo. Interdum et malesuada fames ac ante ipsum primis in faucibus. Donec ut sollicitudin lectus, in finibus libero. Morbi tempor turpis at metus porta pulvinar.

70+

71+ Donec sollicitudin posuere turpis, sagittis finibus sapien vestibulum finibus. Suspendisse gravida, quam non faucibus dictum, risus ex vulputate nunc, non viverra ipsum leo ut orci. Pellentesque pellentesque vehicula vulputate. Nullam sagittis quis justo et dignissim. Nulla sodales erat nec malesuada malesuada. Phasellus tincidunt tincidunt tincidunt. Nunc malesuada sem ut lectus elementum, non pulvinar augue porta. Proin ultrices sem ut maximus ultricies.

72+

73+ Sed id luctus massa. Ut elementum erat sed sem euismod viverra. Aenean a libero suscipit, facilisis tellus vitae, egestas lectus. Nunc eget maximus purus, vel varius leo. Suspendisse dui felis, aliquet ut ullamcorper sed, ultrices at purus. Pellentesque luctus odio feugiat hendrerit consectetur. Quisque auctor lobortis sem. Sed arcu odio, fringilla sit amet ipsum et, dapibus maximus risus. Aenean malesuada turpis nec aliquet commodo. Morbi mauris nisi, porttitor et sapien vitae, interdum sollicitudin purus. Aliquam at magna ac quam viverra venenatis sit amet ut velit. Aenean accumsan lorem vel nisi tempor condimentum. Nunc elementum ligula ac placerat viverra. Cras et quam in ligula vestibulum finibus sed nec purus. In a accumsan dui. Donec urna neque, venenatis nec nibh mattis, semper convallis orci.

74+

75+ Maecenas luctus pretium ultrices. Donec rutrum nisi vel augue placerat, vitae laoreet velit vehicula. Suspendisse potenti. Quisque posuere congue metus eu viverra. Etiam lacus ante, ullamcorper vitae consectetur sit amet, elementum sit amet risus. Nulla tempus nisi in arcu eleifend rhoncus. Proin elit risus, ultrices eu dui sit amet, dictum finibus dolor. Nunc faucibus sagittis est, eget tempor dui congue ac. Mauris dictum mollis dolor eget gravida. Duis pharetra sed quam non tempor. Ut elementum nisl vel commodo dictum. Quisque velit urna, eleifend sit amet interdum at, interdum in ante. Duis sed elit mauris. In finibus ipsum nec aliquam venenatis. Sed enim mi, gravida et fringilla vel, viverra ut mi. Maecenas est leo, viverra ut interdum ac, viverra ut est.

76+

77+ Cras faucibus tempor consequat. Donec bibendum magna augue, sed faucibus ex semper vel. Nullam sit amet sem enim. Nunc tincidunt, lectus nec blandit rutrum, mi dui mattis ligula, et interdum massa libero in urna. Curabitur in elit viverra, hendrerit enim quis, finibus turpis. Ut euismod efficitur iaculis. Nunc mauris metus, condimentum ac posuere ac, vehicula eget est. Maecenas tincidunt eget leo vel tempus.

78+

79+ Nam porta nulla et sapien ultricies facilisis. Fusce sed rutrum ligula, scelerisque interdum mauris. Sed feugiat venenatis nibh, vitae interdum purus sodales pharetra. Praesent commodo ultricies laoreet. Donec efficitur porta massa sit amet ullamcorper. Nulla consequat ante nec consequat aliquet. Ut vel rutrum turpis, eu mattis lacus. Donec dapibus fringilla nunc, dictum porttitor risus scelerisque et. Vivamus vitae lorem commodo, laoreet risus a, cursus diam. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.

80+

81+ Vivamus consequat libero venenatis, aliquet felis nec, gravida arcu. Donec iaculis elit massa, in mattis leo lobortis quis. Nunc id tellus egestas, posuere felis nec, dapibus massa. Integer sagittis sem et nulla sagittis, non dapibus odio aliquam. Proin vitae dolor lacus. Maecenas porttitor nisl ut leo eleifend, sed fermentum lorem iaculis. Donec diam lectus, aliquam in commodo et, sodales nec nunc. Vivamus imperdiet ante non porttitor ullamcorper. Donec vestibulum velit ut sapien pharetra porta.

82+

83+ Ut tempus, enim vel aliquet convallis, eros magna interdum nisi, vel fermentum sem lorem eget magna. Nulla eu sapien id augue ornare vestibulum. Curabitur a mollis turpis, eu fringilla quam. Cras congue lorem eget mauris finibus cursus eu sit amet nisi. Sed ante tellus, molestie id velit ut, congue aliquam lacus. Mauris ultrices leo a enim porttitor, ut rutrum mauris feugiat. Vivamus volutpat, quam eget accumsan cursus, diam ante luctus nibh, ut aliquet nisl mauris at enim. Phasellus purus ex, scelerisque vel quam in, facilisis sollicitudin augue.

84+

85+ Morbi faucibus ut nisi eu facilisis. Donec congue sapien eget felis interdum fringilla. Duis eget magna hendrerit, varius velit eu, accumsan augue. Vestibulum massa nibh, pulvinar ac facilisis a, ultrices ac arcu. Suspendisse fermentum et lorem et euismod. Sed auctor purus justo, id malesuada lacus vehicula nec. Phasellus venenatis nulla eu lacus finibus, sed auctor dolor dapibus. Mauris sollicitudin augue mi, sed viverra dolor imperdiet sed. Nulla facilisi. Pellentesque placerat aliquet erat nec pellentesque. Curabitur accumsan ultricies pharetra.

86+

87+ Aliquam eget lobortis velit, a sollicitudin urna. Etiam eget nunc fermentum, pellentesque velit non, commodo nulla. Cras ultrices sapien purus, ut sagittis orci viverra at. Nulla sed auctor neque, quis pulvinar leo. Nulla ut tempus nunc, in condimentum justo. Morbi pretium fermentum quam ac luctus. Duis eu faucibus enim. Duis imperdiet eleifend ante, nec egestas elit posuere vel. Morbi varius porttitor urna quis ullamcorper. In sapien velit, sagittis eu vestibulum sed, faucibus a elit. Praesent eros mi, vestibulum vel est eget, egestas luctus mauris. Morbi fringilla sapien ut purus auctor laoreet.

88+

89+ Mauris dapibus nisl lacus, sit amet malesuada enim molestie non. Pellentesque feugiat tempor nisi vel vehicula. Sed congue ultrices condimentum. Nulla eget urna laoreet, dictum mauris ac, consequat nisi. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Curabitur tempus ante et ex elementum vestibulum. In sit amet nunc quis dui gravida auctor congue non dui. Vestibulum varius vehicula risus sit amet posuere. Morbi a urna volutpat, varius augue sed, sollicitudin diam. In pulvinar felis quis tellus scelerisque, ut dictum turpis placerat. Nunc nunc ligula, cursus a sagittis at, tristique vel ligula. Ut lorem arcu, fringilla vitae molestie nec, dignissim et elit. Praesent commodo, nibh ut semper dapibus, ligula velit maximus lorem, at dapibus ante turpis viverra felis. Etiam mollis mi enim, ac cursus tortor feugiat eu. Phasellus ut augue sit amet nunc vehicula varius.

90+

91+ Ut purus libero, tempor in diam quis, fringilla euismod dolor. Nullam vitae leo magna. Donec elementum eget ex non vestibulum. Praesent vitae consequat urna. Aenean sit amet vehicula lorem. Aliquam malesuada auctor suscipit. Phasellus rhoncus auctor erat. Nam cursus consectetur lacus.

92+

93+ Morbi velit nulla, maximus ac urna ut, finibus tincidunt orci. Sed blandit, nisi sit amet eleifend ultricies, sem justo rhoncus ipsum, eget lobortis enim sem a ante. Vestibulum faucibus sapien magna, nec eleifend eros fermentum sed. Praesent ante lacus, ornare non elementum egestas, porta eget mi. Aenean sit amet luctus erat. Sed dapibus, tortor feugiat viverra luctus, enim sem vestibulum quam, quis elementum nunc velit a nunc. Morbi faucibus pulvinar placerat. Cras vehicula tempor lobortis. Nulla sagittis lorem quis odio eleifend, nec ultricies odio rhoncus. Nunc euismod interdum leo in dignissim. Nullam a metus erat. Phasellus commodo tellus lacus, aliquet faucibus mi accumsan sed. Mauris ultrices sit amet libero in rhoncus. Duis at lectus non est blandit finibus eu id libero.

94+

95+ Donec iaculis ante ut neque dictum, id malesuada orci iaculis. Nunc semper venenatis arcu non consequat. Etiam consectetur arcu ac felis gravida elementum. Suspendisse potenti. Curabitur tortor libero, aliquam nec sem eu, maximus rhoncus augue. Phasellus placerat rhoncus ex, cursus tristique ex efficitur et. Mauris sagittis convallis mollis. Duis tristique vulputate felis, vel accumsan tellus hendrerit vel. Quisque sit amet justo vitae dui pellentesque ullamcorper. Morbi consectetur elit dolor, quis consequat tortor fringilla sit amet.

96+

97+ Praesent molestie ligula non euismod congue. Maecenas semper orci turpis, consectetur varius nisi fringilla a. Donec eget iaculis est, in fermentum augue. Nulla facilisi. In dapibus, nulla non aliquam placerat, tellus nulla commodo neque, eu fermentum augue nulla et magna. Proin auctor nunc fringilla ultricies efficitur. Suspendisse et eros a dolor pharetra semper. Donec sed elit vel odio sollicitudin dapibus vitae at felis. Aliquam sit amet aliquet elit.

98+

99+ Aliquam id quam id felis gravida facilisis quis et velit. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nullam ultricies mauris ut erat sodales dignissim. Vivamus molestie justo et ante congue interdum. Pellentesque id dolor sagittis ex sollicitudin interdum. Donec dictum, quam in tristique volutpat, libero nibh commodo erat, id porttitor diam ante vitae nunc. Donec ut finibus turpis, a luctus lorem.

100+

101+ Donec et elit ut lorem tincidunt maximus id porttitor arcu. Mauris pharetra lacinia dignissim. Aliquam vel rutrum libero. Nam vehicula, nibh et ullamcorper pulvinar, leo nunc dapibus quam, et mattis purus lorem id diam. In ut venenatis felis. Suspendisse et tempor nulla. Sed finibus pretium nisi quis molestie. In hac habitasse platea dictumst. Nunc accumsan egestas dui, nec suscipit turpis efficitur sed. Mauris dapibus nisl nec eros maximus sollicitudin. Curabitur eget tincidunt ligula. Vivamus in maximus odio.

102+

103+ Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Aliquam erat volutpat. Donec et auctor ante. Fusce et ullamcorper risus, nec ullamcorper risus. Vestibulum id iaculis tellus. Quisque a ultricies neque, id viverra quam. Ut est nunc, finibus id leo sed, sodales viverra magna. Proin sit amet purus tellus. Nullam at viverra massa, in gravida justo. In hac habitasse platea dictumst. Mauris orci ligula, porta sit amet est vel, faucibus ullamcorper magna. Nunc eget convallis dui, et faucibus mi. Aliquam erat volutpat. Maecenas mattis mollis mauris in dictum. Suspendisse potenti.

104+ </div>

105+ )

106+}

components/Markdown.jsnew file+47

@@ -0,0 +1,47 @@

1+import remark from "remark";

2+import gfm from "remark-gfm";

3+import slug from "remark-slug";

4+import heading from "remark-heading-id";

5+import html from "remark-html";

6+import remarkprism from "remark-prism";

7+import normalize from "mdurl/encode";

8+

9+// img is wrapped in figure so that images can be extra wide in the blog posts

10+function Img(h, node) {

11+ var props = { src: normalize(node.url), alt: node.alt };

12+ if (node.title !== null && node.title !== undefined) {

13+ props.title = node.title;

14+ }

15+ return {

16+ type: "element",

17+ tagName: "figure",

18+ properties: {},

19+ children: [

20+ {

21+ type: "element",

22+ tagName: "img",

23+ properties: props,

24+ },

25+ ],

26+ };

27+}

28+

29+const options = {

30+ handlers: {

31+ image: Img,

32+ },

33+ entities: "numbers",

34+};

35+

36+// Converts markdown strings into markdown HTML/React components

37+export default async function Markdown({ post }) {

38+ const result = await remark()

39+ .use(html, options)

40+ .use(gfm)

41+ .use(remarkprism)

42+ .use(slug)

43+ .use(heading)

44+ .process(post.content);

45+

46+ return result.toString();

47+}

components/MenuTray.jsnew file+47

@@ -0,0 +1,47 @@

1+import classnames from "classnames";

2+

3+export default function MenuTray(props) {

4+ // Locks document scrolling when menu is open

5+

6+ if (typeof document !== "undefined") {

7+ if (props.isOpen) {

8+ document.body.style.overflow = "hidden";

9+ } else {

10+ document.body.style.overflow = "visible";

11+ }

12+ }

13+

14+ // Slides the tray in or out from the left

15+ const trayClasses = classnames({

16+ "tray-menu-open": props.isOpen,

17+ "tray-menu-closed": !props.isOpen,

18+ });

19+

20+ // Fades the background overlay in or out

21+ const overlayClasses = classnames({

22+ "tray-overlay-open": props.isOpen,

23+ "tray-overlay-closed": !props.isOpen,

24+ });

25+

26+ // Hides or shows the menu

27+ const menuClasses = classnames({

28+ "menu-open": props.isOpen,

29+ "menu-closed": !props.isOpen,

30+ });

31+

32+ return (

33+ <nav className={`z-10 w-screen h-screen top-0 left-0 fixed ${menuClasses}`}>

34+ <div

35+ onClick={() => props.toggleTray(!props.isOpen)}

36+ className={`bg-washedWhite w-screen h-screen ${overlayClasses}`}

37+ />

38+ <div

39+ className={`absolute bg-wall h-screen top-0 left-0 tray-menu-width overflow-y-scroll ${trayClasses}`}

40+ >

41+ <div className="flex flex-col px-4 md:px-8 pt-8 md:pt-10 lg:pt-12 pb-10 md:pb-12 lg:pb-24">

42+ {props.children}

43+ </div>

44+ </div>

45+ </nav>

46+ );

47+}

components/Meta.jsdeleted−54

@@ -1,54 +0,0 @@

1−export default function Meta(post, disableImage, large = false) {

2− const author = post?.extra?.author || "urbit.org";

3− const title = post?.title ? post.title : "";

4− const description =

5− post?.description || "Urbit is a new kind of computer that you can own completely in ways that matter: networking, identity, & data.";

6− const image =

7− post?.extra?.image ||

8− post?.image ||

9− "https://storage.googleapis.com/media.urbit.org/site/opengraph/sig-white.png";

10− return (

11− <>

12− <link rel="icon" type="image/png" href="/images/favicon.ico" />

13− <link

14− rel="apple-touch-icon"

15− sizes="180x180"

16− href="/images/apple-touch-icon.png"

17− />

18− <link

19− rel="icon"

20− type="image/png"

21− sizes="32x32"

22− href="/images/favicon-32x32.png"

23− />

24− <link

25− rel="icon"

26− type="image/png"

27− sizes="16x16"

28− href="/images/favicon-16x16.png"

29− />

30− <link rel="manifest" href="/images/site.webmanifest" />

31−

32− <meta

33− name="twitter:card"

34− content={large ? "summary_large_image" : "summary"}

35− key="twitter-card"

36− />

37− <meta name="twitter:site" content="@urbit" key="twitter-site" />

38− <meta name="twitter:creator" content="@urbit" key="twitter-creator" />

39− <meta name="og:title" content={title} key="title" />

40− <meta name="og:description" content={description} key="description" />

41− <meta name="description" content={description} />

42− <meta name="author" content={author} key="author" />

43− {!disableImage && (

44− <meta name="twitter:image" content={image} key="image" />

45− )}

46− <link

47− rel="alternative"

48− type="application/rss+xml"

49− title="RSS"

50− href="/rss.xml"

51− />

52− </>

53− );

54−}

components/NewsletterSignup.js → components/NewletterSignup.jsrenamed+3−3

@@ -12,8 +12,8 @@ export default function NewsletterSignup(props) {

12 <div className="input-group" id="mc_embed_signup_scroll">

12 <div className="input-group" id="mc_embed_signup_scroll">

13 <div className="mc-field-group w-full relative">

13 <div className="mc-field-group w-full relative">

14 <input

14 <input

15− className={`appearance-none outline-none text-wall-500 type-ui bg-white black ${

15+ className={`appearance-none outline-none text-gray type-ui black border-${

16− props.color || "border-wall-600"

16+ props.color || "green"

17 } border-4 px-3 w-full mb-2 h-16 rounded-xl`}

17 } border-4 px-3 w-full mb-2 h-16 rounded-xl`}

18 type="email"

18 type="email"

19 name="EMAIL"

19 name="EMAIL"

@@ -23,7 +23,7 @@ export default function NewsletterSignup(props) {

23 <div className="flex h-16 items-center justify-center absolute top-0 right-6">

23 <div className="flex h-16 items-center justify-center absolute top-0 right-6">

24 <button

24 <button

25 id="mc-embedded-subscribe"

25 id="mc-embedded-subscribe"

26− className="type-ui dark:text-green-400 text-wall-500 bg-transparent"

26+ className="type-ui text-gray bg-transparent"

27 type="submit"

27 type="submit"

28 name="subscribe"

28 name="subscribe"

29 >

29 >

components/Pagination.jsdeleted−22

@@ -1,22 +0,0 @@

1−import Link from "next/link";

2−export default function Pagination(props) {

3− return (

4− <Link

5− href={`/${props.section}/${props.post.slug}`}

6− key={`post-${props.post.slug}`}

7− >

8− <div

9− className="bg-wall-100 cursor-pointer font-semibold p-2 px-4 rounded-xl flex"

10− style={{ maxWidth: "45%" }}

11− >

12− <p className="shrink-0 pr-1">{props.previous ? "<- " : ""}</p>

13− <p className="text-wall-600 truncate">{props.post.title}</p>

14− <p className="shrink-0 pl-1">{props.next ? " ->" : ""}</p>

15− </div>

16− </Link>

17− );

18−}

19−

20−Pagination.defaultProps = {

21− className: "",

22−};

components/PostPreview.js+17−18

@@ -1,24 +1,23 @@

1−import {

1+import Link from "next/link";

2− Card,

2+import BackgroundImage from "./BackgroundImage";

3− formatDate,

3+import { formatDate } from "../lib/lib";

4− generateDisplayDate,

5−} from "@urbit/foundation-design-system";

6

4

7export default function PostPreview(props) {

5export default function PostPreview(props) {

8− const section = props?.section ? props.section : "blog";

9−

10− const date = generateDisplayDate(props.post.date);

11 return (

6 return (

12− <Card

7+ <div className={`cursor-pointer ${props.className}`}>

13− slug={`/${section}/${props.post.slug}`}

14− image={props.post.extra.image}

15− title={props?.title || props.post?.title || ""}

8+ {props.title ? <h3 className="mb-2">{props.title}</h3> : null}

16− author={props.post?.extra?.author || ""}

9+

10+ <Link href={`/blog/${props.post.slug}`} key={`post-${props.post.slug}`}>

11+ <div>

12+ <BackgroundImage

13+ className="w-full h-96 rounded-lg"

17− ship={props.post?.extra?.ship || ""}

14+ src={props.post.extra.image || ""}

18− content={

15+ />

19− <div className="text-wall-500 type-sub mt-1">{formatDate(date)}</div>

16+ <p className="text-black mt-2">{props.post.title}</p>

20− }

17+ <p className="text-gray">{formatDate(new Date(props.post.date))}</p>

21− />

18+ </div>

19+ </Link>

20+ </div>

22 );

21 );

23}

22}

24

23

components/Search.jsnew file+190

@@ -0,0 +1,190 @@

1+import { useCallback, useRef, useState, useEffect } from "react";

2+import { glossary } from "../lib/glossary";

3+import Link from "next/link";

4+import { useRouter } from "next/router";

5+

6+const glossarySearch = (query) => {

7+ return glossary.filter((entry) => {

8+ return query.toLowerCase() === entry.name || entry.symbol === query;

9+ });

10+};

11+

12+export default function Search(props) {

13+ const searchRef = useRef(null);

14+ const [query, setQuery] = useState("");

15+ const [active, setActive] = useState(false);

16+ const [results, setResults] = useState([]);

17+ const searchEndpoint = (query) => `/api/search?q=${query}`;

18+

19+ const router = useRouter();

20+

21+ useEffect(() => {

22+ router.events.on("routeChangeComplete", handleRouteChange);

23+ return () => {

24+ router.events.off("routeChangeComplete", handleRouteChange);

25+ };

26+ }, [router.events]);

27+

28+ const handleRouteChange = () => {

29+ setQuery("");

30+ setResults([]);

31+ setActive(false);

32+ props.closeSearch();

33+ };

34+

35+ const onChange = useCallback((event) => {

36+ const query = event.target.value;

37+

38+ setQuery(query);

39+ if (query.length) {

40+ fetch(searchEndpoint(query))

41+ .then((res) => res.json())

42+ .then((res) => {

43+ setResults(res.results);

44+ });

45+ } else {

46+ setResults([]);

47+ }

48+ }, []);

49+

50+ const onFocus = useCallback(() => {

51+ setActive(true);

52+ window.addEventListener("click", onClick);

53+ }, []);

54+

55+ const onClick = useCallback((event) => {

56+ if (searchRef.current && !searchRef.current.contains(event.target)) {

57+ setActive(false);

58+ window.removeEventListener("click", onClick);

59+ props.toggleSearch();

60+ }

61+ }, []);

62+

63+ let glossaryResults = [];

64+ if (query.length) {

65+ glossaryResults = glossarySearch(query);

66+ }

67+

68+ const clear = useCallback((e) => {

69+ e.stopPropagation();

70+ setQuery("");

71+ }, []);

72+

73+ // Locks document scrolling when search is open

74+ if (typeof document !== "undefined") {

75+ if (props.showSearch) {

76+ document.body.style.overflow = "hidden";

77+ } else {

78+ document.body.style.overflow = "visible";

79+ }

80+ }

81+

82+ if (props.showSearch) {

83+ return (

84+ <div

85+ onClick={props.closeSearch}

86+ className="fixed w-screen h-screen bg-washedWall z-50 flex flex-col items-center p-4"

87+ >

88+ <div

89+ className="relative flex flex-col max-w-screen-lg md:my-32 w-full md:w-10/12 lg:w-8/12 xl:w-6/12 rounded-xl bg-white min-h-0"

90+ ref={searchRef}

91+ >

92+ <div className="relative">

93+ <input

94+ className="text-lg md:text-xl lg:text-2xl font-medium text-green bg-transparent py-2 px-4 outline-none relative w-full"

95+ onChange={onChange}

96+ onFocus={onFocus}

97+ placeholder="Search..."

98+ type="text"

99+ value={query}

100+ onClick={(e) => e.stopPropagation()}

101+ autoFocus={true}

102+ />

103+

104+ <span

105+ onClick={props.toggleSearch}

106+ className="absolute cursor-pointer right-1.5 top-1.5 md:right-2 md:top-2 lg:right-2.5 lg:top-2.5"

107+ >

108+ <p className="px-2 h-8 bg-wall flex items-center justify-center text-sm rounded">

109+ ESC

110+ </p>

111+ </span>

112+ </div>

113+

114+ <div

115+ className={"overflow-y-scroll" + (query.length > 0 ? "" : "hidden")}

116+ >

117+ <div>

118+ {active &&

119+ results.length === 0 &&

120+ glossaryResults.length === 0 &&

121+ query !== "" ? (

122+ <div className="flex font-semibold text-sm p-3 py-8 w-full">

123+ <p className="mr-2 text-gray">No Results found for</p>

124+ <p className="font-semibold">"{query}"</p>

125+ </div>

126+ ) : null}

127+ {active && glossaryResults.length > 0 ? (

128+ <>

129+ <div className="sticky top-0 flex font-semibold text-sm p-3 py-1 w-full bg-ultraDeepWall text-white">

130+ <p className="font-semibold text-sm">Glossary</p>

131+ </div>

132+

133+ {glossaryResults.map(({ name, link, desc, symbol }) => {

134+ return (

135+ <Link href={link} as={link} key={link}>

136+ <div className="cursor-pointer hover:bg-wall">

137+ <div className="font-semibold p-3">

138+ {symbol.length > 0 && (

139+ <code className="mr-1 bg-wall rounded px-1 py-0.5">

140+ {symbol}

141+ </code>

142+ )}

143+ {name}

144+ <p className="font-normal text-base mt-1">{desc}</p>

145+ </div>

146+ </div>

147+ </Link>

148+ );

149+ })}

150+ </>

151+ ) : null}

152+ {active && results.length > 0 && (

153+ <>

154+ <div className="sticky top-0 flex font-semibold text-sm p-3 py-1 w-full bg-ultraDeepWall text-white">

155+ <p className="font-semibold text-sm">

156+ {results.length} results for "{query}"

157+ </p>

158+ </div>

159+

160+ {results

161+ .filter((e) => e.parent !== "Glossary")

162+ .map(({ title, slug, content, parent }) => {

163+ return (

164+ <div

165+ key={slug}

166+ className="cursor-pointer hover:bg-wall p-3"

167+ >

168+ <Link href={slug} as={slug}>

169+ <div>

170+ <p className="font-medium text-base">

171+ {parent} / {title}

172+ </p>

173+ <p className="text-base font-regular text-small text-gray">

174+ {content}

175+ </p>

176+ </div>

177+ </Link>

178+ </div>

179+ );

180+ })}

181+ </>

182+ )}

183+ </div>

184+ </div>

185+ </div>

186+ </div>

187+ );

188+ }

189+ return null;

190+}

components/Section.jsnew file+21

@@ -0,0 +1,21 @@

1+import classnames from "classnames";

2+

3+// Provides a flexible layout building block

4+export default function Section({

5+ children,

6+ className = "",

7+ short = false,

8+ narrow = false,

9+}) {

10+ const spacing = classnames({

11+ "py-6 md:py-8 lg:py-10": short,

12+ "py-10 md:py-12 lg:py-24": !short,

13+ "md:w-8/12": narrow,

14+ "md:w-10/12": !narrow,

15+ });

16+ return (

17+ <section className={`w-full px-4 md:px-8 ${spacing} ${className}`}>

18+ {children}

19+ </section>

20+ );

21+}

components/Sidebar.js+64−8

@@ -1,21 +1,77 @@

1+import Link from "next/link";

1import { useState } from "react";

2import { useState } from "react";

2−import { MenuTray } from '@urbit/foundation-design-system';

3+import MenuTray from "./MenuTray";

3

4

4export default function Sidebar(props) {

5export default function Sidebar(props) {

5− const [isOpen, setTray] = useState(false);

6+ const [isOpen, toggleTray] = useState(false);

6 return (

7 return (

7 <>

8 <>

8− <div className="hidden md:flex flex-col h-full sticky top-8">

9+ <div className="hidden md:flex flex-col w-96 bg-wall max-h-screen h-screen">

10+ <header className="flex flex-shrink-0 justify-between items-center pl-6 pt-12 pb-8">

11+ <Link href="/">

12+ <a className="type-ui text-gray">Urbit</a>

13+ </Link>

14+ </header>

9− <div className="overflow-y-auto">

15+ <div className="overflow-y-scroll p-6 pt-16">

10 {props.children}

16 {props.children}

11 <div className="pb-32" />

17 <div className="pb-32" />

12 </div>

18 </div>

13 </div>

19 </div>

14

20

21+ <div className="block md:hidden">

15− <MenuTray isOpen={isOpen} setTray={setTray} search={props.search}>

22+ <MenuTray isOpen={isOpen} toggleTray={toggleTray}>

23+ <header className="flex flex-shrink-0 justify-between items-center pb-8">

24+ <Link href="/">

25+ <a className="type-ui text-gray">Urbit</a>

26+ </Link>

27+ </header>

16− {props.children}

28+ {props.children}

17− <div className="pt-64" />

29+ </MenuTray>

18− </MenuTray>

30+ <button

31+ onClick={(e) => {

32+ e.stopPropagation();

33+ props.search.toggleSearch(e);

34+ }}

35+ className={`z-10 fixed px-4 items-center justify-center type-ui rounded-xl h-16 bg-white text-gray left-4 right-4 bottom-4 mobile-search-button-width ${

36+ isOpen ? "flex" : "hidden"

37+ }`}

38+ >

39+ Search

40+ </button>

41+ <button

42+ onClick={() => toggleTray(!isOpen)}

43+ className="z-10 fixed bottom-4 right-4 w-16 h-16 bg-ultraDeepWall flex items-center justify-center rounded-full"

44+ >

45+ {isOpen ? (

46+ <svg

47+ width="16"

48+ height="16"

49+ viewBox="0 0 16 16"

50+ fill="none"

51+ xmlns="http://www.w3.org/2000/svg"

52+ >

53+ <path

54+ fill-rule="evenodd"

55+ clip-rule="evenodd"

56+ d="M0.39382 13.7045C-0.131273 14.2296 -0.131274 15.081 0.39382 15.6061C0.918913 16.1312 1.77026 16.1312 2.29535 15.6061L7.99999 9.90142L13.7047 15.6061C14.2297 16.1312 15.0811 16.1312 15.6062 15.6061C16.1313 15.081 16.1313 14.2296 15.6062 13.7046L9.90152 7.99989L15.6061 2.29535C16.1312 1.77026 16.1312 0.918913 15.6061 0.39382C15.081 -0.131273 14.2296 -0.131273 13.7045 0.39382L7.99999 6.09836L2.29548 0.393844C1.77038 -0.131249 0.919038 -0.13125 0.393945 0.393844C-0.131148 0.918937 -0.131148 1.77028 0.393945 2.29537L6.09846 7.99989L0.39382 13.7045Z"

57+ fill="white"

58+ />

59+ </svg>

60+ ) : (

61+ <svg

62+ width="16"

63+ height="16"

64+ viewBox="0 0 16 17"

65+ fill="none"

66+ xmlns="http://www.w3.org/2000/svg"

67+ >

68+ <rect width="16" height="3" rx="1.5" fill="white" />

69+ <rect y="7" width="16" height="3" rx="1.5" fill="white" />

70+ <rect y="14" width="16" height="3" rx="1.5" fill="white" />

71+ </svg>

72+ )}

73+ </button>

74+ </div>

19 </>

75 </>

20 );

76 );

21}

77}

components/SingleColumn.jsnew file+8

@@ -0,0 +1,8 @@

1+// Provides a limited-width column with all children center-aligned along the vertical axis

2+export default function SingleColumn({ children }) {

3+ return (

4+ <div className="flex flex-col w-full items-center max-w-screen-2xl">

5+ {children}

6+ </div>

7+ );

8+}

components/Snippets.jsdeleted−111

@@ -1,111 +0,0 @@

1−import Link from "next/link";

2−import {

3− formatDate,

4− formatTime,

5− formatTimeZone,

6−} from "@urbit/foundation-design-system";

7−

8−export function Name({ children, className }) {

9− return <b className={`font-normal ${className || ""}`}>{children}</b>;

10−}

11−

12−export function Patp({ children, className }) {

13− return (

14− <Link href={`/ids/${children}`} passHref>

15− <a>

16− <code className={`font-mono ${className || ""}`}>{children}</code>

17− </a>

18− </Link>

19− );

20−}

21−

22−// Used to render a human name alongside their @p

23−export function Person({

24− name,

25− patp,

26− nameClassNames,

27− patpClassNames,

28− className,

29−}) {

30− return (

31− <>

32− {patp && name ? (

33− <>

34− <Name className={nameClassNames}>{name}</Name>{" "}

35− <Patp className={patpClassNames + " opacity-60"}>{patp}</Patp>

36− </>

37− ) : patp ? (

38− <Patp className={patpClassNames}>{patp}</Patp>

39− ) : name ? (

40− <Name className={nameClassNames}>{name}</Name>

41− ) : null}

42− </>

43− );

44−}

45−

46−// This goes inside a <p/> tag

47−export function ReadableList({ children, serial = ",", conjunction = "and" }) {

48− return (

49− <>

50− {children.map((Child, index) => {

51− if (index < children.length - 2) {

52− return (

53− <>

54− {Child}

55− {serial}

56− </>

57− );

58− } else if (index < children.length - 1) {

59− return (

60− <>

61− {Child} {conjunction}{" "}

62− </>

63− );

64− }

65− return <>{Child}</>;

66− })}

67− </>

68− );

69−}

70−

71−export function ShowOrHide({ children, condition }) {

72− if (condition) {

73− return children;

74− }

75− return null;

76−}

77−

78−export function DateRange({ starts, ends, className, short }) {

79− // For events which have no end datetime

80− if (!ends.isValid) {

81− return (

82− <div>

83− <p className={className}>

84− {`${formatDate(starts)} • ${formatTime(starts)} ${formatTimeZone(

85− starts

86− )}`}

87− </p>

88− </div>

89− );

90− }

91− // For events which start and end on the same day

92− if (starts.hasSame(ends, "day")) {

93− return (

94− <div>

95− <p className={className}>

96− {`${formatDate(starts)} • ${formatTime(starts)} to ${formatTime(

97− ends

98− )} ${formatTimeZone(starts)}`}

99− </p>

100− </div>

101− );

102− }

103− // For multi-day events

104− return (

105− <div>

106− <p className={className}>{`${starts.toFormat(

107− "cccc, LLLL d"

108− )} to ${formatDate(ends)}`}</p>

109− </div>

110− );

111−}

components/ecosystem/Badge.jsdeleted−20

@@ -1,20 +0,0 @@

1−import classnames from "classnames";

2−export default function EcosystemBadge({ type }) {

3− return (

4− <div

5− className={classnames(

6− "uppercase font-bold text-white text-xs w-fit rounded-lg mb-2 px-2 py-1",

7− {

8− "bg-[#B37ED7]": type === "Organization",

9− "bg-[#83b2d4]": type === "Application",

10− "bg-wall-600": type === "Podcast",

11− "bg-[#8dd5b1]": type === "Marketplace",

12− "bg-[#B5966D]": type === "Article",

13− "bg-[#219DFF]": type === "Group",

14− }

15− )}

16− >

17− {type}

18− </div>

19− );

20−}

components/ecosystem/BasicPage.jsdeleted−146

@@ -1,146 +0,0 @@

1−import { useRouter } from "next/router";

2−import Head from "next/head";

3−import Link from "next/link";

4−import Meta from "../Meta";

5−import ErrorPage from "../../pages/404";

6−import classnames from "classnames";

7−import {

8− Container,

9− SingleColumn,

10− Section,

11− Markdown,

12− IntraNav,

13−} from "@urbit/foundation-design-system";

14−import Header from "../Header";

15−import Footer from "../Footer";

16−import MetadataBlock from "./MetadataBlock";

17−

18−export default function BasicPage({

19− section,

20− post,

21− markdown,

22− search,

23− children,

24−}) {

25− const router = useRouter();

26− if (!router.isFallback && !post?.slug) {

27− return <ErrorPage />;

28− }

29− const metaPost = Object.assign({}, post);

30− metaPost.title = `${post.title} - ${section}`;

31− metaPost.description =

32− section === "Podcast" ? `${post.podcast} - ${post.date}` : post.description;

33− section === "Article" ? `${post.publication} - ${post.date}` : post.description;

34− return (

35− <Container>

36− <Head>

37− <title>

38− {post.title} • {section}

39− </title>

40− {Meta(metaPost)}

41− </Head>

42− <IntraNav ourSite="https://urbit.org" search={search} />

43− <SingleColumn>

44− <Header search={search} />

45− <Section narrow className="space-y-12">

46− <div className="flex items-center space-x-4">

47− <img src={post.image} className="w-36" />

48− <div className="flex flex-col pl-2">

49− <h1 className="text-3xl">

50− {post.title}

51− </h1>

52− <p>{section}</p>

53− </div>

54− </div>

55− {/* General purpose metadata bar -- podcast listen button is special-cased URL, flexed at the end of the row */}

56− <div className="flex justify-between">

57− <div className="flex space-x-12">

58− {post?.podcast && (

59− <MetadataBlock

60− title="Podcast"

61− content={post.podcast}

62− />

63− )}

64− {post?.publication && (

65− <MetadataBlock

66− title="Publication"

67− content={post.publication}

68− />

69− )}

70− {post?.author && (

71− <MetadataBlock

72− title="Author"

73− content={post.author}

74− />

75− )}

76− {post?.date && (

77− <MetadataBlock

78− title="Date"

79− content={post.date}

80− />

81− )}

82−

83− {post?.twitter && (

84− <div className="flex flex-col">

85− <p className="font-bold text-wall-400">Twitter</p>

86− <Link href={"http://twitter.com/" + post.twitter}>

87− <a className="text-green-400 text-sm font-semibold font-mono">@{post.twitter}</a>

88− </Link>

89− </div>

90− )}

91−

92−

93− {post?.URL && section !== "Podcast" && section !== "Article" && (

94− <div className="flex flex-col">

95− <p className="font-bold text-wall-400">Website</p>

96− <a

97− className="text-green-400 text-sm font-semibold font-mono"

98− href={post.URL}

99− >

100− {post.URL.slice(post.URL.indexOf("://") + 3)}

101− </a>

102− </div>

103− )}

104−

105− {post?.URL && section === "Urbit Marketplace" && (

106− <div className="flex flex-col">

107− <p className="font-bold text-wall-400">Accepts</p>

108− <p className="text-sm font-semibold font-mono">

109− {post.payment.join(", ")}

110− </p>

111− </div>

112− )}

113− </div>

114−

115−

116−

117− {post?.URL && section === "Podcast" && (

118− <a

119− href={post.URL}

120− className="button-lg bg-green-400 text-white cursor-pointer flex space-x-2"

121− >

122− <img src="/images/sound.svg" />

123− &nbsp;Listen

124− </a>

125− )}

126− {post?.URL && section === "Article" && (

127− <a

128− href={post.URL}

129− className="button-lg bg-green-400 text-white cursor-pointer flex space-x-2"

130− >

131− Read

132− </a>

133− )}

134− </div>

135− <div className="flex">

136− <div className="markdown w-full">

137− <Markdown.render content={JSON.parse(markdown)} />

138− {children}

139− </div>

140− </div>

141− </Section>

142− </SingleColumn>

143− <Footer />

144− </Container>

145− );

146−}

components/ecosystem/EcosystemSidebar.jsdeleted−86

@@ -1,86 +0,0 @@

1−import { useRouter } from "next/router";

2−import Link from "next/link";

3−import classnames from "classnames";

4−function ActiveLink({ children, href, className, currentPath }) {

5− // special casing this behaviour which overloads one nav

6− const archive = Boolean(

7− currentPath === "/ecosystem?type=archive" && href === "/ecosystem"

8− );

9− const activeClassName = classnames({

10− "text-wall-800": currentPath === href || archive,

11− "text-wall-400": currentPath !== href && !archive,

12− });

13−

14− return (

15− <Link href={href} passHref>

16− <a className={`${className} ${activeClassName}`}>{children}</a>

17− </Link>

18− );

19−}

20−

21−export default function EcosystemSidebar() {

22− const router = useRouter();

23− let currentPath = router.asPath;

24− return (

25− <div className="flex flex-col space-y-4 pr-24">

26− <ActiveLink

27− currentPath={currentPath}

28− className="type-ui"

29− href="/ecosystem"

30− >

31− Spotlight

32− </ActiveLink>

33− <ActiveLink

34− currentPath={currentPath}

35− className="type-ui"

36− href="/ecosystem?type=communities"

37− >

38− Communities

39− </ActiveLink>

40− <ActiveLink

41− currentPath={currentPath}

42− className="type-ui"

43− href="/ecosystem?type=organizations"

44− >

45− Organizations

46− </ActiveLink>

47−

48− <ActiveLink

49− currentPath={currentPath}

50− className="type-ui"

51− href="/ecosystem?type=applications"

52− >

53− Applications

54− </ActiveLink>

55− <ActiveLink

56− currentPath={currentPath}

57− className="type-ui"

58− href="/ecosystem?type=groups"

59− >

60− Groups

61− </ActiveLink>

62− <ActiveLink

63− currentPath={currentPath}

64− className="type-ui"

65− href="/ecosystem?type=marketplaces"

66− >

67− Marketplaces

68− </ActiveLink>

69− <ActiveLink

70− currentPath={currentPath}

71− className="mr-5 type-ui"

72− href="/ecosystem?type=podcasts"

73− >

74− Podcasts

75− </ActiveLink>

76−

77− <ActiveLink

78− currentPath={currentPath}

79− className="mr-5 type-ui"

80− href="/ecosystem?type=articles"

81− >

82− Articles

83− </ActiveLink>

84− </div>

85− );

86−}

components/ecosystem/IndexCard.jsdeleted−34

@@ -1,34 +0,0 @@

1−import Link from "next/link";

2−import EcosystemBadge from "./Badge";

3−export default function IndexCard({ slug, feat }) {

4− return (

5− <Link href={slug}>

6− <div className="cursor-pointer bg-wall-100 rounded-xl min-h-0 flex-1">

7− <div className="flex flex-col p-4 h-full relative">

8− {feat.image ? (

9− <div

10− className="w-64 md:w-full rounded-xl object-cover overflow-hidden basis-1/2"

11− style={{

12− backgroundColor: feat?.matchedPost?.bgColor || "rgba(0,0,0,0)",

13− }}

14− >

15− <img className="h-full w-64 md:w-full object-cover" src={feat.image} />

16− </div>

17− ) : (

18− <div

19− className="rounded-xl w-full"

20− style={{

21− backgroundColor: feat?.matchedPost?.bgColor || "rgba(0,0,0,0)",

22− }}

23− />

24− )}

25− <div className="pt-4">

26− <p className="mb-2 font-semibold leading-5">{feat.title}</p>

27− <EcosystemBadge type={feat.type} />

28− <p className="text-sm leading-5">{feat?.description}</p>

29− </div>

30− </div>

31− </div>

32− </Link>

33− );

34−}

components/ecosystem/MetadataBlock.jsdeleted−7

@@ -1,7 +0,0 @@

1−export default function MetadataBlock({ title, content }) {

2− return <div className="flex flex-col py-2 basis-1/2">

3− <p className="font-bold text-wall-400">{title}</p>

4− <p>{content}</p>

5− </div>

6−

7−}

components/ecosystem/Post.jsdeleted−107

@@ -1,107 +0,0 @@

1−import { Markdown } from "@urbit/foundation-design-system";

2−import EcosystemBadge from "./Badge";

3−

4−import Link from "next/link";

5−export default function Post({ post }) {

6− return ["featured-1", "featured-2", "featured-3"].map((feat) => {

7− const childPath =

8− post[feat] && (post[feat]?.matchedPost?.type === "Application" || post[feat]?.matchedPost?.type === "Group")

9− ? `${post[feat]?.matchedPost.ship}/${post[feat].matchedPost.slug}`

10− : `${post[feat].matchedPost?.slug}`;

11− const href = post[feat]?.matchedPost

12− ? `/${post[feat].matchedPost.type.toLowerCase()}s/${childPath}`

13− : null;

14− return post?.[feat] ? (

15− <div

16− className="mt-8 mb-24"

17− id={post?.[feat].title.toLowerCase().replace(/ /, "-")}

18− >

19− <div className="flex space-x-4 items-center">

20− <div

21− className="h-24 w-24 rounded-xl items-center justify-center shrink-0 overflow-hidden"

22− style={{

23− backgroundColor:

24− post[feat]?.matchedPost?.bgColor || "rgba(0,0,0,0)",

25− }}

26− >

27− {(post[feat]?.matchedPost?.image || post[feat]?.matchedPost?.tile) && (

28− <img

29− className="rounded-xl w-24 object-cover"

30− src={post[feat]?.matchedPost?.image || post[feat]?.matchedPost?.tile}

31− />

32− )}

33− </div>

34− <div className="flex flex-col">

35− <h4 className="text-xl pb-2 leading-6 font-bold">

36− {post?.[feat].title}

37− </h4>

38− <EcosystemBadge type={post[feat].type} />

39− </div>

40− </div>

41− <div className="markdown mt-8 mb-8">

42− <Markdown.render content={JSON.parse(post[feat].content)} />

43− </div>

44−

45− {post[feat].type === "Podcast" && (

46− <Link href={href || "#"} passHref>

47− <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">

48− Listen to {post[feat].type}

49− </a>

50− </Link>

51− )}

52−

53− {post[feat].type === "Article" && (

54− <Link href={href || "#"} passHref>

55− <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">

56− Read {post[feat].type}

57− </a>

58− </Link>

59− )}

60−

61− {post[feat].type === "Application" && (

62− <Link href={href || "#"} passHref>

63− <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">

64− View {post[feat].type}

65− </a>

66− </Link>

67− )}

68−

69− {post[feat].type === "Organization" && (

70− <Link href={href || "#"} passHref>

71− <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">

72− More about {post[feat].title}

73− </a>

74− </Link>

75− )}

76−

77− {post[feat].type === "Community" && (

78− <Link href={href || "#"} passHref>

79− <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">

80− More about {post[feat].title}

81− </a>

82− </Link>

83− )}

84−

85−

86− {post[feat].type === "Marketplace" && (

87− <Link href={href || "#"} passHref>

88− <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">

89− More about {post[feat].title}

90− </a>

91− </Link>

92− )}

93−

94− {post[feat].type === "Group" && (

95− <Link href={href || "#"} passHref>

96− <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">

97− More about {post[feat].title}

98− </a>

99− </Link>

100− )}

101−

102− </div>

103− ) : null;

104− });

105−}

106−

107−

components/ecosystem/SpotlightArchive.jsdeleted−66

@@ -1,66 +0,0 @@

1−import { Container, IntraNav, SingleColumn, Section } from "@urbit/foundation-design-system";

2−import Header from "../Header";

3−import Footer from "../Footer";

4−import Meta from "../Meta";

5−import Head from "next/head";

6−import Link from "next/link";

7−import EcosystemSidebar from "./EcosystemSidebar";

8−import Sidebar from "../Sidebar";

9−

10−export default function SpotlightArchive({ posts, search }) {

11− const post = {

12− title: "Spotlight Archive",

13− description: "The archive of ecosystem spotlights.",

14− };

15− return (

16− <Container>

17− <Head>

18− <title>Archive • Spotlight • Urbit</title>

19− {Meta(post)}

20− </Head>

21− <IntraNav ourSite="https://urbit.org" search={search} />

22− <SingleColumn>

23− <Header search={search} />

24− <Section>

25− <div className="measure">

26− <h1>Ecosystem</h1>

27− </div>

28− </Section>

29− <Section className="flex">

30− <Sidebar>

31− <EcosystemSidebar />

32− </Sidebar>

33− <div>

34− <h3 className="mb-12">Spotlight Archive</h3>

35− {posts.map((post) => {

36− return (

37− <div key={post.slug} className="mb-24 cursor-pointer">

38− <Link href={`/ecosystem/spotlight/${post.slug}`}>

39− <div>

40− <h3 className="text-green-400">{post.title}</h3>

41− <div className="type-ui mt-2">

42− {["featured-1", "featured-2", "featured-3"].map(

43− (feat, i) => {

44− if (post?.[feat]) {

45− return (

46− <>

47− {i ? ", " : ""}

48− <span>{post[feat].title}</span>

49− </>

50− );

51− }

52− }

53− )}

54− </div>

55− </div>

56− </Link>

57− </div>

58− );

59− })}

60− </div>

61− </Section>

62− </SingleColumn>

63− <Footer />

64− </Container>

65− );

66−}

components/gateway/Description.jsdeleted−19

@@ -1,19 +0,0 @@

1−import { Markdown } from "@urbit/foundation-design-system";

2−

3−const Description = ({ description, fallback, markdown }) => {

4− return (

5− (description !== fallback || markdown) && (

6− <div className="flex flex-col space-y-4">

7− {markdown ? (

8− <div className="markdown">

9− <Markdown.render content={JSON.parse(markdown)} />

10− </div>

11− ) : (

12− <p>{description}</p>

13− )}

14− </div>

15− )

16− );

17−};

18−

19−export default Description;

components/gateway/Gateway404.jsdeleted−29

@@ -1,29 +0,0 @@

1−import GatewayHeader from "./GatewayHeader";

2−import {

3− Container,

4− SingleColumn,

5− Section,

6−} from "@urbit/foundation-design-system";

7−import Link from "next/link";

8−

9−const Gateway404 = ({ type }) => {

10− return (

11− <Container>

12− <SingleColumn>

13− <Section narrow className="space-y-12">

14− <GatewayHeader

15− title="Error 404"

16− error

17− item={`No ${type} at this address`}

18− />

19− <hr className="text-wall-200" />

20− <Link href="/" passHref>

21− <a className="text-xl block font-semibold">Urbit.org</a>

22− </Link>

23− </Section>

24− </SingleColumn>

25− </Container>

26− );

27−};

28−

29−export default Gateway404;

components/gateway/GatewayHeader.jsdeleted−29

@@ -1,29 +0,0 @@

1−import GatewayImage from "./Image";

2−

3−const GatewayHeader = ({

4− image,

5− patp,

6− color,

7− subtitle,

8− subtitleMono,

9− error,

10− title,

11− item,

12−}) => {

13− return (

14− <div className="flex items-center space-x-4">

15− <GatewayImage patp={patp} color={color} image={image} error={error} />

16− <div className="flex flex-col">

17− <h2>{title}</h2>

18− {subtitle && (

19− <p className={(subtitleMono ? "font-mono" : "font-sans") }>

20− {subtitle}

21− </p>

22− )}

23− <p className="mt-1">{item}</p>

24− </div>

25− </div>

26− );

27−};

28−

29−export default GatewayHeader;

components/gateway/Image.jsdeleted−62

@@ -1,62 +0,0 @@

1−import { Sigil } from "@urbit/foundation-design-system";

2−const GatewayImage = ({

3− error = false,

4− patp = false,

5− color = "transparent",

6− image = "",

7− size = 100,

8−}) => {

9− if (error) {

10− return (

11− <div className="overflow-hidden rounded-xl shrink-0">

12− <svg

13− width={size}

14− height={size}

15− viewBox="0 0 100 100"

16− fill="none"

17− xmlns="http://www.w3.org/2000/svg"

18− >

19− <rect width="100" height="100" rx="10" className="fill-wall-600" />

20− <path

21− d="M28.8906 27.9844C28.5019 28.0215 28.1699 28.2833 28.043 28.6524C27.914 29.0235 28.0137 29.4336 28.2969 29.7032L70.2969 71.7032C70.4844 71.8965 70.7402 72.0059 71.0098 72.0059C71.2773 72.0079 71.5352 71.9004 71.7246 71.709C71.9141 71.5176 72.0176 71.2598 72.0137 70.9903C72.0098 70.7227 71.8984 70.4668 71.7031 70.2813L66.2501 64.8283C69.8204 60.9181 72.0001 55.7073 72.0001 50.0003C72.0001 37.8618 62.1386 28.0003 50.0001 28.0003C44.2931 28.0003 39.0976 30.1956 35.1876 33.7658L29.7031 28.2813C29.4922 28.0645 29.1934 27.9551 28.8906 27.9844L28.8906 27.9844ZM50.0001 30C61.0566 30 70.0001 38.9435 70.0001 50C70.0001 55.17 68.0411 59.8575 64.8281 63.406L36.5936 35.1715C40.1405 31.9606 44.8336 29.9995 49.9996 29.9995L50.0001 30ZM32.1721 37.8125C31.842 37.8321 31.5452 38.0137 31.3752 38.2969C29.2424 41.6856 28.0002 45.7029 28.0002 49.9999C28.0002 62.1384 37.8617 71.9999 50.0002 71.9999C54.2951 71.9999 58.3147 70.7558 61.7032 68.6249C62.1739 68.3319 62.3165 67.7128 62.0235 67.2421C61.7305 66.7714 61.1114 66.6288 60.6407 66.9218C57.5587 68.8593 53.9122 69.9999 50.0002 69.9999C38.9437 69.9999 30.0002 61.0564 30.0002 49.9999C30.0002 46.0878 31.1233 42.4414 33.0627 39.3594C33.2697 39.043 33.2815 38.6387 33.092 38.3125C32.9045 37.9844 32.5491 37.7929 32.1721 37.8125L32.1721 37.8125Z"

22− className="fill-white"

23− />

24− </svg>

25− </div>

26− );

27− }

28−

29− if (patp) {

30− return (

31− <div className="rounded-xl overflow-hidden shrink-0">

32− <Sigil patp={patp} size={size} color={color} />

33− </div>

34− );

35− }

36−

37− if (image?.startsWith("#")) {

38− return (

39− <div

40− style={{ height: size, width: size, backgroundColor: image }}

41− className="rounded-xl shrink-0"

42− />

43− );

44− }

45−

46− return image ? (

47− <div

48− className="rounded-xl overflow-hidden shrink-0"

49− style={{ backgroundColor: color }}

50− >

51− <img src={image} style={{ height: size, width: size }} />

52− </div>

53− ) : (

54− <img

55− className="object-contain shadow-sm rounded-xl"

56− style={{ height: size, width: size }}

57− src="https://media.urbit.org/public-links/placeholder-image.png"

58− />

59− );

60−};

61−

62−export default GatewayImage;

components/gateway/MetadataBlock.jsdeleted−8

@@ -1,8 +0,0 @@

1−const MetadataBlock = ({ title, content }) => (

2− <div className="flex flex-col basis-1/2 pr-2 sm:basis-1/4 mb-4 md:mb-0 flex-1">

3− <p className="font-bold text-wall-400">{title}</p>

4− <p className="font-mono">{content}</p>

5− </div>

6−);

7−

8−export default MetadataBlock;

components/gateway/MetadataLink.jsdeleted−14

@@ -1,14 +0,0 @@

1−import Link from "next/link";

2−

3−const MetadataLink = ({ title, href, content }) => (

4− <div className="flex flex-col basis-1/2 sm:basis-1/4 pr-2 mb-4 min-w-0 flex-1">

5− <p className="font-bold text-wall-400">{title}</p>

6− <Link href={href}>

7− <div className="flex truncate">

8− <a className="truncate font-mono text-green-400">{content}</a>

9− </div>

10− </Link>

11− </div>

12−);

13−

14−export default MetadataLink;

components/gateway/ResourceCard.jsdeleted−24

@@ -1,24 +0,0 @@

1−import Link from "next/link";

2−import GatewayImage from "./Image";

3−import classNames from "classnames";

4−import { capitalize } from "@urbit/foundation-design-system";

5−

6−const ResourceCard = ({ type, shortcode, title, description = "", color, image, full }) => (

7− <Link href={`/${type}s/${shortcode}`}>

8− <div className={classNames("cursor-pointer rounded-xl bg-wall-100 p-4 flex items-center space-x-4 mr-2 my-1", {

9− "basis-full": full

10− })}>

11− <GatewayImage color={color} image={image || color} size={50} />

12− {full

13− ? <><div className="flex flex-col w-full">

14− <a className="font-semibold">{title}</a>

15− <p className="hidden lg:block">{description}</p>

16− </div>

17− <a className="button-lg bg-green-400 text-white shrink-0">View {capitalize(type)}</a>

18− </>

19− : <a className="font-semibold">{title}</a>}

20− </div>

21− </Link>

22−);

23−

24−export default ResourceCard;

components/icons/Cross.jsdeleted−11

@@ -1,11 +0,0 @@

1−export default function Cross(props) {

2− return (

3− <svg {...props} viewBox="0 0 12 12">

4− <path

5− fillRule="evenodd"

6− clipRule="evenodd"

7− d="M0.292893 10.2942C-0.0976311 10.6847 -0.0976311 11.3179 0.292893 11.7084C0.683417 12.0989 1.31658 12.0989 1.70711 11.7084L6.00063 7.41487L10.2948 11.7091C10.6853 12.0996 11.3185 12.0996 11.709 11.7091C12.0996 11.3185 12.0996 10.6854 11.709 10.2949L7.41484 6.00066L11.7084 1.70711C12.0989 1.31658 12.0989 0.683417 11.7084 0.292894C11.3179 -0.0976312 10.6847 -0.0976312 10.2942 0.292894L6.00063 4.58645L1.70775 0.293571C1.31723 -0.0969534 0.684061 -0.0969534 0.293536 0.293571C-0.0969879 0.684095 -0.0969879 1.31726 0.293536 1.70778L4.58641 6.00066L0.292893 10.2942Z"

8− />

9− </svg>

10− );

11−}

components/index/BubbleLink.jsdeleted−25

@@ -1,25 +0,0 @@

1−export default function BubbleLink(props) {

2− return (

3− <li className={"list-none " + props.className}>

4− <a className={"flex"} href={props.href} target={props.target}>

5− <div>{props.children}</div>

6− <div className="flex flex-col ml-4">

7− <p className="font-bold">{props.title}</p>

8− <p className="text-wall-400 dark:text-antiwall-400 font-bold leading-snug">

9− {props.caption}

10− </p>

11− </div>

12− </a>

13− </li>

14− );

15−}

16−

17−BubbleLink.defaultProps = {

18− className: "",

19− title: "",

20− caption: "",

21− children: (

22− <div className="w-12 h-12 bg-wall-500 dark:bg-antiwall-500 rounded-full" />

23− ),

24− target: "_blank",

25−};

content/bitcoin-wallet.md → content/Bitcoin-wallet.mdrenamed+10−17

@@ -1,44 +1,37 @@

1+++

1+++

2−title = "Bitcoin Wallet"

2+title = "Bitcoin Wallet Disclaimers"

3+++

3+++

4

4

5−The latest Urbit release includes a native Bitcoin wallet. Please read the following security recommendations and disclaimers carefully. Urbit.org cannot recover any lost keys.

6−

7−### Instructions

8−

9−Run `|start %btc-wallet` in the dojo. After refreshing Landscape you should see an orange bitcoin tile in the first row. Clicking on it will prompt a two-step process:

10

5

11−1. Enter a provider who is connected to a full-node (such as `~zod`). The provider will maintain a synced Bitcoin ledger, index your public addresses to determine your balance, and process your transactions.

12

6

13−2. The next step is to provide an extended public key (or xpub). Providing your xpub allows the Bitcoin Wallet to automatically generate new public addresses (called _child public keys_—you can learn more about this [here](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)) when bitcoin is sent to your ship. To provide an xpub you can either enter your master ticket (which can be downloaded from [Bridge](https://bridge.urbit.org)), or directly import your xpub (such as from a hardware wallet like [Ledger](https://support.ledger.com/hc/en-us/articles/360011069619-Extended-public-key) or [Trezor](<https://wiki.trezor.io/User_manual:Displaying_account_public_key_(XPUB)>)).

7+The latest Urbit release includes a native Bitcoin wallet. Please read the following security recommendations and disclaimers carefully. Urbit.org cannot recover any lost keys.

14

8

15−Clicking on the Landscape tile will take you to the Bitcoin Wallet application, where you can view your balance and send bitcoin. All that you'll need to do is enter the recipient's Urbit ID (if they have configured the wallet using the above steps) or a Bitcoin address.

16

9

17−If you are interested in [being a provider](https://subject.network/posts/btc-wallet-config/#connecting-a-provider-to-a-full-node) or [running a bitcoin full node](https://subject.network/posts/pi-fullnode-urbit/#bitcoind) on the Urbit network please check out `~sitful-hatred`’s excellent tutorials.

18

10

19### Verify

11### Verify

20

12

21−You should verify your version of this Bitcoin wallet. To do so, follow the instructions in the README in our [Github](https://github.com/urbit/urbit/blob/master/pkg/btc-wallet/README) repo.

13+You should verify your version of this Bitcoin wallet. To do so, follow the instructions in the README in our [Github](https://github.com/urbit/urbit/blob/master/pkg/btc-wallet/README.md) repo.

22

14

23−Instructions reproduced here:

15+Instructions reproduced here:

24

16

25To verify your version of the bitcoin wallet, run the following command in the dojo:

17To verify your version of the bitcoin wallet, run the following command in the dojo:

26`> +btc-wallet-check`

18`> +btc-wallet-check`

27It should return with the following hash:

19It should return with the following hash:

28`0v9t022.n8kv1.5emkt.s2p9i.hvsa9`

20`0v9t022.n8kv1.5emkt.s2p9i.hvsa9`

29

21

30−### Disclaimer Statement

31

22

32−The Urbit Bitcoin Wallet and its related components are experimental pieces of software. You are free to review the open-source code before using:

23+### Statement

33

24

25+The Urbit Bitcoin Wallet and its related components are experimental pieces of software. You are free to review the open-source code before using:

34−- [Wallet](https://github.com/urbit/urbit/tree/master/pkg/btc-wallet)

26+- [Wallet](https://github.com/urbit/urbit/tree/master/pkg/btc-wallet)

35- [Full Node Provider Agents](https://github.com/timlucmiptev/btc-agents)

27- [Full Node Provider Agents](https://github.com/timlucmiptev/btc-agents)

36

28

37−No guarantees are made about the security of this software. It may contain vulnerabilities that could lead to loss of funds. This wallet software has not had a formal security audit.

29+No guarantees are made about the security of this software. It may contain vulnerabilities that could lead to loss of funds. This wallet software has not had a formal security audit. 

38

30

39You can read about the security audit for Urbit's networking protocol in this [post](https://urbit.org/blog/security-audit/). This audit does not encompass the wallet, except to the extent that the wallet operates on Urbit's networking architecture.

31You can read about the security audit for Urbit's networking protocol in this [post](https://urbit.org/blog/security-audit/). This audit does not encompass the wallet, except to the extent that the wallet operates on Urbit's networking architecture.

40

32

41−If you decide to use this wallet, please store responsible amounts of Bitcoin, and use best security practices. The developers of this software cannot help you recover your keys / funds, if lost.

33+If you decide to use this wallet, please store responsible amounts of Bitcoin, and use best security practices. The developers of this software cannot help you recover your keys / funds, if lost. 

34+

42

35

43### License

36### License

44

37

content/applications/_index.mddeleted−3

@@ -1,3 +0,0 @@

1−+++

2−title = "Application Directory"

3−+++

content/applications/~bacwyl-samweg/templeochess.mddeleted−22

@@ -1,22 +0,0 @@

1−+++

2−title = "Temple O Chess"

3−shortcode = "~bacwyl-samweg/templeochess"

4−license = "MIT"

5−image = "https://0x0.st/oFuT.png"

6−bgColor = "#FFFF55"

7−developer = "~bacwyl-samweg"

8−website = "https://youtu.be/Raej8C2yIEc"

9−description = "chess game from Temple OS"

10−+++

11−

12−### Chess from Temple OS

13−

14−

15−Temple O Chess is a pixel-for-pixel reproduction of the chess game from Temple OS.

16−

17−It was created using [this youtube video](https://youtu.be/Raej8C2yIEc) as a reference.

18−

19−It's a fully playable online chess game. Instead of a challenge system, games are formed using a naive public queue.

20−

21−Just queue up, and you will be automatically matched with the next (or previous) player.

22−

content/applications/~datder-sonnet/hodl.mddeleted−16

@@ -1,16 +0,0 @@

1−+++

2−title = "hodl"

3−description = "Track your digital hodlings"

4−shortcode = "~hodler-datder-sonnet/hodl"

5−license = "MIT"

6−image = "https://user-images.githubusercontent.com/16504501/194947852-8802fd63-5954-4ce8-b147-2072bd929242.png"

7−bgColor = "#b8a3d1"

8−developer = "~datder-sonnet"

9−website = "https://github.com/tomholford/hodl"

10−+++

11−

12−A portfolio app for tracking your digital assets.

13−

14−Add transactions to get a summary of your crypto net worth.

15−

16−Supports over 13K coins via the Coingecko API.

content/applications/~disreb-winner-mittec/urbit-go.mddeleted−12

@@ -1,12 +0,0 @@

1−+++

2−title = "Go"

3−shortcode = "~disreb-winner-mittec/urbit-go"

4−license = "GPLv3"

5−image = "https://winnermittec.space/icon.svg"

6−bgColor = "#D37504"

7−developer = "~winner-mittec"

8−website = "https://winnermittec.space/"

9−description = "Go on Urbit"

10−+++

11−

12−The classic board-game Go, now on Urbit!

content/applications/~dister-dister-datryn-ribdun/campfire.mddeleted−12

@@ -1,12 +0,0 @@

1−+++

2−title = "Campfire"

3−shortcode = "~dister-dister-datryn-ribdun/campfire"

4−description = "Voice and video chat"

5−license = "MIT"

6−image = "https://raw.githubusercontent.com/datryn-ribdun/urbit-webrtc/master/campfire/logo.svg"

7−bgColor = "#FFC179"

8−developer = "~datryn-ribdun"

9−website = "https://github.com/datryn-ribdun/urbit-webrtc"

10−+++

11−

12−Hang out with your friends. Voice and video chat by Holium.

content/applications/~dister-dister-sidnym-ladrut/quorum.mddeleted−17

@@ -1,17 +0,0 @@

1−+++

2−title = "Quorum"

3−shortcode = "~dister-dister-sidnym-ladrut/quorum"

4−developer = "Quorum Team"

5−description = "A choral explanations app for Urbit"

6−license = "MIT"

7−website = ""

8−bgColor = ""

9−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/quorum-logo.png"

10−+++

11−

12−Quorum is a Stack Overflow/Quora style application that allows individuals to submit and vote on questions and answers in threads.

13−

14−To join the Urbit Foundation's [battery payload] board, when prompted to add a board, enter `~dister-dozzod-lapdeg` as the provider, and `battery-payload` as the board.

15−

16−

17−

content/applications/~dister-dozzod-bacdun/uqbar-suite.mddeleted−20

@@ -1,20 +0,0 @@

1−+++

2−title = "Uqbar Development Suite"

3−shortcode = "~dister-dozzod-bacdun/zig"

4−developer = "Uqbar"

5−description = "The contract & app development, wallet, and block explorer suite from Uqbar."

6−license = "MIT"

7−website = "https://uqbar.network"

8−bgColor = ""

9−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/uqbarsuite.png"

10−+++

11−

12−The Uqbar Development Suite, also known as Ziggurat, is an all-in-one developer suite designed to give programmers a seamless coding experience as they create and deploy smart contracts and blockchain-integrated Urbit apps to our testnet. The Ziggurat suite consists of:

13−

14−

15−

16−

17−

18−

19−

20−For more information, read our [Developer Docs](https://uqbar-network.gitbook.io/uqbar-developer-documentation/developer-documentation/developer-documentation).

content/applications/~dister-dozzod-dalten/books.mddeleted−20

@@ -1,20 +0,0 @@

1−+++

2−title = "Books"

3−developer = "Quartus Co."

4−shortcode = "~dister-dozzod-dalten/books"

5−description = "It just makes cents"

6−license = "MIT"

7−website = "https://dalten.org"

8−bgColor = "#E44D11"

9−+++

10−

11−Books is an application for managing your crypto wallets, transactions, and counterparties. It allows you to add your wallet and other people’s, track balances and transactions, and add private annotations to all of the above.

12−

13−

14−

15−## Books in a Nutshell

16−If you spend much time interacting with crypto, you probably have a few wallets: a few hot wallets in metamask, a ledger or two, perhaps an Urbit ID on a master ticket, and that’s just Ethereum.

17−

18−To get a good picture of your aggregate activity you can use a variety of chain analytics tools, but there’s always a sizable catch: there’s nowhere to record the identities of the counter parties you transact with, or the purpose of the transactions. To do this now, your options are to either keep your own records (offline), use a local-storage based address book like Metamask’s, or put your data on someone else’s servers.

19−

20−Books provides an ideal solution: annotate on-chain, public information with private data stored on your urbit, your personal server. This lets you account for your spending, keep records of the people you transact with, and organize your wallets without compromising on privacy or mobility.

content/applications/~dister-dozzod-dalten/gora.mddeleted−24

@@ -1,24 +0,0 @@

1−+++

2−title = "Gora - ピタゴラ装置"

3−developer = "~dalten"

4−shortcode = "~mister-dozzod-dalten/gora"

5−description = "A Proof of Attendance Protocol for Urbit"

6−license = "MIT"

7−website = "https://dalten.org"

8−bgColor = "#FCD977"

9−+++

10−

11−### A Proof of Attendance Protocol for Urbit

12−

13−Gora is a proof of presence protocol (POPP) that is

14−intended to be extensible, flexible and educational

15−(at least for new hooners).

16−

17−

18−

19−

20−Gora has two distros in

21−circulation - these can be found at:

22−~laddys-dozzod-dalten (Vue.js frontend)

23−~mister-dozzod-dalten (sail frontend)

24−The canonical distro for all Quartus and Dalten Collective apps can always be found at ~dister-dozzod-dalten

content/applications/~dister-dozzod-dalten/keep.mddeleted−13

@@ -1,13 +0,0 @@

1−+++

2−title = "Keep"

3−developer = "Quartus Co."

4−shortcode = "~dister-dozzod-dalten/keep"

5−description = "State backup for your agents"

6−license = "MIT"

7−website = "https://dalten.org"

8−bgColor = "#E44D11"

9−+++

10−

11−Keep is backup utility for preserving the state of your applications across breaches. Unlike [peat](https://urbit.org/ecosystem/applications/~dister-dozzod-dalten/peat), Keep can backup the state of any arbitrary agent, but does not offer granular control of specific graphs or other targeted contexts.

12−

13−For support with any of Quartus' applications, please visit the [Quartus public group](https://urbit.org/ecosystem/groups/~mister-hilper-dozzod-dalten/quartus)

content/applications/~dister-dozzod-dalten/orca.mddeleted−17

@@ -1,17 +0,0 @@

1−+++

2−title = "Orca"

3−developer = "Quartus Co."

4−shortcode = "~dister-dozzod-dalten/orca"

5−description = "Now THIS is podchatting"

6−license = "MIT"

7−website = "https://dalten.org"

8−bgColor = "#13181C"

9−+++

10−

11−** ocra has been deprecated and will soon be replaced with updated tooling supporting chat federation for the new Groups backend **

12−

13−Now THIS is podchatting

14−

15−

16−

17−

content/applications/~dister-dozzod-dalten/peat.mddeleted−36

@@ -1,36 +0,0 @@

1−+++

2−title = "peat"

3−developer = "Quartus Co."

4−shortcode = "~dister-dozzod-dalten/peat"

5−description = "Graph Backup and Restoration Utility"

6−license = "REKT"

7−website = "https://dalten.org"

8−bgColor = "#574D5A"

9−+++

10−

11−Peat is Urbit's first backup utility and works with the %graph-store backend. Quartus is also working to support backup and recovery for arbitrary agent state via %keep, as well as updated utility tooling that supports the new Groups backend.

12−

13−

14−

15−## Peat in a Nutshell

16−- Import

17− - Recover a Social `graph` from a saved file - transferrable between ships

18−- Export

19− - Export a Social `graph` to a file on underlying file system (e.g. Unix)

20−- Backup/Restore

21− - Local recreation of a `graph` that exists, 're-basing' the `graph` to be hosted by the local ship

22−## Import from Disk - Details

23−- User has a `/path/to/pier/<project-desk>/hav` directory for importing (though they could import from anywhere, really).

24−- User also has a form interface, through Peat's webapp allowing them to import without tracking the files in their loom.

25−### From Clay

26−- User gets instructions from the frontend as to how to add files to this directory and commit the desk so the files are available in the OS

27− - NOTE: This should be converted to using `drum`'s `get` functionality at some point, but this hasn't been wired up yet in `drum`.

28−- User can see all files available for restoration in the default `hav` directory, delineated by whether they represent Agent `state` or `graph`s

29−- User can select a file for restoration

30−- User can apply the file for restoration

31− - Potentially needing to specify additional details, for a `graph` (e.g. what `group` to associate it with, and what to call the new `resource`)

32−User is informed that the restoration is underway/has completed

33−### From Web

34−- User gets instructions from the frontend as to how to upload files through the frontend, resulting in their unpacking and importing to graph store

35−- User can select from local files on the computer through which they're accessing the frontend.

36−- Note: This method avoids polluting loom with transient files - it is to be the preferred method

content/applications/~dister-dozzod-dalten/wrdu.mddeleted−15

@@ -1,15 +0,0 @@

1−+++

2−title = "wrdu"

3−developer = "Quartus Co."

4−shortcode = "~dister-dozzod-dalten/wrdu"

5−description = "Word game by ~dalten for our mothers"

6−license = "MIT"

7−website = "https://dalten.org"

8−bgColor = "#79A86B"

9−+++

10−

11−word game by ~dalten for our mothers

12−

13−

14−

15−

content/applications/~donpub-datdux/forms.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "Forms"

3−shortcode = "~donpub-datdux/forms"

4−developer = "~nallux-dozryl"

5−description = "Publish and Respond to Forms."

6−license = "MIT"

7−website = "https://github.com/nallux-dozryl/urbit-forms"

8−bgColor = "#AFC4E0"

9−image = ""

10−+++

11−

12−Create and fill out forms and surveys on Urbit.

13−

14−

content/applications/~fabnev-hinmur/escape.mddeleted−16

@@ -1,16 +0,0 @@

1−+++

2−title = "EScape"

3−shortcode = "~dister-fabnev-hinmur/escape"

4−developer = "Uqbar"

5−description = "EScape from Eternal September. The UI from Uqbar."

6−license = "MIT"

7−website = "https://uqbar.network"

8−bgColor = "#f2f3ef"

9−image = "https://escape-app-dist.s3.us-east-2.amazonaws.com/escape-logo.png"

10−+++

11−

12−EScape is a fully-integrated social management and DAO Tooling system. EScape provides a simple, intuitive, and unified interface for managing groups, messaging ships, receiving notifications, and interacting with other Urbit apps.

13−

14−

15−

16−Get EScape on [iOS](https://apps.apple.com/my/app/escape-by-uqbar/id1610194217) and [Android](https://play.google.com/store/apps/details?id=network.uqbar.escape).

content/applications/~fabnev-hinmur/handshake.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "Handshake"

3−developer = "Uqbar"

4−shortcode = "~dister-fabnev-hinmur/handshake"

5−description = "Confirm Urbit IDs via QR code."

6−license = "MIT"

7−website = "https://uqbar.network"

8−bgColor = "#df828b"

9−image = "https://static.thenounproject.com/png/2002633-200.png"

10−+++

11−

12−Handshake generates and verifies QR codes for admission into IRL events.

13−

14−

content/applications/~finmep-lanteb/chess.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "Chess"

3−shortcode = "~finmep-lanteb/chess"

4−developer = "~bonbud-macryg, ~finmep-lanteb, ~nordus-mocwyl, ~rovmug-ticfyn, ~sigryn-habrex"

5−description = "Fully peer-to-peer chess over Urbit"

6−license = "GPL3"

7−website = "https://github.com/thecommons-urbit/chess"

8−bgColor = "#ffffff"

9−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/finmep-chess.svg"

10−+++

11−

12−Fully decentralized, peer-to-peer Chess app for Urbit

13−

14−

content/applications/~haddef-sigwen/transit.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "Transit"

3−shortcode = "~haddef-sigwen/transit"

4−license = "MIT"

5−image = "https://haddefsigwen1.s3.us-east-1.amazonaws.com/haddef-sigwen/2022.5.07..20.27.02-image.png"

6−bgColor = "#38285c"

7−developer = "~haddef-sigwen"

8−description = "Planetary transit occurs once per day."

9−website = ""

10−+++

11−

12−Planetary transit occurs once per day.

13−

14−

content/applications/~hanfel-dovned/board.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "Board"

3−shortcode = "~dister-hanfel-dovned/board"

4−license = "MIT"

5−image = ""

6−bgColor = "#9E34EB"

7−developer = "~hanfel-dovned"

8−website = "https://github.com/hanfel-dovned/Board"

9−description = "A digital bulletin-board"

10−+++

11−

12−An implementation of [Robin Sloan’s Spring ‘83](https://www.robinsloan.com/lab/specifying-spring-83/) concept as an Urbit app called %board. Imagine a digital bulletin-board where each item is a person’s miniature homepage, and the pages you see are based on who you know.

13−

14−

content/applications/~hanfel-dovned/pony.mddeleted−12

@@ -1,12 +0,0 @@

1−+++

2−title = "Pony"

3−shortcode = "~dister-hanfel-dovned/pony"

4−license = "MIT"

5−image = ""

6−bgColor = "#232323"

7−developer = "~hanfel-dovned"

8−website = "https://github.com/hanfel-dovned/Pony"

9−description = "Pony is an app for longform threaded conversations"

10−+++

11−

12−Pony is an app for longform threaded conversations, like a blend of email and message boards. Create private threads with arbitrary sets of ships, fork threads to new sets of participants, schedule messages to be sent later, and much more.

content/applications/~hanfel-dovned/slam.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "Slam"

3−shortcode = "~dister-hanfel-dovned/slam"

4−license = "MIT"

5−image = "https://hanfel-dovned.sfo3.digitaloceanspaces.com/slam-tile.png"

6−bgColor = "#100032"

7−developer = "~hanfel-dovned"

8−website = "https://github.com/hanfel-dovned/Slam"

9−description = "A social arcade game"

10−+++

11−

12−Slam is a social arcade game where you battle waves of enemies that are generated from your pals' gorae.

13−

14−Requires [gora](https://urbit.org/applications/~dalten/gora) and [pals](https://urbit.org/applications/~paldev/pals).

content/applications/~hanrut-sillet-dachus-tiprel/blog.mddeleted−16

@@ -1,16 +0,0 @@

1−+++

2−title = "%blog"

3−shortcode = "~hanrut-sillet-dachus-tiprel/blog"

4−license = "MIT"

5−image = ""

6−bgColor = "#533E78"

7−developer = "~dachus-tiprel"

8−website = "https://dachus-tiprel.tlon.network/blog/introducing-blog"

9−description = "The easiest and most versatile publishing app on Urbit"

10−+++

11−

12−A publishing tool for creating a basic blog with markdown and css.

13−

14−Blog is just what it sounds like. A new tool from Uqbar, the app lets anyone on Urbit spin up and customize a blog that displays to the net at an auto-generated URL. Nothing could be breezier. Plus it’s got payments through Uqbar and group-blogging settings on the roadmap. Find out more about it on it's [creator's blog](https://dachus-tiprel.tlon.network/blog/introducing-blog).

15−

16−

content/applications/~larryx-woldyr/osmosis.mddeleted−12

@@ -1,12 +0,0 @@

1−+++

2−title = "Osmosis"

3−shortcode = "~larryx-woldyr/osmosis"

4−license = "MIT"

5−image = "https://holium-app-globs.nyc3.cdn.digitaloceanspaces.com/osmosis/osmosis-logo-wc.png"

6−bgColor = "#180D39"

7−developer = "~larryx-woldyr"

8−website = "https://https://osmosis.zone/"

9−description = "Interchain liquidity lab."

10−+++

11−

12−A fully self-hosted Osmosis frontend, deployed via Urbit.

content/applications/~larryx-woldyr/safe.mddeleted−12

@@ -1,12 +0,0 @@

1−+++

2−title = "Safe"

3−shortcode = "~larryx-woldyr/safe"

4−license = "MIT"

5−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/safe.jpeg"

6−bgColor = "#180D39"

7−developer = "~larryx-woldyr"

8−website = "https://safe.global/"

9−description = "Safe front-end"

10−+++

11−

12−A fully self-hosted Safe frontend, deployed via Urbit.

content/applications/~larryx-woldyr/uniswap.mddeleted−12

@@ -1,12 +0,0 @@

1−+++

2−title = "Uniswap"

3−shortcode = "~larryx-woldyr/uniswap-v3"

4−license = "MIT"

5−image = "https://cryptologos.cc/logos/uniswap-uni-logo.png"

6−bgColor = "0xffffff"

7−developer = "~larryx-woldyr"

8−website = "http://uniswap.org"

9−description = "Self-hosted Uniswap interface"

10−+++

11−

12−A self-hosted Uniswap interface for swapping assets on Ethereum.

content/applications/~larryx-woldyr/urbhue.mddeleted−18

@@ -1,18 +0,0 @@

1−+++

2−title = "Hue"

3−shortcode = "~larryx-woldyr/urbhue"

4−license = "MIT"

5−image = "https://i.imgur.com/czmkmoK.png"

6−bgColor = "#F0B43D"

7−developer = "~larryx-woldyr"

8−website = "https://ajlamarc.com"

9−description = "Controlling Philips Hue"

10−+++

11−

12−In this prototype, Philips Hue Lightbulbs and groups can be controlled from a standard Urbit application by using the Hue Remote API.

13−

14−History and logging of the bulb are collected to provoke consideration of what should be controlled and tracked by the people living in a smart home.

15−

16−This app will hopefully inspire people to think of the potential utility of Urbit in the smart home, inspire non-Urbit users to think of Urbit in non-community driven scenarios, and be a small step forward in understanding the affordances for Urbit in the home.

17−

18−For more information on `%urbhue`, check out our Urbit group: `~pilwyc-fastec/communal-computing-for-urbit`

content/applications/~lomder-librun/ballot.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "Ballot"

3−shortcode = "~livdel-binmun-lomder-librun/ballot"

4−license = "MIT"

5−image = "https://lomder-librun.sfo3.digitaloceanspaces.com/tiles/ballot-app-tile.svg"

6−bgColor = "#cebef0"

7−developer = "~lomder-librun"

8−website = "https://www.holium.com"

9−description = "An app that allows you to vote with other ships."

10−+++

11−

12−Ballot allows you to create and vote on proposals, delegate votes to other urbit ships, and trigger actions based on results.

13−

14−

content/applications/~lomder-librun/realm.mddeleted−18

@@ -1,18 +0,0 @@

1−+++

2−title = "Realm"

3−shortcode = "~lomdyr-librun/realm"

4−license = ""

5−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/realm-icon.png"

6−bgColor = ""

7−developer = "Holium"

8−website = "https://www.holium.com/"

9−description = "A desktop interface for Urbit"

10−+++

11−

12−Realm is a desktop app for Urbit communities (currently in private alpha).

13−

14−[Sign up for the alpha.](https://www.holium.com/)

15−

16−<iframe width="560" height="315" src="https://www.youtube.com/embed/gdu4QtFR-Bs" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

17−

18−Note that the shortcode will not install this application.

content/applications/~midlev-mindyr/astrolabe.mddeleted−30

@@ -1,30 +0,0 @@

1−+++

2−title = "Astrolabe"

3−shortcode = "~dister-midlev-mindyr/astrolabe"

4−license = ""

5−image = "https://raw.githubusercontent.com/johnhyde/astrolabe/main/ui/src/assets/astrolabe-tile.svg"

6−bgColor = ""

7−developer = "~midlev-mindyr"

8−website = "https://github.com/johnhyde/astrolabe"

9−description = "Astrolabe is a one-stop shop app for exploring Urbit address space."

10−+++

11−

12−### Astrolabe is a one-stop shop app for exploring Urbit address space.

13−

14−Features:

15−

16−- **ID Search**:

17−When you search a partial @p (or use wildcards), it will show you the spawned/owned ships which match your search.

18−

19−- **Sigil Search**:

20−You can use a visual interface to enter sigils, either just general shapes, or specific shape/pattern combos

21−

22−- **Sky Chart**:

23− Astrolabe integrates with %pals to highlight your pals on the sky chart. Clicking/tapping on a point opens a small modal with basic info and a button to take you to a Ship View of the point.

24−

25−- **Ship View**:

26−Summary view for any ship. As on urbit.live or urbit.me, it shows the @p, owner, parent, etc. Allows PNG or SVG download of sigils. Displays tags from %pals, and potentially allows you to add pals and/or edit tags from that screen.

27−

28−

29−

30−Astrolabe integrates with pals wherever possible, and contains documentation to explain the many quirks of Urbit address space to a new user.

content/applications/~midsum-salrux/faux.mddeleted−11

@@ -1,11 +0,0 @@

1−+++

2−title = "Faux"

3−developer = "~midsum-salrux"

4−shortcode = "~tindys-botter-dozzod-tomdys/faux"

5−description = "An Urbit-native Discord bridge"

6−license = "MIT"

7−website = "https://github.com/midsum-salrux/faux"

8−bgColor = "#000000"

9−+++

10−

11−Faux, a bridge between discord and urbit groups. When a member posts a new message in your discord group, a bot reposts it in your urbit group, and vice versa. This is implemented as a native gall agent and includes a frontend app to configure the connections between your discord and urbit servers.

content/applications/~migmeg-fidlen-sillus-mallus/kenning.mddeleted−17

@@ -1,17 +0,0 @@

1−+++

2−title = "kenning"

3−shortcode = "~migmeg-fidlen-sillus-mallus/kenning"

4−license = "MIT"

5−image = "https://upload.wikimedia.org/wikipedia/commons/thumb/a/a0/Voiced_dental_fricative_%28vector%29.svg/1920px-Voiced_dental_fricative_%28vector%29.svg.png"

6−bgColor = "#a59a2d"

7−developer = "~sillus-mallus"

8−website = "https://lovecrypt.net"

9−description = "Memorization tool for text passages."

10−+++

11−

12−Memorize passages of text. Every passage is called a “kenning”.

13−

14−1. Every kenning is assigned a kelvin version based on word count.

15−1. You may test your knowledge by filling in the blanks.

16−1. As kelvin decreases, the number of blanks increases.

17−1. For large passages, split the text into several kens for best results.

content/applications/~mister-dister-dozzod-dozzod/terminal.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "Terminal"

3−developer = "Tlon"

4−shortcode = "~mister-dister-dozzod-dozzod/webterm"

5−description = "A web interface to your Urbit's command line."

6−license = "MIT"

7−website = "https://tlon.io"

8−bgColor = "#324246"

9−+++

10−

11−

12−Terminal is a command line interface for your urbit. You can run commands, script, and program your Urbit directly, even if your urbit is located on a remote server. Discover the gratification of programming a computer that is truly yours.

13−

14−

content/applications/~niblyx-malnus/gol-cli.mddeleted−15

@@ -1,15 +0,0 @@

1−+++

2−title = "Goals"

3−shortcode = "~dister-dozzod-niblyx-malnus/gol-cli"

4−license = "MIT"

5−image = ""

6−bgColor = "#362711"

7−developer = "~niblyx-malnus"

8−website = ""

9−description = "Hierarchically nested goals and projects"

10−+++

11−

12−### Goals helps you track and share interrelated tasks

13−

14−

15−Goals is primarily dealing with four kinds of relationships: containment/ownership, virtual nesting, precedence, and priority. These fundamental relationships between goals and that any other important information about a goal does not require any complex sort of topological representation, but can simply be a piece of data associated with the goal.

content/applications/~nocsyx-lassul/silo.mddeleted−20

@@ -1,20 +0,0 @@

1−+++

2−title = "silo"

3−shortcode = "~dister-nocsyx-lassul/silo"

4−license = "MIT"

5−image = ""

6−bgColor = "#4f46e5"

7−developer = "~nocsyx-lassul"

8−description = "An S3 storage manager"

9−website = "https://github.com/arthyn/silo"

10−+++

11−

12−### An S3 storage manager

13−

14−Silo is an application for viewing and managing your urbit's file storage. Currently that means the files in an S3-compatible storage system, but hopefully soon we'll also be able to provide an interface for your local urbit's filesystem too.

15−

16−

17−

18−Currently silo allows you to upload, delete, add folders, and otherwise manage your files like you expect. It also offers easy access to downloading files and copying their URLs.

19−

20−In the future we hope to add the ability to easily share files with others, offer storage to friends or groups, a fully urbit-side S3 and virtual filesystem API, and a drop-in file-picker component that devs can use to easily add image uploads to their apps.

content/applications/~nocsyx-lassul/sphinx.mddeleted−20

@@ -1,20 +0,0 @@

1−+++

2−title = "sphinx"

3−shortcode = "~dister-nocsyx-lassul/sphinx"

4−license = "MIT"

5−image = "https://nyc3.digitaloceanspaces.com/hmillerdev/nocsyx-lassul/2022.7.16..04.35.22-sphinx-web-shifted.svg"

6−bgColor = "#b25068"

7−developer = "~nocsyx-lassul"

8−website = "https://github.com/arthyn/sphinx"

9−description = "Community powered search"

10−+++

11−

12−### Community powered search

13−

14−Sphinx is a search engine powered by you and your pals. Using the gossip mechanism developed by ~paldev for [%rumors](https://urbit.org/applications/~paldev/rumors), anytime you post a listing it gets indexed on your urbit and then shared with your friends and friends of friends.

15−

16−

17−

18−Currently sphinx is probably best as a tool for finding groups and apps, but will likely index content soon too. It uses exact, phonetic, and unordered trigram matching to index the keywords in your listings. This allows you to type a query inconsistently and still get similar results as if it was spelled right.

19−

20−Future features include tag aggregation for more "classifieds"-type browsing, browsing by who shared something, ability to specify who a listing gets shared with (private/pals/pals+sponsor), and the ability to add search providers who might host non-gossiped indexes.

content/applications/~nodmyn-dosrux/basket.mddeleted−34

@@ -1,34 +0,0 @@

1−+++

2−title = "basket"

3−shortcode = "~nodmyn-dosrux/basket"

4−license = "MIT"

5−image = "https://0x0.st/oFHB.png"

6−bgColor = "#F2F2F2"

7−developer = "Assembly Capital"

8−website = "https://github.com/bacwyls/basket"

9−description = "show off your meme collection"

10−+++

11−

12−

13−### Basket is a simple db of tagged images

14−

15−The frontend displays the most recent image in the full window,

16−so it can be used to add some personal style to an urbit desktop environment.

17−

18−In addition to being a personal db, basket is an experimental app on top of the 'rooms' primitive in [Realm](https://twitter.com/HoliumCorp).

19−

20−Members of a room have temporary write-access to each others basket db.

21−The frontend makes it ergonomic and fun to share / collaboritively create this data.

22−

23−In theory (at scale), this creates a kind of decentralized giphy.

24−

25−The images you know about are the images your friends have shared with you.

26−It gamifies the creation of rich, human curated image metadata.

27−One obvious use case for this is keeping track of memes.

28−

29−To export the full dataset you can GET `http://yoururbitship.com/~/scry/basket/images.json`

30−Then you might want to use a python script to actually download the images to local storage.

31−

32−Eventually, it would be nice to have a simple way to export and share the dataset.

33−

34−Read full documentation on the [Github repository](https://github.com/bacwyls/basket).

content/applications/~nodmyn-dosrux/houston.mddeleted−17

@@ -1,17 +0,0 @@

1−+++

2−title = "houston"

3−shortcode = "~nodmyn-dosrux/houston"

4−license = "MIT"

5−image = "https://0x0.st/ojrj.png"

6−bgColor = "#FFFFFF"

7−developer = "Assembly Capital"

8−website = "https://github.com/assemblycapital/houston"

9−description = "Moon Management Dashboard"

10−+++

11−

12−### Moon Management Dashboard

13−

14−

15−

16−Keeps track of the moons you've spawned and exposes a poke API for the standard moon utilities: `|moon`, `|moon-breach` and `|moon-cycle`

17−

content/applications/~nodmyn-dosrux/radio.mddeleted−15

@@ -1,15 +0,0 @@

1−+++

2−title = "radio"

3−shortcode = "~nodmyn-dosrux/radio"

4−license = "MIT"

5−image = "https://0x0.st/o4--.png"

6−bgColor = "#f2f2f2"

7−developer = "Assembly Capital"

8−website = "https://github.com/bacwyls/radio"

9−description = "an app for urbit disc jockeys"

10−+++

11−

12−Create and tune into virtual radio stations where you can chat and play Youtube videos with your friends.

13−

14−

15−

content/applications/~nodmyn-dosrux/vita.mddeleted−20

@@ -1,20 +0,0 @@

1−+++

2−title = "vita"

3−shortcode = "~nodmyn-dosrux/vita"

4−license = "MIT"

5−image = "https://bwyl.nyc3.digitaloceanspaces.com/vita%2Fvita.png"

6−bgColor = "#F2F2F2"

7−developer = "Assembly Capital"

8−website = "https://github.com/assemblycapital/vita"

9−description = "monitor your app distributions"

10−+++

11−

12−### Keep track of your app distributions

13−

14−To get downloads, `:vita` periodically scrys %cs /subs for each desk and caches the results.

15−

16−`:vita` accepts foreign pokes attesting to activity on a desk.

17−`/lib/vita-client.hoon` helps any agent send vita activity pokes.

18−It sends a maximum of one poke per day, and allows users to opt-in / opt-out depending on developer preference.

19−

20−Read full documentation on the [Github repository](https://github.com/assemblycapital/vita).

content/applications/~norsyr-torryn/canvas.mddeleted−29

@@ -1,29 +0,0 @@

1−+++

2−title = "canvas"

3−shortcode = "~dister-norsyr-torryn/canvas"

4−license = "MIT"

5−image = "https://yosoyubik.fra1.digitaloceanspaces.com/canvas/tile.svg"

6−bgColor = "#3787B9"

7−developer = "~norsyr-torryn"

8−website = "https://github.com/yosoyubik/canvas"

9−description = "Collaborative Pixel Art"

10−+++

11−

12−### Collaborative Pixel Art

13−

14−

15−

16−#### Features

17−- Each stroke is stored automatically on your Urbit.

18−- Export Canvas Images as SVG.

19−- Image files are stored on S3 Storage, if configured.

20−- Allows creation of public or private canvases.

21−- Others can join a public canvas and work collaboratively in a cool art project.

22−

23−#### Access

24−Search for ~dister-norsyr-torryn in Grid to find the Canvas app, and install it from there

25−

26−A public canvas is hosted at: ~picsel-norsyr-torryn/public

27−

28−

29−Come and join the group to share your creations and see what others are doing: ~norsyr-torryn/canvas

content/applications/~paldev/face.mddeleted−13

@@ -1,13 +0,0 @@

1−+++

2−title = "face"

3−developer = "~paldev"

4−shortcode = "~paldev/face"

5−description = "see your friends"

6−license = "MIT"

7−website = "https://pal.dev/suite/face"

8−bgColor = "#3b5998"

9−+++

10−

11−Face is an image rolodex of your urbit friends. Compatible with [pals](/applications/~paldev/pals), face lets you share a photo of yourself with mutuals and also see a gallery of their faces. To share, enter an image link in the url field.

12−

13−

content/applications/~paldev/fafa.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "fafa"

3−developer = "~paldev"

4−shortcode = "~paldev/fafa"

5−description = "2fa otp authenticator app"

6−license = "MIT"

7−website = "https://pal.dev/suite/fafa"

8−bgColor = "#1a1a2a"

9−+++

10−

11−

12−Fafa is a two-factor authentication app. Log in to your saved accounts with a one-time passcode generated on your urbit. (Only access this app over a secure connection and remember to also save your backup codes somewhere secure.)

13−

14−

content/applications/~paldev/pals.mddeleted−15

@@ -1,15 +0,0 @@

1−+++

2−title = "pals"

3−shortcode = "~paldev/pals"

4−developer = "~paldev"

5−description = "friendlist for peer discovery"

6−license = "MIT"

7−website = "https://pal.dev/suite/pals"

8−bgColor = "#99D3BD"

9−+++

10−

11−Pals is a contact list for your urbit friends. Send and receive friend requests with intuitive ease. Once you're pals, a smiley face icon indicates mutual status.

12−

13−

14−

15−Keep track of who your pals are or how you know them with tags, which exist mostly for your own book-keeping, but could be used in the future by other applications to group content. Similarly, some apps work better with pals, like [rumors](/applications/~paldev/rumors), an anonymous gossip app, and [sphinx](/applications/~nocsyx-lassul/sphinx), an Urbit search engine.

content/applications/~paldev/picture.mddeleted−13

@@ -1,13 +0,0 @@

1−+++

2−title = "picture"

3−developer = "~paldev"

4−shortcode = "~paldev/picture"

5−description = "a picture frame for the garden"

6−license = "MIT"

7−website = "https://pal.dev/suite/picture"

8−bgColor = "#DDDDDD"

9−+++

10−

11−Picture is a digital frame for your urbit. Simply upload an image to see it every time you open up Landscape. (Refrain from uploading huge images to avoid memory pressure.)

12−

13−

content/applications/~paldev/rumors.mddeleted−15

@@ -1,15 +0,0 @@

1−+++

2−title = "rumors"

3−shortcode = "~paldev/rumors"

4−developer = "~paldev"

5−description = "anonymous gossip from friends of friends"

6−license = "MIT"

7−website = "https://pal.dev/suite/rumors"

8−bgColor = "#bb77dd"

9−+++

10−

11−Rumors is an anonymous gossip feed powered by [pals](/applications/~paldev/pals). The more mutuals you have, the more rumors you'll see: messages posted by your pals, and their pals, populate the feed.

12−

13−

14−

15−Built using a p2p gossip protocol, rumors anonymizes posts and orders them chronologically. Drop links, ask questions, lurk, or whisper secrets into the void …

content/applications/~paldev/scooore.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "sc'o're"

3−developer = "~paldev"

4−shortcode = "~paldev/scooore"

5−description = "leaderboard for groups' ['o']s, as seen on tv!"

6−license = "MIT"

7−image ="https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/scooore.svg"

8−website = "https://pal.dev/suite/scooore"

9−bgColor = "#FDFF54"

10−+++

11−

12−A leaderboard of your peers' emoji reactions in Groups.

13−

14−

content/applications/~paldev/verse.mddeleted−13

@@ -1,13 +0,0 @@

1−+++

2−title = "verse"

3−developer = "~paldev"

4−shortcode = "~paldev/verse"

5−description = "a random Bible verse, every day"

6−license = "MIT"

7−website = "https://pal.dev/suite/verse"

8−bgColor = "#EEEEDD"

9−+++

10−

11−Verse displays a random Bible verse. Whenever you open Landscape, a new daily passage awaits.

12−

13−

content/applications/~pocwet/docs.mddeleted−17

@@ -1,17 +0,0 @@

1−+++

2−title = "Docs"

3−developer = "~pocwet"

4−shortcode = "~pocwet/docs"

5−description = "User and developer documentation for Urbit apps"

6−license = "MIT"

7−website = "https://github.com/tinnus-napbus/docs-app"

8−bgColor = "#FBCF44"

9−image = "https://m.tinnus-napbus.xyz/pub/books.svg"

10−+++

11−

12−

13−Docs is an Urbit app for documenting other Urbit apps - it finds docs in other desks and displays them for users and deveopers to browse.

14−

15−

16−

17−The docs folder contains the source of the app, and the docs-dev folder contains the files necessary for including docs in your app. Note that the files in docs-dev are symlinked, so the'll need to be copied with cp -rL or equivalent.

content/applications/~pocwet/straw.mddeleted−13

@@ -1,13 +0,0 @@

1−+++

2−title = "Straw"

3−developer = "~pocwet"

4−shortcode = "~pocwet/straw"

5−description = "Vote on what to publish."

6−license = "MIT"

7−website = "https://urbit.org"

8−bgColor = "#6C6973"

9−image = ""

10−+++

11−

12−

13−This app lets group members vote on whether a post is published to a notebook. It is intended for use with Studio, which you can install from ~tirrel/studio.

content/applications/~ribben-donnyl/funes-notes.mddeleted−15

@@ -1,15 +0,0 @@

1−+++

2−title = "Funes Notes"

3−shortcode = "~ribben-donnyl/funes-notes"

4−license = "MIT"

5−image = "https://is4-ssl.mzstatic.com/image/thumb/Purple112/v4/64/64/8b/64648bfc-02b2-b955-6230-b86af334b6b1/AppIcon-0-1x_U007emarketing-0-10-0-85-220.png/230x0w.webp"

6−bgColor = ""

7−developer = "~ribben-donnyl"

8−website = "https://funes.app"

9−description = "Mobile notetaking application using urbit as a back-end."

10−+++

11−

12−Funes Notes is a mobile notetaking application [available for iOS](https://apps.apple.com/us/app/funes-notes/id1627315560), using urbit's `%graph-store` as a backend.

13−

14−

15−Initial development funded by the Urbit Foundation via [Urbit Notes](https://urbit.org/grants/urbit-notes) proposal grant.

content/applications/~sitden-sonnet/channel.mddeleted−20

@@ -1,20 +0,0 @@

1−+++

2−title = "Channel"

3−shortcode = "~sitden-sonnet/channel"

4−license = "REKT"

5−image = "https://s3.us-east-1.amazonaws.com/haddefsigwen1/reciprocal/2022.7.09..22.54.53-channel.png"

6−bgColor = "#000000"

7−developer = "Quartus Co., Reciprocal Ltd."

8−website = "https://reciprocal.ltd"

9−description = "A distributed imageboard platform, with love"

10−+++

11−

12−### An imageboard platform, with love

13−

14−Developed as a collaboration between the Quartus Corporation and [Reciprocal Ltd.](https://reciprocal.ltd), Channel is an imageboard platform that leverages graph-store to allow any ship on the Urbit network to create and manage their own imageboard.

15−

16−

17−

18−Incoming posts have their authors scrambled with a per-ship, per-installation SHA-256 salt and thus get rotated into a "tripcode comet" visible when viewing the graph outside the interface. The interface by default hides all authors.

19−

20−Board owners can ban ships (using their rotated names), delete threads, and ban words and URLs, as well as assign janitors. You can even connect two boards using Quartus' Orca tool to syndicate posts across boards.

content/applications/~sogryp-dister-dozzod-dozzod/groups.mddeleted−40

@@ -1,40 +0,0 @@

1−+++

2−title = "Groups"

3−shortcode = "~sogryp-dister-dozzod-dozzod/groups"

4−license = "MIT"

5−image = "https://bootstrap.urbit.org/icon-groups.svg"

6−bgColor = "#EFF0F4"

7−developer = "Tlon"

8−website = "https://github.com/tloncorp/landscape-apps"

9−description = "Groups is a decentralized platform that integrates with Talk, Notebook, and Gallery for a full, communal suite of tools."

10−+++

11−

12−Start, host, and cultivate communities. Own your communications, organize your resources, and share documents. Groups is a decentralized platform that integrates with Talk, Notebook, and Gallery for a full, communal suite of tools.

13−

14− <video autoPlay muted loop playsInline>

15− <source

16− src="https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/groups-create-a-group.webm"

17− type="video/webm"

18− />

19− </video>

20−

21−Teams, clubs, DAOs, and secret societies use Groups to digitally congregate, using channel integrations to extend their capabilities.

22−

23− <video autoPlay muted loop playsInline>

24− <source

25− src="https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/groups-create-a-channel.webm"

26− type="video/webm"

27− />

28− </video>

29−

30−Write, edit, and publish longform or shorter documents with Notebook, a basic text editor for announcements, internal meeting minutes, blogs, and everything in between.

31−

32− <video autoPlay muted loop playsInline>

33− <source

34− src="https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/notebooks.webm"

35− type="video/webm"

36− />

37− </video>

38−

39−

40−Gather links to images, articles, and web pages to maintain a collection of references with Gallery, a versatile and interoperable repository for day-to-day digital trawling.

content/applications/~sogryp-dister-dozzod-dozzod/talk.mddeleted−21

@@ -1,21 +0,0 @@

1−+++

2−title = "Talk"

3−shortcode = "~sogryp-dister-dozzod-dozzod/talk"

4−license = "MIT"

5−image = "https://bootstrap.urbit.org/icon-talk.svg"

6−bgColor = "#2B5DC0"

7−developer = "Tlon"

8−website = "https://github.com/tloncorp/landscape-apps"

9−description = "Talk is a decentralized chat app that integrates with Groups, Notebook, and Gallery for a full, communal suite of tools."

10−+++

11−

12−Send peer-to-peer direct messages to one or many friends. Talk is a simple chat tool for catching up, getting work done, and everything in between.

13−

14− <video autoPlay muted loop playsInline>

15− <source

16− src="https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/talk.webm"

17− type="video/webm"

18− />

19− </video>

20−

21−Start threads. React with emojis. Respond to your Groups chat channels from Talk. When integrated with Groups, both direct messages and team chats appear in Talk. Two apps in one place.

content/applications/~sortug/gate.mddeleted−27

@@ -1,27 +0,0 @@

1−+++

2−title = "Gate"

3−shortcode = "~dister-dozzod-sortug/gate"

4−license = "MIT"

5−image = "https://s3.sortug.com/img/fav.png"

6−bgColor = "#000000"

7−developer = "Sortug Development"

8−website = "https://sortug.com"

9−description = "Seamless QR login"

10−+++

11−

12−# Secure, seamless login for Urbit

13−

14−Let's make joining Urbit easier!

15−

16−Why do this?

17−

18−When you can do this?

19−

20−

21−Logging in to any Urbit app requires you to input your ship's URL and the `+code` generated on dojo. This requires people to login to their ship's terminal, output the code on dojo, then copy and paste it in their browser or app. This is bad enough if you have a ship running locally, but if you have it running remotely (as is common) the process becomes seriously annoying.

22−

23−Mainstream mobile apps such as Signal handle first login much more seamlessly; after registration is done, further logins are done via QR code. The app produces a QR code, you scan it, and that's it. That's the state-of-the-art, battle-tested user experience for modern applications. Now available on Urbit.

24−

25−Gate makes it easier for newcomers to use Urbit, and greatly enhances the user experience of native applications, desktop and mobile, that Urbit deserves.

26−

27−Users can login to Urbit just by scanning a QR code, receive a URL link and login to an Urbit ship instantly by clicking on it. That simple. Most importantly, hosting providers can use Gate to send a QR code or a URL link to a user, and have the user access his Urbit apps with a simple camera scan or click of a link, making the onboarding process much easier for non-technical users.

content/applications/~sortug/trill.mddeleted−27

@@ -1,27 +0,0 @@

1−+++

2−title = "Trill"

3−shortcode = "~dister-dozzod-sortug/trill"

4−license = "MIT"

5−image = "https://s3.urbit.cloud/img/trill-logo.png"

6−bgColor = "#000000"

7−developer = "Sortug Development"

8−website = "https://sortug.com"

9−description = "Urbit Native Microblog"

10−+++

11−

12−### Your own social feed, forever.

13−

14−Urbit is a networked personal server. It is the ideal stack to host a microblog service.

15−

16−For years Urbit users have been busy chatting to each other, coordinating to build the network. But it is time that we lay back a little and just post at our leisure.

17−

18−Trill is an Urbit native microblog. You can post text or media links into your feed, make threads, and share it with your friends and followers. You can also build a timeline of your favorite Urbit users, and keep lists of users, categorized as you want.

19−

20−Unlike other microblogs, however, users of Trill truly own their feed. Users host their own content. They can even program it; tinker with the source as much as you want.

21−

22−There are no ads in Trill, no "trends", no analytics. We don't even know how many people are using Trill. And we don't care. We just want to trill. Please join the party.

23−

24−### More information

25−You can install the app by searching for ~dister-dozzod-sortug on your Grid interface, or by running `|install ~dister-dozzod-sortug %trill` in Dojo.

26−

27−The official group of the app is at ~hoster-dozzod-sortug/trill on the Groups app.

content/applications/~sortug/ufa.mddeleted−27

@@ -1,27 +0,0 @@

1−+++

2−title = "Urbit Feed Aggregator"

3−shortcode = "~dister-dozzod-sortug/ufa"

4−license = "MIT"

5−image = "https://s3.urbit.cloud/img/lan.png"

6−bgColor = "#000000"

7−developer = "Sortug Development"

8−website = "https://sortug.com"

9−description = "Bring all the web into Urbit"

10−+++

11−

12−### Own your content, share it with your friends

13−

14−Urbit is your personal server. Why do you want a personal server? Many things. But one of them, part of the initial vision of Urbit's development, was to use to interact programatically with the Web. To interact with Web services, but in your own terms. Using your chosen frontend, blocking all tracking, telemetry, analytics and other malicious code. Urbit as an API aggregator.

15−

16−The Urbit Feed Aggregator (aka UFA) makes that vision true. Now you will be able to browse the best content on the internet, but really own it, like people used to own books, magazines and newspapers. Control, curate, save and share your the content you like, with complete freedom.

17−

18−UFA is not just an app, it's a platform to which a myriad apps will be added in the future. As of present (August 2022) UFA includes support for Trill (our sister app, the Urbit native microblog) and Twitter. You can read and keep lists of Twitter content without having to login to Twitter.com, and you can save and share that content inside Urbit, via the Trill or Groups apps.

19−

20−### More information

21−You can install the app by searching for ~dister-dozzod-sortug on your Grid interface, or by running `|install ~dister-dozzod-sortug %ufa` in Dojo.

22−

23−The official group of the app is at ~hoster-dozzod-sortug/ufa on the Groups app.

24−

25−You can also follow ~sortug on Trill for announcements.

26−

27−Within 2022 RSS, Instagram and Email support will be added. For the future, the sky is the limit. If you want to help create a new plugin for UFA, please contact us at the official group.

content/applications/~tiller-tolbus/membrane.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "Membrane"

3−shortcode = "~mister-master-tiller-tolbus/membrane"

4−license = "MIT"

5−image = "https://tiller-tolbus.nyc3.digitaloceanspaces.com/membrane.png"

6−bgColor = ""

7−developer = "~tiller-tolbus"

8−website = ""

9−description = "Spreadsheets and databases"

10−+++

11−

12−### Membrane is a spreadsheet tool for Urbit

13−

14−Spreadsheets were the original tool for the productivity power user, so it is only fitting that we bring them to Urbit. Keep a budget, run a formula, and share your sheets with friends using Membrane.

content/applications/~tirrel/scene.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "Scene"

3−shortcode = ""

4−license = ""

5−image = "https://tirrel.io/assets/scene-logo-stroke.svg"

6−bgColor = "rgb(0, 0, 0)"

7−developer = "Tirrel Corp."

8−website = "https://tirrel.io"

9−description = "The new Urbit desktop, by ~tirrel corp."

10−+++

11−

12−

13−

14−[Download scene here](https://tirrel.io/scene/index.html).

content/applications/~tirrel/studio.mddeleted−21

@@ -1,21 +0,0 @@

1−+++

2−title = "Studio"

3−shortcode = "~tirrel/studio"

4−license = ""

5−image = "https://tirrel.io/assets/stool.svg"

6−bgColor = "rgb(160, 226, 167)"

7−developer = "Tirrel Corp."

8−website = "https://tirrel.io"

9−description = "Tools for making money."

10−+++

11−

12−### Studio is a publishing tool for Urbit

13−

14−

15−

16−Need a personal website, fast? Studio can set one up in under a minute. For writers, Studio connects you with your legacy-web audience, even if they’re not on Urbit yet. With a click, you can share your newsletter or blog via auto-generated blog or email distribution list

17−

18−Studio pulls content from your Groups notebooks. Notebooks from any group you own will appear.

19−

20−If you need any help, we’re always available in our group: ~tirrel/tirrel-support

21−

content/applications/~worpet-bildet/portal.mddeleted−16

@@ -1,16 +0,0 @@

1−+++

2−title = "Portal"

3−shortcode = "~worpet-bildet/portal"

4−license = ""

5−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/portal.svg"

6−bgColor = "rgb(0,0,0)"

7−developer = ""

8−website = ""

9−description = "Portal is the front page"

10−+++

11−

12−### Portal is the front page for urbit

13−

14−Portal made its debut as the solution to decentralized discovery on Urbit. Portal enables anyone on Urbit to curate content, apps, and groups for other ships to discover

15−

16−

content/apprenticeships.mddeleted−38

@@ -1,38 +0,0 @@

1−+++

2−title = "Become an Apprentice"

3−date = "2023-01-04"

4−weight = 1

5−description = "Everything you need to know about applying for an apprenticeship"

6−+++

7−

8−Apprenticeships are practical learning opportunities for new Urbit developers provided by experienced members of the Urbit development community. As an apprentice, you'll have the opportunity to:

9−

10−- Learn from an experienced Urbit contributor

11−- Make helpful contributions to an active project, and

12−- Earn address space for learning

13−

14−Becoming an apprentice is easily one of the best ways to level up your skills, and perhaps even land a job.

15−

16−## Get started

17−

18−Apprenticeships are for those that are new to Urbit development (or an area of it), and would like to find their grounding by working on a pre-existing codebase and problem set. Nearly all apprenticeships involve some degree of Hoon work, so you should make sure that you've completed [Hoon School](https://developers.urbit.org/guides/core/hoon-school) and [App School](https://developers.urbit.org/guides/core/app-school/intro) in either their asychronous or [cohort formats](https://developers.urbit.org/courses) prior to signing up.

19−

20−To become an apprentice, [apply for an open apprenticeship](/grants?program=apprenticeship&open=true&wip=false&completed=false#view-grants)

21−

22−Although some apprenticeships are posted on this site to be claimed, more often than not they emerge out of a conversation between a mentor and an enthusiastic potential apprentice. This is because mentors are generally busy engineering, and while they know many things that need to be done, getting those ideas into writing is difficult.

23−

24−## How it works

25−

26−Once a mentor has written up an apprenticeship, and approved an apprentice, The Urbit Foundation will perform a quick KYC step and send contracts to all parties for signing. Once those contracts are executed, work can proceed.

27−

28−Mentors and apprentices work together by having weekly pairing sessions and maintaining an open line of communication over Urbit. It's expected that mentors put at least two hours per week into supporting their apprentice.

29−

30−## Funding

31−

32−Apprenticeships pay 1 star upon the sucessful completion of the apprenticeship, for an apprenticeship of a duration of up to three months.

33−

34−## Getting Paid

35−

36−When you have completed the scope of your grant, you will create a detailed writeup of the work completed and your learnings, share the writeup with your mentor, and get your approval of completion. After recieving this approval from your mentor, please [submit an invoice here](https://airtable.com/shrXXCs1uaxtNSBcg). Your mentor must also contact `~marfun-pacpet` to confirm completion of the apprenticeship and approve the payment. Once the Urbit Foundation receives approval from your champion and an invoice for the amount agreed upon in your grant or milestone, the Foundation will pay your star allocation to the Ethereum address you have provided.

37−

38−We approve and issue payments within 30 days of invoice receipt and approval, although often payment is made more quickly. If you have any questions regarding getting paid or submitting an invoice, please contact `~marfun-pacpet` for assistance.

content/articles/2022-09-24_urbit-courts-daos-crypto.mddeleted−10

@@ -1,10 +0,0 @@

1−+++

2−title = "Urbit Courts DAOs, Crypto Teams in Quest to Make Internet P2P Again"

3−publication = "Coindesk"

4−author = "March Hochstein and Daniel Kuhn"

5−date = "2022-09-24"

6−URL = "https://www.coindesk.com/layer2/2022/09/24/urbit-courts-daos-crypto-teams-in-push-to-make-internet-p2p-again/"

7−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/coindesk.jpg"

8−+++

9−

10−A wildly ambitious project to reinvent the entire internet computing stack is finally shipping usable apps after a decade-plus of laying groundwork. Can it overcome a “janky” UX?

content/articles/2022-09-24_urbit-is-web3-weird-and-wonderful.mddeleted−10

@@ -1,10 +0,0 @@

1−+++

2−title = "Urbit Is Web3, Weird and Wonderful and I Don’t Care Who Made It"

3−publication = "Coindesk"

4−author = "March Hochstein"

5−date = "2022-09-24"

6−URL = "https://www.coindesk.com/layer2/2022/09/24/urbit-is-web3-weird-and-wonderful-and-i-dont-care-who-made-it/"

7−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/coindesk.jpg"

8−+++

9−

10−Software can have bugs, but it doesn’t have cooties.

content/articles/2022-09-28_college-course-on-urbit.mddeleted−10

@@ -1,10 +0,0 @@

1−+++

2−title = "Why Would Anyone Take a College Course on Urbit?"

3−publication = "Coindesk"

4−author = "Daniel Kuhn"

5−date = "2022-09-28"

6−URL = "https://www.coindesk.com/layer2/2022/09/28/why-would-anyone-take-a-college-course-on-urbit/"

7−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/coindesk.jpg"

8−+++

9−

10−Neal Davis taught the first graduate-level seminar on the controversial computing platform Urbit. Here’s why.

content/articles/2022-09-29_assembly-miami-dispatch.mddeleted−11

@@ -1,11 +0,0 @@

1−+++

2−title = "Urbit Assembly: If We’re All Here, Who’s Watching The Internet?"

3−publication = "Zora Zine"

4−author = "Madeline Cash"

5−date = "2022-09-29"

6−URL = "https://zine.zora.co/urbit-assembly-miami-dispatch"

7−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/zorazine.png"

8−+++

9−

10−Forever Magazine founder and Zora Zine contributor Madeline Cash reports on secret societies, subjective idealism, and digital intimacy in her dispatch from Urbit Assembly in Miami

11−

content/articles/2022-09-29_the-dream-of-digital-homesteading.mddeleted−10

@@ -1,10 +0,0 @@

1−+++

2−title = "The Dream of Digital Homesteading"

3−publication = "Compact"

4−author = "Geoff Schullenberger"

5−date = "2022-09-29"

6−URL = "https://compactmag.com/article/the-dream-of-digital-homesteading"

7−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/compactmag.png"

8−+++

9−

10−Geoff Schullenberger attends Assembly 2022 and chronicles his impressions and thoughts.

content/articles/2022-10-04_a-more-beautiful-computer.mddeleted−11

@@ -1,11 +0,0 @@

1−+++

2−title = "User Error: A More Beautiful Computer"

3−publication = "Spike Art Magazine"

4−author = "Adina Glickstein"

5−date = "2022-10-04"

6−URL = "https://www.spikeartmagazine.com/?q=articles/user-error-more-beautiful-computer"

7−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/spike-logo-text.jpg"

8−+++

9−

10−From Dimes Square to the Network State, new frontiers are in the making. Adina Glickstein attends Urbit Assembly and considers the politics of tech-augmented exit.

11−

content/articles/2022-10-13_my-weekend-with-the-martians.mddeleted−10

@@ -1,10 +0,0 @@

1−+++

2−title = "My Weekend With the Martians"

3−publication = "Astra"

4−author = "Ruby Sutton"

5−date = "2022-10-13"

6−URL = "https://astra-mag.com/articles/my-weekend-with-the-martians/"

7−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/astra.png"

8−+++

9−

10−At the Assembly, a conference of Urbit denizens, Ruby Sutton discovers a community of eccentrics who dare to dream of a different internet.

content/articles/2022-10-23_three-things.mddeleted−10

@@ -1,10 +0,0 @@

1−+++

2−title = "Three Things #40: October 23, 2022"

3−publication = "Three Things"

4−author = "Lane Rettig"

5−date = "2022-10-23"

6−URL = "https://rettig.substack.com/p/three-things-40-october-23-2022"

7−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/3things40.jpg"

8−+++

9−

10−Lane Rettig outlines three unique aspects of Urbit in an attempt to answer the eternal question "What is Urbit?"

content/articles/2023-02-20_trailblazing-urbit-startup-makes-earth-shaking-acquisition.mddeleted−10

@@ -1,10 +0,0 @@

1−+++

2−title = "Trailblazing Urbit Startup Makes Earth Shaking Acquisition"

3−publication = "Globe Newswire"

4−author = "Globe Newswire"

5−date = "2023-02-20"

6−URL = "https://www.globenewswire.com/en/news-release/2023/02/20/2611391/0/en/Trailblazing-Urbit-Startup-Makes-Earth-Shaking-Acquisition.html"

7−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/globe-newswire.jpeg"

8−+++

9−

10−Holium Corp closes $2.9 million in seed funding and acquires Third Earth in record pace.

content/articles/2023-05-10_urbit-a-network-older-and-weirder-than-bitcoin.mddeleted−10

@@ -1,10 +0,0 @@

1−+++

2−title = "Urbit, a Network Older and Weirder Than Bitcoin, Finally Turns Toward Growth"

3−publication = "Coindesk"

4−author = "Bradley Keoun"

5−date = "2023-05-10"

6−URL = "https://www.coindesk.com/tech/2023/05/10/urbit-a-network-older-and-weirder-than-bitcoin-finally-turns-toward-growth/"

7−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/coindesk.jpg"

8−+++

9−

10−The peer-to-peer network started in 2002 says it's taking on "MEGACORP," much in the same vein as many blockchain networks. A bit more fun are the "secret code names" that users are assigned.

content/audits.mddeleted−22

@@ -1,22 +0,0 @@

1−+++

2−title = "Audits"

3−date = "2021-10-10"

4−weight = 1

5−description = "Urbit Security Audits"

6−+++

7−

8−Confidence and trust are fundamental to Urbit's ethos. The strength of our smart contract protocols are regularly scrutinized for potential vulnerabilities and enhanced when weaknesses are identified.

9−

10−To that end, we continue to maintain a robust security protocol. Our smart contracts are generally healthy and secure, but the process of auditing is never fully complete. As our ecosystem evolves, our security protocols evolve with it.

11−

12−Since transparency is an integral feature of trust, we've made our security audits publicly available. Please refer to the below documents for a more thorough analysis.

13−

14−### Security Audits

15−

16−- [Ames Networking Protocol Review](<https://storage.googleapis.com/media.urbit.org/site/audits/Tlon.io%20-%20Urbit%20AMES%20Networking%20Protocol%20Review%20Final%20Report%20(1).pdf>), Leviathan, November 2020

17−- [Urbit Constitution Audit](https://storage.googleapis.com/media.urbit.org/site/audits/Urbit%20Constitution%20Audit%20-%20OpenZeppelin.pdf), OpenZepplin, September 2021

18−- [Urbit Constitution JS Library Audit](https://storage.googleapis.com/media.urbit.org/site/audits/Urbit%20Constitution%20JS%20Audit.pdf), bloctrax, July 2018

19−- [Urbit Constitution JS Library Code Review](https://storage.googleapis.com/media.urbit.org/site/audits/Urbit%20Constitution%20JS%20Library%20Report%20-%20December%202018%20Review.pdf), bloctrax, December 2018

20−- [Urbit Keygen JS Library Report](https://storage.googleapis.com/media.urbit.org/site/audits/Urbit%20Keygen%20JS%20Library%20Report.pdf), bloctrax, September 2018

21−- [Urbit Keygen JS Library Report, 2nd Review](https://storage.googleapis.com/media.urbit.org/site/audits/Urbit%20Keygen%20JS%20Library%20Report%20-%20Second%20Review%20with%20Resolutions.pdf), bloctrax, November 2018

22−- [Urbit Security Audit](https://storage.googleapis.com/media.urbit.org/site/audits/Urbit%20Security%20Audit.pdf), bloctrax, June 2018

content/bitcoin.mddeleted−125

@@ -1,125 +0,0 @@

1−+++

2−title = "Bitcoin Development on Urbit"

3−+++

4−

5−### Overview

6−

7−Urbit OS currently ships with our Bitcoin wallet, %btc-wallet, released in 2021,

8−and our Lightning implementation, %volt, is almost ready for live use on the network. Several integrations with the app ecosystem are planned immediately following its release, including subscription publishing, social payments, and more.

9−

10−**The Urbit Advantage**

11−

12−- Composability: Modular userspace applications expose a consistent API format to each other locally and over the network, making seamless integration of Lightning payments, Taro assets, and other protocols easy

13−- Networking and identity: Exactly-once message delivery, NAT traversal, and E2E encryption come built into Urbit's P2P protocol, and Urbit identities are sybil-resistant, human-readable network addresses bound to BIP32 extended public keys

14−- Efficient, secure development: Urbit OS is strictly typed and purely functional, and apps have reproducible builds on all client machines, removing much of the complexity, risk, and pain points from development

15−

16−**Getting Involved**

17−

18−Interested in contributing to or supporting Bitcoin development on Urbit? GitHub repos for individual projects and information on the Urbit Foundation grant program are linked below, and dedicated Urbit groups and Bitcoin node operators on Urbit are listed in the Community section. You can also reach out to current contributors ~tondes-sitrym and ~pindet-timmut on Urbit or at urbitcoin@protonmail.com.

19−

20−### Wallet

21−

22−Urbit's Bitcoin wallet consists of two agents: %btc-provider, which communicates with an external full node; and %btc-wallet, which handles transaction generation and signing, and uses a %btc-provider instance (on the same ship or elsewhere on the Urbit network) to broadcast transactions and receive data from the Bitcoin network.

23−

24−Wallet users can receive payments using the xpub associated with their Urbit ID, allowing Bitcoin payments to be sent between ships with a persistent, human-readable network address without compromising on-chain privacy.

25−

26−**Resources**

27−

28−GitHub

29−

30−- Agents: [https://github.com/urbit/urbit/tree/master/pkg/bitcoin](https://github.com/urbit/urbit/tree/master/pkg/bitcoin)

31−- UI: [https://github.com/urbit/urbit/tree/master/pkg/btc-wallet](https://github.com/urbit/urbit/tree/master/pkg/btc-wallet)

32−- Provider utilities: [https://github.com/urbit/urbit-bitcoin-rpc](https://github.com/urbit/urbit-bitcoin-rpc)

33−

34−Writeups

35−

36−- Grant proposal: [https://urbit.org/grants/bitcoin-full-node-provider-and-wallet](https://urbit.org/grants/bitcoin-full-node-provider-and-wallet)

37−- Architecture document: [https://gist.github.com/jalehman/e0c91071427ca4c349c0673f376945cb](https://gist.github.com/jalehman/e0c91071427ca4c349c0673f376945cb)

38−- Provider setup guide: [https://subject.network/posts/pi-fullnode-urbit/#bitcoind](https://subject.network/posts/pi-fullnode-urbit/#bitcoind)

39−

40−

41−**Continuing Work**

42−

43−The current %btc-wallet implementation is not a modern BIP-157/158 light client. While users who depend on another ship's %btc-provider/full node for communication with the Bitcoin network do not risk loss of on-chain funds, their lack of visibility on the network will be more problematic for those also using it with Lightning. Funding is available for developers interested in contributing: reach out to the Urbit Foundation, ~tondes-sitrym on Urbit, or urbitcoin@protonmail.com.

44−

45−### Lightning

46−

47−Volt, Urbit's Lightning implementation, like our Bitcoin wallet consists of two agents: %volt, the primary agent that manages channels, payments, invoices, and chain monitoring; and %volt-provider, which connects to an external LND node for handling payments with endpoints outside the Urbit network.

48−

49−All Volt nodes will run %volt, and be able to operate channels with Urbit peers without maintaining an LND instance or depending on another ship that does. To transact with non-Urbit Lightning peers, and in the short term (see below) to perform multi-hop payments inside Urbit, they will need to open a channel with a node that uses %volt-provider to connect with LND. Chain monitoring likewise requires connecting to a local or remote %btc-provider agent (see Wallet above). For more details on the network architecture, see the grant proposal linked below.

50−

51−Volt implements BOLTs 2, 3, 5, and 11, and in the near future will add onion routing (variants on BOLTs 4 and 7). Because %ames, Urbit's networking module, already handles transport, guarantees required message delivery properties, and furnishes persistent, unique 'domain names', implementation of BOLTs 1, 8, and 9 is unnecessary for Volt nodes.

52−

53−Beta release of Volt is planned for the end of 2022, and additional features including multi-hop/onion routing implementation are proposed for completion by mid-2023.

54−

55−**Resources**

56−

57−GitHub: [https://github.com/dasrun-fadben/volt/tree/on-chain](https://github.com/dasrun-fadben/volt/tree/on-chain)

58−

59−Initial grant proposal and spec: [https://urbit.org/grants/volt-lightning-on-urbit](https://urbit.org/grants/volt-lightning-on-urbit)

60−

61−Proposal for further work: [https://urbit.org/grants/lightning-development](https://urbit.org/grants/lightning-development)

62−

63−**Continuing Work**

64−

65−The primary element currently missing from Volt is onion routing of multi-hop payments for full privacy and efficiency of payments to and from nodes that don't also operate LND. This has been partially specified in the second proposal linked above: funding and collaborators are available for this as well as work described there on application integrations, submarine swaps, and more, so interested developers should take a look and get in touch.

66−

67−### Roadmap

68−

69−**2022**

70−

71−- *Volt Beta Release*

72−Final work on channel sweeps, remaining safety checks, and UI development is currently ongoing and expected to be complete by EOY 2022.

73−

74−**2023**

75−

76−- *Initial Ecosystem Integrations*

77− - Submarine swaps: Implementation of the PeerSwap protocol, fallback use of the Loop API, and UI targeted at merchant use-cases. Funded, expected completion in spring 2023.

78− - Apps: Integration of Lightning subscription and one-time paygates into Groups, social payments and %volt-provider discovery with %pals, and app tipjar module. Specified and proposed for grant funding.

79−- *Lightning Routing*

80−Payments with multiple intra-Urbit hops and via multiple %volt-provider channels are the last remaining component for full-featured and private payments with Volt. Specified and proposed for grant funding.

81−- *Wallet Improvements*

82−Work on feature, security, and UI upgrades for the Bitcoin wallet and node provider, aimed at making the application a full-featured and BIP157/158-compliant light client, should begin before EOY 2023.

83−

84−**Future**

85−

86−- *Taro Implementation*

87−Implementation of Taproot Asset Representation Overlay, with an initial focus on using nonfungible Taro assets to represent credentials, permissions, and reputation of Urbit identities.

88−- *Atomic Streaming Payments*

89− - Integration of Volt payments with streaming apps like %radio and the Holium WebRTC client via HTLC-DASH or similar implementation.

90− - Generic protocol for non-media pay-to-stream data

91−

92−### Grants

93−

94−The Urbit Foundation operates a grant program aimed at new Urbit developers, network public goods, and community development. Work on the Bitcoin wallet, Lightning implementation, and submarine swaps for Volt (Urbit Lightning) users all has received funding from UF, and interesting non-technical proposals with social value to the network are also considered.

95−

96−Grants homepage: [https://urbit.org/grants](https://urbit.org/grants)

97−

98−Past Bitcoin-related grants

99−

100−- [https://urbit.org/grants/bitcoin-full-node-provider-and-wallet](https://urbit.org/grants/bitcoin-full-node-provider-and-wallet)

101−- [https://urbit.org/grants/volt-lightning-on-urbit](https://urbit.org/grants/volt-lightning-on-urbit)

102−- [https://urbit.org/grants/lightning-development](https://urbit.org/grants/lightning-development)

103−

104−## Bitcoiners on Urbit

105−

106−### Groups

107−

108−Urbitcoiners: ~pindet-timmut/urbitcoiners

109−

110−### Providers

111−

112−**Bitcoin Full Nodes**

113−

114−~tirrel

115−~zod

116−

117−**Lightning Nodes**

118−

119−~tondes-sitrym

120−~bosdys

121−

122−### Guides

123−

124−Running %btc-provider with a full node on Raspberry Pi: [https://subject.network/posts/pi-fullnode-urbit/](https://subject.network/posts/pi-fullnode-urbit/)

125−

content/blog/2019-10-3-roadmap.md+15−16

@@ -1,12 +1,8 @@

1+++

1+++

2title = "~2019.10 Roadmap"

2title = "~2019.10 Roadmap"

3−date = "2019-10-02"

3+date = 2019-10-03

4description = "Galen Wolfe-Pauly on the road ahead for the identity/OS/interface/community stack."

4description = "Galen Wolfe-Pauly on the road ahead for the identity/OS/interface/community stack."

5−aliases = [

6− "/posts/essays/2019-10-3-roadmap",

5+aliases = ["/posts/essays/2019-10-3-roadmap", "/posts/2019-10-3-roadmap"]

7− "/posts/2019-10-3-roadmap"

8−]

9−

10[extra]

6[extra]

11author = "Galen Wolfe-Pauly"

7author = "Galen Wolfe-Pauly"

12ship = "~ravmel-ropdyl"

8ship = "~ravmel-ropdyl"

@@ -19,21 +15,21 @@ The daily work of building a new OS from scratch is so engaging and exciting tha

19

15

20It’s a good thing I have a recurring reminder to write these updates. While our focus is on the future, it’s good to get a sense of the rate that we’re moving forward, and to let everyone know what’s been going on. We’ve made great progress over the past few months.

16It’s a good thing I have a recurring reminder to write these updates. While our focus is on the future, it’s good to get a sense of the rate that we’re moving forward, and to let everyone know what’s been going on. We’ve made great progress over the past few months.

21

17

22−We’ve got a new interface, Urbit 0.8.0, Hoon School, and a grants program among lots of other updates. We’ll go into detail about all of these, and talk a bit about where we’re headed next. The system is improving at a really good pace. We intend to keep it up.

18+We’ve got a new interface, Urbit 0.8.0, Hoon School, and a grants program among lots of other updates. We’ll go into detail about all of these, and talk a bit about where we’re headed next. The system is improving at a really good pace. We intend to keep it up.

23

19

24## Identity (Azimuth)

20## Identity (Azimuth)

25

21

26−The other day I got an email, clicked a link, and got a planet. A real, live, piece of cryptographic property with paper wallets and everything. It took about two minutes. And at the end, I could have easily sent invites to my friends.

22+The other day I got an email, clicked a link, and got a planet. A real, live, piece of cryptographic property with paper wallets and everything. It took about two minutes. And at the end, I could have easily sent invites to my friends.

27

23

28−This experience is part of a completely new Bridge, the interface for interacting with your Urbit identity. The beta experience we’re testing today is quite stripped down, but it’s a huge improvement over the last Bridge release. Clicking a link is a lot easier than downloading source code, running it from the command-line, and probably running into a python-related error.

24+This experience is part of a completely new Bridge, the interface for interacting with your Urbit identity. The beta experience we’re testing today is quite stripped down, but it’s a huge improvement over the last Bridge release. Clicking a link is a lot easier than downloading source code, running it from the command-line, and probably running into a python-related error.

29

25

30Getting to this point involved rewriting Bridge from scratch, figuring out how to host it securely, building infrastructure to fund the requisite transactions involved in registering a new identity, and setting up a service to send emails (and dispose of them afterward). We've also redesigned our paper wallets to make them simpler and clearer.

26Getting to this point involved rewriting Bridge from scratch, figuring out how to host it securely, building infrastructure to fund the requisite transactions involved in registering a new identity, and setting up a service to send emails (and dispose of them afterward). We've also redesigned our paper wallets to make them simpler and clearer.

31

27

32−We still want to get this new version of Bridge a bit further along before releasing it to everyone — but we’re excited about it. We didn’t quite get to the point of building an affordance for payments, which we had hoped to do, but that’s coming later.

28+We still want to get this new version of Bridge a bit further along before releasing it to everyone — but we’re excited about it. We didn’t quite get to the point of building an affordance for payments, which we had hoped to do, but that’s coming later.

33

29

34We want everyone to have an Urbit identity. And we want it to be incredibly easy to get one, so we’ll get Bridge out this month with a new urbit.org (more on that below).

30We want everyone to have an Urbit identity. And we want it to be incredibly easy to get one, so we’ll get Bridge out this month with a new urbit.org (more on that below).

35

31

36−The other area of identity-related work was Sigils — the algorithmically generated images that go with every Urbit identity. (We’ve got a blog post in the works that covers how we created these, which is a good story that needs to be told.) The original version of Sigils didn’t look very good at small sizes and a few collisions were found (thanks to [urbit.live](https://urbit.live) for helping to discover the collisions). The [new, improved sigils](https://github.com/urbit/sigil-js) have no collisions and look great at small sizes.

32+The other area of identity-related work was Sigils — the algorithmically generated images that go with every Urbit identity. (We’ve got a blog post in the works that covers how we created these, which is a good story that needs to be told.) The original version of Sigils didn’t look very good at small sizes and a few collisions were found (thanks to [urbit.live](https://urbit.live) for helping to discover the collisions). The [new, improved sigils](https://github.com/urbit/sigil-js) have no collisions and look great at small sizes.

37

33

38**Q4 2019**

34**Q4 2019**

39

35

@@ -46,6 +42,7 @@ The other area of identity-related work was Sigils — the algorithmically gener

46

42

47- Integrate Bridge with a native app for Arvo

43- Integrate Bridge with a native app for Arvo

48

44

45+

49## OS (Arvo)

46## OS (Arvo)

50

47

51As a team, we want Urbit to be our primary computer, our last computer, our permanent computer. And we want this now — or at least as soon as we possibly can. We’re both ambitious and impatient.

48As a team, we want Urbit to be our primary computer, our last computer, our permanent computer. And we want this now — or at least as soon as we possibly can. We’re both ambitious and impatient.

@@ -54,13 +51,13 @@ The frustration that we can’t move onto Urbit today propels us forward. The sy

54

51

55We’re very nearly to the point that all the kernel-level code in the system has been written by our current team. The one remaining vane that deserves a rewrite (Gall) has had a major cleanup by Jared just recently. The [Ship of Theseus](https://en.wikipedia.org/wiki/Ship_of_Theseus) approach does appear to be working. The infrastructure team is doing fantastic work and has really deepened their ownership of the system. The Urbit of today is on the road to becoming a great piece of system software.

52We’re very nearly to the point that all the kernel-level code in the system has been written by our current team. The one remaining vane that deserves a rewrite (Gall) has had a major cleanup by Jared just recently. The [Ship of Theseus](https://en.wikipedia.org/wiki/Ship_of_Theseus) approach does appear to be working. The infrastructure team is doing fantastic work and has really deepened their ownership of the system. The Urbit of today is on the road to becoming a great piece of system software.

56

53

57−The biggest infrastructure-level milestone was the release of [Urbit 0.8.0](https://github.com/urbit/urbit/releases/tag/v0.8.0). We introduced a new process-separation architecture, implemented the correct bootstrap sequence, moved to LMDB for persistence, replaced our http vane (%eyre) and moved to Nix for our build system.

54+The biggest infrastructure-level milestone was the release of [Urbit 0.8.0](https://github.com/urbit/urbit/releases/tag/v0.8.0). We introduced a new process-separation architecture, implemented the correct bootstrap sequence, moved to LMDB for persistence, replaced our http vane (%eyre) and moved to Nix for our build system.

58

55

59−To put it simply, Arvo is now much more stable and durable. During the beginning of the year we were seeing bugs and instability that were frustrating and unacceptable. While there are still issues on the live network, none of them terrify us much. We also implemented the ability for users to ‘individually breach’, which means that you can now reset your Urbit without waiting for us to reset the network.

56+To put it simply, Arvo is now much more stable and durable. During the beginning of the year we were seeing bugs and instability that were frustrating and unacceptable. While there are still issues on the live network, none of them terrify us much. We also implemented the ability for users to ‘individually breach’, which means that you can now reset your Urbit without waiting for us to reset the network.

60

57

61### Landscape (Arvo UI)

58### Landscape (Arvo UI)

62

59

63−We don’t just build infrastructure for others to develop on top of. We build interfaces too. At the top of the stack, we released a completely new Landscape, the interface for Arvo. This new interface makes it possible to build other ‘modules’ for Arvo that go beyond chat and publishing.

60+We don’t just build infrastructure for others to develop on top of. We build interfaces too. At the top of the stack, we released a completely new Landscape, the interface for Arvo. This new interface makes it possible to build other ‘modules’ for Arvo that go beyond chat and publishing.

64

61

65This new Landscape is a complete departure from the last direction. Your Urbit now has a simple home screen that launches individual modules and it’s [relatively easy](https://github.com/urbit/create-landscape-app) to create new ones. We’re all enjoying using Landscape around the office. It’s still a bit of a prototype — but it’s quite a good one, I think.

62This new Landscape is a complete departure from the last direction. Your Urbit now has a simple home screen that launches individual modules and it’s [relatively easy](https://github.com/urbit/create-landscape-app) to create new ones. We’re all enjoying using Landscape around the office. It’s still a bit of a prototype — but it’s quite a good one, I think.

66

63

@@ -81,9 +78,10 @@ This version of Landscape is, I think, the last one that we’ll call a prototyp

81

78

82**Q1 2020**

79**Q1 2020**

83

80

84−- Integrated client with Bridge and Arvo

81+- Integrated client with Bridge and Arvo

85- New interface framework, codenamed ‘Widescreen’

82- New interface framework, codenamed ‘Widescreen’

86

83

84+

87## Docs + Community

85## Docs + Community

88

86

89We had quite a bit of interest in our second session of Hoon School. We ended up with 150 people enrolled in Hoon 101, and 42 in 201. The 101 session just ended, with a lot of positive responses and feedback from the participants. We learned a lot doing it and got quite a bit of interesting new example code.

87We had quite a bit of interest in our second session of Hoon School. We ended up with 150 people enrolled in Hoon 101, and 42 in 201. The 101 session just ended, with a lot of positive responses and feedback from the participants. We learned a lot doing it and got quite a bit of interesting new example code.

@@ -103,10 +101,11 @@ We also did some experimentation with holding events on Arvo. We held weekly AMA

103- Vane level documentation

101- Vane level documentation

104- An active grant program

102- An active grant program

105

103

104+

106## urbit.org

105## urbit.org

107

106

108Urbit.org is about ready for a refresh — so we’re in the process of rebuilding it. We have, for a long time, told the story of Urbit by describing the system technically. We think Urbit can be explained much more simply and much more concisely. We’re working to put together a new set of materials in this direction.

107Urbit.org is about ready for a refresh — so we’re in the process of rebuilding it. We have, for a long time, told the story of Urbit by describing the system technically. We think Urbit can be explained much more simply and much more concisely. We’re working to put together a new set of materials in this direction.

109

108

110We’d also like to populate urbit.org with a lot more content about what we’re working on and thinking about. We do a reasonable job of writing updates, but many of our projects get released without any background info. Tlon and the Urbit community are full of smart, thoughtful people — and we’d like to do a lot more to surface their work. We plan to close out the year with both a new website and a lot of writing about what we’ve been building. Not everyone wants to read the source code!

109We’d also like to populate urbit.org with a lot more content about what we’re working on and thinking about. We do a reasonable job of writing updates, but many of our projects get released without any background info. Tlon and the Urbit community are full of smart, thoughtful people — and we’d like to do a lot more to surface their work. We plan to close out the year with both a new website and a lot of writing about what we’ve been building. Not everyone wants to read the source code!

111

110

112−That covers it for now. If you have questions or want to chat — find us in `~dopzod/urbit-help`. See you online!

111+That covers it for now. If you have questions or want to chat — find us in `~dopzod/urbit-help`. See you online!

content/blog/2019-5-roadmap.md+3−4

@@ -1,9 +1,8 @@

1+++

1+++

2title = "~2019.5 Roadmap"

2title = "~2019.5 Roadmap"

3−date = "2019-05-15"

3+date = 2019-05-16

4description = "Where we are and where we're going as of mid-2019."

4description = "Where we are and where we're going as of mid-2019."

5−aliases = [ "/posts/essays/2019-5-roadmap", "/posts/2019-5-roadmap" ]

5+aliases = ["/posts/essays/2019-5-roadmap", "/posts/2019-5-roadmap"]

6−

7[extra]

6[extra]

8author = "Galen Wolfe-Pauly"

7author = "Galen Wolfe-Pauly"

9ship = "~ravmel-ropdyl"

8ship = "~ravmel-ropdyl"

@@ -30,7 +29,7 @@ It’s true. Azimuth is operational, secure, and well tested. It’s a pretty co

30

29

31So the question is why haven’t we told the world about it?

30So the question is why haven’t we told the world about it?

32

31

33−I tend to think that in order for a technology to succeed it has to not only be an important technical innovation, it also has to be easy to understand as a product. And that’s our answer: we’ve undersold Azimuth because we want it to be easier to understand by _using_, not just by reading the code. Azimuth is quite an elegant piece of technology — but that doesn’t matter until it has a great user experience to match.

32+I tend to think that in order for a technology to succeed it has to not only be an important technical innovation, it also has to be easy to understand as a product. And that’s our answer: we’ve undersold Azimuth because we want it to be easier to understand by *using*, not just by reading the code. Azimuth is quite an elegant piece of technology — but that doesn’t matter until it has a great user experience to match.

34

33

35That’s why, in the near term, we’re focused on building on top of Azimuth ourselves. We can’t ask others to go down roads if we haven’t already been down them.

34That’s why, in the near term, we’re focused on building on top of Azimuth ourselves. We can’t ask others to go down roads if we haven’t already been down them.

36

35

content/blog/2020-to-2021.md+6−2

@@ -1,16 +1,19 @@

1+++

1+++

2title = "2020 -> 2021"

2title = "2020 -> 2021"

3description = "Reflecting and looking forward."

3description = "Reflecting and looking forward."

4−date = "2021-01-20"

4+date = 2021-01-21

5−

6[extra]

5[extra]

7author = "Josh Lehman"

6author = "Josh Lehman"

8ship = "~wolref-podlex"

7ship = "~wolref-podlex"

9image = "https://media.urbit.org/site/posts/essays/arch-sunrise-2.jpeg"

8image = "https://media.urbit.org/site/posts/essays/arch-sunrise-2.jpeg"

10+++

9+++

11

10

11+<br>

12+

12

13

13

14

15+<br>

16+

14In this post, which has been adapted from our most recent [newsletter](https://urbit.us11.list-manage.com/subscribe/post?u=972a03db9e0c6c25bb58de8c8&id=be143888d2), we'll take a moment to reflect on the events of the last year, and then turn our attention to the next one.

17In this post, which has been adapted from our most recent [newsletter](https://urbit.us11.list-manage.com/subscribe/post?u=972a03db9e0c6c25bb58de8c8&id=be143888d2), we'll take a moment to reflect on the events of the last year, and then turn our attention to the next one.

15

18

16## 2020

19## 2020

@@ -40,6 +43,7 @@ Growth in Urbit’s developer community has been growing organically in lockstep

40

43

41My strategy to date has been heavily focused on working directly with contributors to provide technical guidance and direction, and it’s been working really well. To that end I’ll also be scaling our ability to provide such support by bringing more individuals into urbit.org that can mentor, review work, and provide guidance on where to best direct contributors' energy.

44My strategy to date has been heavily focused on working directly with contributors to provide technical guidance and direction, and it’s been working really well. To that end I’ll also be scaling our ability to provide such support by bringing more individuals into urbit.org that can mentor, review work, and provide guidance on where to best direct contributors' energy.

42

45

46+

432021 is shaping up to be a big year for Urbit, and we'd [love your help](https://grants.urbit.org) in building it. If you want to see what we're working on in real time, join us in Landscape at ~wolref-podlex/foundation.

472021 is shaping up to be a big year for Urbit, and we'd [love your help](https://grants.urbit.org) in building it. If you want to see what we're working on in real time, join us in Landscape at ~wolref-podlex/foundation.

44

48

45See you on the network!

49See you on the network!

content/blog/20200929-state-of-urbit.md+11−4

@@ -1,19 +1,22 @@

1+++

1+++

2title = "Late 2020 Progress Update: OS 1 -> OS 1.N"

2title = "Late 2020 Progress Update: OS 1 -> OS 1.N"

3−date = "2020-09-28"

3+date = 2020-09-29

4description = "When we announced OS 1, in April, we started to disappear into Urbit. Since then, we’ve been living on Urbit like we never have before."

4description = "When we announced OS 1, in April, we started to disappear into Urbit. Since then, we’ve been living on Urbit like we never have before."

5−

6[extra]

5[extra]

7author = "Galen Wolfe-Pauly"

6author = "Galen Wolfe-Pauly"

8ship = "~ravmel-ropdyl"

7ship = "~ravmel-ropdyl"

9−image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/state-of-urbit-1.jpg"

8+image ="https://storage.googleapis.com/media.urbit.org/site/posts/essays/state-of-urbit-1.jpg"

10+++

9+++

11

10

11+<br>

12+

12

13

13

14

15+<br>

16+

14When we announced OS 1, in April, we started to disappear into Urbit. Since then, we’ve been living on Urbit like we never have before. This has been our goal for years: to mature the system we’re building by becoming its first committed users. We knew that critical step toward Urbit’s maturity was being able to depend on it ourselves, but the system itself had to mature to the point that we could do that practically.

17When we announced OS 1, in April, we started to disappear into Urbit. Since then, we’ve been living on Urbit like we never have before. This has been our goal for years: to mature the system we’re building by becoming its first committed users. We knew that critical step toward Urbit’s maturity was being able to depend on it ourselves, but the system itself had to mature to the point that we could do that practically.

15

18

16−We’ve done this in fits and starts. We’ve _tried_ and failed a few times over the years. We’ve always _used_ Urbit to some extent, but we’ve never _relied_ on it. These past six months have been different. I can’t tell whether it was out of sheer determination and commitment, or that the system was just genuinely ‘there’. Either way, both Tlon and the Urbit Community genuinely live on Urbit now.

19+We’ve done this in fits and starts. We’ve *tried* and failed a few times over the years. We’ve always *used* Urbit to some extent, but we’ve never *relied* on it. These past six months have been different. I can’t tell whether it was out of sheer determination and commitment, or that the system was just genuinely ‘there’. Either way, both Tlon and the Urbit Community genuinely live on Urbit now.

17

20

18In a way, our ability to use Urbit day to day doesn’t make sense. When we shipped OS 1, it was full of holes. There were serious performance, stability, and reliability issues. Plenty of people showed up and thought, ‘I don’t understand why you think this is useful.’ But, it was good enough that we wanted to use it. And since we wanted to use it, we put our energy into making it better like we hadn’t ever before. Being able to use a system that you can really trust is a wonderful feeling. It’s Computing Without Compromises.

21In a way, our ability to use Urbit day to day doesn’t make sense. When we shipped OS 1, it was full of holes. There were serious performance, stability, and reliability issues. Plenty of people showed up and thought, ‘I don’t understand why you think this is useful.’ But, it was good enough that we wanted to use it. And since we wanted to use it, we put our energy into making it better like we hadn’t ever before. Being able to use a system that you can really trust is a wonderful feeling. It’s Computing Without Compromises.

19

22

@@ -23,6 +26,7 @@ The tl;dr is that Urbit is much faster, more reliable, and nicer to use than it

23

26

24Anyway, let’s walk through the details. We’ll talk about our infrastructure and interface work independently, since that’s how we organize things internally. Then we’ll talk a bit about what’s going on on the network.

27Anyway, let’s walk through the details. We’ll talk about our infrastructure and interface work independently, since that’s how we organize things internally. Then we’ll talk a bit about what’s going on on the network.

25

28

29+

26### Infrastructure

30### Infrastructure

27

31

28

32

@@ -39,6 +43,7 @@ We also rewrote a large part of our runtime in Haskell and made overall progress

39

43

40The network is stable, fast, and safe from day to day. We’re pretty confident it can grow quite a bit without serious issues. When we shipped OS 1 we really weren’t sure what we could handle. Now we’re standing on much more solid ground.

44The network is stable, fast, and safe from day to day. We’re pretty confident it can grow quite a bit without serious issues. When we shipped OS 1 we really weren’t sure what we could handle. Now we’re standing on much more solid ground.

41

45

46+

42### Interface

47### Interface

43

48

44

49

@@ -55,6 +60,7 @@ Those two are by far the most significant, but there’s so much more. We [rewro

55

60

56And I almost forgot [Leap](https://github.com/urbit/urbit/pull/3231): an omnibox for navigating around OS 1 with the keyboard. We have plans to make Leap much more powerful — but it’s a great first start toward making OS 1 keyboard accessible. I almost exclusively use [Leap](https://upload.wikimedia.org/wikipedia/commons/0/06/Canon_Cat_keyboard.jpg) to get around OS 1 these days.

61And I almost forgot [Leap](https://github.com/urbit/urbit/pull/3231): an omnibox for navigating around OS 1 with the keyboard. We have plans to make Leap much more powerful — but it’s a great first start toward making OS 1 keyboard accessible. I almost exclusively use [Leap](https://upload.wikimedia.org/wikipedia/commons/0/06/Canon_Cat_keyboard.jpg) to get around OS 1 these days.

57

62

63+

58### Community + network

64### Community + network

59

65

60

66

@@ -65,6 +71,7 @@ Getting onto Urbit is still relatively challenging. By the standards of software

65

71

66Turns out, there are plenty of people who are up for running Urbit themselves and quite a few small communities have sprouted around the network. Overall the network has a fun, cozy feeling. It’s nice.

72Turns out, there are plenty of people who are up for running Urbit themselves and quite a few small communities have sprouted around the network. Overall the network has a fun, cozy feeling. It’s nice.

67

73

74+

68### What’s next

75### What’s next

69

76

70We’re still more or less flat-out, full speed ahead into an even better Urbit-world. The seeds of change were planted when we made Josh the [interim technical director of urbit.org](https://urbit.org/blog/first-steps-towards-urbit-org/). Urbit itself is getting close to the point where the separation between Urbit and Tlon has to become more real. Urbit is aimed at being an ubiquitous platform, Tlon is aimed at making it as usable and useful as possible.

77We’re still more or less flat-out, full speed ahead into an even better Urbit-world. The seeds of change were planted when we made Josh the [interim technical director of urbit.org](https://urbit.org/blog/first-steps-towards-urbit-org/). Urbit itself is getting close to the point where the separation between Urbit and Tlon has to become more real. Urbit is aimed at being an ubiquitous platform, Tlon is aimed at making it as usable and useful as possible.

content/blog/20201119-models-of-society.md+16−4

@@ -1,15 +1,14 @@

1+++

1+++

2title = "Models of Society"

2title = "Models of Society"

3description = "Conversations compose society. What composes conversation — how do we digitize it in a way that enhances society without imposing upon it? How do we form this new medium, both to facilitate natural human behavior and to inspire the best of it?"

3description = "Conversations compose society. What composes conversation — how do we digitize it in a way that enhances society without imposing upon it? How do we form this new medium, both to facilitate natural human behavior and to inspire the best of it?"

4−date = "2020-11-18"

4+date = 2020-11-19

5−

6[extra]

5[extra]

7author = "Tyler Shuster"

6author = "Tyler Shuster"

8ship = "~radbur-sivmus"

7ship = "~radbur-sivmus"

9image = "https://media.urbit.org/site/posts/essays/cochno-stone.png"

8image = "https://media.urbit.org/site/posts/essays/cochno-stone.png"

10+++

9+++

11

10

12−_I had used Facebook and Google for my entire adult life. I knew they were toxic but I didn't know why. For a few weeks I tried to create a website that would scrape data from Facebook’s API and push data back, puppetting it from my own server. But as I stared headlong into the ever-shifting darkness of the modern web, I despaired and abandoned my attempt. Less than a year later I heard about Urbit. Technically, it went way over my head&mdash;but socially I knew exactly what it was, what it always had to be, why it was a discovery and not an invention, a place and not a product. I've watched the settlers there for four years, only just now using the opportunity of the pandemic to swim to this new landscape and gaze upon this young nation, this digital city, this urbis ec bit. I do not work for Tlon. I just live here._

11+*I had used Facebook and Google for my entire adult life. I knew they were toxic but I didn't know why. For a few weeks I tried to create a website that would scrape data from Facebook’s API and push data back, puppetting it from my own server. But as I stared headlong into the ever-shifting darkness of the modern web, I despaired and abandoned my attempt. Less than a year later I heard about Urbit. Technically, it went way over my head&mdash;but socially I knew exactly what it was, what it always had to be, why it was a discovery and not an invention, a place and not a product. I've watched the settlers there for four years, only just now using the opportunity of the pandemic to swim to this new landscape and gaze upon this young nation, this digital city, this urbis ec bit. I do not work for Tlon. I just live here.*

13

12

14<hr>

13<hr>

15

14

@@ -17,8 +16,12 @@ All people like to talk. Society is built by talking. In this&mdash;the year of

17

16

18## Modes of Messaging

17## Modes of Messaging

19

18

19+<br>

20+

20

21

21

22

23+<br>

24+

22In general, technology serves humanity as a kind of appendage&mdash;instead of thinking new thoughts or acting on its own, it does what we command. Technology never creates new social structures&mdash;it merely makes existing ones easier, or it facilitates the creation of new ones. We use our tools to expand our capacities, and once we are capable of doing more, we can imagine new things to do. Inventing the wheel did not invent motorized transportation&mdash;but it did facilitate it and it was a necessary step, even an inspirational one. Similarly, the invention of writing made new forms of human interaction and new tools for organization possible.

25In general, technology serves humanity as a kind of appendage&mdash;instead of thinking new thoughts or acting on its own, it does what we command. Technology never creates new social structures&mdash;it merely makes existing ones easier, or it facilitates the creation of new ones. We use our tools to expand our capacities, and once we are capable of doing more, we can imagine new things to do. Inventing the wheel did not invent motorized transportation&mdash;but it did facilitate it and it was a necessary step, even an inspirational one. Similarly, the invention of writing made new forms of human interaction and new tools for organization possible.

23

26

24Consider the following conversational conventions, or modes of messaging: a letter; a dialogue; a book; a meeting; minutes of that meeting. These are each pieces of technology: finely constrained solutions to human problems. Now, we have digital forms of each of these which diverge variously from the original. A letter becomes an email. A dialogue becomes a chat room, or a series of blog posts, or a twitter spat. A book becomes a website or an ebook. Meetings in 2020 have virtually been replaced by their virtual counterparts. Minutes become recordings or transcripts.

27Consider the following conversational conventions, or modes of messaging: a letter; a dialogue; a book; a meeting; minutes of that meeting. These are each pieces of technology: finely constrained solutions to human problems. Now, we have digital forms of each of these which diverge variously from the original. A letter becomes an email. A dialogue becomes a chat room, or a series of blog posts, or a twitter spat. A book becomes a website or an ebook. Meetings in 2020 have virtually been replaced by their virtual counterparts. Minutes become recordings or transcripts.

@@ -40,8 +43,12 @@ Having an indistinct sense of place makes the form of conversation ambiguous and

40

43

41## People in Places

44## People in Places

42

45

46+<br>

47+

43

48

44

49

50+<br>

51+

45As the internet grew to accommodate new conversation forms using the basic substrate of hypertext, web developers began to conceive of "digital spaces" through analogy&mdash;chat "rooms" and "forums,” or the "silo" and the "walled garden." Today, most of our conversation takes place in these walled gardens&mdash;privately-owned places which may be beautiful on the inside, but inaccessible from elsewhere. While some of these walled gardens are very large, our conversation is essentially confined to them. There is no roaming from one space to another while keeping one’s identity. We create new identities for new spaces both because we must and because we are afraid of repercussions on one platform for what we say on another. This is because we do not own our identity; we merely have a key&mdash;our password. The owners of the walled garden still own the artifacts of our tenure there, and can revoke our access to them at any time.

52As the internet grew to accommodate new conversation forms using the basic substrate of hypertext, web developers began to conceive of "digital spaces" through analogy&mdash;chat "rooms" and "forums,” or the "silo" and the "walled garden." Today, most of our conversation takes place in these walled gardens&mdash;privately-owned places which may be beautiful on the inside, but inaccessible from elsewhere. While some of these walled gardens are very large, our conversation is essentially confined to them. There is no roaming from one space to another while keeping one’s identity. We create new identities for new spaces both because we must and because we are afraid of repercussions on one platform for what we say on another. This is because we do not own our identity; we merely have a key&mdash;our password. The owners of the walled garden still own the artifacts of our tenure there, and can revoke our access to them at any time.

46

53

47The concept of identity and the concept of place are fundamentally linked. We imagine the prince who travels overseas where no one knows his name, or we imagine the old prospect of traveling to a new world to make a fortune. While those both exemplify a dramatic change in identity and place, we usually want to keep our identity consistent. We want to be recognized by friends whichever place we go, and we all strive toward having a good reputation, which is a consistent identity across places. This consistent identity also allows control of that reputation per place. A man is not judged in public by the words he says among friends. And there is no way to search what someone has said except by asking him. With our current system of identity providers (an absurd term, but a real one), we surrender our rights to selectively expose our thoughts, regardless of the place they have been uttered. A data breach or a weak password might lay bare our most private thoughts. We run the real risk of being confronted by an old conversation presented out of context or after we have learned better.

54The concept of identity and the concept of place are fundamentally linked. We imagine the prince who travels overseas where no one knows his name, or we imagine the old prospect of traveling to a new world to make a fortune. While those both exemplify a dramatic change in identity and place, we usually want to keep our identity consistent. We want to be recognized by friends whichever place we go, and we all strive toward having a good reputation, which is a consistent identity across places. This consistent identity also allows control of that reputation per place. A man is not judged in public by the words he says among friends. And there is no way to search what someone has said except by asking him. With our current system of identity providers (an absurd term, but a real one), we surrender our rights to selectively expose our thoughts, regardless of the place they have been uttered. A data breach or a weak password might lay bare our most private thoughts. We run the real risk of being confronted by an old conversation presented out of context or after we have learned better.

@@ -52,8 +59,13 @@ In theory, we would have a digital city with unique regions, public fora, and so

52

59

53## Urbis ec Bit

60## Urbis ec Bit

54

61

62+

63+<br>

64+

55

65

56

66

67+<br>

68+

57Urbit does solve this underlying problem. At this point the explanation goes so far down the stack that you could spend years tracing it all, but the relevant part is this: Urbit is not an empire; it’s a territory. An empire is an entangling of land and rule: within the bounds of said empire, you agree to be bound by its laws and the penalties for transgression. The laws exist at the whim of a despot or cabal. Your standing as a Roman citizen buys you no favors in Persia. In contrast, a territory imposes only physical laws. For example, in the desert, you will die faster. The only way to change that is to alter the desert. Urbit imposes nothing but the digital equivalent of physical laws. You have an identity which can be said to be truly yours, and you have a piece of software that runs on whatever computer you choose and can do anything you want with the messages sent to your identity. There are no social protocols enforced, because no one can control what software you run on your computer. As long as you agree to communicate using the same basic substrate, you can communicate with anyone using Urbit. This is the digital equivalent of speaking the same language. Whether or not others will accept you into their coalitions is not the technology's concern.

69Urbit does solve this underlying problem. At this point the explanation goes so far down the stack that you could spend years tracing it all, but the relevant part is this: Urbit is not an empire; it’s a territory. An empire is an entangling of land and rule: within the bounds of said empire, you agree to be bound by its laws and the penalties for transgression. The laws exist at the whim of a despot or cabal. Your standing as a Roman citizen buys you no favors in Persia. In contrast, a territory imposes only physical laws. For example, in the desert, you will die faster. The only way to change that is to alter the desert. Urbit imposes nothing but the digital equivalent of physical laws. You have an identity which can be said to be truly yours, and you have a piece of software that runs on whatever computer you choose and can do anything you want with the messages sent to your identity. There are no social protocols enforced, because no one can control what software you run on your computer. As long as you agree to communicate using the same basic substrate, you can communicate with anyone using Urbit. This is the digital equivalent of speaking the same language. Whether or not others will accept you into their coalitions is not the technology's concern.

58

70

59In the same way that the land provides clay and timber, Urbit also provides the tools and material for building places both public and private. These include the aforementioned consistent message substrate (content), as well as tools for organizing people/audiences, structure for referencing other content, and an identity system that is owned only by you while being verified by all. The places are being built&mdash;private rooms with just a few people, meeting halls, club houses, huge public spaces, and countless personal encounters, the contents of which are known to none but the participants.

71In the same way that the land provides clay and timber, Urbit also provides the tools and material for building places both public and private. These include the aforementioned consistent message substrate (content), as well as tools for organizing people/audiences, structure for referencing other content, and an identity system that is owned only by you while being verified by all. The places are being built&mdash;private rooms with just a few people, meeting halls, club houses, huge public spaces, and countless personal encounters, the contents of which are known to none but the participants.

@@ -62,4 +74,4 @@ The default tools work with messages in a few of the ways with which we've grown

62

74

63Similar to working undeveloped land, it takes a lot of hard work, which is why Urbit is not ready for mainstream adoption yet, and why I alluded to the idea of settlers in my opening paragraph. Traveling to the new world is not for everyone, but everyone is welcome.

75Similar to working undeveloped land, it takes a lot of hard work, which is why Urbit is not ready for mainstream adoption yet, and why I alluded to the idea of settlers in my opening paragraph. Traveling to the new world is not for everyone, but everyone is welcome.

64

76

65−_How could one do other than submit to Tlön, to the minute and vast evidence of an orderly plant? It is useless to answer that reality is also orderly. Perhaps it is, but in accordance with divine laws&mdash;I translate: inhuman laws&mdash;which we never quite grasp. Tlön is surely a labyrinth, but it is a labyrinth devised by men, a labyrinth destined to be deciphered by men._

77+*How could one do other than submit to Tlön, to the minute and vast evidence of an orderly plant? It is useless to answer that reality is also orderly. Perhaps it is, but in accordance with divine laws&mdash;I translate: inhuman laws&mdash;which we never quite grasp. Tlön is surely a labyrinth, but it is a labyrinth devised by men, a labyrinth destined to be deciphered by men.*

content/blog/2021-11-18-report-from-the-field.mddeleted−94

@@ -1,94 +0,0 @@

1−+++

2−title = "Report from the field: Assembly 2021"

3−date = "2021-11-18"

4−description = "The system builds the community and the community builds the system."

5−[extra]

6−author = "Galen Wolfe-Pauly"

7−ship = "~ravmel-ropdyl"

8−image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/galen-at-assembly.JPG"

9−+++

10−

11−

12−

13−Before Assembly I committed to write a ‘recap’ post for everyone who couldn’t make it. Originally I figured this post would be an opportunity to walk through the list of things that we shipped and showed off in Austin. But it turns out that the most important thing about Assembly was simply the way it felt to be there.

14−

15−I’m not sure it’s possible to really do the feeling in the room justice, but I’m going to try. Then I’ll get into the announcements and happenings for those of you who couldn’t make it.

16−

17−But first, a quick note:

18−

19−We ran Assembly under the [Chatham House rule](https://en.wikipedia.org/wiki/Chatham_House_Rule). Basically, you can talk about what happens at Assembly—but you can’t name anyone.

20−

21−I’ve run many of our Urbit events this way because I think it puts people at ease. Everyone in the room can just relax, connect with one another, and hang out without worrying about being named on the internet.

22−

23−I’ll try to abide by the Chatham rule in this post which is why no one is named specifically.

24−

25−

26−

27−New world energy -

28−

29−In the months leading up to Assembly we were totally focussed on using the event as a release date for a bunch of different lines of work. Coming out of that sprint, we didn’t really know what to expect. We wanted to make sure Urbit was ready for people to build on and that everything we were going to ship worked well. What we didn’t realize was just how emphatically people are *ready to build*.

30−

31−When I got up on stage on Friday night to welcome everyone I was really impressed by the room itself. It was packed with people who looked excited and motivated. The room just looked amazing. There were so many different kinds of people staring back at me. Some who I recognized from the earliest days of the project, and lots I had never seen before. I’ve been at my share of Urbit events, but this was something totally different.

32−

33−We didn’t have much scheduled during Assembly. Most of the time was unstructured to allow for freeform discussion, sunbathing on the lawn, and gathering at picnic tables. The panels that we did schedule will go down in history. Panelists discussed questions about creators, escaping reward systems, and the role of DAOs from governance to governments. There was hard money with a computer on it, Moloch shoes, community members grabbing the mic, and a talk written two hours before it was delivered about the relationship between centralization and decentralization when it comes to UX that blew our minds.

34−

35−I spent the weekend of Assembly in almost constant conversation with people building Urbit hardware, experimenting with different kinds of Urbit software, and thinking about incredible things like a Nock chip. I talked to the lead architect of a CPU from the 90s, a former senior US government official, an editor of a well-known literary magazine, the inventor of a new display technology, musicians whose work I already admired, a fragrance designer, writers, and, of course, lots of engineers and designers from many different backgrounds. Data scientists, systems hackers, language nerds, someone running a successful currency. I watched these people get projects off the ground, start raising money, plan the future of Urbit hosting companies, and plan new features for Landscape. I saw a last-minute warehouse party come together that kept people talking well into the early hours of the morning.

36−

37−Where did these people come from? All over the place. They have this incredible *new world energy*. They understand immediately, intuitively that Urbit has the potential to be a foundation for the society they want to live in. I’ve never seen anything like it.

38−

39−This energy seems to have come from the very practical work we do day-to-day: building Urbit, refining it, making it easier to use. The crowd at Assembly was somehow brought together by Urbit itself. It’s insanely exciting. It makes working on Urbit feel even more like a form of definite optimism. The system builds the community and the community builds the system.

40−

41−

42−

43−Urbit is ready to be built upon -

44−

45−Sometime in early 2021 we realized that there were many lines of work converging on a single theme: ‘Urbit is ready to be built upon’. This is the spirit we wanted to bring to Assembly, and it was very much in the room in Austin. Some of that feeling is still lingering on the network. I think it comes from some very concrete improvements that have been made to the system.

46−

47−We’ve always wanted Urbit to be maintained by a self-sustaining ecosystem and, early this year, we could see what needed to be done to really let others begin doing so. There were four parallel projects that came together to hit this milestone: Software distribution, star.market, developer and operator guides, and the Foundation roadmap. We talked about all of these things in the Assembly keynote (which you can watch [here](https://www.youtube.com/watch?v=ywj36TUtbS4)), but let’s touch on them one by one.

48−

49−Software distribution

50−

51−The most important thing that we shipped just before Assembly is the ability to actually package and distribute software over Urbit itself. It’s now possible for someone to build an app, package it up, and share it with a friend directly over the network.

52−

53−For their friend, the experience is incredibly nice. You can simply send someone a link and they can install the app and run it themselves, on their own urbit, right away. The whole thing is peer-to-peer, of course. There’s no app store, no vetting process. It’s networked software like it’s supposed to be: people computing together freely.

54−

55−We’ve been saying for years that we want people to build on top of Urbit and we always meant it. Now it’s possible in a way it never has been before. To check it out, watch [this segment](https://www.youtube.com/watch?v=MA8sqFi8Bd8) from Assembly.

56−

57−Software distribution can get better in _a lot_ of ways, and we’re continuing to work on it. But it’s live, and people are experimenting with it already. There’s Chess, there’s Pokur, there are video calls (although they’re still a little buggy). Everyone seems to love ‘pals’ and ‘zone’—but you’ll have to get on the network to check those out.

58−

59−star.market

60−

61−We’ve always used the address space to fund our work as one of the primary Urbit developers. As Urbit has become more useful, and address space has become more expensive, it’s more and more difficult for others to do this. The community saw the need for developers to easily use their granted address space to fund their work and a higher resolution for the Foundation to fund contributions to Urbit.

62−

63−This is what [star.market](https://star.market/) and the WSTR project are for. WSTR is an ERC-20 token that is backed 1:1 by ERC-721 Urbit stars. Unlike a star, a WSTR token can be fractionally divided, allowing for a broader distribution of ownership of Urbit. WSTR was built by the community over the past couple of months with no involvement from Tlon. Tlon did, eventually, help to put together star.market—the interface for interacting with the WSTR contracts safely and securely.

64−

65−I’ve come to think that WSTR can be a powerful tool for funding new Urbit projects. I’m excited to see what both our early community of developers and operators can do with it, as well as the nascent Urbit Foundation.

66−

67−Guides

68−

69−As we make it easier for developers to build software, operators to participate in the economy, and communities to make Urbit their home, we need to improve our documentation. We always like to do things bottom-up: the product work comes first. Well, the product is now live.

70−To this end we recently launched:

71−

72−[operators.urbit.org](https://operators.urbit.org/) collects all of the information about participating in the Urbit economy, running infrastructure nodes, and participating in governance in one place.

73−

74−[developers.urbit.org](https://developers.urbit.org/) has an overhauled program for learning about Urbit as a system and beginning to develop on top of it.

75−

76−[network.urbit.org](https://network.urbit.org/) allows anyone to explore the network. View galaxy transfers or how many planets a star has spawned.

77−

78−We’ve got a lot more planned in this area of work in the coming months, and these three sites are a great start.

79−

80−Urbit Foundation

81−

82−Over these past few years we’ve operated the Urbit Foundation as a ‘protocol’ inside of Tlon. Our goal has been to develop that protocol to the point that it’s refined, working, and can run on its own outside of Tlon.

83−

84−Josh has done an exceptional job running the foundation protocol at Tlon over the last year or so. He and I have been working closely together on everything that Tlon builds, while also coordinating our community of contributors. I’m very excited that the Foundation, with Josh as its Director, is now separating from Tlon as a fully independent entity focussed on supporting the ecosystem.

85−

86−Assembly was the perfect moment to begin formally separating out the Foundation and, as of a week ago, it is an independent entity. We’ve thought long and hard about how to make the Foundation an enduring, stable organization. Josh will be the first Executive Director but, ultimately, the Senate of Galaxies will elect the Board. This will keep the Foundation accountable to the network as a whole and I’m optimistic it can work well.

87−

88−If you’re on the network, you can read more about the Foundation in ~wolref-podlex/foundation.

89−

90−Assembly 2022 -

91−

92−I had more than a few enthusiastic people come up to me at Assembly and ask what we were planning for Assembly 2022. I have absolutely no idea, of course. We poured all our energy into making Assembly 2021 a success.

93−

94−Given what I saw in Austin, I’m pretty confident that next year we’ll be in completely new territory. The goal of this project has always been to build a completely new digital world. And now, it seems to be building itself.

content/blog/2021-11-18-the-promise-and-paradox-of-decentralization.mddeleted−55

@@ -1,55 +0,0 @@

1−+++

2−title = "The Promise and Paradox of Decentralization"

3−date = "2021-11-17"

4−description = "Is centralization just a natural tendency of all networks? Are we destined to have a 'decentralization sandwich?'"

5−[extra]

6−author = ""

7−ship = "~lableg-tadrex"

8−image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/ux-centralization.JPG"

9−+++

10−

11−

12−

13−Every so often, a platform will do something outrageous—changing its terms of use, kicking off API partners, restricting [the content category it was built on](https://www.theverge.com/2018/12/3/18123752/tumblr-adult-content-porn-ban-date-explicit-changes-why-safe-mode), banning Donald Trump, failing to ban Donald Trump, etc.—and we'll all realize we're utterly dependent on centralized entities that can make arbitrary and unaccountable decisions. Sure, you can build your own minimal Facebook or Twitter clone, if you really want, but can you build your own Cloudflare? How about your own payment network? If your company does something legal in your country but banned in America, and the US decides to sanction you, which leads to local banks cutting you off because they can't survive without access to the dollar, are you going to build your own reserve currency? Your own Taiwan Semiconductor Manufacturing Co. or ASML?

14−

15−There are, to varying extents, efforts to do all of the above. But what's worth considering is that *all of these bans happen through centralized actors running on decentralized systems*. The Internet was supposed to be a totally open set of protocols that anyone could interact with, and for a long time it was, and yet getting kicked off Facebook and Twitter means being exiled from public discourse. Banks are regulated, but every country can set up their own banking regulations, and different countries see the social role of banks very differently; for some countries they're a tool of economic planning, for others a way to help connect local companies to global markets, for others a source of money that can be channeled to politically favored groups. The chip industry was historically very open to new entrants; the transistor was developed at Bell Labs, and for political reasons AT&T licensed it to all comers at a low price.

16−

17−And yet all of these originally decentralized systems end up facing some degree of centralization.

18−

19−The promise of a decentralized system is that anyone can build anything they want, because no one owns it. There are three important features of this; two downsides and a caveat:

20−

21−- The first downside to "Anyone can build anything" is that "anyone" means *anyone*, and the people to whom decentralized systems are the most attractive are the ones who are banned from other systems, often for good reasons. Free speech absolutists want to be defending Aleksandr Solzhenitsyn or Eugene V. Debs or even Lenny Bruce, but if you want to get a sense for the typical piece of content enabled by a totally uncensored communications system, check your spam folder.

22−

23−- The second downside is that a lack of ownership means that no one is responsible when things go wrong. Bitcoin doesn't have a way to censor your decision to move money from one address to another or even a protocol-level sense of whether you're buying Alpaca socks or a rocket launcher. (nb: You are almost certainly not buying a rocket launcher with Bitcoin; you are at best getting scammed, and at worst [getting in trouble](https://www.justice.gov/usao-cdca/pr/los-angeles-county-man-pleads-guilty-federal-charge-attempting-obtain-biological-toxin)). But this also means that the protocol can't tell when you meant to send your life savings to your cold wallet and sent it to the wrong address instead.

24−

25−- The caveat is that, to quote a [*Diff* piece from last year](https://www.thediff.co/p/amazon-a-new-kind-of-antitrust-risk#:~:text=does%20it%2C%20too.-,Technology-Governance%20Fit,-Pondering%20Durian%20has) ($), "[A]ny decentralized order requires a centralized substrate, and the more decentralized the approach is the more important it is that you can count on the underlying system." This applies to cryptocurrencies (you can trust the protocols) and to the Internet (ditto). It also applies, in an interesting way, to the increasingly decentralized world of free trade and free-flowing capital: money can only flow and deals can only be made if everyone has a consistent sense of property rights and contracts, and the definition of those concepts will typically be determined by whichever participant in a transaction has the more sophisticated financial and legal system. Globalization ends up being a bit like Henry Ford's pitch: you can use any economic paradigm you want, as long as it's the American one.1

26−

27−An open, decentralized system is *sparse*: there's room for anything, which means that most of the possibility space consists of nothing at all. This creates a natural demand for onramps—Coinbase for figuring out Bitcoin, portals for figuring out the Internet, TSM for turning chip designs into functioning products, and the like. These create a complicated dynamic: these onramps are built on an open system, but part of their function is to close off some of it. And the better they do that, the more value they can capture. Meanwhile, because they have a monopoly on what they've fenced off, their economics support providing a better user experience. Make a really helpful update to the Bitcoin wiki, and you can feel good about yourself and perhaps contribute to the price of Bitcoin in a highly indirect way; design and launch an improved onboarding process at Coinbase and your contribution is quantifiable, and affects your next cycle's equity grants.

28−

29−This privatization proceeds in three different ways:

30−

31−- Some companies start building on an open protocol and then slowly make it their own. Chrome's decision to make the search bar synonymous with the address bar was a slight improvement in the interface, but also a very strong statement that Google had replaced manually typing in URLs as the default way to navigate. (The strongest evidence for this is the frequency of navigational searches; [the most commonly-searched term on Google](https://www.mondovo.com/keywords/) is "Facebook" and [the most frequently searched term on Bing is "Google"](https://www.bloomberg.com/news/articles/2021-09-28/google-tells-judges-it-s-so-popular-it-s-bing-s-top-search-term).) Typing in URLs is a sometimes-decent way to find what you're looking for, though [the half-life of links is about two years](https://blog.zomdir.com/2017/10/the-half-life-of-link-is-two-year.html). But guessing at URLs can be [perilous](https://en.wikipedia.org/wiki/Whitehouse.com). No one is responsible for fixing this, but Google is the closest approximation, because what they are responsible for is solving the "look for something on the Internet and get the wrong result" problem, a different but related one from the broader task of allowing arbitrary site owners to host arbitrary content. Privatizing is effective, and solves problems for users rather than protocol designers. But it does go against the spirit of the original network.

32−

33−- Twitter is another example, except that they basically created their own open mostly-open protocol and then slowly took control of it. Tweets were originally a simple format, with 140 characters of text and a bit more metadata (this made it compatible with SMS, which had a 160-character limit). For a while, Twitter looked like it would operate a novel protocol and let third parties decide what to put on it and what to read off it. And then the company started to realize that an open system was also one where it was trivial to filter out ads and recommendations. So the outside partners gradually got cut off.

34−

35−- Facebook—the product, not the company—is a third example. It essentially implemented a missing element to the protocol: *identity matters*. When the original protocols were being hammered out, identity was a problem taken care of by the fact that getting online required steep hurdles; if everyone involved is affiliated with a university that trusts them to use a PDP-10 responsibly, spam or abuse were not big concerns. (Not that early usage was [strictly professional](https://www.theguardian.com/science/2013/apr/19/online-high-net-drugs-deal).) With billions of people online, accessing relevant information can mean traversing a graph of people rather than links, so the identities of those people becomes important. To the user, if not to the network itself, a name and relationship is a far more important unique identifier than an IP address.

36−

37−This pattern raises a question: is centralization just a natural tendency of all networks? Are we destined to have a "decentralization sandwich," where there's a hard-to-change set of protocols, something open built on top of *that*, and a series of closed systems built on top of that, which are the only ones the average person interacts with?

38−

39−One of the interesting alternatives to this is [Urbit](https://urbit.org), which is trying to build a network in which identity exists from the start, and is neither free nor monopolized. One of Urbit's principles is that users own their data, and while they can use third-party services, they're sharing their data with services, not using a login to access information that lives on someone else's servers.

40−

41−This is a nice theoretical solution to the "build your own" problem above: if someone tries to start Twitter-but-without-banning-X, they begin with "Twitter-but-it's-100%-X," which seems bad until they reach the next stage where trolls arrive and they start to learn that Online Censorship is mostly about spam and gore and only occasionally about politics. But if they're moving their data around, and their friends graph with it, then spinning up a separate instance of the same service, pulling in the same content from their friends, and whitelisting someone who's blacklisted elsewhere is a lot more feasible.

42−

43−At least at first. One of the problems with owning your own data is that it ignores the question of what format that data is in. Data formats are sometimes considered carefully, but they can also be hammered out fast to get a minimum viable product out the door. Then they evolve over time, accumulating cruft and complexity, until they might as well be encrypted.

44−

45−And indeed, what's to stop someone from having a proprietary format that's literally encrypted? Or one that gets changed to an encrypted version later on? This is not a trivial point; if you're ever in a position where you absolutely have to share some information that you want to keep secret, the smartest thing to do is share a huge amount of confusing and poorly-explained information, or use an [annoying but technically accurate format](https://www.vice.com/en/article/gv5vxb/crypto-keys-printout-of-edward-snowdens-email-service-lavabit-ladar-levison). Strict and unalterable rules are no match for determined adversaries, whether they're trying to play a prank, make a point, or maximize shareholder value.

46−

47−But the data format questions are not rhetorical: there is actually an answer of sorts, though it's a frustrating one. Software systems are not just lines of code, but the entire extended system of people who maintain, host, and build on platforms. And the norms of those communities can push back against market pressures. I've been spending an increasing amount of time around Urbit users and devs, and they really do view the current centralized model of the Internet as anathema. They are aware that the fun apps we use are all either designed to be addictive from the start or subject to relentless evolutionary pressure to get more addictive. There's a history of [norms evolving in response to new addictive behavior](https://gist.github.com/jm3/6724931). And Urbit's architecture is a lot closer to norms than to the clumsy mechanism of laws; instead of centralized services that own data, there's a set of 256 Urbit identities that can route messages between users. Instead of single points of failure, there are a few hundred fallback options; instead of the binary of on-Facebook-or-anathematized, there's a 2^8 bit gradient.

48−

49−One possibility for the successor to the current Internet is that it will end up being a system designed to support communities that achieve cohesion based on which forms of addictive or socially corrosive technology they reject. Sort of a digital version of the Amish, [not rejecting technology wholesale but carefully considering every new technology before adopting it](https://kk.org/thetechnium/amish-hackers-a/). If you assume that the pace of change in consumer-facing Internet stays high, and that it gets more compelling over time, then in the long run the only options are a) be careful what you use, or b) accept that you're outsourcing a growing share of your decisions to product managers and growth hackers who do not necessarily have your interests at heart.

50−

51−Norms are not a perfect solution to these problems (if they were, we'd only know about issues like novel addictive behaviors, monopolies, and the homogenization of entertainment from history books). And technology can't fully solve social problems. But it can certainly have an effect on them—"you can't solve a social problem with technology" is a good guideline, but technologies mitigate them all the time. What's a streetlight if not a technological solution to the social problem that there are places where it's dangerous to be out when it's dark? What's asymmetric-key cryptography if not a technological solution to the social problem that it's hard to keep secrets? There's still a fundamental tension with open systems, where they get mature enough to be useful at which point the median user's priority is getting things done rather than adhering to the network's original design principles. But a design that recognizes this from the beginning, and a community that wants to make it happen, can stave off decline for a long time. And that's the positive story of technology: we're all fighting against entropy, which is a hard fight to win, but there are long and fascinating stalemates ahead.

52−

53−(Disclosure: I'm long decentralization by way of Bitcoin and Urbit. If you're on Urbit and would like to discuss *The Diff*, go to ~lableg-tadrex/the-diff.)

54−

55−1. There is naturally some resistance to this, both because of conflicts with different countries' norms and with other countries' natural desire to determine their own destiny. So it's a leaky abstraction, but it gets less leaky over time as economies get more integrated and thus more of the world has to standardize. The most direct example of this is the fact that [the dollar's share of global invoices is 4.7x the US's share of global imports](https://www.economist.com/schools-brief/2020/08/27/global-trades-dependence-on-dollars-lessens-its-benefits) ($, *Economist*). In the same way that English is most likely to be the shared second language of any two randomly-selected people who don't speak it as a first language, the dollar is most likely to be the second most useful currency to anyone in a country that doesn't use dollars.

content/blog/a-founders-farewell.md+32−36

@@ -1,12 +1,8 @@

1+++

1+++

2title = "A Founder's Farewell"

2title = "A Founder's Farewell"

3−date = "2019-01-13"

3+date = 2019-01-14

4description = "My goal was always to fire myself at the first possible opportunity. I'm super happy to reach it."

4description = "My goal was always to fire myself at the first possible opportunity. I'm super happy to reach it."

5−aliases = [

6− "/posts/essays/a-founders-farewell",

5+aliases = ["/posts/essays/a-founders-farewell", "/posts/a-founders-farewell"]

7− "/posts/a-founders-farewell"

8−]

9−

10[extra]

6[extra]

11author = "Curtis Yarvin"

7author = "Curtis Yarvin"

12ship = "~sorreg-namtyv"

8ship = "~sorreg-namtyv"

@@ -33,7 +29,7 @@ ceased to be mine and became the world's. Urbit works; its PKI

33is on the Ethereum mainnet; it's open source; in every way,

29is on the Ethereum mainnet; it's open source; in every way,

34technical, legal, and mathematical, it is the world's.

30technical, legal, and mathematical, it is the world's.

35

31

36−(What _is_ Urbit? Please read the [primer](/primer).)

32+(What _is_ Urbit? Please read the [primer](/primer).)

37

33

38Let's talk about: why I've left; the state of Tlon; and the state

34Let's talk about: why I've left; the state of Tlon; and the state

39of Urbit. If there's any time left, we'll read some poetry.

35of Urbit. If there's any time left, we'll read some poetry.

@@ -72,7 +68,7 @@ nothing ever built before.

72

68

73Urbit in 2013 had roughly the same feature set as Slack in 2013,

69Urbit in 2013 had roughly the same feature set as Slack in 2013,

74but less polished, and decentralized. It was pretty buggy and

70but less polished, and decentralized. It was pretty buggy and

75−slow. But had we put all our resources into debugging and

71+slow. But had we put all our resources into debugging and

76optimization, it would not have taken five years.

72optimization, it would not have taken five years.

77

73

78My instinct was always that Urbit's delivery schedule should be

74My instinct was always that Urbit's delivery schedule should be

@@ -92,7 +88,7 @@ As seen from the 2019 Urbit, this is very lame indeed.

92The conventional wisdom is to ship your embarrassing "MVP." For

88The conventional wisdom is to ship your embarrassing "MVP." For

93several reasons, Urbit occupies a unique strategic position.

89several reasons, Urbit occupies a unique strategic position.

94Urbit just isn't relevant until Urbit is, if not perfect,

90Urbit just isn't relevant until Urbit is, if not perfect,

95−uniformly excellent. It can't just work. It has to work right.

91+uniformly excellent. It can't just work. It has to work right.

96Urbit has to be amazing – which is hardly a useless discipline.

92Urbit has to be amazing – which is hardly a useless discipline.

97

93

98I still did not think it would take five years to make Urbit

94I still did not think it would take five years to make Urbit

@@ -125,7 +121,7 @@ not even the best engineer on the project; I just got here first.

125This codebase is very young and very general; there is a lot of

121This codebase is very young and very general; there is a lot of

126fun left to be had with it; others deserve to have that fun.

122fun left to be had with it; others deserve to have that fun.

127

123

128−I have no successor as "BDFL." Technical leadership passes to

124+I have no successor as "BDFL." Technical leadership passes to

129Tlon as a company. Urbit is open source and anyone may play, but

125Tlon as a company. Urbit is open source and anyone may play, but

130anyone who wants to catch up to Tlon still has a lot to learn.

126anyone who wants to catch up to Tlon still has a lot to learn.

131Not that that should stop them!

127Not that that should stop them!

@@ -147,7 +143,7 @@ The startup is the least worst. I'd do it again.

147

143

148A normal startup lifecycle (Tlon actually got into YC, but

144A normal startup lifecycle (Tlon actually got into YC, but

149declined – this was either cool or lame) looks nothing like a

145declined – this was either cool or lame) looks nothing like a

150−normal system-software lifecycle. Nor is Urbit normal. But

146+normal system-software lifecycle. Nor is Urbit normal. But

151while Silicon Valley is absurd, it still fits Marianne Moore's

147while Silicon Valley is absurd, it still fits Marianne Moore's

152line: "with a perfect contempt for it, one discovers that there

148line: "with a perfect contempt for it, one discovers that there

153is in it after all a place for the genuine."

149is in it after all a place for the genuine."

@@ -179,7 +175,7 @@ is not for lack of talent-hours. Imagine a bazaar creating a

179feature film, and you'll get the picture. (And Fuchsia seems

175feature film, and you'll get the picture. (And Fuchsia seems

180like a fairly traditional OS.)

176like a fairly traditional OS.)

181

177

182−Why is creative work so hard for bazaars? We could take this as

178+Why is creative work so hard for bazaars? We could take this as

183an axiom – but it's worth understanding.

179an axiom – but it's worth understanding.

184

180

185The path from concept to product is an annealing process. Your

181The path from concept to product is an annealing process. Your

@@ -208,7 +204,7 @@ now, and hard problems. Unless you postpone anything that isn't

208a hard but solvable problem, your gas will never turn into steel.

204a hard but solvable problem, your gas will never turn into steel.

209There are lots and lots and lots of ways to go nowhere fast.

205There are lots and lots and lots of ways to go nowhere fast.

210

206

211−Somehow it's 2019. Urbit is hot iron under the hammer. It is

207+Somehow it's 2019. Urbit is hot iron under the hammer. It is

212solid, but not yet hard. It has shape, but can yet be shaped.

208solid, but not yet hard. It has shape, but can yet be shaped.

213It is done, but ought to be finished. It is a sword; you don't

209It is done, but ought to be finished. It is a sword; you don't

214want to get stabbed with it; it is not Excalibur, the blade to

210want to get stabbed with it; it is not Excalibur, the blade to

@@ -263,8 +259,8 @@ others know better. When we transitioned from Nock 5 to Nock 4,

263all I contributed was a suggestion. The same for our Ethereum

259all I contributed was a suggestion. The same for our Ethereum

264address collection, which our customers absolutely loved.

260address collection, which our customers absolutely loved.

265

261

266−Who's responsible for growing and maintaining this team? Who's

262+Who's responsible for growing and maintaining this team? Who's

267−the stone at at the top of the pyramid? Not me: if you gave me a

263+the stone at at the top of the pyramid? Not me: if you gave me a

268goat to feed, the goat would die. The stone that holds the arch

264goat to feed, the goat would die. The stone that holds the arch

269together is Tlon's CEO and my cofounder, Galen Wolfe-Pauly.

265together is Tlon's CEO and my cofounder, Galen Wolfe-Pauly.

270

266

@@ -301,8 +297,8 @@ words that might otherwise go unsaid.

301### Urbit, a level and neutral platform

297### Urbit, a level and neutral platform

302

298

303Urbit's distribution and sponsorship hierarchy of galaxies,

299Urbit's distribution and sponsorship hierarchy of galaxies,

304−stars and planets is _not_ designed as a political structure,

300+stars and planets is *not* designed as a political structure,

305−or even a social structure. The actual social layer is in

301+or even a social structure. The actual social layer is in

306userspace -- one layer up.

302userspace -- one layer up.

307

303

308Socially and politically, Urbit is a flat network of planets.

304Socially and politically, Urbit is a flat network of planets.

@@ -338,10 +334,10 @@ less than half). The rest are held by third parties – all of

338whom have either much more, or much less, than they deserve.

334whom have either much more, or much less, than they deserve.

339

335

340But although the distribution of Urbit space was thoroughly

336But although the distribution of Urbit space was thoroughly

341−unfair, it was always _honest_ and never _corrupt_. Everyone

337+unfair, it was always _honest_ and never _corrupt_. Everyone

342who has galaxies or stars did _something_ for Urbit. Some gave a

338who has galaxies or stars did _something_ for Urbit. Some gave a

343lot of money, some gave a little; some contributed a lot of code,

339lot of money, some gave a little; some contributed a lot of code,

344−some just showed up. We paid a lawyer by bartering a pair. A

340+some just showed up. We paid a lawyer by bartering a pair. A

345bunch went to contest winners who solved a trivial Nock problem

341bunch went to contest winners who solved a trivial Nock problem

346in 2010.

342in 2010.

347

343

@@ -351,14 +347,14 @@ often had to be in the right place at the right time. This is

351another problem with life that we can't fix.

347another problem with life that we can't fix.

352

348

353Every real system of property is unfair. Who deserves to own

349Every real system of property is unfair. Who deserves to own

354−Manhattan? Who does own it? If property be not unfair – if it

350+Manhattan? Who does own it? If property be not unfair – if it

355is not the result of respecting past accidents – it is not

351is not the result of respecting past accidents – it is not

356property at all, but something else. I certainly would not do it

352property at all, but something else. I certainly would not do it

357this haphazardly again, but the outcome is no tragedy.

353this haphazardly again, but the outcome is no tragedy.

358

354

359When you live in Manhattan, you simply don't worry about who

355When you live in Manhattan, you simply don't worry about who

360−owns it or why; and nor does it matter. Are they Jews? Muslims?

356+owns it or why; and nor does it matter. Are they Jews? Muslims?

361−Christians? Communists? Italians? You don't care and you don't

357+Christians? Communists? Italians? You don't care and you don't

362have to. You know it's basically random and probably unfair.

358have to. You know it's basically random and probably unfair.

363Randomness, even blatant unfairness, creates a kind of neutral,

359Randomness, even blatant unfairness, creates a kind of neutral,

364peaceful, even promising urban anonymity.

360peaceful, even promising urban anonymity.

@@ -405,7 +401,7 @@ Turing Award – my money is definitely on Raph at this point.

405You can even go and read my Usenix '93 paper on ASLR-secured

401You can even go and read my Usenix '93 paper on ASLR-secured

406RPC, which won Best Student Paper and has like 50 citations.

402RPC, which won Best Student Paper and has like 50 citations.

407

403

408−Well. That whole scene is a bad trip, kids. Avoid it. Also, if

404+Well. That whole scene is a bad trip, kids. Avoid it. Also, if

409you start out as Rimbaud, you might end up as Lebowski. On the

405you start out as Rimbaud, you might end up as Lebowski. On the

410other hand, to have any excuse for boiling the ocean, you do have

406other hand, to have any excuse for boiling the ocean, you do have

411to make some serious CS problems just go away. Here are three.

407to make some serious CS problems just go away. Here are three.

@@ -440,13 +436,13 @@ transactions.

440

436

441This means you can't write a command protocol where your commands

437This means you can't write a command protocol where your commands

442get executed exactly once. You can only choose "at least once"

438get executed exactly once. You can only choose "at least once"

443−or "at most once." This problem is as ridiculous and frustrating

439+or "at most once." This problem is as ridiculous and frustrating

444as it sounds.

440as it sounds.

445

441

446You can address it in three ways: (a) make all your commands

442You can address it in three ways: (a) make all your commands

447formally idempotent, so that repeating them has no additional

443formally idempotent, so that repeating them has no additional

448effect; (b) insert a layer of stateful middleware — a message

444effect; (b) insert a layer of stateful middleware — a message

449−queue; (c) be fine with "almost always once." Guess which

445+queue; (c) be fine with "almost always once." Guess which

450approach is most popular?

446approach is most popular?

451

447

452Your Urbit ship has one permanent brain. Its acks are end-to-end

448Your Urbit ship has one permanent brain. Its acks are end-to-end

@@ -457,14 +453,14 @@ queue. And every message is executed once.

457#### Dependencies

453#### Dependencies

458

454

45920th-century languages are all at least vaguely based on a

45520th-century languages are all at least vaguely based on a

460−formalism from the '30s called the "lambda calculus." The

456+formalism from the '30s called the "lambda calculus." The

461fundamental operation in lambda calculus is variable reduction

457fundamental operation in lambda calculus is variable reduction

462from name to value. So lambda languages all have a symbol table

458from name to value. So lambda languages all have a symbol table

463or environment which binds names to values.

459or environment which binds names to values.

464

460

465Modern build systems assemble large programs out of small files

461Modern build systems assemble large programs out of small files

466by reusing this symbol table for global function names, a process

462by reusing this symbol table for global function names, a process

467−called "linking." Unfortunately, linking causes a problem known

463+called "linking." Unfortunately, linking causes a problem known

468as "dependency hell," involving baffling, unpredictable upgrade

464as "dependency hell," involving baffling, unpredictable upgrade

469failures. The fundamental problem is the "diamond dependency" —

465failures. The fundamental problem is the "diamond dependency" —

470when a build requires two different versions of one symbol.

466when a build requires two different versions of one symbol.

@@ -521,7 +517,7 @@ demands "space-rated" code that documents every variable and

521every line – and almost none of the codebase is space-rated.

517every line – and almost none of the codebase is space-rated.

522

518

523Urbit's internal opacity persists for two reasons, one good and

519Urbit's internal opacity persists for two reasons, one good and

524−one bad. The bad reason is just laziness. The good reason is

520+one bad. The bad reason is just laziness. The good reason is

525justified fear of _premature explanation_, which like premature

521justified fear of _premature explanation_, which like premature

526optimization ruins the annealing process.

522optimization ruins the annealing process.

527

523

@@ -546,7 +542,7 @@ in a box for 50 years, or 100, or 500, and when you turn it on

546in a modern interpreter it will upgrade itself and work fine.

542in a modern interpreter it will upgrade itself and work fine.

547

543

548There aren't any significant structural obstacles to each of

544There aren't any significant structural obstacles to each of

549−these milestones. But we can't claim them yet. We haven't

545+these milestones. But we can't claim them yet. We haven't

550really even worried about them. This is another triage case:

546really even worried about them. This is another triage case:

551in this case, the issue is _premature reliability_.

547in this case, the issue is _premature reliability_.

552

548

@@ -568,10 +564,10 @@ computer obviously suggests.

568

564

569Instead, Urbit today is built more the Unix way (if not the

565Instead, Urbit today is built more the Unix way (if not the

570Windows way). It has separate subsystems for tracking and

566Windows way). It has separate subsystems for tracking and

571−updating these three kinds of data. This was my design. Like

567+updating these three kinds of data. This was my design. Like

572Urbit's opacity or impermanence, this was always obviously lame.

568Urbit's opacity or impermanence, this was always obviously lame.

573

569

574−Why do it the lame way? Because, before understanding the union

570+Why do it the lame way? Because, before understanding the union

575of these problems, we had to understand each problem by itself.

571of these problems, we had to understand each problem by itself.

576We didn't – not even close.

572We didn't – not even close.

577

573

@@ -591,17 +587,17 @@ ahead, and falling down an impossible rathole.

591

587

592## Further reading

588## Further reading

593

589

594−What will I do personally? I'll spend more time with my kids.

590+What will I do personally? I'll spend more time with my kids.

595I'll finish reading my 1911 Britannica – I am only on the B's.

591I'll finish reading my 1911 Britannica – I am only on the B's.

596I have no other long-term plans.

592I have no other long-term plans.

597

593

598But I won't be back to Urbit. I am leaving not just the project

594But I won't be back to Urbit. I am leaving not just the project

599but the field – no less than Satoshi, or Everett, or Rimbaud.

595but the field – no less than Satoshi, or Everett, or Rimbaud.

600−Will Satoshi weigh in on the next Bitcoin Cash fork? Did Rimbaud

596+Will Satoshi weigh in on the next Bitcoin Cash fork? Did Rimbaud

601−fly back from Ethiopia for his book-release tour? (Did anyone

597+fly back from Ethiopia for his book-release tour? (Did anyone

602−want him back?) It's not so bad to be a middle-aged Rimbaud.

598+want him back?) It's not so bad to be a middle-aged Rimbaud.

603

599

604−Is there more to say? Of course, but not in prose. Read

600+Is there more to say? Of course, but not in prose. Read

605Bunting's _Chomei at Toyama_ and _Notes on a Fly-Leaf_; Cavafy's

601Bunting's _Chomei at Toyama_ and _Notes on a Fly-Leaf_; Cavafy's

606_Il Gran Rifiuto_, Keeley & Sherrard translation; Canto XV of the

602_Il Gran Rifiuto_, Keeley & Sherrard translation; Canto XV of the

607Inferno, Pinsky translation. You might learn something.

603Inferno, Pinsky translation. You might learn something.

content/blog/a-topiary.mddeleted−38

@@ -1,38 +0,0 @@

1−+++

2−title = "A Topiary: Hypertext and Urbit"

3−date = "2021-06-13"

4−description = "A brief history of hypertext and Urbit networking"

5−

6−[extra]

7−author = "Reid Scoggin"

8−ship = "~sitful-hatred"

9−image = "https://media.urbit.org/site/posts/essays/treebranches.jpeg"

10−+++

11−

12−

13−

14−> Under the trees of England I meditated on this lost and perhaps mythical labyrinth. I imagined it untouched and perfect on the secret summit of some mountain; I imagined it drowned under rice paddies or beneath the sea; I imagined it infinite, made not only of eight-sided pavilions and of twisting paths but also of rivers, provinces and kingdoms... I thought of a maze of mazes, of a sinuous, ever growing maze which would take in both past and future and would somehow involve the stars.

15−

16−-- _The Garden of Forking Paths_, Jorge Luis Borges

17−

18−The pre-technological world was already [networked](https://en.wikipedia.org/wiki/Indra%27s_net). No material object and no idea has ever stood alone—"no man is an island". Language itself is a network of associations shared between a group of people. The question of technology is: how do we bring our web of associations into the realm of computers? The legacy internet has focused on social networks almost exclusively—our mammalian brains readily took to this, we all love to [signal](https://conversationswithtyler.com/episodes/robin-hanson/). But before “social media” there was something called hypertext: a seemingly modest way to connect documents shared between computers.

19−

20−A footnote in a book used to require a library, locating the referenced book, and finding the cited page (which might have footnotes itself)! Hypertext allows one to traverse a network quickly and easily with just mouse clicks, making information accessible to those without the time and resources to hunt down physical artifacts. Urbit’s “%graph-store” is not the same as hypertext but it does bear some familial resemblances. Fundamentally, %graph-store is a data structure that can accommodate disparate data types within a single edifice. It is based on [graph databases](https://en.wikipedia.org/wiki/Graph_database) and recent implementations such as [GraphQL](https://graphql.org/). To understand this data structure it is worth diving into the origins of hypertext—the original linked network.

21−

22−The story of hypertext begins at the end of WWII with an article in _The Atlantic_ that proposed to extend the human mind via machine. Vannevar Bush had seen first-hand the explosion of electronics manufacturing and scientific knowledge, recognizing the great peril and opportunity of such a revolution. His [description](https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/) of the Memex presaged the technological world of today, envisioning a personal device that would allow the user to draw upon a vast library of information, and link documents together arbitrarily—what he called "associative indexing"—a deliberate recreation of how the mind connects thoughts.

23−

24−The 1960s saw the first implementations of these ideas. Ted Nelson's [writing](https://archive.org/details/SelectedPapers1977/page/n15/mode/2up) around _Project Xanadu_ elaborated this linking between documents into what Nelson called _hypertext_. Nelson imagined "a text arranged in a graph structure", centered around a corpus arranged in nonlinear sequence, manipulable by author or audience. The concept was first demonstrated in 1968, at Douglas Engelbart's 'Mother of all Demos', where a vision of computers as a collaborative social environment was revealed to the world. "[The Journal](https://www.dougengelbart.org/content/view/137/#7)", presented alongside other revolutionary demos, exhibited collaboratively edited documents with hyperlinked connections. Any time-travellers in the audience would have immediately recognized the first webpage. From here, the idea of a linked network of documents would be developed through successive phases of computing, from the mainframe to the PC.

25−

26−Experimentation with these ideas continued through the 1970s and 80s. A team directed by Andy Lippman at MIT extended the concept to threaded visual hypermedia with the _Aspen Movie Map_, a user-directed virtual tour of Aspen, Colorado. Hypertext and hypermedia gained a mass audience for the first time with HyperCard, a program that shipped with Mac computers. Users were able to collect or create '[stacks](https://archive.org/details/hypercardstacks)' of interlinked cards; a personal body of text, art, and knowledge could be accrued and modified, or shared with others—though not yet with native networking capabilities.

27−

28−With the World Wide Web, hypertext achieved escape velocity. Initially a one-man [project](http://info.cern.ch/hypertext/WWW/TheProject.html), the world wide web was similar to Bush’s vision of the Memex—a way to share, index, and connect information between individuals and groups. The web succeeded by utilizing the physical infrastructure already available: PCs with graphical interfaces, DNS, and the internet. Critically, its method of transmitting and traversing texts was a standardized protocol, allowing a free body of information to assemble atop the new infrastructure by anyone willing to learn the tools. A new frontier was cleared and cultivated with open standards, but it would gradually face enclosure.

29−

30−In the following decade, after the first wave of social networking sites had crested but before phones became the primary web clients, Twitter was launched. Originally an awkward bridge between SMS and the web, its design eventually coalesced around static identity, posts with chronological sorting, and interlinked post threads. These simple primitives spawned a vast corpus of information, a graph-of-graphs intertwined and overlapped, mapping an entire platonic world. Twitter is fundamentally constrained by its very nature: it is the walled garden of an advertising company. The financial incentives of the server operators demanded seizure of the commons and the replacement of standardized protocols with proprietary databases.

31−

32−As the first networked services withered, a new critique was implicitly articulated in the construction of a [new kind of abstract machine](https://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html). Urbit learned from the past: tightly defined protocols, baked-in cryptography, and decentralization were key. If power over the network was determined by those who ran the servers, then we would run the servers ourselves.

33−

34−Urbit is not fundamentally a hypertext system; it is a new kind of computer, designed to participate in a peer-to-peer network that rejects the client-server model. All Urbit software takes its networking model for granted, it is not an ad-hoc layering of mismatched abstractions. Fundamental design decisions determine the trajectory of the future.

35−

36−Early [implementations](https://en.wikipedia.org/wiki/Neo4j) of graph databases and projects like [RDF](https://en.wikipedia.org/wiki/Resource_Description_Framework) hit on the same core idea: linked data needs its own data structure. In 2020 Urbit OS adopted an application called %graph-store that made use of a new, native [data structure](https://docs.google.com/document/d/1-Gwfg442kV3cdfG7NnWPEf2TMa3uLUTAKkZD70ALZkE/edit) which would act as a database service for social applications. Chats, long-form text, and other types of data produced in the course of social computing now share the same tent, a single structure extensible to new types of content. Each item added to it is a node in a personal graph—a tree that grows branches as your computer communicates. These nodes can be linked arbitrarily to other graphs—Urbit's global immutable namespace grants both permanence and ownership and allows the graph’s branches to intertwine with others. Graphs can accommodate a variety of content, from simple text, to code and media yet to be conceived. You own your graph, and it is a record of your digital journey with others.

37−

38−Personal hypertext graphs are leaving behind proprietary platforms and gaining independence. Graphs until now have been used as tools of surveillance and marketing, but they are being reclaimed and sewn back into the network, each bound to the cryptographic identity of an individual, permanent computer. Where the map of your life was once splintered across a thousand systems and held in the custody of strangers, it is now possessed only by you and shared only as you see fit. On Urbit, an infinite forest of digital lives can take root, nesting their boughs and stalks.

content/blog/aesthetic-culture-1.md+7−4

@@ -1,18 +1,21 @@

1+++

1+++

2title = "Aesthetic Culture #1"

2title = "Aesthetic Culture #1"

3description = "One of the most exciting things about Urbit is the aesthetic and design around it, developed partly by Tlon (through the design of Urbit itself) and partly by the community (by producing great Urbit art)."

3description = "One of the most exciting things about Urbit is the aesthetic and design around it, developed partly by Tlon (through the design of Urbit itself) and partly by the community (by producing great Urbit art)."

4−date = "2020-11-11"

4+date = 2020-11-12

5−

6[extra]

5[extra]

7description = "One of the most exciting things about Urbit is the aesthetic and design around it, developed partly by Tlon (through the design of Urbit itself) and partly by the community (by producing great Urbit art)."

6description = "One of the most exciting things about Urbit is the aesthetic and design around it, developed partly by Tlon (through the design of Urbit itself) and partly by the community (by producing great Urbit art)."

8−author = "~nartes-fasrum"

7+author = "Nikolai Mallett"

9ship = "~nartes-fasrum"

8ship = "~nartes-fasrum"

10image = "https://media.urbit.org/site/posts/essays/help-the-environment.jpg"

9image = "https://media.urbit.org/site/posts/essays/help-the-environment.jpg"

11+++

10+++

12

11

12+<br>

13+

13

14

14

15

16+<br>

17+

15−_This post is the first in a series of digests centered on art produced within and about Urbit by a member of the community, ~nartes-fasrum. Monthly digests will be available within the Urbit Community group in Landscape, and will occasionally be compiled here on the blog to give you a sneak peek at some of what’s happening on the network. Enjoy! ~wolref-podlex_

18+*This post is the first in a series of digests centered on art produced within and about Urbit by a member of the community, ~nartes-fasrum. Monthly digests will be available within the Urbit Community group in Landscape, and will occasionally be compiled here on the blog to give you a sneak peek at some of what’s happening on the network. Enjoy! ~wolref-podlex*

16

19

17One of the most exciting things about Urbit is the aesthetic and design around it, developed partly by Tlon (through the design of Urbit itself) and partly by the community (by producing great Urbit art). As the community grows, it creates more art, and we have the opportunity to showcase some of the pieces we love. These works can draw curious new users in, and they give existing users ways to communicate their excitement to friends.

20One of the most exciting things about Urbit is the aesthetic and design around it, developed partly by Tlon (through the design of Urbit itself) and partly by the community (by producing great Urbit art). As the community grows, it creates more art, and we have the opportunity to showcase some of the pieces we love. These works can draw curious new users in, and they give existing users ways to communicate their excitement to friends.

18

21

content/blog/after-machine-war.md+8−2

@@ -1,16 +1,20 @@

1+++

1+++

2title = "After the Machine War"

2title = "After the Machine War"

3description = "The date is January 1, 2050. The place, New York City. The vibe...subdued."

3description = "The date is January 1, 2050. The place, New York City. The vibe...subdued."

4−date = "2021-03-14"

4+date = 2021-03-15

5−

6[extra]

5[extra]

7author = "Simon Kovacs"

6author = "Simon Kovacs"

8ship = "~bacbec-lormur"

7ship = "~bacbec-lormur"

9image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/berlin-wall.jpeg"

8image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/berlin-wall.jpeg"

10+++

9+++

11

10

11+<br>

12+

12

13

13

14

15+<br>

16+

17+

14> The following fictional passage, from a book being written in an Urbit Group called “the Aleph,” sketches out a dismal future for the human race. As an item of speculative fiction, the piece is not what one might call original. Anyone could have come up with these ideas. In fact, several already have. The Matrix is an obvious antecedent. Vonnegut isn’t far behind either. And the treacly humanism lodged beneath the bitter humor resembles nothing so much as the work of that beau monde satirist, George Saunders.

18> The following fictional passage, from a book being written in an Urbit Group called “the Aleph,” sketches out a dismal future for the human race. As an item of speculative fiction, the piece is not what one might call original. Anyone could have come up with these ideas. In fact, several already have. The Matrix is an obvious antecedent. Vonnegut isn’t far behind either. And the treacly humanism lodged beneath the bitter humor resembles nothing so much as the work of that beau monde satirist, George Saunders.

15>

19>

16> Really the only notable thing about it is that it was written on Urbit. And that, perhaps, has made all the difference.

20> Really the only notable thing about it is that it was written on Urbit. And that, perhaps, has made all the difference.

@@ -21,6 +25,8 @@ image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/berlin

21>

25>

22> Then as now, the unexpected is more likely to occur than most would believe. One thing is not only possible, but an established fact: A brand new digital infrastructure is slowly, quietly being built. While U.S. political parties haggle over $1,400 disbursements for citizens, the rules of global finance are being re-written in code. While pundits debate the merits of Dr. Seuss’s lesser known titles, a global shift away from traditional publishing is gaining steam. And while users and social apps themselves pop up and down like whack-a-mole, folks are putting down roots with permanent peer-to-peer digital identities. If you’re anything like an optimist, you’ll probably want to get on Urbit ASAP and put down your own.

26> Then as now, the unexpected is more likely to occur than most would believe. One thing is not only possible, but an established fact: A brand new digital infrastructure is slowly, quietly being built. While U.S. political parties haggle over $1,400 disbursements for citizens, the rules of global finance are being re-written in code. While pundits debate the merits of Dr. Seuss’s lesser known titles, a global shift away from traditional publishing is gaining steam. And while users and social apps themselves pop up and down like whack-a-mole, folks are putting down roots with permanent peer-to-peer digital identities. If you’re anything like an optimist, you’ll probably want to get on Urbit ASAP and put down your own.

23

27

28+<br>

29+

24The date is January 1, 2050. The place, New York City. The vibe...subdued. Back in 2020, you made a note to yourself to take stock of the world around you here at the half-century mark. And now the time has come. What do you find? The air quality is a bit worse, the bad parts of town are a bit more dilapidated, the Knicks are still terrible—all in all, from the outside at least, not much has changed from 30 years ago. Today you wake up groggy on your self-adjusting Smart Bed (Smart Bed Never Sleeps), you make yourself a steaming pot of coffee (locally sourced, delivered within the half-hour by a drone, now that you’ve got Titicaca Prime), you shower and get ready for work.

30The date is January 1, 2050. The place, New York City. The vibe...subdued. Back in 2020, you made a note to yourself to take stock of the world around you here at the half-century mark. And now the time has come. What do you find? The air quality is a bit worse, the bad parts of town are a bit more dilapidated, the Knicks are still terrible—all in all, from the outside at least, not much has changed from 30 years ago. Today you wake up groggy on your self-adjusting Smart Bed (Smart Bed Never Sleeps), you make yourself a steaming pot of coffee (locally sourced, delivered within the half-hour by a drone, now that you’ve got Titicaca Prime), you shower and get ready for work.

25

31

26But what was that dream you had last night? Only the faintest traces of it remain. A luminous rainbow, a mountain landscape, a sense of profound inner peace, mixed with euphoria, mixed with...an intense desire to go out and buy some Health Morsels cereal?

32But what was that dream you had last night? Only the faintest traces of it remain. A luminous rainbow, a mountain landscape, a sense of profound inner peace, mixed with euphoria, mixed with...an intense desire to go out and buy some Health Morsels cereal?

content/blog/agency-daos.mddeleted−110

@@ -1,110 +0,0 @@

1−+++

2−title = "The Dream of the Agency DAO"

3−date = "2022-11-04"

4−description = "As creative studios and agencies struggle for more creative freedom, DAOs and tokenization will surely take a more central role in the marketing and branding industries. Decentralization offers such entities benefits that could fundamentally reshape creatives’ relationships with clients—reducing layers of inefficiency and anti-creative incentives."

5−

6−[extra]

7−author = "Isaac Simpson"

8−ship = "~mogmet-tadnem"

9−image = "https://storage.googleapis.com/media.urbit.org/blog/skybanner.jpg"

10−+++

11−

12−

13−

14−

15−Chris Callahan runs an independent brand strategy agency called [Visitor](https://visitor.agency/). Visitor wrote the line that [emblazoned](https://astra-mag.com/articles/my-weekend-with-the-martians/) the sky over the parking lot that housed Urbit Assembly. Its work focuses on Web3 blue chips and up-and-comers: dev marketing, notoriously one of the toughest niches in the branding world.

16−

17−“Devs are very sensitive to puffery and cringe,” says Callahan. “Traditional tactics like headlines and manifestos fall flat. Clarity and vision are much more important because they showcase the benefit as well as a long term potential for use.”

18−

19−Why? Because developers eschew sales. If something is good, it will rise to the top without the help of annoying salespeople. The thing is, marketing-world creatives usually agree—we’re just bogged down by salespeople of our own. So we, like devs, yearn for the day when decentralization will save us from the social climbers and “connectors” that suck up all the oxygen.

20−

21−Enter the Agency DAO. The idea—a creative agency that solicits work, receives clients, hires creatives, and makes decisions all on the blockchain—is oft-discussed because it appeals to the crunchy, anti-establishment vibe at the core of every major ad agency. A trustless, leaderless creative community where everyone has equal voice and the best creative rises naturally to the top? The dream of the ‘90s come true!

22−

23−Unfortunately, decentralization in the ad world currently occupies much more podcast time than reality.

24−

25−## Creative by Committee

26−

27−But there are some actual attempts at making the Agency DAO a reality. Koto, a top creative agency known for creating the AirBNB brand, tried it with Web3 brand Polkadot. [It pit two pitches against each other to determine the future direction of the Polkadot brand by vote](https://vote.polkadot.network/). It used a quadratic voting via Snapshot to deliver the will of the Polkadot network to four “multisig curators” who executed the vote on chain.

28−

29−While the experiment worked, it also revealed the shortcomings of the blockchain’s ability to guide creative decisionmaking.

30−

31−“To organize Polkadot token holders who wanted to participate and create the voting parameters took very long,” says Callahan. “To have the wisdom of crowds decide on two design elements was an exemplary concept for Polkadot to own. The question is, did it push the work? Or was its value in consensus alone?”

32−

33−Quadratic voting is cool, but the creative process is long and complicated. Stakeholders chose between option A and option B. At the end of the day, that doesn’t feel like a significant innovation, especially if the vote isn’t even actually happening on chain. Rebranding sprints typically take around 3 months. This process took 11. Sure, it was a good way for Koto to play ball, but it wasn’t much more than that.

34−

35−Agency DAOs face the same central problem as ordinary DAOs, which can be summed up thusly: every decentralizing force is too costly, and every cost compromise moves the system back towards traditional hierarchies. The nature of creative work even further stymies the theoretical Agency DAO. Creative products almost always suffer when anti-hierarchical principles are put in place. As David Ogivly famously said,

36−

37−_“Some agencies pander to the craze for doing everything in committee. They boast about ‘team-work’ and decry the role of the individual. But no team can write an advertisement, and I doubt whether there is a single agency of any consequence which is not the lengthened shadow of one man.”_

38−

39−So this leaves us with the question of how exactly the DAO model can help creative agencies, and what such an organization might look like, and how Urbit can help. There are roughly three paths: 1) Project Bountification 2) Talent Retention 3) Idea Valuation.

40−

41−## Project Bountification

42−

43−In the Mad Men era, a few Agencies of Record (AORs) dominated the advertising world. These massive whales took every cent of a given big brand’s yearly advertising budget and charged a simple 15% premium on all media (e.g. radio time, TV time) purchased. A very simple and very profitable system, [now long gone](https://www.genedelibero.com/the-agency-of-record-the-shift-is-on-to-specialized-agencies/).

44−

45−Today, big brands typically have many agencies—sometimes hundreds—each with a different specialty, and each fighting for their own share of the budget. I’ve been in rooms with representatives from no less than 10 agencies—digital, DEI, experiential, CSR, influencer, etc—all pitching ideas for the same holiday campaign, and all surely billing upwards of $100/hour per person to do so.

46−

47−This sounds nice for agencies, but actually it isn’t—instead of focusing on the creative work, they must dedicate their energy towards constantly re-pitching themselves to the client and fighting with procurement people on rates. The managerial class types who control the budgets care a lot less about the quality of the creative than whether you remembered their dog’s birthday.

48−

49−Crypto could provide a solution to modern agencies’ woes by creating a flatter system for project acquisition; adopting the sort of decentralized bounty system some devs already use for Web3 projects.

50−

51−“Bounties are great,” says Callahan. “Big agency players should popularize them. I feel like if there's a way to do an on-chain bounty with select members who either hold a special token that allows participation on key briefs, that would help a lot.”

52−

53−How would such a system work? First, a brand issues a bounty for a project for work it needs done. Luckily, this basically already happens in advertising, it’s called a request for proposal, or RFP. The only difference here is instead of RFP acquisition and response being 90% schmooze-fest and 10% creativity/pitching prowess, it’s a lot more like what you’ve seen on Mad Men: the client’s RFP passes trustlessly to the bold creatives who spend many drunk, sleepless nights coming up with genius ways to knock their socks off.

54−

55−“A brand issues a bounty for a stunt activation that, for example, educates the world on the psychological benefits of calm computing,” Callahan explains. “The members of Agency DAO approve it, and create their own bounty for creatives inside the DAO. Bounties burn after 10 days. Ideas submitted and sent to client in the manner set by DAO.”

56−

57−Once the job is awarded, the chosen agency will continue this pattern, effectively removing the “account guy” layer—the sales-y middle people abhorred by both creatives and devs alike—and returning more focus to creativity.

58−

59−## Talent Retention

60−

61−“Professional creative” industries, e.g. marketing, branding, etc, suffer from turnover rates orders of magnitude higher than the industries they serve. Being a creative is both kind of awesome, because a new gig is never too far away, and also scary, your current gig reliant on the slightest whims of the client.

62−

63−This means that the market for creative talent in the form of copywriters, designers, art directors, animators, producers, editors, etc, is always choppy and competitive. Staffing sucks—it’s difficult to evaluate the quality of someone’s work until you’re actually working with them, because creatives stuff their portfolios with successful projects they’ve barely touched. Beyond that, now bloated Web2 lowballers like Fiverr and Upwork bottom out the market with garbage time labor that even the biggest brands still somehow fall for. Another great opportunity for Web3 disruption.

64−

65−The Agency DAO model provides permanence. Currently, some independent agencies offer equity packages that take a long time to vest, and are only ever worth anything if the agency sells. Owning fungible tokens from day one is a much better way to incentivize both work quality and retention.

66−

67−DAOs also offer flatter and more collaborative atmospheres, which creatives at least ostensibly want.

68−

69−“There’s total transparency of who works on what. Better collaboration between members, meaning happier, more fulfilled workers. Awards will be more meaningful and accurate,” says Callahan. “Plus, the value of your tokens naturally increases or decreases based on your performance. Just by getting hired at a successful DAO you can already be doing well.”

70−

71−Finally, a system that allows democratized voting on creative products, as opposed to traditional [Hype Dad aristocracies](https://thecarousel.substack.com/p/vibe-shift-to-destroy-marketing-world), could actually foster more Darwinistic environments where the best creative has a higher chance of rising to the top.

72−

73−“Eventually group preference will select one creative over others; causing repeat elections of the same member,” says Callahan. This could occur on both the agency level—removing the Hype Dad problem, e.g. lazy incumbents making lame decisions. “There's a sort of Darwinism that is created that can determine benefits or even redundancies for those not pulling their weight or who simply aren't as talented as others.”

74−

75−## Idea Valuation

76−

77−The creative industries are perhaps the only example of a field in which the artists retain no intellectual property right for their ideas. This is why advertising creatives make so much money—an advertiser can milk a good idea for decades and we’ll never see a dime.

78−

79−The tokenization inherent to the DAO model opens up several possibilities for valuing ideas in new ways that behave more like copyright.

80−

81−“The basic thought now is starting something I’m calling General Idea; pre-created, white label ideas based on research of real creative problems that need fixing,” says Callahan. “We NFT the ideas, sell them to clients. They make them or they resell that idea to other clients or agencies. That monetary markup value on the idea trickles down the original creator. More democratic way to share ideas and defend their ownership when they’ve been recorded on the blockchain.”

82−

83−This sort of blockchain-based soft copyright is one way to value an agency’s DAOs. Another, simpler way, is to sell NFTs or NFT-related independent creations of the agency itself. Art collective/creative agency [MSCHF](https://mschf.xyz/), for example, makes its money both via brand deals and also a la carte meme-to-merch drops. Agencies with a certain amount of clout could easily tokenize the clever side projects of its creatives—making it far less reliant on client deals and more able to capitalize on its creative prowess.

84−

85−“Pool Suite [another creative studio] does a great job of being a creative company that happens to make NFTs of music and general drops and stuff,” says Callahan. “They're a studio first and then a blockchain player after. I'd still consider them a ‘diet-DAO.’”

86−

87−[Édouard Urcades](https://fabled-faster.tlon.network/writing/stars) has designed interfaces for Tumblr and IBM, and currently serves as a design lead at Tlon. His project Structure is a “cork board” for creative projects on Urbit—sort of a “mercenary guild,” for UX/UI designers looking for work. Structure is run by a gnosis safe wallet operated by its 12 members. Beyond serving as a “soft on-ramp for Urbit-related design labor,” Ed plans to monetize Structure by selling Urbit merch designed in-house, both NFT and IRL.

88−

89−## How Urbit Can Help

90−

91−The three categories discussed above—project bountification, talent retention, idea valuation—present theoretical frameworks for the Agency DAO. However, the shortcomings of current DAO infrastructure and governance make them largely impossible. Enter Urbit.

92−

93−The creative industries rely almost entirely on reputation—so any Agency DAO without permanent pseudonymous ID is dead in the water.

94−

95−“Goodby Silverstein and Partners, for example, is widely regarded as one of the best ad agencies out there,” says Callahan. “When a big name in the creative industry goes to work there, the reputation of Goodby Silverstein increases.”

96−

97−Urbit IDs let you maintain your creative and working reputations while operating within a self-owned ecosystem that can’t be deleted. Beyond that, Urbit’s design-forward OS selects for self-expression in a way that no corporate-owned platform could.

98−

99−

100−“The sigil itself is its own design feature,” says Callahan.

101−

102−Simply put, running an Agency DAO on Discord and Google Docs would be fundamentally unserious. It’s one thing for a traditional agency to use Web2 products as _tools_ for its creatives. It’s quite another for Web2 products to be the only connection the agency has with its creatives outside of the blockchain.

103−

104−Recruitment, ideation, project sharing, and even simple chat aren’t possible on Web3 without something like Urbit to tie it all together. Sure, you could get a bunch of anonymous creatives together on a shared Figma, but there will be zero accountability and likely low participation. Whereas Urbit—particularly Holium’s forthcoming Realm—brings Urbit ID into a decentralized, permanent environment that connects members P2P, and allows on-chain transactions without leaving Urbit. All while maintaining permanent IDs.

105−

106−As creative studios and agencies struggle for more creative freedom, DAOs and tokenization will surely take a more central role in the marketing and branding industries. Decentralization offers such entities benefits that could fundamentally reshape creatives’ relationships with clients—reducing layers of inefficiency and anti-creative incentives. However, a decentralized ID layer like Urbit is needed before the Agency DAO can be practically attempted.

107−

108−–

109−

110−*Isaac Simpson is a Los Angeles based writer and the founder of the marketing agency [WILL](https://willtheagency.com/). You can read his work on his substack [The Carousel](https://thecarousel.substack.com/).*

content/blog/an-email.md+12−8

@@ -1,8 +1,7 @@

1+++

1+++

2title = "An Email from the Archive"

2title = "An Email from the Archive"

3description = "I found this email in my archives recently and thought it might be fun to share publicly."

3description = "I found this email in my archives recently and thought it might be fun to share publicly."

4−date = "2020-11-29"

4+date = 2020-11-30

5−

6[extra]

5[extra]

7author = "Galen Wolfe-Pauly"

6author = "Galen Wolfe-Pauly"

8ship = "~ravmel-ropdyl"

7ship = "~ravmel-ropdyl"

@@ -28,30 +27,32 @@ Our collective desire to depend on digital communication tools vastly exceeds wh

28

27

29In the pre-digital world we enjoyed a few things about the way we communicated, collaborated and did business that are dwindling: simplicity, durability and ownership. I’ll try to give some straightforward examples of what I mean:

28In the pre-digital world we enjoyed a few things about the way we communicated, collaborated and did business that are dwindling: simplicity, durability and ownership. I’ll try to give some straightforward examples of what I mean:

30

29

31−A - When I talk to someone directly, I’m not worried that someone else is listening in. If they go tell someone else what I said to them, that’s something for us to work out between us — they’re not _always_ reporting our conversations back to a third party. The constraints of the interaction and the privacy implications are _simple_ — I don’t think about them at all. Good privacy guarantees flow from a strict focus on simplicity. When two people want to talk to each other: give them a secure channel to talk. Putting a centrally-controlled service between them is just an interim solution because no one could figure out a better way to do it.

30+A - When I talk to someone directly, I’m not worried that someone else is listening in. If they go tell someone else what I said to them, that’s something for us to work out between us — they’re not *always* reporting our conversations back to a third party. The constraints of the interaction and the privacy implications are *simple* — I don’t think about them at all. Good privacy guarantees flow from a strict focus on simplicity. When two people want to talk to each other: give them a secure channel to talk. Putting a centrally-controlled service between them is just an interim solution because no one could figure out a better way to do it.

32

31

33B - When I write something down on paper, or type into a typewriter, I have an intuitive sense of the durability of what I’ve made. I have notes on my shelf I took ten years ago. I don’t worry about them disappearing. This means I can have a very direct, high-resolution relationship with the medium. I can pour myself into my physically-written notes in a way I would never pour myself into a Google Doc. Our digital tools are deeply untrustworthy because we know they can disappear, that they won’t actually last forever.

32B - When I write something down on paper, or type into a typewriter, I have an intuitive sense of the durability of what I’ve made. I have notes on my shelf I took ten years ago. I don’t worry about them disappearing. This means I can have a very direct, high-resolution relationship with the medium. I can pour myself into my physically-written notes in a way I would never pour myself into a Google Doc. Our digital tools are deeply untrustworthy because we know they can disappear, that they won’t actually last forever.

34

33

35−C - Around 2008 I started limiting myself to a few specific drawing and writing tools. I use them all the time and can actually refine my relationship to them since I know they’re not going to change out from under me. Perhaps at some point these pens wont be made anymore, but the ones I have are actually _mine_. Similarly, the things I make with them actually belong to me in a way that doesn’t require some ridiculous terms of service. A sense of ownership, when it comes to the medium of communication, determines our level of trust and commitment.

34+C - Around 2008 I started limiting myself to a few specific drawing and writing tools. I use them all the time and can actually refine my relationship to them since I know they’re not going to change out from under me. Perhaps at some point these pens wont be made anymore, but the ones I have are actually *mine*. Similarly, the things I make with them actually belong to me in a way that doesn’t require some ridiculous terms of service. A sense of ownership, when it comes to the medium of communication, determines our level of trust and commitment.

36

35

37Our digital tools have to achieve the same level of simplicity, durability and ownership that our pre-digital tools did. Until they do, we’re always going to be in conflict with them, full stop.

36Our digital tools have to achieve the same level of simplicity, durability and ownership that our pre-digital tools did. Until they do, we’re always going to be in conflict with them, full stop.

38

37

39−The main thing is that exactly none of our present platform-centric world can survive when you see things this way. The digital world we live in is composed of an insanely complicated, ephemeral set of tools that distinctly _do not_ belong to the people that use them.

38+The main thing is that exactly none of our present platform-centric world can survive when you see things this way. The digital world we live in is composed of an insanely complicated, ephemeral set of tools that distinctly *do not* belong to the people that use them.

40

39

41We’re going to be in a constant struggle with technology until it conforms to these three very basic expectations. These are the expectations we try to get Urbit to fall in-line with, of course. Something else could also succeed by satisfying them. But I also don’t really see anything else, aside from Bitcoin and maybe Ethereum, falling in line with these core principles.

40We’re going to be in a constant struggle with technology until it conforms to these three very basic expectations. These are the expectations we try to get Urbit to fall in-line with, of course. Something else could also succeed by satisfying them. But I also don’t really see anything else, aside from Bitcoin and maybe Ethereum, falling in line with these core principles.

42

41

43So: while I wish that Urbit was more mature and ready to capture those that are being purged from mainstream social media, are bored with it or are frustrated with the constraints of ‘productivity software’ — I think this conflict is going to drag on until people realize that what we’re in conflict with is the structure of the software we use. Using software that’s managed by other people is always going to cause serious problems all the way up at the user level. For more speculation on how this might play out, watch Black Mirror.

42So: while I wish that Urbit was more mature and ready to capture those that are being purged from mainstream social media, are bored with it or are frustrated with the constraints of ‘productivity software’ — I think this conflict is going to drag on until people realize that what we’re in conflict with is the structure of the software we use. Using software that’s managed by other people is always going to cause serious problems all the way up at the user level. For more speculation on how this might play out, watch Black Mirror.

44

43

44+

452 -

452 -

46

46

47(1) is, in a way, a long-winded way of saying that the state of the world hasn’t changed our direction all that much. In order for Urbit to be approachable to use, it has to be very nicely made and that takes time and iteration. As the system stabilizes, Urbit can evolve in a more traditional way: we, along with others in the ecosystem, release stuff, observe how people use it, and try to make it better. We’re at the point where we’re nearly ready to get into that feedback loop, and we very much need to get there. We’re close.

47(1) is, in a way, a long-winded way of saying that the state of the world hasn’t changed our direction all that much. In order for Urbit to be approachable to use, it has to be very nicely made and that takes time and iteration. As the system stabilizes, Urbit can evolve in a more traditional way: we, along with others in the ecosystem, release stuff, observe how people use it, and try to make it better. We’re at the point where we’re nearly ready to get into that feedback loop, and we very much need to get there. We’re close.

48

48

49−Urbit is a distinctly different _kind_ of software than anything we have now. Your Urbit is something you actually own and can do whatever you want with: not unlike your furniture or your kitchen tools. An Urbit is a tool for individual, human-scale computing and our whole approach to designing and making things is completely different. Most computing is about industrial-scale computing: where the software system stores everyone’s data and is managed by the people who build it.

49+Urbit is a distinctly different *kind* of software than anything we have now. Your Urbit is something you actually own and can do whatever you want with: not unlike your furniture or your kitchen tools. An Urbit is a tool for individual, human-scale computing and our whole approach to designing and making things is completely different. Most computing is about industrial-scale computing: where the software system stores everyone’s data and is managed by the people who build it.

50

50

51Urbit is the opposite of industrial-scale. Urbit is much more like something that’s carefully crafted and delivered to you directly. This craftsman-like approach to building software really isn’t a part of most modern software engineering.

51Urbit is the opposite of industrial-scale. Urbit is much more like something that’s carefully crafted and delivered to you directly. This craftsman-like approach to building software really isn’t a part of most modern software engineering.

52

52

53When I think about this from the standpoint of the person using what we make, it’s especially important. Urbit should feel like something that’s purposefully made by hand — not something you picked off the shelf at Wal-Mart. Some of this ethos was present in the early PC movement, but it’s mostly lost today. The care and attention that goes into building the system is also exactly what we make money on. People pay us to own a piece of it, to use it. We’re incentivized to make nice things, in the Urbit model, and we take that responsibility seriously.

53When I think about this from the standpoint of the person using what we make, it’s especially important. Urbit should feel like something that’s purposefully made by hand — not something you picked off the shelf at Wal-Mart. Some of this ethos was present in the early PC movement, but it’s mostly lost today. The care and attention that goes into building the system is also exactly what we make money on. People pay us to own a piece of it, to use it. We’re incentivized to make nice things, in the Urbit model, and we take that responsibility seriously.

54

54

55+

553 -

563 -

56

57

57Networks are a really important social form that’s only just beginning to come into existence. A network is neither a state nor a company, but something in-between. Bitcoin is a network, Ethereum is network (but it’s still far too centralized). Urbit is a young network.

58Networks are a really important social form that’s only just beginning to come into existence. A network is neither a state nor a company, but something in-between. Bitcoin is a network, Ethereum is network (but it’s still far too centralized). Urbit is a young network.

@@ -62,13 +63,15 @@ Urbit is controlled by the collective of people who use it — in varying degree

62

63

63On a successful Urbit network, Facebook, Airtable, and Signal are just successful applications. You could probably build companies around them that ship software to Urbit — but they’re more like 5 - 10 people instead of thousands.

64On a successful Urbit network, Facebook, Airtable, and Signal are just successful applications. You could probably build companies around them that ship software to Urbit — but they’re more like 5 - 10 people instead of thousands.

64

65

65−Urbit doesn’t aim to eat away at the government per se. Instead, it’s an important communication tool for institutions of any scale to actually take control of their means of collaboration. The efficiency of inter-government communication and government to populace communication can clearly be improved by _a whole lot_.

66+Urbit doesn’t aim to eat away at the government per se. Instead, it’s an important communication tool for institutions of any scale to actually take control of their means of collaboration. The efficiency of inter-government communication and government to populace communication can clearly be improved by *a whole lot*.

67+

66

68

674 -

694 -

68

70

69The most important thing is that people can generate a vision of the future. This can only emerge from a small collective of motivated people. Our public life is overwhelmed by people shooting from the hip, aiming for likes.

71The most important thing is that people can generate a vision of the future. This can only emerge from a small collective of motivated people. Our public life is overwhelmed by people shooting from the hip, aiming for likes.

70

72

71−There are difficult, infrastructural problems _all over the place_ that desperately need the considerate attention of small groups of people. Urbit, as communication tooling, is aimed at improving the quality of the fabric that binds these groups together. Or, to put it another way, before you can solve any specific problem you have to improve the problem solving process overall. Everything is gated on solving the process.

73+There are difficult, infrastructural problems *all over the place* that desperately need the considerate attention of small groups of people. Urbit, as communication tooling, is aimed at improving the quality of the fabric that binds these groups together. Or, to put it another way, before you can solve any specific problem you have to improve the problem solving process overall. Everything is gated on solving the process.

74+

72

75

735 -

765 -

74

77

@@ -80,5 +83,6 @@ The thing that comes to mind lately is Hejduk. He had passed away by the time I

80

83

81Hejduk was able to see that architecture isn’t about building buildings per se, but something else. That was always quite obvious to me.

84Hejduk was able to see that architecture isn’t about building buildings per se, but something else. That was always quite obvious to me.

82

85

86+

83Talk soon!

87Talk soon!

84G

88G

content/blog/an-urbit-overview.md+80−84

@@ -1,12 +1,8 @@

1+++

1+++

2title = "An Urbit Overview"

2title = "An Urbit Overview"

3−date = "2016-05-10"

3+date = 2016-05-11

4description = "A high-level overview of Urbit."

4description = "A high-level overview of Urbit."

5−aliases = [

6− "/posts/essays/an-urbit-overview",

5+aliases = ["/posts/essays/an-urbit-overview", "/posts/an-urbit-overview"]

7− "/posts/an-urbit-overview"

8−]

9−

10[extra]

6[extra]

11author = "Galen Wolfe-Pauly"

7author = "Galen Wolfe-Pauly"

12ship = "~ravmel-ropdyl"

8ship = "~ravmel-ropdyl"

@@ -21,79 +17,79 @@ Urbit is a virtual city of general-purpose personal servers.

21

17

22## Your old personal server

18## Your old personal server

23

19

24−What's a personal server? In a sense, you already have one. Your

20+What's a personal server? In a sense, you already have one. Your

25personal server is the combination of all the cloud services you use

21personal server is the combination of all the cloud services you use

26now.

22now.

27

23

28−This "server" is a mess. It's broken into 17 different fragments

24+This "server" is a mess. It's broken into 17 different fragments

29−which are scattered all over the planet. You have no control at all

25+which are scattered all over the planet. You have no control at all

30−over any of the pieces. The more we depend on Web services, the more

26+over any of the pieces. The more we depend on Web services, the more

31we realize how unsustainable this situation is.

27we realize how unsustainable this situation is.

32

28

33−Can you remember all the services you have accounts for? How about

29+Can you remember all the services you have accounts for? How about

34−the username and password for each? Some of them will let you pull

30+the username and password for each? Some of them will let you pull

35−your data out somehow, some won't. Sometimes you can move your data

31+your data out somehow, some won't. Sometimes you can move your data

36−between them, sometimes you can't. But they're all good at

32+between them, sometimes you can't. But they're all good at

37showing you ads.

33showing you ads.

38

34

39## Your new personal server

35## Your new personal server

40

36

41−Your urbit is your own general-purpose server. It holds your

37+Your urbit is your own general-purpose server. It holds your

42data; runs your apps; wrangles your connected devices; and

38data; runs your apps; wrangles your connected devices; and

43−defines your secure identity. If you still need your old

39+defines your secure identity. If you still need your old

44services, it drives them with APIs.

40services, it drives them with APIs.

45

41

46Your urbit presents your whole digital life as a single web

42Your urbit presents your whole digital life as a single web

47−service. And since it's yours, open source and patent-free, it

43+service. And since it's yours, open source and patent-free, it

48−never shows you ads. Or loses your data. Or updates without

44+never shows you ads. Or loses your data. Or updates without

49your consent.

45your consent.

50

46

51Technically, Urbit is a new kind of OS that has a precise formal

47Technically, Urbit is a new kind of OS that has a precise formal

52−definition. (Urbit is actually a [single mathematical function](https://media.urbit.org/whitepaper.pdf).) One advantage of a math-based OS is that Urbit is perfectly

48+definition. (Urbit is actually a [single mathematical function](https://media.urbit.org/whitepaper.pdf).) One advantage of a math-based OS is that Urbit is perfectly

53−portable. It can't tell whether it's in a cloud data center or on

49+portable. It can't tell whether it's in a cloud data center or on

54your home PC.

50your home PC.

55

51

56−Concerned about mass surveillance? Download your urbit and restart it

52+Concerned about mass surveillance? Download your urbit and restart it

57−on your laptop, or move to a new host in Iceland. Urbit's formal

53+on your laptop, or move to a new host in Iceland. Urbit's formal

58simplicity makes managing it as easy as managing an iPhone: all you

54simplicity makes managing it as easy as managing an iPhone: all you

59have to decide is what apps to add.

55have to decide is what apps to add.

60

56

61−Each urbit is a node on a global, encrypted P2P network. Your Urbit

57+Each urbit is a node on a global, encrypted P2P network. Your Urbit

62name, a generated pseudonym like `~talsur-todres`, is also your

58name, a generated pseudonym like `~talsur-todres`, is also your

63−network address. Like Bitcoin, Urbit address space is a cryptographic

59+network address. Like Bitcoin, Urbit address space is a cryptographic

64asset with a limited supply.

60asset with a limited supply.

65

61

66−By keeping addresses scarce, we make spam and abuse expensive. Urbit

62+By keeping addresses scarce, we make spam and abuse expensive. Urbit

67is a "friendly network," like the Internet in 1986, where a stranger

63is a "friendly network," like the Internet in 1986, where a stranger

68−is nice until proven nasty. As it matures, Urbit will grow into a

64+is nice until proven nasty. As it matures, Urbit will grow into a

69decentralized, self-governing virtual city both safe and free.

65decentralized, self-governing virtual city both safe and free.

70

66

71## The Urbit future

67## The Urbit future

72

68

73In an Urbit world, your data is no longer trapped in a jumble of

69In an Urbit world, your data is no longer trapped in a jumble of

74−proprietary servers. Your urbit is a permanent, versioned, typed

70+proprietary servers. Your urbit is a permanent, versioned, typed

75−archive the size of your digital life. Even before you move your data

71+archive the size of your digital life. Even before you move your data

76from a Web service to a local Urbit app, your urbit can drive your

72from a Web service to a local Urbit app, your urbit can drive your

77account with an API or scraper.

73account with an API or scraper.

78

74

79−And within Urbit, data is never locked inside apps. Imagine if you

75+And within Urbit, data is never locked inside apps. Imagine if you

80could painlessly switch between Facebook and Google+, Asana and

76could painlessly switch between Facebook and Google+, Asana and

81−Trello, Tumblr and WordPress. Not only does your urbit upgrade itself

77+Trello, Tumblr and WordPress. Not only does your urbit upgrade itself

82and its apps automatically, you can "sidegrade" a running app to

78and its apps automatically, you can "sidegrade" a running app to

83another vendor without losing data.

79another vendor without losing data.

84

80

85−Your urbit is also your digital identity. Along with your data

81+Your urbit is also your digital identity. Along with your data

86lifestream of media, messages and documents, it has the keys and

82lifestream of media, messages and documents, it has the keys and

87−tokens to manage all your legacy Web services. It holds the keys

83+tokens to manage all your legacy Web services. It holds the keys

88for your cryptocurrency wallets, so it can buy and sell for you.

84for your cryptocurrency wallets, so it can buy and sell for you.

89(With one personal server to secure, not 17 different accounts,

85(With one personal server to secure, not 17 different accounts,

90you actually have the bandwidth to take security seriously.)

86you actually have the bandwidth to take security seriously.)

91

87

92−You still use network services. But instead of interacting with

88+You still use network services. But instead of interacting with

93the service provider's HTML UI, which phones home using

89the service provider's HTML UI, which phones home using

94proprietary HTTP APIs, you interact with a third-party app on

90proprietary HTTP APIs, you interact with a third-party app on

95your urbit, which talks to multiple service providers using

91your urbit, which talks to multiple service providers using

96−public, typed Urbit protocols. For example, your urbit runs a

92+public, typed Urbit protocols. For example, your urbit runs a

97single shopping app, which downloads catalogs and uploads orders.

93single shopping app, which downloads catalogs and uploads orders.

98This app is one store which sells everything in the world, with a

94This app is one store which sells everything in the world, with a

99salesman who's 100% on your side and always has the best price.

95salesman who's 100% on your side and always has the best price.

@@ -101,115 +97,115 @@ Every computing experience is different when the UI is working

101exclusively for the user.

97exclusively for the user.

102

98

103Finally, your urbit is the hub for your network of connected

99Finally, your urbit is the hub for your network of connected

104−devices. Your smart thermostat, your wristband, your phone and

100+devices. Your smart thermostat, your wristband, your phone and

105tablet, all run satellite urbits which talk securely to your main

101tablet, all run satellite urbits which talk securely to your main

106urbit in the cloud.

102urbit in the cloud.

107

103

108## A chance for digital freedom

104## A chance for digital freedom

109

105

110The promise of the personal server isn't just convenience.

106The promise of the personal server isn't just convenience.

111−General-purpose computing is magic. This magic must be in the

107+General-purpose computing is magic. This magic must be in the

112−hands of all, not just those who can master Unix. The computer

108+hands of all, not just those who can master Unix. The computer

113−is a bicycle for the mind. It's an open vehicle for exploration

109+is a bicycle for the mind. It's an open vehicle for exploration

114−and discovery. It's not a way to optimize ad delivery.

110+and discovery. It's not a way to optimize ad delivery.

115

111

116Urbit, as virtual city, is a platform that brings together all our

112Urbit, as virtual city, is a platform that brings together all our

117datastreams -- from emails to heartbeats -- in a way that we ourselves

113datastreams -- from emails to heartbeats -- in a way that we ourselves

118−control. Can we work together to match faces in photos, without

114+control. Can we work together to match faces in photos, without

119−submitting to some panopticon in Mountain View? While the first step

115+submitting to some panopticon in Mountain View? While the first step

120in freedom is the right to be left alone, the second is the power to

116in freedom is the right to be left alone, the second is the power to

121form new intentional communities, to create and evolve a voluntary

117form new intentional communities, to create and evolve a voluntary

122−definition of public space. We have no idea at all what people will

118+definition of public space. We have no idea at all what people will

123do with this power.

119do with this power.

124

120

125−General-purpose computing is digital freedom. And today, a cloud data

121+General-purpose computing is digital freedom. And today, a cloud data

126−center is the technically optimal locus of computation. The cloud is

122+center is the technically optimal locus of computation. The cloud is

127−always on, always available, never loses data. Hosts are sometimes

123+always on, always available, never loses data. Hosts are sometimes

128attacked; but they never intentionally tamper with their virtual

124attacked; but they never intentionally tamper with their virtual

129−computers. The cloud can never be secure against a global adversary;

125+computers. The cloud can never be secure against a global adversary;

130−but most people don't have a global adversary. A single portable

126+but most people don't have a global adversary. A single portable

131platform provides "herd immunity" for the few who do need direct

127platform provides "herd immunity" for the few who do need direct

132physical control over their main computers.

128physical control over their main computers.

133

129

134Though even laptops are atrophying into mere browsers, mass-market,

130Though even laptops are atrophying into mere browsers, mass-market,

135general-purpose computing on the client side remains an endangered

131general-purpose computing on the client side remains an endangered

136−species that must be protected. But on the server side, this species

132+species that must be protected. But on the server side, this species

137−has never even _existed_. There has never been anything like a

133+has never even _existed_. There has never been anything like a

138−mass-market personal server. Why not?

134+mass-market personal server. Why not?

139

135

140## Freedom is an engineering problem

136## Freedom is an engineering problem

141

137

142−Urbit is not a difficult idea. Urbit is like a flying car: the idea

138+Urbit is not a difficult idea. Urbit is like a flying car: the idea

143−is not the hard part. Almost everyone we talk to about Urbit turns

139+is not the hard part. Almost everyone we talk to about Urbit turns

144−out to have had pretty much the same idea themselves. The problem is

140+out to have had pretty much the same idea themselves. The problem is

145building it.

141building it.

146

142

147−A server is a computer. It's running some operating system. This OS

143+A server is a computer. It's running some operating system. This OS

148−is a flavor of Unix. There are no alternatives. It's connected to

144+is a flavor of Unix. There are no alternatives. It's connected to

149−some network. This network is the Internet. It has no competitors.

145+some network. This network is the Internet. It has no competitors.

150You can have a personal server, if it's a Unix server on the Internet.

146You can have a personal server, if it's a Unix server on the Internet.

151

147

152−Almost no one thinks being a Unix system administrator is fun. Not

148+Almost no one thinks being a Unix system administrator is fun. Not

153even Unix system administrators think running an Internet server is

149even Unix system administrators think running an Internet server is

154−fun. So the personal Unix/Internet server is like the personal

150+fun. So the personal Unix/Internet server is like the personal

155−bulldozer. This is not a consumer product. Any number of engineers

151+bulldozer. This is not a consumer product. Any number of engineers

156can't turn a bulldozer into a bicycle.

152can't turn a bulldozer into a bicycle.

157

153

158−How did we build the personal bulldozer? We didn't. We started

154+How did we build the personal bulldozer? We didn't. We started

159−from scratch. (The people who built the first PCs didn't start

155+from scratch. (The people who built the first PCs didn't start

160−with a mainframe OS, either.) We created a new platform: Urbit.

156+with a mainframe OS, either.) We created a new platform: Urbit.

161

157

162−Urbit doesn't compete with Unix and the Internet. It's a new,

158+Urbit doesn't compete with Unix and the Internet. It's a new,

163−opaque layer on top of them. Your browser runs on a native OS,

159+opaque layer on top of them. Your browser runs on a native OS,

164but it doesn't give Web apps any way to talk to the native OS.

160but it doesn't give Web apps any way to talk to the native OS.

165Urbit is like a browser for the server side: code within Urbit is

161Urbit is like a browser for the server side: code within Urbit is

166formally isolated from the platform it runs on top of.

162formally isolated from the platform it runs on top of.

167

163

168−Your urbit is a Unix process, in a data center or your PC. It sends

164+Your urbit is a Unix process, in a data center or your PC. It sends

169−UDP packets over the Internet. It can both load and serve web pages

165+UDP packets over the Internet. It can both load and serve web pages

170−over HTTP. Except for character sets and crypto, nothing in Urbit

166+over HTTP. Except for character sets and crypto, nothing in Urbit

171reuses or depends on any 20th-century code.

167reuses or depends on any 20th-century code.

172

168

173Urbit is a complete, clean-slate system software stack: a

169Urbit is a complete, clean-slate system software stack: a

174non-lambda interpreter (Nock), a functional language (Hoon), and

170non-lambda interpreter (Nock), a functional language (Hoon), and

175an event-driven OS (Arvo), with its own encrypted protocol

171an event-driven OS (Arvo), with its own encrypted protocol

176(Ames), typed revision control (Clay), reactive web server (Eyre)

172(Ames), typed revision control (Clay), reactive web server (Eyre)

177−and functional build system (Ford). The full system, including

173+and functional build system (Ford). The full system, including

178basic apps, is only 30,000 lines of Hoon.

174basic apps, is only 30,000 lines of Hoon.

179

175

180The first end-to-end prototype of Urbit took one engineer eleven

176The first end-to-end prototype of Urbit took one engineer eleven

181−years. The current beta took three more years, with about three

177+years. The current beta took three more years, with about three

182engineers on average.

178engineers on average.

183

179

184−How does it take 14 years to write 30,000 lines of code? The code

180+How does it take 14 years to write 30,000 lines of code? The code

185−wasn't the hard part. The hard part was rewriting it until it was

181+wasn't the hard part. The hard part was rewriting it until it was

186−right. We think we've solved all the real CS problems, and we're

182+right. We think we've solved all the real CS problems, and we're

187−certainly done changing major interfaces. But it will take more than

183+certainly done changing major interfaces. But it will take more than

188our small team to deliver a polished Urbit user experience that can

184our small team to deliver a polished Urbit user experience that can

189actually challenge modern web apps.

185actually challenge modern web apps.

190

186

191## Where we are, what we're doing

187## Where we are, what we're doing

192

188

193−Urbit is in feature freeze. It's a minimum viable product in

189+Urbit is in feature freeze. It's a minimum viable product in

194−early beta. It still needs quite a bit of fit-and-finish work.

190+early beta. It still needs quite a bit of fit-and-finish work.

195We certainly don't recommend it for end users or consider it in

191We certainly don't recommend it for end users or consider it in

196−any way secure. But it's fun to play with, if you're a hacker.

192+any way secure. But it's fun to play with, if you're a hacker.

197

193

198This summer, we're making the switch to an open and transparent

194This summer, we're making the switch to an open and transparent

199−development and specification process. A system as unusual as

195+development and specification process. A system as unusual as

200−Urbit can't be invented in public. But it has to be finished and

196+Urbit can't be invented in public. But it has to be finished and

201maintained in public.

197maintained in public.

202

198

203Additionally, we're creating an open political and economic process,

199Additionally, we're creating an open political and economic process,

204−with a small, fixed-price public presale of Urbit address space. Join

200+with a small, fixed-price public presale of Urbit address space. Join

205us and help make this future actually happen.

201us and help make this future actually happen.

206

202

207To keep reading, learn more about [Urbit's address

203To keep reading, learn more about [Urbit's address

208−space](/blog/the-urbit-address-space); share our vision of the Urbit user

204+space](../the-urbit-address-space); share our vision of the Urbit user

209−experience, from the [top down](/blog/what-is-urbit-for) or the [bottom

205+experience, from the [top down](../what-is-urbit-for) or the [bottom

210−up](/blog/magic); check out the [development roadmap](/blog/roadmap);

206+up](../magic); check out the [development roadmap](../roadmap);

211−evaluate Urbit's [beliefs and principles](/blog/beliefs-and-principles) or its

207+evaluate Urbit's [beliefs and principles](../beliefs-and-principles) or its

212−[interim constitution](/blog/interim-constitution).

208+[interim constitution](../interim-constitution).

213

209

214(For technical readers, check out our [documentation](https://urbit.org/docs/) or

210(For technical readers, check out our [documentation](https://urbit.org/docs/) or

215the [whitepaper](https://media.urbit.org/whitepaper.pdf)).

211the [whitepaper](https://media.urbit.org/whitepaper.pdf)).

content/blog/announcing-urbit-grants.md+2−6

@@ -1,12 +1,8 @@

1+++

1+++

2title = "Announcing: Urbit Grants Program"

2title = "Announcing: Urbit Grants Program"

3−date = "2019-08-05"

3+date = 2019-08-06

4description = "Announcing Urbit Grants, a way to earn stars through contributing."

4description = "Announcing Urbit Grants, a way to earn stars through contributing."

5−aliases = [

6− "/posts/essays/announcing-urbit-grants",

5+aliases = ["/posts/essays/announcing-urbit-grants", "/posts/announcing-urbit-grants"]

7− "/posts/announcing-urbit-grants"

8−]

9−

10[extra]

6[extra]

11author = "Robert Mariani"

7author = "Robert Mariani"

12ship = "~lodleb-ritrul"

8ship = "~lodleb-ritrul"

content/blog/ares.mddeleted−51

@@ -1,51 +0,0 @@

1−+++

2−title = "Ares"

3−date = "2023-06-26"

4−description = "A light technical description of Ares, the new Urbit runtime"

5−

6−[extra]

7−author = "Noah Kumin"

8−ship = "~librex-dozryc"

9−image = "https://storage.googleapis.com/media.urbit.org/blog/ares-header.png"

10−+++

11−

12−

13−

14−## What is Ares?

15−

16−Ares is a new Urbit runtime that will be much faster and manage a much larger amount of data than previous versions of the runtime. Those new to Urbit commonly ask if they will be able to host photos and videos on their Urbit ships. Ares—a joint project from the Urbit Foundation, Tlon, and Zorp—sets the stage for us to be able to answer, simply, “Yes.” Ares is still a work in progress, but we expect to see the new binaries rolled out later this year. There are three components to the project. Let’s talk about them one by one.

17−

18−## 1. Code Generation

19−

20−Modern CPUs are extraordinarily fast. But until now your Urbit hasn’t been able to take full advantage of this fact. One way to conceptualize the problem is to imagine a train that is only able to go as fast as a track-worker can lay down track for it. In this analogy, your CPU is the train, and the track-worker is the Urbit runtime. The aim is to have large sections of track laid down ahead of time. Ares includes a codegen system that compiles Nock, Urbit’s assembly language, to machine code that the CPU can predict well.

21−

22−This system addresses what has until now been a problem: Nock is meant to invoke other code in a given Urbit computer’s “subject.” Or, in more common parlance, in the computer’s “state.” Your state changes with every new message your Urbit computer sends and receives, or with any new event in any app. That makes it hard to make the resulting machine code run fast, since the CPU needs to read from the subject while it’s running in order to figure out what machine code will be run next.

23−

24−The new code generation process in Ares solves this problem by using a system which the developers have called “subject knowledge analysis.” What does this mean? By analyzing how an Urbit subject might change over the course of a Nock computation, Ares will learn about the subject's tree shape and about its data dependencies (*i.e.*, the way that later parts of the computation depend on earlier parts of the computation). This allows those parts of the subject which are known at the time of compiling Nock to machine code to remain known at later points in the computation.

25−

26−To go back to our metaphor of train tracks, this is what allows the “track” to be laid down ahead of time. This set of known parts of the subject typically includes Nock formulas stored in [cores](https://developers.urbit.org/guides/core/hoon-school/F-cores#cores). This allows the resulting machine code to use direct jumps to perform Nock function calls. Without this “subject knowledge analysis,” the CPU would have had to perform an “indirect jump” by calculating the location to which a later instruction would jump. Now your computer’s CPU can jump directly to where it’s supposed to go.

27−

28−## 2. 2stackz Noun Allocator

29−

30−Ares will make use of what we’re calling the *2stackz noun allocator*. With the advent of Ares, your Urbit will be a virtual machine with two stacks and no heap. What does this mean? Traditionally, a program has a *stack* and a *heap*. The stack is a linear data structure within a program used for the program’s execution. The heap is a less structured region of memory that is used for storing large pieces of data or data that you want to keep around for a while without taking up space in the stack. However, the heap is slower, because its system for allocating memory is less orderly. (Imagine, say, trying to find a specific pair of socks in a heap of clothing.)

31−

32−Ares recognizes that because Nock is much more constrained than most languages, the Urbit runtime doesn’t actually need a heap. Instead you can take the function call stack and split it in two. The top of either stack can then be used as a little temporary heap. Whenever a function executes, you copy the data that gets returned from one stack to the other. And all the intermediate products that get created when running that function (*i.e.*, other functions that got called by the initial function) sit there as *garbage* (unwanted or unused data) in between the two stacks. But you don’t have to do the same sort of bookkeeping—tracking and updating these values—that you would have to do with a heap.

33−

34−Every piece of data in your Urbit computer is a noun. A noun is an atom (a positive integer or zero) or a cell (a pair of nouns). Before Ares, both allocating and freeing a noun in the Urbit runtime were processes that took a lot of time. (To *allocate* a noun is to put that noun in memory and to *free* it is to tell your urbit that you don’t need it any more.) Ares should make both of these processes much faster. This is good news because the Urbit runtime allocates nouns (particularly pairs of nouns, known as cells) like nobody’s business.

35−

36−## 3. Persistent Memory Arena

37−

38−Ares’s Persistent Memory Arena is for managing large amounts of data within your urbit in such a way that your urbit does not get slow. If you have terabytes of data within your Urbit, you can only have a very small subset of that within your hardware’s RAM at a given time. The rest of that data is going to have to live on disk—the section of your hardware that is more capacious but takes more time to access.

39−

40−To deal with this fact, your motherboard moves data back and forth between RAM and disk depending on what data needs to be accessed at a given time. This is known as *paging*, because it does so one *page* (usually four kilobytes) at a time. Traditionally operating systems will handle paging for you, but they do it in a generic way. The Persistent Memory Arena is designed specifically for managing Urbit's single-level store.

41−

42−A *single-level store* means that there’s no distinction in the operating system between data that lives in RAM and data that lives on disk. Instead of having two levels from which you can access data, you only have one, and the system itself manages which parts of the data are in RAM and which are in disk. The Persistent Memory Arena is an optimization for handling a large amount of data in a single level store. It is for nouns that persist between computations. Using the PMA, your urbit’s state can grow large without being hemmed in by the limitations of your hardware’s RAM.

43−

44−

45−## Updates and Links

46−

47−You can find the Ares GitHub repository [here](https://github.com/urbit/ares). The technical proposal is [here](https://github.com/urbit/ares/blob/status/docs/proposal/proposal-nock-performance.md). Check back at the Urbit Google Groups [listserv](https://groups.google.com/a/urbit.org/g/dev/), the [@zodisok](https://twitter.com/zodisok) Twitter account, and the Urbit Foundation [group](https://tlon.network/lure/~halbex-palheb/uf-public) for updates about the upcoming release.

48−

49−–

50−

51−*Noah Kumin is the founder and editor in chief of the [Mars Review of Books](https://marsreview.org/).*

content/blog/august-2022-grants-program.mddeleted−73

@@ -1,73 +0,0 @@

1−+++

2−title = "August Grants Program Review"

3−date = "2022-08-30"

4−description = "The completion of the first cohort of Hoon School Live and the following App School Live program minted dozens of capable new Hoon developers. These developers are completing applications, closing out bounties, and putting together proposals at a rapid pace, with more to come as Assembly 2022 draws near."

5−[extra]

6−author = ""

7−ship = "~sarlev-sarsen"

8−image = "https://storage.googleapis.com/media.urbit.org/blog/b52.jpg"

9−+++

10−

11−

12−

13−# Completed Grants

14−

15−Recently completed grant projects include Urbit micro-blogging, Hoon-native Discord bridging, Urbit’s first arcade-style game, Port application improvements, Ethereum bookkeeping and eth-provider infrastructure.

16−

17−* [Trill](https://urbit.org/applications/~sortug/trill) and sister application [Urbit Feed Aggregator](https://urbit.org/applications/~sortug/ufa) give you a way to escape from Twitter’s algorithms while still being able to share your shower thoughts with your followers.

18−* [Faux](https://urbit.org/applications/~midsum-salrux/faux) is a transformation of the python-based Urbit to Discord bridge, turning it into a Hoon native app and offering a front-end that takes you through the setup experience, letting you to bring your Discord friends a little taste of Urbit.

19−* [Slam](https://urbit.org/applications/~hanfel-dovned/slam), everyone’s favorite new arcade game, integrates with [Gora](https://urbit.org/applications/~dalten/gora) and [pals](https://urbit.org/applications/~paldev/pals), utilizing a mechanism whereby the number of gorae held by your pals will influence the way your game is played.

20−* The [Ethereum Provider](https://urbit.org/grants/eth-provider) grant gets the network a step closer to decentralized Ethereum access, particularly for those who don’t wish to rely on an infura node.

21−* A bounty for [Port Maintenance](https://urbit.org/grants/port-maintenance) delivered iterative improvements to the Port application for those who run their ships on a local machine.

22−* And Quartus delivered [Books](https://urbit.org/applications/~doller-doller-rabsef-bicrym/books), an Ethereum address and transaction manager for you to easily append notes and memos to your on chain transactions without having to rely on a third party (as a friendly reminder, [Urbit is not yet a secure environment so please be careful](https://twitter.com/pcmonk/status/1563634078779592709?s=20&t=FN7VVjMdjyIdukSvtg5_7g) what information you store on your ship).

23−

24−

25−# Proposals

26−

27−As the above grants wrap up, more grants are coming to life. Proposals are community generated and selected projects which offer contributors the space to build whatever tooling or applications they believe Urbit needs. Each of the following projects was funded in August:

28−

29−

30−

31−* [Herd](https://urbit.org/grants/herd) - Dependency management for Citadel

32−* [Full Stop](https://urbit.org/grants/full-stop) - A menstruation tracker for Urbit

33−* [Peat](https://urbit.org/grants/peat) - Urbit’s first backup utility

34−* [Quorum](https://urbit.org/grants/quorum) - A clone of stack exchange on Urbit

35−* [Gather](https://urbit.org/grants/gather) - an Urbit native meetup tool

36−* [Olif](https://urbit.org/grants/olif) - Olfactive rendering of Urbit address space

37−* [Urbit Interface Framework](https://urbit.org/grants/urbit-interface-framework) - Framework for alternative web browser interface

38−* [Whom](https://urbit.org/grants/whom) - A profile and contacts manager

39−

40−

41−# Apprenticeships

42−

43−Apprenticeships are also bringing opportunities for hands-on developer education and enabling seasoned contributors to share knowledge through real world projects. And contributors get to earn address space as they learn the stack and grow their network.

44−

45−Three new apprenticeships began in August:

46−

47−

48−

49−* [Loom Pointer Compression](https://urbit.org/grants/loom-pointer-compression) - Work to double the size of the loom

50−* [Build a UI for Volt](https://urbit.org/grants/volt-ui) - An interface for %volt, Urbit’s lightning wallet agent

51−* [Vere Profiling](https://urbit.org/grants/profiling) - Uncovering and visualized performance bottlenecks in the runtime

52−

53−

54−# Bounties

55−

56−August also brings with it the assignment of previously open bounties to developers looking to grow their portfolio of Urbit projects. Many of bounties that found contributors are a part of [Holium’s App Dev Summer](https://www.youtube.com/watch?v=dHyzH09QaZQ), and are slated to be completed by Assembly in Miami:

57−

58−* [Minesweeper](https://urbit.org/grants/minesweeper) - A classic desktop game, now natively in hoon

59−* [Abacus](https://urbit.org/grants/abacus) - A basic calculator app with the ability to convert units

60−* [Chronicle](https://urbit.org/grants/chronicle) - A news app that links articles from group channels

61−* [Lexicon](https://urbit.org/grants/lexicon) - A simple dictionary app with custom definitions for a group

62−* [Chess Improvements](https://urbit.org/grants/chess-bounty) - An enhanced chess experience with timing and ELO servers

63−

64−Even with all the claimed bounties, there remain a variety of projects which currently seek developers. Check out the following grants and apply to those that fit your skills and interests:

65−

66−

67−* [Trove](https://urbit.org/grants/trove) - A group file sharing tool

68−* [Urbit Native Ethereum wallet](https://urbit.org/grants/eth-wallet) - An ETH wallet for Urbit maxis

69−* [UrbitSwap](https://urbit.org/grants/urbitswap) - An Urbit-hosted Uniswap instance

70−* [Tune slaw/scot jets](https://urbit.org/grants/slaw-scot-jets) - Tuning jets for better performance

71−* [New Mars Persistent Memory](https://urbit.org/grants/persistent-memory) - Development of a persistent memory arena

72−

73−Have a project that you want to help fund and think would make a good bounty? Want to propose a project about which you are passionate? Looking for a mentor to better learn a part of the Urbit ecosystem? For more information on current projects and opportunities from the Urbit Foundation’s grant program, visit [urbit.org/grants](/grants) or reach out to ~sarlev-sarsen to get involved.

content/blog/azimuth-as-multipass.md+3−6

@@ -1,12 +1,8 @@

1+++

1+++

2title = "Azimuth as Multipass"

2title = "Azimuth as Multipass"

3−date = "2019-05-15"

3+date = 2019-05-16

4description = "What if everyone had a single 'civilizational key'?"

4description = "What if everyone had a single 'civilizational key'?"

5−aliases = [

6− "/posts/essays/azimuth-as-multipass/",

5+aliases = ["/posts/essays/azimuth-as-multipass/", "/posts/azimuth-as-multipass"]

7− "/posts/azimuth-as-multipass"

8−]

9−

10[extra]

6[extra]

11author = "Galen Wolfe-Pauly"

7author = "Galen Wolfe-Pauly"

12ship = "~ravmel-ropdyl"

8ship = "~ravmel-ropdyl"

@@ -32,3 +28,4 @@ If you’re someone who’s worried about getting kidnapped, just use a child id

32Perhaps part of how we ended up in the world we’re in is that we didn’t have something like Azimuth to begin with. Today, it’s backwards: everyone has an address on the network, but no one has an identity.

28Perhaps part of how we ended up in the world we’re in is that we didn’t have something like Azimuth to begin with. Today, it’s backwards: everyone has an address on the network, but no one has an identity.

33

29

34We think everyone needs an identity that can hold money and have packets routed to it. Start there, and it’s quite fun to imagine where you end up. A civilized digital society might even be possible after all.

30We think everyone needs an identity that can hold money and have packets routed to it. Start there, and it’s quite fun to imagine where you end up. A civilized digital society might even be possible after all.

31+

content/blog/azimuth-is-on-chain.md+3−7

@@ -1,12 +1,8 @@

1+++

1+++

2title = "Azimuth is On-Chain"

2title = "Azimuth is On-Chain"

3−date = "2019-01-13"

3+date = 2019-01-14

4description = "The Urbit address space, now called Azimuth, is on the blockchain. And too many other things to fit into a single post."

4description = "The Urbit address space, now called Azimuth, is on the blockchain. And too many other things to fit into a single post."

5−aliases = [

6− "/posts/essays/azimuth-is-on-chain",

5+aliases = ["/posts/essays/azimuth-is-on-chain", "/posts/azimuth-is-on-chain"]

7− "/posts/azimuth-is-on-chain"

8−]

9−

10[extra]

6[extra]

11author = "Galen Wolfe-Pauly"

7author = "Galen Wolfe-Pauly"

12ship = "~ravmel-ropdyl"

8ship = "~ravmel-ropdyl"

@@ -68,7 +64,7 @@ So, how do you get an Azimuth point? We've left that question unanswered intenti

68

64

69Arvo boots from Ethereum, is no longer embarrassingly slow, and has a brand new build system. [Our documentation](https://urbit.org/docs/learn/arvo/hoon) has also improved quite a lot. Hoon, Arvo's programming language, has had a lot of work done to its type system and compiler. We built new tooling for generating static sites (you're probably reading this on one right now) that are much, much faster and easier to use.

65Arvo boots from Ethereum, is no longer embarrassingly slow, and has a brand new build system. [Our documentation](https://urbit.org/docs/learn/arvo/hoon) has also improved quite a lot. Hoon, Arvo's programming language, has had a lot of work done to its type system and compiler. We built new tooling for generating static sites (you're probably reading this on one right now) that are much, much faster and easier to use.

70

66

71−It's tough to talk about the progress we've made on Arvo without writing a long technical post. We'll save that for later. In a way, what's remarkable about Arvo is that it has become _less_ remarkable. It's more stable, faster, and the code quality has improved.

67+It's tough to talk about the progress we've made on Arvo without writing a long technical post. We'll save that for later. In a way, what's remarkable about Arvo is that it has become *less* remarkable. It's more stable, faster, and the code quality has improved.

72

68

73There's plenty of work to do, though. Should you be building on top of Arvo? Probably not yet. The kernel and kernel modules are really where the work still lies. We build things on top of Arvo, and in doing so it's pretty clear that the system can be better. Clay (the filesystem) and Gall (the application model) are due for a rewrite. A complete rewrite of the web server, Eyre is almost finished.

69There's plenty of work to do, though. Should you be building on top of Arvo? Probably not yet. The kernel and kernel modules are really where the work still lies. We build things on top of Arvo, and in doing so it's pretty clear that the system can be better. Clay (the filesystem) and Gall (the application model) are due for a rewrite. A complete rewrite of the web server, Eyre is almost finished.

74

70

content/blog/azimuth-security-bounty-program.md+2−6

@@ -1,12 +1,8 @@

1+++

1+++

2title = "Azimuth Security Bounty Program"

2title = "Azimuth Security Bounty Program"

3−date = "2019-07-21"

3+date = 2019-07-22

4description = "Inviting you (and your friends) to help us make Azimuth as secure as possible."

4description = "Inviting you (and your friends) to help us make Azimuth as secure as possible."

5−aliases = [

6− "/posts/essays/azimuth-security-bounty-program",

5+aliases = ["/posts/essays/azimuth-security-bounty-program", "/posts/azimuth-security-bounty-program"]

7− "/posts/azimuth-security-bounty-program"

8−]

9−

10[extra]

6[extra]

11author = "Anthony Arroyo"

7author = "Anthony Arroyo"

12ship = "~poldec-tonteg"

8ship = "~poldec-tonteg"

content/blog/beliefs-and-principles.md+24−28

@@ -1,13 +1,9 @@

1+++

1+++

2title = "Beliefs and Principles Guiding the Urbit Project"

2title = "Beliefs and Principles Guiding the Urbit Project"

3−date = "2016-05-10"

3+date = 2016-05-11

4description = "We believe."

4description = "We believe."

5−aliases = [

6− "/posts/essays/beliefs-and-principles",

5+aliases = ["/posts/essays/beliefs-and-principles",

7− "/posts/beliefs-and-principles",

6+"/posts/beliefs-and-principles", "/posts/principles"]

8− "/posts/principles"

9−]

10−

11[extra]

7[extra]

12author = "Curtis Yarvin + Galen Wolfe-Pauly"

8author = "Curtis Yarvin + Galen Wolfe-Pauly"

13ship = "~sorreg-namtyv + ~ravmel-ropdyl"

9ship = "~sorreg-namtyv + ~ravmel-ropdyl"

@@ -29,19 +25,19 @@ software, through the IETF principles of sincerity and rough consensus.

29The ability of the engineering community to govern itself through

25The ability of the engineering community to govern itself through

30republican forms is not an abstract theory; it's a proven fact.

26republican forms is not an abstract theory; it's a proven fact.

31

27

32−We believe in both free speech and individual accountability. We

28+We believe in both free speech and individual accountability. We

33believe that a healthy network is one with diverse and well-defined

29believe that a healthy network is one with diverse and well-defined

34communities, and clear, user-controlled, boundaries between public and

30communities, and clear, user-controlled, boundaries between public and

35private space.

31private space.

36

32

37We believe that no software system can replace human trust and

33We believe that no software system can replace human trust and

38−communication. Dialogue, judgment and governance are essential to

34+communication. Dialogue, judgment and governance are essential to

39−communities of all scales. Code and law can reduce conflict in the

35+communities of all scales. Code and law can reduce conflict in the

40common case; they can never handle all exceptions.

36common case; they can never handle all exceptions.

41

37

42## Principles

38## Principles

43

39

44−Here are some principles of Urbit. Where principles conflict,

40+Here are some principles of Urbit. Where principles conflict,

45the first stated takes precedence.

41the first stated takes precedence.

46

42

47### Digital independence

43### Digital independence

@@ -54,56 +50,56 @@ independence a useful and widely available product.

54### Code is law

50### Code is law

55

51

56Wherever possible, the rules of Urbit must be executable as code.

52Wherever possible, the rules of Urbit must be executable as code.

57−Wherever possible, code must be self-enforcing. If not, it must

53+Wherever possible, code must be self-enforcing. If not, it must

58−be perfectly defined. If not, it must not be stated.

54+be perfectly defined. If not, it must not be stated.

59

55

60### Sovereignty is conserved

56### Sovereignty is conserved

61

57

62Even where code is law, exceptional situations demanding

58Even where code is law, exceptional situations demanding

63−effective collective action will always arise. There must

59+effective collective action will always arise. There must

64always be a collective authority to solve these problems.

60always be a collective authority to solve these problems.

65

61

66Two known problems in Urbit that require central authority are

62Two known problems in Urbit that require central authority are

67−approval of software updates and activation of the network. But

63+approval of software updates and activation of the network. But

68there will certainly be others.

64there will certainly be others.

69

65

70### Purpose of collective authority

66### Purpose of collective authority

71

67

72−Urbit, as opposed to the Tlon corporation, is a republic. Its

68+Urbit, as opposed to the Tlon corporation, is a republic. Its

73government has one task: promoting, preserving and protecting Urbit.

69government has one task: promoting, preserving and protecting Urbit.

74−It may take any legal action which advances this goal. Any other

70+It may take any legal action which advances this goal. Any other

75−actions are _ultra vires_, out of scope. Urbit is not a

71+actions are *ultra vires*, out of scope. Urbit is not a

76general-purpose charity.

72general-purpose charity.

77

73

78### Decentralized control

74### Decentralized control

79

75

80−Urbit should never fall under any kind of central control. All

76+Urbit should never fall under any kind of central control. All

81transitions in galaxy ownership should divide positions, not

77transitions in galaxy ownership should divide positions, not

82unite them.

78unite them.

83

79

84−Galaxy and star ownership should also be separated. It is

80+Galaxy and star ownership should also be separated. It is

85harmful for a single entity to hold both galaxies and stars.

81harmful for a single entity to hold both galaxies and stars.

86

82

87### Property is contingent

83### Property is contingent

88

84

89Property rights are contingent and accidental, not moral or

85Property rights are contingent and accidental, not moral or

90−meritorious. A property register does not record why an owner

86+meritorious. A property register does not record why an owner

91−deserves some property. Ownership is neither a reward nor a

87+deserves some property. Ownership is neither a reward nor a

92right; it is a fact.

88right; it is a fact.

93

89

94### Governance is by stake

90### Governance is by stake

95

91

96−Ultimately, Urbit must be governed by those who own it. In each

92+Ultimately, Urbit must be governed by those who own it. In each

97tier, equal stakes must hold equal authority.

93tier, equal stakes must hold equal authority.

98

94

99### Content-neutral

95### Content-neutral

100

96

101Urbit does not admit a tradeoff between anarchy and tyranny,

97Urbit does not admit a tradeoff between anarchy and tyranny,

102−order and liberty. Urbit has zero tolerance for abuse, nor does

98+order and liberty. Urbit has zero tolerance for abuse, nor does

103it facilitate censorship.

99it facilitate censorship.

104

100

105Urbit will do everything possible to help you block content you

101Urbit will do everything possible to help you block content you

106−don't want to see. It does nothing to help you block content you

102+don't want to see. It does nothing to help you block content you

107don't want others to see.

103don't want others to see.

108

104

109### Trolling considered harmful

105### Trolling considered harmful

@@ -115,12 +111,12 @@ properly for automatic blocking.

115### Sockpuppets considered harmful

111### Sockpuppets considered harmful

116

112

117The only legitimate reason for one individual to use multiple

113The only legitimate reason for one individual to use multiple

118−identities is to maintain multiple active pseudonyms. But

114+identities is to maintain multiple active pseudonyms. But

119multiple identities must never interact in the same context.

115multiple identities must never interact in the same context.

120

116

121### Not a darknet

117### Not a darknet

122

118

123−Urbit is not a darknet. It does not break real-world laws. It

119+Urbit is not a darknet. It does not break real-world laws. It

124is not designed to facilitate the breaking of real-world laws.

120is not designed to facilitate the breaking of real-world laws.

125For any problem that lawbreakers have, there must always be a

121For any problem that lawbreakers have, there must always be a

126better solution that is not Urbit.

122better solution that is not Urbit.

@@ -129,6 +125,6 @@ better solution that is not Urbit.

129

125

130As long as they are not facilitating violations of any of these

126As long as they are not facilitating violations of any of these

131principles, or laws in their own jurisdictions, stars and

127principles, or laws in their own jurisdictions, stars and

132−galaxies are responsible for routing their children. They are

128+galaxies are responsible for routing their children. They are

133also collectively responsible for escape-routing the children of

129also collectively responsible for escape-routing the children of

134stars and galaxies which fail in their responsibility.

130stars and galaxies which fail in their responsibility.

content/blog/bootstrapping-urbit-from-ethereum.md+21−28

@@ -1,20 +1,13 @@

1+++

1+++

2title = "Bootstrapping Urbit from Ethereum"

2title = "Bootstrapping Urbit from Ethereum"

3−date = "2017-09-19"

3+date = 2017-09-20

4description = "We've decided to launch Urbit's constitution as a system of Ethereum contracts."

4description = "We've decided to launch Urbit's constitution as a system of Ethereum contracts."

5−aliases = [

6− "/posts/essays/bootstrapping-urbit-from-ethereum",

5+aliases = ["/posts/essays/bootstrapping-urbit-from-ethereum", "/posts/bootstrapping-urbit-from-ethereum", "/blog/2017.9.20-bootstrapping-urbit-from-ethereum/", "/blog/2017.9-eth/"]

7− "/posts/bootstrapping-urbit-from-ethereum",

8− "/blog/2017.9.20-bootstrapping-urbit-from-ethereum/",

9− "/blog/2017.9-eth/"

10−]

11−

12[extra]

6[extra]

13author = "Curtis Yarvin + Galen Wolfe-Pauly"

7author = "Curtis Yarvin + Galen Wolfe-Pauly"

14ship = "~sorreg-namtyv + ~ravmel-ropdyl"

8ship = "~sorreg-namtyv + ~ravmel-ropdyl"

15+++

9+++

16−

17−_TL;DR:_

10+*TL;DR:*

18

11

19We've decided to launch Urbit's constitution as a system of Ethereum contracts.

12We've decided to launch Urbit's constitution as a system of Ethereum contracts.

20

13

@@ -26,49 +19,49 @@ auction stars, and stars to distribute planets.

26## A bit of background

19## A bit of background

27

20

28One thing we realized after the last sale was, 'oh hey, the network has been up

21One thing we realized after the last sale was, 'oh hey, the network has been up

29−for about a year.' Not bad! It wasn't that long ago that we were rebooting the

22+for about a year.' Not bad! It wasn't that long ago that we were rebooting the

30−universe every few weeks. We still have plenty of work to do — but Urbit has

23+universe every few weeks. We still have plenty of work to do — but Urbit has

31matured to the point where public ownership of the network really should be

24matured to the point where public ownership of the network really should be

32cryptographically real.

25cryptographically real.

33

26

34But even when the servers stay up, Urbit is still a testnet and remains

27But even when the servers stay up, Urbit is still a testnet and remains

35−centralized in practice. We (Tlon) retain the ability to reset the network keys

28+centralized in practice. We (Tlon) retain the ability to reset the network keys

36−at any time. This just isn't very 2017.

29+at any time. This just isn't very 2017.

37

30

38In theory, Urbit doesn't need a blockchain, because real estate moves slowly.

31In theory, Urbit doesn't need a blockchain, because real estate moves slowly.

39In digital real estate, as opposed to digital currency, a low-friction,

32In digital real estate, as opposed to digital currency, a low-friction,

40zero-trust solution to the double-spend problem isn't an economic necessity.

33zero-trust solution to the double-spend problem isn't an economic necessity.

41

34

42−In practice, though, we have a hard chicken-egg problem. In the current design,

35+In practice, though, we have a hard chicken-egg problem. In the current design,

43the key you use to secure your urbit is the same key that you use to sign your

36the key you use to secure your urbit is the same key that you use to sign your

44−network packets. Abstractly, this is the right design -- you want one

37+network packets. Abstractly, this is the right design -- you want one

45definition of who owns an identity.

38definition of who owns an identity.

46

39

47But concretely, since Urbit keys are valuable, you don't want to put them in an

40But concretely, since Urbit keys are valuable, you don't want to put them in an

48−operating system that isn't generally recognized as systematically secure. It's

41+operating system that isn't generally recognized as systematically secure. It's

49−hard to achieve this status while you're a testnet. So the virtuous cycle never

42+hard to achieve this status while you're a testnet. So the virtuous cycle never

50gets started.

43gets started.

51

44

52Moving the Urbit land registry to Ethereum is an easy and obvious solution to

45Moving the Urbit land registry to Ethereum is an easy and obvious solution to

53−this problem. If your urbit is owned by an offline Ethereum key, there's now a

46+this problem. If your urbit is owned by an offline Ethereum key, there's now a

54−mature ecosystem for protecting this property. And its security doesn't depend

47+mature ecosystem for protecting this property. And its security doesn't depend

55on the security of Urbit. So, we realized, maybe Urbit actually does need a

48on the security of Urbit. So, we realized, maybe Urbit actually does need a

56−blockchain for its land registry. While the system matures, we can bootstrap

49+blockchain for its land registry. While the system matures, we can bootstrap

57off of Ethereum, without changing the design of the Urbit cryptosystem.

50off of Ethereum, without changing the design of the Urbit cryptosystem.

58

51

59And best of all, you can get your Urbit star or planet entirely through the

52And best of all, you can get your Urbit star or planet entirely through the

60blockchain, without interacting with any centralized database or payment

53blockchain, without interacting with any centralized database or payment

61−mechanism. So we're really living in 2017.

54+mechanism. So we're really living in 2017.

62

55

63Sounds good, right?

56Sounds good, right?

64

57

65−It does sound good. Although, as usual, we care about making things that _work_

58+It does sound good. Although, as usual, we care about making things that *work*

66−above all else. So, rather than a 'announcing the Urbit token sale' post, this

59+above all else. So, rather than a 'announcing the Urbit token sale' post, this

67−is going to get fairly technical. We want to start the discussion about how

60+is going to get fairly technical. We want to start the discussion about how

68−this change is going to work, and how it's going to get implemented. We'll save

61+this change is going to work, and how it's going to get implemented. We'll save

69the hype for later.

62the hype for later.

70

63

71−First, we'll walk through the costs and benefits of using Ethereum. Then,

64+First, we'll walk through the costs and benefits of using Ethereum. Then,

72we'll refresh our memories on how the Urbit address space works, and finally

65we'll refresh our memories on how the Urbit address space works, and finally

73we'll walk through some of the details of how we plan on implementing this.

66we'll walk through some of the details of how we plan on implementing this.

74We've thought quite thoroughly about these things, but public criticism is

67We've thought quite thoroughly about these things, but public criticism is

@@ -221,7 +214,7 @@ Following Ethereum best practice, we'll use separate storage and logic

221contracts. The logic contract is stateless, and can upgrade itself without

214contracts. The logic contract is stateless, and can upgrade itself without

222replacing the storage contracts.

215replacing the storage contracts.

223

216

224−We'll walk through how we have designed these contracts in detail here. You can

217+We'll walk through how we have designed these contracts in detail here. You can

225also view our in-progress source at the

218also view our in-progress source at the

226[`urbit/azimuth` GitHub repo](https://github.com/urbit/azimuth).

219[`urbit/azimuth` GitHub repo](https://github.com/urbit/azimuth).

227

220

content/blog/common-objections-to-urbit.md+213−218

@@ -1,23 +1,18 @@

1+++

1+++

2title = "Common Objections to Urbit"

2title = "Common Objections to Urbit"

3−date = "2016-06-27"

3+date = 2016-06-28

4description = "Some common objections to Urbit, discussed."

4description = "Some common objections to Urbit, discussed."

5−aliases = [

6− "/posts/essays/common-objections-to-urbit",

5+aliases = ["/posts/essays/common-objections-to-urbit", "/posts/common-objections-to-urbit", "/posts/objections/"]

7− "/posts/common-objections-to-urbit",

8− "/posts/objections/"

9−]

10−

11[extra]

6[extra]

12author = "Curtis Yarvin"

7author = "Curtis Yarvin"

13ship = "~sorreg-namtyv"

8ship = "~sorreg-namtyv"

14−image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/common-objections-to-urbit-1.jpg"

9+image ="https://storage.googleapis.com/media.urbit.org/site/posts/essays/common-objections-to-urbit-1.jpg"

15+++

10+++

16

11

17

12

18

13

19−We love crowdsourced criticism. We've heard a lot of great

14+We love crowdsourced criticism. We've heard a lot of great

20−objections to Urbit. Surely there's more out there! We'll

15+objections to Urbit. Surely there's more out there! We'll

21revise this document to include anything new and interesting.

16revise this document to include anything new and interesting.

22

17

23Here's our list right now:

18Here's our list right now:

@@ -26,12 +21,12 @@ Here's our list right now:

26- [Nock jets are a total hoax.](#jets)

21- [Nock jets are a total hoax.](#jets)

27- [Urbit needs an infinitely extending packet/event log.](#log)

22- [Urbit needs an infinitely extending packet/event log.](#log)

28- [Urbit is a total scamcoin. It's 100% premined.](#scam)

23- [Urbit is a total scamcoin. It's 100% premined.](#scam)

29−- [Urbit isn't even really decentralized! It has a government!](#gov)

24+- [Urbit isn't even really decentralized! It has a government!](#gov)

30- [Sandstorm/IPFS/Ethereum is way ahead of Urbit.](#sand)

25- [Sandstorm/IPFS/Ethereum is way ahead of Urbit.](#sand)

31- [Urbit doesn't have enough planets for every human being.](#planet)

26- [Urbit doesn't have enough planets for every human being.](#planet)

32- [Cloud computing is inherently non-private.](#pwned)

27- [Cloud computing is inherently non-private.](#pwned)

33- [Urbit will never be able to call any existing code.](#code)

28- [Urbit will never be able to call any existing code.](#code)

34−- [Hoon is too weird. No one will be able to program in it.](#program)

29+- [Hoon is too weird. No one will be able to program in it.](#program)

35- [Urbit programmers are stuck with Hoon.](#stuck)

30- [Urbit programmers are stuck with Hoon.](#stuck)

36- [Ordinary users will never be able to manage an Urbit server.](#user)

31- [Ordinary users will never be able to manage an Urbit server.](#user)

37- [Urbit has no killer app.](#killer)

32- [Urbit has no killer app.](#killer)

@@ -40,89 +35,89 @@ Here's our list right now:

40_"We choose to go to the moon, not because it is easy, but because it is hard."_

35_"We choose to go to the moon, not because it is easy, but because it is hard."_

41— [John F. Kennedy](https://www.youtube.com/watch?v=g25G1M4EXrQ)

36— [John F. Kennedy](https://www.youtube.com/watch?v=g25G1M4EXrQ)

42

37

43−## Urbit is not ready for prime time. {% #prime %}

38+## <a name="prime"></a>Urbit is not ready for prime time.

44

39

45−_TLDR_: we agree.

40+*TLDR*: we agree.

46

41

47−Urbit right now is a fun toy. It is fun to learn Hoon. It is

42+Urbit right now is a fun toy. It is fun to learn Hoon. It is

48even fun and quite practical to make actual contributions.

43even fun and quite practical to make actual contributions.

49(Hoon's IEEE floating-point was written by someone we've never

44(Hoon's IEEE floating-point was written by someone we've never

50−met: `~nym`, formerly `~nodpet-rinned`.) In fact, we have never

45+met: `~nym`, formerly `~nodpet-rinned`.) In fact, we have never

51seen anyone _not_ have fun with Urbit.

46seen anyone _not_ have fun with Urbit.

52

47

53−But there is all kinds of stuff wrong with the codebase. Urbit's

48+But there is all kinds of stuff wrong with the codebase. Urbit's

54documentation is much improved, but remains incredibly weak --

49documentation is much improved, but remains incredibly weak --

55−Arvo is almost totally undocumented. Scaling is poor at best.

50+Arvo is almost totally undocumented. Scaling is poor at best.

56−Urbit's reliability is dubious. Its security is nil.

51+Urbit's reliability is dubious. Its security is nil.

57

52

58−Urbit is feature-frozen. The only thing we're working on now,

53+Urbit is feature-frozen. The only thing we're working on now,

59and for the rest of 2016, is doc, debugging and and self-hosting.

54and for the rest of 2016, is doc, debugging and and self-hosting.

60In that order of importance -- teaching Urbit is more important

55In that order of importance -- teaching Urbit is more important

61than fixing it, which is more important than making it useful.

56than fixing it, which is more important than making it useful.

62But we're quite confident that these are all solvable problems.

57But we're quite confident that these are all solvable problems.

63

58

64The most important milestone about Urbit today is that it's ready

59The most important milestone about Urbit today is that it's ready

65−for technical decisions to be made collectively. A system like

60+for technical decisions to be made collectively. A system like

66−Urbit can only be invented by a mad auteur. It can't be

61+Urbit can only be invented by a mad auteur. It can't be

67−maintained or stabilized by a mad auteur. Our primary goal today

62+maintained or stabilized by a mad auteur. Our primary goal today

68is expanding the number of people who understand Urbit, and we

63is expanding the number of people who understand Urbit, and we

69expect these pioneers to participate in technical governance.

64expect these pioneers to participate in technical governance.

70

65

71−## Nock jets are a total hoax. {% #jets %}

66+## <a name="jets"></a>Nock jets are a total hoax.

72

67

73−_TLDR_: all of computing is a hoax. You can't compare a hoax

68+*TLDR*: all of computing is a hoax. You can't compare a hoax

74−to nothing. You can only compare it to all the other hoaxes.

69+to nothing. You can only compare it to all the other hoaxes.

75

70

76−A "jet" is a sort of software device driver in Urbit. Urbit is

71+A "jet" is a sort of software device driver in Urbit. Urbit is

77precisely defined in terms of an interpreter that fits on a

72precisely defined in terms of an interpreter that fits on a

78−T-shirt, Nock. But a naive implementation of Nock is nowhere

73+T-shirt, Nock. But a naive implementation of Nock is nowhere

79near practical, because Nock has only one integer operation:

74near practical, because Nock has only one integer operation:

80−increment. For example, to decrement a number in Nock, you

75+increment. For example, to decrement a number in Nock, you

81increment a counter up to the number under it.

76increment a counter up to the number under it.

82

77

83The only way an efficient Nock interpreter can work is to

78The only way an efficient Nock interpreter can work is to

84recognize algorithms like decrement, and implement them

79recognize algorithms like decrement, and implement them

85−non-naively. By far the easiest way to do this is not to analyze

80+non-naively. By far the easiest way to do this is not to analyze

86arbitrary code as it's being executed, but to register and match

81arbitrary code as it's being executed, but to register and match

87−well-known implementations in the standard library. No one

82+well-known implementations in the standard library. No one

88should be writing their own decrement.

83should be writing their own decrement.

89

84

90But the semantics of the interpreter, _so long as the jet and the

85But the semantics of the interpreter, _so long as the jet and the

91jet harness are defined correctly_, are exactly those of Nock.

86jet harness are defined correctly_, are exactly those of Nock.

92−We are not extending or changing Nock in any way. We are just

87+We are not extending or changing Nock in any way. We are just

93taking a shortcut in certain cases we understand perfectly.

88taking a shortcut in certain cases we understand perfectly.

94

89

95It's not at all unprecedented to have implementations much more

90It's not at all unprecedented to have implementations much more

96−complex than the corresponding specification. The x86

91+complex than the corresponding specification. The x86

97instruction set is relatively simple; the complexity of its

92instruction set is relatively simple; the complexity of its

98−decoding and execution path in a modern CPU is enormous. This

93+decoding and execution path in a modern CPU is enormous. This

99path may well have "peephole optimizations" that replace matched

94path may well have "peephole optimizations" that replace matched

100−algorithms, and if it doesn't the modern compiler does. People,

95+algorithms, and if it doesn't the modern compiler does. People,

101_bad_ people, use "jets" to cheat on benchmarks all the time.

96_bad_ people, use "jets" to cheat on benchmarks all the time.

102

97

103−Nock is designed as a standard. It's built like a standard.

98+Nock is designed as a standard. It's built like a standard.

104Typically what causes real problems in standards is ambiguity.

99Typically what causes real problems in standards is ambiguity.

105Two implementations are incompatible, but each swears it has the

100Two implementations are incompatible, but each swears it has the

106−right interpretation of the natural-language spec. This simply

101+right interpretation of the natural-language spec. This simply

107−cannot happen in the Nock world. If two implementations

102+cannot happen in the Nock world. If two implementations

108−disagree, at least one of them is incorrect. This puts us firmly

103+disagree, at least one of them is incorrect. This puts us firmly

109in "with enough eyeballs, all bugs are shallow" territory.

104in "with enough eyeballs, all bugs are shallow" territory.

110

105

111The fact remains, however, that a Nock interpreter without jets

106The fact remains, however, that a Nock interpreter without jets

112−is completely useless. And there is not even an informal

107+is completely useless. And there is not even an informal

113document that tells you what jets you need for a reasonably

108document that tells you what jets you need for a reasonably

114−efficient Urbit. (There should be such a document.)

109+efficient Urbit. (There should be such a document.)

115

110

116The correct way to think about jets is not to compare them to a

111The correct way to think about jets is not to compare them to a

117−perfect interpreter created by unicorns. Jets are a combined

112+perfect interpreter created by unicorns. Jets are a combined

118replacement for two other techniques in language implementation:

113replacement for two other techniques in language implementation:

119intrinsics and a foreign-function interface.

114intrinsics and a foreign-function interface.

120

115

121Compared to both intrinsics and an FFI, your jets have one key

116Compared to both intrinsics and an FFI, your jets have one key

122−disadvantage: they need to be specified in pure code. You may

117+disadvantage: they need to be specified in pure code. You may

123not have this executable specification, which means you need to

118not have this executable specification, which means you need to

124−write it. Is this really so bad for your development process?

119+write it. Is this really so bad for your development process?

125−An executable specification? Which can be trivially tested

120+An executable specification? Which can be trivially tested

126against the efficient implementation?

121against the efficient implementation?

127

122

128Compared to intrinsics, jets give you true separation between

123Compared to intrinsics, jets give you true separation between

@@ -130,7 +125,7 @@ mechanism and policy; only the interpreter, not the programmer

130and not the compiler, needs to know what's accelerated.

125and not the compiler, needs to know what's accelerated.

131

126

132Compared to an FFI, jets preclude I/O, so can be trivially

127Compared to an FFI, jets preclude I/O, so can be trivially

133−sandboxed. Except that the programmer needs to mark routines

128+sandboxed. Except that the programmer needs to mark routines

134which may benefit from optimization with a hint, here too we

129which may benefit from optimization with a hint, here too we

135separate mechanism (efficient implementation) from policy.

130separate mechanism (efficient implementation) from policy.

136

131

@@ -138,41 +133,41 @@ Yes, formal verification of jet equivalence is desirable.

138However, in the real world, many specifications, including quite

133However, in the real world, many specifications, including quite

139complex ones, are tested into equivalence by brute force.

134complex ones, are tested into equivalence by brute force.

140

135

141−Urbit has some jet abuses. The equivalence between our markdown

136+Urbit has some jet abuses. The equivalence between our markdown

142−parser in Hoon and the CommonMark C library is super dubious. It

137+parser in Hoon and the CommonMark C library is super dubious. It

143should be revisited.

138should be revisited.

144

139

145But the miscomputation resulting from a minor jet discrepancy is

140But the miscomputation resulting from a minor jet discrepancy is

146−not a security hole or even fatal. It effectively means the

141+not a security hole or even fatal. It effectively means the

147event history, computed correctly, does not match the current

142event history, computed correctly, does not match the current

148−state. The way to resolve this conflict is for the current state

143+state. The way to resolve this conflict is for the current state

149to win, and the event history to be discarded -- not abnormal

144to win, and the event history to be discarded -- not abnormal

150−anyway. See the next question.

145+anyway. See the next question.

151

146

152−## Urbit needs an infinitely extending packet/event. {% #log %}

147+## <a name="log"></a>Urbit needs an infinitely extending packet/event.

153

148

154−_TLDR_: no, it doesn't. Urbit can prune the log.

149+*TLDR*: no, it doesn't. Urbit can prune the log.

155

150

156We can prune the event log because the Urbit transition function

151We can prune the event log because the Urbit transition function

157doesn't have any access to the event history -- just the current

152doesn't have any access to the event history -- just the current

158state and the current event.

153state and the current event.

159

154

160−Urbit defines the semantics of a complete event log. It doesn't

155+Urbit defines the semantics of a complete event log. It doesn't

161and can't require an implementation to maintain the whole log.

156and can't require an implementation to maintain the whole log.

162It can maintain a checkpoint and the log since that checkpoint.

157It can maintain a checkpoint and the log since that checkpoint.

163

158

164However, any practical urbit maintains a periodically updated

159However, any practical urbit maintains a periodically updated

165−checkpoint. Our present implementation doesn't provide a way to

160+checkpoint. Our present implementation doesn't provide a way to

166−prune the event log. But that's just a missing feature. We have

161+prune the event log. But that's just a missing feature. We have

167one or two of those!

162one or two of those!

168

163

169−## Urbit is a total scamcoin. It's 100% premined. {% #scam %}

164+## <a name="scam"></a>Urbit is a total scamcoin. It's 100% premined.

170

165

171−_TLDR_: yeah. But at least it's not the DAO.

166+*TLDR*: yeah. But at least it's not the DAO.

172

167

173−Like a cryptocurrency, Urbit is a digital title. But Urbit is

168+Like a cryptocurrency, Urbit is a digital title. But Urbit is

174−digital land, not digital money. If you assess it as a currency,

169+digital land, not digital money. If you assess it as a currency,

175−it's a lousy currency. If you assess a cat as a dog, it's a

170+it's a lousy currency. If you assess a cat as a dog, it's a

176lousy dog.

171lousy dog.

177

172

178In real-world economics, the crucial distinction between land and

173In real-world economics, the crucial distinction between land and

@@ -180,25 +175,25 @@ money is that land (a) has intrinsic utility and (b) is

180non-fungible.

175non-fungible.

181

176

182Because of (b) alone, frictionless transactions in land are

177Because of (b) alone, frictionless transactions in land are

183−impossible. A blockchain is only needed to ensure zero-cost

178+impossible. A blockchain is only needed to ensure zero-cost

184−high-frequency transactions. So digital land doesn't need a

179+high-frequency transactions. So digital land doesn't need a

185−blockchain. Which means it doesn't need mining.

180+blockchain. Which means it doesn't need mining.

186

181

187Of course, just because a digital title system doesn't need

182Of course, just because a digital title system doesn't need

188mining, doesn't mean it can't distribute an initial allocation by

183mining, doesn't mean it can't distribute an initial allocation by

189proof-of-work -- or by any other arbitrary method which is

184proof-of-work -- or by any other arbitrary method which is

190−careful not to benefit the system's own developers. Could we

185+careful not to benefit the system's own developers. Could we

191−give away the Urbit address space randomly? Sure. But why?

186+give away the Urbit address space randomly? Sure. But why?

192

187

193Probably the purest design is the "proof-of-burn" initial

188Probably the purest design is the "proof-of-burn" initial

194−allocation used by some coins. By any standard, proof-of-burn is

189+allocation used by some coins. By any standard, proof-of-burn is

195technically beautiful and results in an extraordinary level of

190technically beautiful and results in an extraordinary level of

196−ethical independence. We can't help but admire it.

191+ethical independence. We can't help but admire it.

197

192

198−But any altcoin or metacoin is just way less work than Urbit. An

193+But any altcoin or metacoin is just way less work than Urbit. An

199altcoin can afford to burn even its creation energy, capturing no

194altcoin can afford to burn even its creation energy, capturing no

200−value at all from its seigniorage. Your altcoin doesn't have a

195+value at all from its seigniorage. Your altcoin doesn't have a

201−clean-slate system software stack to drive. If your rocket has

196+clean-slate system software stack to drive. If your rocket has

202to go to the moon, it's going to leave a little bit of smoke in

197to go to the moon, it's going to leave a little bit of smoke in

203the air.

198the air.

204

199

@@ -207,78 +202,78 @@ of the currency are rewarded disproportionately for their effort.

207The scamcoin is a get-rich-quick scheme, vaguely pyramid-shaped.

202The scamcoin is a get-rich-quick scheme, vaguely pyramid-shaped.

208Nothing about Urbit matches this pattern at all.

203Nothing about Urbit matches this pattern at all.

209

204

210−Curtis invented Urbit. So by the [homestead

205+Curtis invented Urbit. So by the [homestead

211principle](https://en.wikipedia.org/wiki/Homestead_principle), he

206principle](https://en.wikipedia.org/wiki/Homestead_principle), he

212−started out owning all of it. But by now, Urbit's 8-bit galaxies

207+started out owning all of it. But by now, Urbit's 8-bit galaxies

213have already been distributed among [57 separate individuals](https://github.com/urbit/arvo/blob/master/sys/vane/ames.hoon#L118-L373).

208have already been distributed among [57 separate individuals](https://github.com/urbit/arvo/blob/master/sys/vane/ames.hoon#L118-L373).

214Curtis owns 20, or about 8%.

209Curtis owns 20, or about 8%.

215

210

216Tlon, the corporation which still runs Urbit development, has 95.

211Tlon, the corporation which still runs Urbit development, has 95.

217−(Without Tlon, there is basically no Arvo.) 50 are reserved for

212+(Without Tlon, there is basically no Arvo.) 50 are reserved for

218−a hypothetical Urbit Foundation. Tlon employees have another 16.

213+a hypothetical Urbit Foundation. Tlon employees have another 16.

219

214

220The rest of the galaxies belong to donors, investors,

215The rest of the galaxies belong to donors, investors,

221contributors, contest winners, and just random people who were in

216contributors, contest winners, and just random people who were in

222−the right place at the right time. One is a Silicon Valley

217+the right place at the right time. One is a Silicon Valley

223−tycoon. Another is an Orthodox nun in a monastery in Greece. A

218+tycoon. Another is an Orthodox nun in a monastery in Greece. A

224−couple are ex-Tlon employees who might totally hate us. There is

219+couple are ex-Tlon employees who might totally hate us. There is

225nothing they all have in common, which is sort of the point.

220nothing they all have in common, which is sort of the point.

226

221

227This property distribution looks a lot like land ownership in the

222This property distribution looks a lot like land ownership in the

228−real world -- complex and asymmetrical. That's no accident. If

223+real world -- complex and asymmetrical. That's no accident. If

229you have a problem living in New York because New York's real

224you have a problem living in New York because New York's real

230estate is not distributed equally among its residents, you may

225estate is not distributed equally among its residents, you may

231−have a similar problem with Urbit. The reality is that Urbit,

226+have a similar problem with Urbit. The reality is that Urbit,

232like New York, wasn't born yesterday and comes with a complex

227like New York, wasn't born yesterday and comes with a complex

233ownership history which we couldn't possibly change, even if we

228ownership history which we couldn't possibly change, even if we

234wanted to.

229wanted to.

235

230

236−Decentralization is hard. The only real goal of a property

231+Decentralization is hard. The only real goal of a property

237system in address space is to create and maintain

232system in address space is to create and maintain

238−decentralization. The whole network has to exhibit centrifugal

233+decentralization. The whole network has to exhibit centrifugal

239−force, not centripetal force. Proof-of-work systems certainly

234+force, not centripetal force. Proof-of-work systems certainly

240seem to have unexpected centripetal qualities, producing

235seem to have unexpected centripetal qualities, producing

241−unanticipated concentrations of centralized hashpower. See the

236+unanticipated concentrations of centralized hashpower. See the

242next objection.

237next objection.

243

238

244−## Urbit isn't even really decentralized! It has a government! {% #gov %}

239+## <a name="gov"></a>Urbit isn't even really decentralized! It has a government!

245

240

246−_TLDR_: it's technically impossible for Urbit to be

241+*TLDR*: it's technically impossible for Urbit to be

247−decentralized at this stage of its life. Urbit is designed to

242+decentralized at this stage of its life. Urbit is designed to

248achieve decentralization, not be born with it.

243achieve decentralization, not be born with it.

249

244

250−A young network can't afford to be decentralized. It has to act

245+A young network can't afford to be decentralized. It has to act

251−as a unit. Because it has no network effect, it needs every

246+as a unit. Because it has no network effect, it needs every

252scrap of efficiency it can get.

247scrap of efficiency it can get.

253

248

254A decentralized general-purpose computing network like Urbit can

249A decentralized general-purpose computing network like Urbit can

255−_only_ be bootstrapped by a central government. For example, by

250+_only_ be bootstrapped by a central government. For example, by

256default your urbit upgrades its OS automatically (like an

251default your urbit upgrades its OS automatically (like an

257−"evergreen" browser) with signed network updates. Whoever signs

252+"evergreen" browser) with signed network updates. Whoever signs

258these updates is a government by definition.

253these updates is a government by definition.

259

254

260When it's impossible to eliminate centralized power, it becomes

255When it's impossible to eliminate centralized power, it becomes

261−necessary to tame, stabilize, and limit it. This should not be

256+necessary to tame, stabilize, and limit it. This should not be

262surprising to anyone living under a constitutional government.

257surprising to anyone living under a constitutional government.

263

258

264As we found out with the DAO, if a network isn't ready to be

259As we found out with the DAO, if a network isn't ready to be

265−decentralized, its developers shouldn't even try. If Ethereum is

260+decentralized, its developers shouldn't even try. If Ethereum is

266hard-forked to roll back the DAO (which looks like the most

261hard-forked to roll back the DAO (which looks like the most

267probable result), it acknowledges that it both has a central

262probable result), it acknowledges that it both has a central

268−government, and needs a central government. Decentralization is

263+government, and needs a central government. Decentralization is

269−good. Pretend decentralization -- "decentralization theater" --

264+good. Pretend decentralization -- "decentralization theater" --

270is harmful, and not a effective path to actual decentralization.

265is harmful, and not a effective path to actual decentralization.

271

266

272A key test of a free software project's health is whether it can

267A key test of a free software project's health is whether it can

273−fork. So long as the unity of the public-key hierarchy and the

268+fork. So long as the unity of the public-key hierarchy and the

274network protocol is maintained, the Arvo kernel and Urbit system

269network protocol is maintained, the Arvo kernel and Urbit system

275can fork in all kinds of ways without disrupting the network.

270can fork in all kinds of ways without disrupting the network.

276Any stress will fragment the "government" that develops the

271Any stress will fragment the "government" that develops the

277kernel, and as it fragments it grows more limited and stable.

272kernel, and as it fragments it grows more limited and stable.

278

273

279Urbit is designed to govern itself collectively by address space

274Urbit is designed to govern itself collectively by address space

280−ownership -- effectively, "proof of stake." Any arbitrary power,

275+ownership -- effectively, "proof of stake." Any arbitrary power,

281−will tend to fracture along these property lines. For instance,

276+will tend to fracture along these property lines. For instance,

282our hot updates are sent through the galaxy hierarchy; in a

277our hot updates are sent through the galaxy hierarchy; in a

283development fork, active galaxies would pick upstream sources.

278development fork, active galaxies would pick upstream sources.

284Two implementations of a standard are better than one.

279Two implementations of a standard are better than one.

@@ -288,8 +283,8 @@ we've created a global property map which is much more likely to

288splinter further, than reunite.

283splinter further, than reunite.

289

284

290In the long run, every galaxy should have a separate owner, who

285In the long run, every galaxy should have a separate owner, who

291−is a human being rather than a corporation. Combining galaxy

286+is a human being rather than a corporation. Combining galaxy

292−holdings will damage the reputation of both galaxies. The only

287+holdings will damage the reputation of both galaxies. The only

293reason to merge ownership is to move toward incipient monopoly.

288reason to merge ownership is to move toward incipient monopoly.

294Whether a galaxy admits this openly or denies it dishonestly, its

289Whether a galaxy admits this openly or denies it dishonestly, its

295reputation will suffer.

290reputation will suffer.

@@ -297,61 +292,61 @@ reputation will suffer.

297The technical goal of Urbit is to create a network which, _if it

292The technical goal of Urbit is to create a network which, _if it

298actually takes over the world_, inevitably becomes decentralized.

293actually takes over the world_, inevitably becomes decentralized.

299Even if Urbit takes over the world, no individual or coherent

294Even if Urbit takes over the world, no individual or coherent

300−organization takes over the world. There is nothing even close

295+organization takes over the world. There is nothing even close

301to a single point of failure in a mature, successful Urbit.

296to a single point of failure in a mature, successful Urbit.

302

297

303−This is the goal of all the new "web3" decentralized systems. If

298+This is the goal of all the new "web3" decentralized systems. If

304IPFS, Sandstorm or Ethereum takes over the world, nobody takes

299IPFS, Sandstorm or Ethereum takes over the world, nobody takes

305−over the world. (The same is almost true of the Internet --

300+over the world. (The same is almost true of the Internet --

306though it wouldn't be that surprising if a time traveler from

301though it wouldn't be that surprising if a time traveler from

3072116 revealed that ICANN had become a planetary government.)

3022116 revealed that ICANN had become a planetary government.)

308

303

309Urbit, by starting out as a centralized network, just reduces the

304Urbit, by starting out as a centralized network, just reduces the

310−technical problem to match the actual goal. Only long-term

305+technical problem to match the actual goal. Only long-term

311decentralization matters.

306decentralization matters.

312

307

313It's very important that Urbit in 2116 be fully decentralized.

308It's very important that Urbit in 2116 be fully decentralized.

314For Urbit in 2016, pretending to be decentralized would be a joke

309For Urbit in 2016, pretending to be decentralized would be a joke

315−at best, and a hoax at worst. And of course, no one can DAO us

310+at best, and a hoax at worst. And of course, no one can DAO us

316-- since the property system is still just a central registry.

311-- since the property system is still just a central registry.

317−Among other things, we check it into GitHub. GitHub is not a

312+Among other things, we check it into GitHub. GitHub is not a

318blockchain -- but still, good luck with that.

313blockchain -- but still, good luck with that.

319

314

320−## Sandstorm/IPFS/Ethereum is way ahead of Urbit. {% #sand %}

315+## <a name="sand"></a>Sandstorm/IPFS/Ethereum is way ahead of Urbit.

321

316

322In general, web3 (next distributed web) solutions don't compete

317In general, web3 (next distributed web) solutions don't compete

323−with each other. They support each other. Concretely, they are

318+with each other. They support each other. Concretely, they are

324all part of each others' network effect.

319all part of each others' network effect.

325

320

326IPFS, Sandstorm, Ethereum, and Urbit can all take over the world

321IPFS, Sandstorm, Ethereum, and Urbit can all take over the world

327−at the same time. None of them competes with the others. They

322+at the same time. None of them competes with the others. They

328enable each other.

323enable each other.

329

324

330For instance, IPFS and Urbit are both global immutable

325For instance, IPFS and Urbit are both global immutable

331−namespaces. IPFS is a chord-routed, content-addressed namespace.

326+namespaces. IPFS is a chord-routed, content-addressed namespace.

332−Urbit is a direct-routed, identity-addressed namespace. Urbit is

327+Urbit is a direct-routed, identity-addressed namespace. Urbit is

333−a typed revision-control system; IPFS is a blob store. IPFS

328+a typed revision-control system; IPFS is a blob store. IPFS

334isn't a computer; the work hasn't been done, but Urbit can easily

329isn't a computer; the work hasn't been done, but Urbit can easily

335mount the IPFS namespace and compute functionally against it.

330mount the IPFS namespace and compute functionally against it.

336

331

337So the better IPFS does, the less Urbit needs to struggle against

332So the better IPFS does, the less Urbit needs to struggle against

338−its lack of network effect. The better Urbit does, the easier it

333+its lack of network effect. The better Urbit does, the easier it

339is for IPFS to point to a functional language that can actually

334is for IPFS to point to a functional language that can actually

340−use its referential transparency directly. So their relationship

335+use its referential transparency directly. So their relationship

341is symbiotic, not competitive at all.

336is symbiotic, not competitive at all.

342

337

343The closest thing to a general-purpose competitor that Urbit has

338The closest thing to a general-purpose competitor that Urbit has

344−is Sandstorm. Sandstorm, which by the way rocks, is also a

339+is Sandstorm. Sandstorm, which by the way rocks, is also a

345personal server built around a network protocol.

340personal server built around a network protocol.

346

341

347But Sandstorm and Urbit compete in the way that, on the PC, the

342But Sandstorm and Urbit compete in the way that, on the PC, the

348−OS and the browser compete. In theory, the OS could solve the

343+OS and the browser compete. In theory, the OS could solve the

349problems that the browser solves; or the browser could be the OS.

344problems that the browser solves; or the browser could be the OS.

350In practice, Windows is a great OS to run a browser on.

345In practice, Windows is a great OS to run a browser on.

351

346

352Similarly, a world in which Sandstorm takes off is an awesome

347Similarly, a world in which Sandstorm takes off is an awesome

353world for Urbit, because everyone who has a Sandstorm instance

348world for Urbit, because everyone who has a Sandstorm instance

354−has a great platform for running Urbit on. Urbit on Sandstorm

349+has a great platform for running Urbit on. Urbit on Sandstorm

355will be a sort of "double-hulled" personal server, safer and more

350will be a sort of "double-hulled" personal server, safer and more

356friendly than either system alone.

351friendly than either system alone.

357

352

@@ -359,24 +354,24 @@ Sandstorm and Urbit have very different approaches to network

359identification; Sandstorm uses capabilities, Urbit identity.

354identification; Sandstorm uses capabilities, Urbit identity.

360Broadly speaking, we believe, capabilities are optimal for

355Broadly speaking, we believe, capabilities are optimal for

361expressive power; but identity is optimal for the UI of the

356expressive power; but identity is optimal for the UI of the

362−common case. We'd need to see the Powerbox, Sandstorm's UI, more

357+common case. We'd need to see the Powerbox, Sandstorm's UI, more

363fully fleshed out to understand its UI approach better.

358fully fleshed out to understand its UI approach better.

364

359

365−## Urbit doesn't have enough planets for every human {% #planet %}

360+## <a name="planet"></a>Urbit doesn't have enough planets for every human

366

361

367−A 32-bit planet is a tool, not a toy. Like a car, it's a device

362+A 32-bit planet is a tool, not a toy. Like a car, it's a device

368−for a responsible and independent adult. There aren't 4 billion

363+for a responsible and independent adult. There aren't 4 billion

369cars in the world, nor 4 billion independent adults.

364cars in the world, nor 4 billion independent adults.

370

365

371If you aren't an independent adult, and you don't need or even

366If you aren't an independent adult, and you don't need or even

372shouldn't have unconditional digital freedom (no one's 8-year-old

367shouldn't have unconditional digital freedom (no one's 8-year-old

373daughter needs unconditional digital freedom), a moon from

368daughter needs unconditional digital freedom), a moon from

374−someone else's planet is fine. (Even most of today's independent

369+someone else's planet is fine. (Even most of today's independent

375adults don't complain enough about being Facebook's moons.)

370adults don't complain enough about being Facebook's moons.)

376

371

377And limiting the supply of anything doesn't create a shortage.

372And limiting the supply of anything doesn't create a shortage.

378−It sets a price. Ideally, in the long run, we think a planet

373+It sets a price. Ideally, in the long run, we think a planet

379−should cost about $10. This could be off by an order of

374+should cost about $10. This could be off by an order of

380magnitude either way, and it wouldn't be the end of the world.

375magnitude either way, and it wouldn't be the end of the world.

381

376

382If a planet costs $10, that means you paid $10 to get a planet.

377If a planet costs $10, that means you paid $10 to get a planet.

@@ -388,51 +383,51 @@ social network social.

388There is always a tradeoff between free speech and free beer.

383There is always a tradeoff between free speech and free beer.

389Urbit will always choose free speech.

384Urbit will always choose free speech.

390

385

391−## Cloud computing is inherently non-private. {% #pwned %}

386+## <a name="pwned"></a>Cloud computing is inherently non-private.

392

387

393−_TLDR_: a general-purpose cloud computer is much, much more

388+*TLDR*: a general-purpose cloud computer is much, much more

394−private than a special-purpose cloud computer. In general, a

389+private than a special-purpose cloud computer. In general, a

395cloud VM is secure against corporations but not governments.

390cloud VM is secure against corporations but not governments.

396With a global adversary, compute in your closet -- or even on

391With a global adversary, compute in your closet -- or even on

397your body.

392your body.

398

393

399One reason we want the decentralized Internet is that we're tired

394One reason we want the decentralized Internet is that we're tired

400−of giant corporations spying on us. Think about it this way:

395+of giant corporations spying on us. Think about it this way:

401−Amazon is Netflix's main competitor. And yet, Netflix runs its

396+Amazon is Netflix's main competitor. And yet, Netflix runs its

402−whole operation on AWS. Why is Netflix sure that Amazon won't

397+whole operation on AWS. Why is Netflix sure that Amazon won't

403spy on it?

398spy on it?

404

399

405A general-purpose virtual machine is special from a privacy

400A general-purpose virtual machine is special from a privacy

406standpoint, just because it's commercially realistic to design

401standpoint, just because it's commercially realistic to design

407terms of service that prevent the host from peeking and poking at

402terms of service that prevent the host from peeking and poking at

408−the customer's machine. Crossing this moat is technically

403+the customer's machine. Crossing this moat is technically

409nontrivial and can't possibly happen by any reasonable accident.

404nontrivial and can't possibly happen by any reasonable accident.

410No hosting contract could contemplate it.

405No hosting contract could contemplate it.

411

406

412Whereas when your cloud computer is a special-purpose machine --

407Whereas when your cloud computer is a special-purpose machine --

413just a database row on some corporation's mainframe -- there is

408just a database row on some corporation's mainframe -- there is

414no way these services can promise not to handle your data.

409no way these services can promise not to handle your data.

415−Handling your data is _what they do_. On a special-purpose

410+Handling your data is _what they do_. On a special-purpose

416server, the concept of privacy is not even defined.

411server, the concept of privacy is not even defined.

417

412

418Where even a general-purpose server falls down is where the user

413Where even a general-purpose server falls down is where the user

419has a sovereign adversary, which can secretly violate explicit or

414has a sovereign adversary, which can secretly violate explicit or

420−implicit hosting contracts. Users with a sovereign adversary

415+implicit hosting contracts. Users with a sovereign adversary

421must rely only on their own physical security.

416must rely only on their own physical security.

422

417

423−However, most users don't have a sovereign adversary. And those

418+However, most users don't have a sovereign adversary. And those

424who do maximize their "herd immunity" if they can use the same

419who do maximize their "herd immunity" if they can use the same

425−protocols as those who don't. Otherwise, the adversary could

420+protocols as those who don't. Otherwise, the adversary could

426simply focus on everyone who uses the secure protocols.

421simply focus on everyone who uses the secure protocols.

427

422

428−Also, the portability of a cloud server image is critical. Of

423+Also, the portability of a cloud server image is critical. Of

429course, since Urbit is formally specified, it's trivially

424course, since Urbit is formally specified, it's trivially

430−portable. In fact, one strategy against sovereign adversaries

425+portable. In fact, one strategy against sovereign adversaries

431may be continuous rotation between hosts, like an MX missile.

426may be continuous rotation between hosts, like an MX missile.

432

427

433−## Urbit will never be able to call any existing code. {% #code %}

428+## <a name="code"></a>Urbit will never be able to call any existing code.

434

429

435−_TLDR_: neither will Javascript. And dear Unix, the browser

430+*TLDR*: neither will Javascript. And dear Unix, the browser

436does not miss interacting with your `$LD_LIBRARY_PATH` at all.

431does not miss interacting with your `$LD_LIBRARY_PATH` at all.

437

432

438You can't talk to the OS or use system libraries from Javascript.

433You can't talk to the OS or use system libraries from Javascript.

@@ -441,31 +436,31 @@ compatibility bridge, native methods, or other interface between

441Javascript and C.

436Javascript and C.

442

437

443When in doubt, remember that Urbit is "the browser for the server

438When in doubt, remember that Urbit is "the browser for the server

444−side." It plays by the same general rules. Isolation means

439+side." It plays by the same general rules. Isolation means

445isolation.

440isolation.

446

441

447−## There's no way Urbit will ever be adopted. It's too weird. {% #weird %}

442+## <a name="weird"></a>There's no way Urbit will ever be adopted. It's too weird.

448

443

449−_TLDR_: Urbit adoption is designed to be driven by ordinary end

444+*TLDR*: Urbit adoption is designed to be driven by ordinary end

450−users. Urbit isn't ready for ordinary end users yet. We're

445+users. Urbit isn't ready for ordinary end users yet. We're

451working on it -- come help.

446working on it -- come help.

452

447

453−Right now, Urbit is a developer tool. Or rather, a developer toy

448+Right now, Urbit is a developer tool. Or rather, a developer toy

454−-- since the only thing it's useful for is developing Urbit. It

449+-- since the only thing it's useful for is developing Urbit. It

455−also could be a much better toy. We're working on that too.

450+also could be a much better toy. We're working on that too.

456

451

457But it's absolutely wrong to think of Urbit being adopted as a

452But it's absolutely wrong to think of Urbit being adopted as a

458−developer tool in the conventional sense. If you think this is

453+developer tool in the conventional sense. If you think this is

459almost impossible, you're right.

454almost impossible, you're right.

460

455

461If we look at the way most successful platforms are adopted,

456If we look at the way most successful platforms are adopted,

462−they're not adopted for their own virtues. They're adopted

457+they're not adopted for their own virtues. They're adopted

463−because they're part of a larger solution. It's very hard to

458+because they're part of a larger solution. It's very hard to

464−displace a native component of an existing platform. Urbit is

459+displace a native component of an existing platform. Urbit is

465not trying to do this.

460not trying to do this.

466

461

467C is a better language than Pascal, but it didn't beat Pascal

462C is a better language than Pascal, but it didn't beat Pascal

468−because it's a better language. C beat Pascal because C was the

463+because it's a better language. C beat Pascal because C was the

469native language of Unix, and people wanted to program in Unix.

464native language of Unix, and people wanted to program in Unix.

470People don't use Javascript because Javascript is a great

465People don't use Javascript because Javascript is a great

471language, but because it's the native language of the browser.

466language, but because it's the native language of the browser.

@@ -473,9 +468,9 @@ Replacing the native language of a platform may be doable -- but

473it's incredibly hard.

468it's incredibly hard.

474

469

475Hoon is not competing with C, or even Haskell, as a Unix

470Hoon is not competing with C, or even Haskell, as a Unix

476−programming language. The only reason to program in Hoon is that

471+programming language. The only reason to program in Hoon is that

477−it's the native language of Urbit. Urbit is not competing with

472+it's the native language of Urbit. Urbit is not competing with

478−node.js or Rails as a Web backend. The only reason to run Urbit

473+node.js or Rails as a Web backend. The only reason to run Urbit

479is to run a personal server.

474is to run a personal server.

480

475

481Nock is cool, but it only gets adopted if Hoon gets adopted.

476Nock is cool, but it only gets adopted if Hoon gets adopted.

@@ -484,9 +479,9 @@ Urbit only gets adopted if it's useful as a personal server for

484human beings -- most of whom won't be Hoon programmers, or

479human beings -- most of whom won't be Hoon programmers, or

485programmers at all.

480programmers at all.

486

481

487−## Hoon is too weird. No one will be able to program in it. {% #program %}

482+## <a name="program"></a>Hoon is too weird. No one will be able to program in it.

488

483

489−_TLDR_: Hoon is ridiculously simple. Our documentation and

484+*TLDR*: Hoon is ridiculously simple. Our documentation and

490tooling are just immature.

485tooling are just immature.

491

486

492It's pretty fair to assume that (a) functional programming is

487It's pretty fair to assume that (a) functional programming is

@@ -496,94 +491,94 @@ so (c) Hoon must be hard-squared.

496Actually, Hoon is weird even for a functional language because

491Actually, Hoon is weird even for a functional language because

497it's an attempt to remove the hardest things about functional

492it's an attempt to remove the hardest things about functional

498programming: category theory, lazy evaluation, and gratuitous

493programming: category theory, lazy evaluation, and gratuitous

499−abstraction. To know a language is to know what the compiler is

494+abstraction. To know a language is to know what the compiler is

500doing; all the semantics of the Hoon compiler fit in 2000 lines

495doing; all the semantics of the Hoon compiler fit in 2000 lines

501of code.

496of code.

502

497

503It's too easy for us to wind up living in Isaac Asimov's Trantor,

498It's too easy for us to wind up living in Isaac Asimov's Trantor,

504a world in which everything got invented thousands of years ago

499a world in which everything got invented thousands of years ago

505−and the idea of new technology is just weird and scary. History

500+and the idea of new technology is just weird and scary. History

506isn't over yet, and nor is technical history.

501isn't over yet, and nor is technical history.

507

502

508−New things are harder to learn than old things. We ask smart

503+New things are harder to learn than old things. We ask smart

509−high-school students to learn calculus. Think about how much

504+high-school students to learn calculus. Think about how much

510harder it was for Newton and Leibniz to invent calculus, or for

505harder it was for Newton and Leibniz to invent calculus, or for

511−their first students to pick it up. Hoon is nowhere near as hard

506+their first students to pick it up. Hoon is nowhere near as hard

512as calculus.

507as calculus.

513

508

514Most of the difference is just the collective certainty that our

509Most of the difference is just the collective certainty that our

515society conveys to a high-school student that calculus is

510society conveys to a high-school student that calculus is

516−learnable. When you're learning Urbit, you don't have this

511+learnable. When you're learning Urbit, you don't have this

517collective knowledge; so you don't have the confidence that the

512collective knowledge; so you don't have the confidence that the

518−problem is solvable. Confidence makes a huge difference.

513+problem is solvable. Confidence makes a huge difference.

519Moreover, any bug or glitch in the developer experience destroys

514Moreover, any bug or glitch in the developer experience destroys

520this confidence and takes a long time to heal.

515this confidence and takes a long time to heal.

521

516

522−Yes, we know: Hoon remains quite hard to learn. Again, we have

517+Yes, we know: Hoon remains quite hard to learn. Again, we have

523−no reason to think this problem isn't solvable. Public

518+no reason to think this problem isn't solvable. Public

524enlightenment remains our main priority.

519enlightenment remains our main priority.

525

520

526−## Urbit programmers are stuck with Hoon. {% #stuck %}

521+## <a name="stuck"></a>Urbit programmers are stuck with Hoon.

527

522

528−_TLDR_: patience, grasshopper.

523+*TLDR*: patience, grasshopper.

529

524

530There's quite a straightforward way to implement any perfectly

525There's quite a straightforward way to implement any perfectly

531−specified language with a reliable interpreter in Hoon. First,

526+specified language with a reliable interpreter in Hoon. First,

532−write an interpreter for that language in Hoon. Second, jet that intepreter function with the existing implementation.

527+write an interpreter for that language in Hoon. Second, jet that intepreter function with the existing implementation.

533

528

534It is not clear that Javascript is _quite_ well-defined enough

529It is not clear that Javascript is _quite_ well-defined enough

535−for this treatment. But Lua probably is.

530+for this treatment. But Lua probably is.

536

531

537−## Ordinary users will never be able to manage an Urbit server. {% #user %}

532+## <a name="user"></a>Ordinary users will never be able to manage an Urbit server.

538

533

539−_TLDR_: Urbit's technical simplicity has always been designed

534+*TLDR*: Urbit's technical simplicity has always been designed

540−to drive human usability. But the polish is the last thing that

535+to drive human usability. But the polish is the last thing that

541−goes on. So we can't evaluate this claim right now.

536+goes on. So we can't evaluate this claim right now.

542

537

543−Right now, Urbit is only for geeks. You already need to be able

538+Right now, Urbit is only for geeks. You already need to be able

544−to wrangle a Unix machine to run it. What's the point?

539+to wrangle a Unix machine to run it. What's the point?

545

540

546−This Urbit isn't the real Urbit. It's an early milestone on the

541+This Urbit isn't the real Urbit. It's an early milestone on the

547way to the real Urbit.

542way to the real Urbit.

548

543

549The real Urbit -- for normal human beings -- is a hosted service.

544The real Urbit -- for normal human beings -- is a hosted service.

550−Getting a planet is as easy as signing up for Facebook. Probably

545+Getting a planet is as easy as signing up for Facebook. Probably

551−many users will think of it as another web account. They might

546+many users will think of it as another web account. They might

552not even know it can run more apps than the ones they use.

547not even know it can run more apps than the ones they use.

553

548

554A deterministic, persistent cloud computer is something different

549A deterministic, persistent cloud computer is something different

555−from a traditional server. Normally when we think of a server in

550+from a traditional server. Normally when we think of a server in

556the cloud, we think of it like a live animal -- a creature that

551the cloud, we think of it like a live animal -- a creature that

557−needs to be cared for, fed, and herded. A file in the cloud is

552+needs to be cared for, fed, and herded. A file in the cloud is

558more like a rock -- you can forget about it for ten years.

553more like a rock -- you can forget about it for ten years.

559

554

560An urbit is a general-purpose computer, but it doesn't even have

555An urbit is a general-purpose computer, but it doesn't even have

561−the concept of a reboot. It upgrades itself. If you don't feed

556+the concept of a reboot. It upgrades itself. If you don't feed

562it any packets for ten years, then turn it back on, it will spend

557it any packets for ten years, then turn it back on, it will spend

563−a day or two upgrading itself, then be back to normal. Maybe

558+a day or two upgrading itself, then be back to normal. Maybe

564it's something in between a rock and an animal -- a cactus?

559it's something in between a rock and an animal -- a cactus?

565

560

566Another huge difference versus an Internet server is that we're

561Another huge difference versus an Internet server is that we're

567confident that Urbit's limited supply of identities will make it

562confident that Urbit's limited supply of identities will make it

568−easy to keep abusers off the network. So far, so good -- but of

563+easy to keep abusers off the network. So far, so good -- but of

569course, no one abuses a young network.

564course, no one abuses a young network.

570

565

571The bottom line is that managing your urbit has to be as easy as

566The bottom line is that managing your urbit has to be as easy as

572−managing your iPhone. Normally, it consists of deciding what

567+managing your iPhone. Normally, it consists of deciding what

573apps you want to be running, and how much you trust them.

568apps you want to be running, and how much you trust them.

574Resources can't be free, so sometimes you have to play memory

569Resources can't be free, so sometimes you have to play memory

575−police. Humans have shown that they can handle these tasks.

570+police. Humans have shown that they can handle these tasks.

576

571

577Our '70s OSes and networks, which were great designs in their day

572Our '70s OSes and networks, which were great designs in their day

578and have matured into excellent industrial tools, give us a

573and have matured into excellent industrial tools, give us a

579totally misleading impression of how hard it should be to manage

574totally misleading impression of how hard it should be to manage

580−a general-purpose computer. Computing isn't scary or dangerous.

575+a general-purpose computer. Computing isn't scary or dangerous.

581−Unix and the Internet are scary and dangerous. That's fine for

576+Unix and the Internet are scary and dangerous. That's fine for

582an industrial tool, but not a personal tool.

577an industrial tool, but not a personal tool.

583

578

584−## Urbit has no killer app. {% #killer %}

579+## <a name="killer"></a>Urbit has no killer app.

585

580

586−_TLDR_: the killer app is personal API aggregation.

581+*TLDR*: the killer app is personal API aggregation.

587

582

588It's a truism that any new platform has to be fundamentally much

583It's a truism that any new platform has to be fundamentally much

589better at solving some problem than the mature platform it seeks

584better at solving some problem than the mature platform it seeks

@@ -596,7 +591,7 @@ From the developer's perspective, Urbit's advantage is that it's

596a network stack which provides exactly-once delivery of typed,

591a network stack which provides exactly-once delivery of typed,

597validated, transactional, encrypted and authenticated messages.

592validated, transactional, encrypted and authenticated messages.

598The difference between an Urbit API and a REST API is like the

593The difference between an Urbit API and a REST API is like the

599−difference between a paved road and a dirt road. On the other

594+difference between a paved road and a dirt road. On the other

600hand, you do need to learn a new functional language.

595hand, you do need to learn a new functional language.

601

596

602From the user's perspective, there's one task that any personal

597From the user's perspective, there's one task that any personal

@@ -605,14 +600,14 @@ unrestricted API aggregation.

605

600

606Well before Urbit is ready to _replace_ any conventional web

601Well before Urbit is ready to _replace_ any conventional web

607services, it should be ready to _command_ them in place by API.

602services, it should be ready to _command_ them in place by API.

608−(Or if needed, by scraping.) If all you care about is being in

603+(Or if needed, by scraping.) If all you care about is being in

609control of your own data, it's fine to leave it in the hands of

604control of your own data, it's fine to leave it in the hands of

610these services, as you have the API secrets to get it out.

605these services, as you have the API secrets to get it out.

611

606

612Managing a set of security connections to your existing services

607Managing a set of security connections to your existing services

613is one of the first important tasks of a modern personal server.

608is one of the first important tasks of a modern personal server.

614This is a stateful task that typically requires both a durable

609This is a stateful task that typically requires both a durable

615−API key and a temporary OAuth token. APIs change all the time,

610+API key and a temporary OAuth token. APIs change all the time,

616so connection maintenance also requires evergreen updates.

611so connection maintenance also requires evergreen updates.

617

612

618The origin of this API key will vary, but usually the best way to

613The origin of this API key will vary, but usually the best way to

@@ -624,7 +619,7 @@ do with your own data.

624

619

625Terms of service which constrain the use of data (as opposed to

620Terms of service which constrain the use of data (as opposed to

626the abuse of the service) simply aren't realistic and will no

621the abuse of the service) simply aren't realistic and will no

627−longer apply. This enables a variety of novel user experiences

622+longer apply. This enables a variety of novel user experiences

628which aren't implementable as traditional web services, and also

623which aren't implementable as traditional web services, and also

629aren't available via conventional third-party API aggregators.

624aren't available via conventional third-party API aggregators.

630

625

@@ -632,41 +627,41 @@ Also, since Urbit is after all quite immature, it doesn't make

632much sense to restrict this security state to code within Urbit.

627much sense to restrict this security state to code within Urbit.

633The Urbit interpreter `vere` runs as a Unix daemon that

628The Urbit interpreter `vere` runs as a Unix daemon that

634implements the FUSE user-level filesystem protocol, and maps the

629implements the FUSE user-level filesystem protocol, and maps the

635−data on your services into the Unix filesystem. For example, one

630+data on your services into the Unix filesystem. For example, one

636of our demos lets you `ls` your GitHub issues.

631of our demos lets you `ls` your GitHub issues.

637

632

638So it's straightforward to build, for instance, a Python app that

633So it's straightforward to build, for instance, a Python app that

639−uses Urbit as a gateway to mash up a bunch of web services. As a

634+uses Urbit as a gateway to mash up a bunch of web services. As a

640Unix programmer, you might even just regard Urbit as a generic

635Unix programmer, you might even just regard Urbit as a generic

641Web API gateway daemon, without worrying about its internals.

636Web API gateway daemon, without worrying about its internals.

642

637

643−We have other ideas for initial killer apps. But this, we feel,

638+We have other ideas for initial killer apps. But this, we feel,

644−is the best one. API libraries for `npm` et al abound.

639+is the best one. API libraries for `npm` et al abound.

645Stateful, self-updating, generic API aggregators with FUSE

640Stateful, self-updating, generic API aggregators with FUSE

646integration, also integrated with a reactive web server, are

641integration, also integrated with a reactive web server, are

647rarer.

642rarer.

648

643

649−## Urbit is sniffed at by Houyhnhyms. {% #horse %}

644+## <a name="horse"></a> Urbit is sniffed at by Houyhnhyms.

650

645

651It's difficult to categorize [this awesome

646It's difficult to categorize [this awesome

652essay](http://ngnghm.github.io/blog/2016/06/11/chapter-10-houyhnhnms-vs-martians/)

647essay](http://ngnghm.github.io/blog/2016/06/11/chapter-10-houyhnhnms-vs-martians/)

653−in a single bullet point. So I've saved it for last.

648+in a single bullet point. So I've saved it for last.

654

649

655When reading this essay, it's important not to forget the amazing

650When reading this essay, it's important not to forget the amazing

656absence of genuine, mutually critical discourse in computer

651absence of genuine, mutually critical discourse in computer

657−science (as in most sciences today). You never hear what Swift's

652+science (as in most sciences today). You never hear what Swift's

658−designers think of Go, or vice versa. And critical public

653+designers think of Go, or vice versa. And critical public

659discourse decreases, not increases, with increasing academic

654discourse decreases, not increases, with increasing academic

660legitimacy.

655legitimacy.

661

656

662The basic test of any field purportedly scientific in nature is

657The basic test of any field purportedly scientific in nature is

663whether its researchers are genuinely interested in each others'

658whether its researchers are genuinely interested in each others'

664−work, and willing to share these genuine responses publicly. If

659+work, and willing to share these genuine responses publicly. If

665this practice does not exist, the field may still be useful

660this practice does not exist, the field may still be useful

666−and/or interesting. But it is not science.

661+and/or interesting. But it is not science.

667

662

668What's awesome about Fare's essay is that he's _doing it right_.

663What's awesome about Fare's essay is that he's _doing it right_.

669−All the actual details are irrelevant. And mostly wrong. But

664+All the actual details are irrelevant. And mostly wrong. But

670that's of very little importance compared to _doing it right_.

665that's of very little importance compared to _doing it right_.

671

666

672Anyway, we've already addressed the idea that jets are a sham.

667Anyway, we've already addressed the idea that jets are a sham.

@@ -675,11 +670,11 @@ Some other points:

675### Event-sourcing and/or caching is a pattern, not a layer

670### Event-sourcing and/or caching is a pattern, not a layer

676

671

677Fare' is perfectly right that "one size does not fit all" in

672Fare' is perfectly right that "one size does not fit all" in

678−persistence. Generally, Urbit uses event-sourced persistence.

673+persistence. Generally, Urbit uses event-sourced persistence.

679

674

680But it has multiple layers of event-sourcing: in the definition

675But it has multiple layers of event-sourcing: in the definition

681of Urbit itself; in the application sandbox vane (Gall), and in

676of Urbit itself; in the application sandbox vane (Gall), and in

682−the application itself. Urbit also has a completely orthogonal

677+the application itself. Urbit also has a completely orthogonal

683revision control system (Clay).

678revision control system (Clay).

684

679

685And there is not a single cache across the whole system, though

680And there is not a single cache across the whole system, though

@@ -693,33 +688,33 @@ or feature, and equally fatal whichever direction you fail.

693### Let's be clear about why DSLs suck

688### Let's be clear about why DSLs suck

694

689

695DSLs suck not because they are difficult to newbies in the base

690DSLs suck not because they are difficult to newbies in the base

696−language. DSLs suck because every time a programmer, even one

691+language. DSLs suck because every time a programmer, even one

697_experienced_ in the base language, comes into a new codebase or

692_experienced_ in the base language, comes into a new codebase or

698project, she has to learn a new custom language.

693project, she has to learn a new custom language.

699

694

700−You need enormous wins to justify this cost. It's the goal of

695+You need enormous wins to justify this cost. It's the goal of

701the base language designer to preempt these wins, creating a

696the base language designer to preempt these wins, creating a

702language which is almost never so tiresome and full of

697language which is almost never so tiresome and full of

703boilerplate that it requires a DSL or template layer.

698boilerplate that it requires a DSL or template layer.

704

699

705Hoon is almost entirely made of macros -- but they are internal,

700Hoon is almost entirely made of macros -- but they are internal,

706−fixed, built-in macros (with no gensyms). This fixed set of

701+fixed, built-in macros (with no gensyms). This fixed set of

707−macros is essentially enough. Occasionally we want to add one or

702+macros is essentially enough. Occasionally we want to add one or

708−two. But we never, ever pine for context-dependent macros.

703+two. But we never, ever pine for context-dependent macros.

709

704

710### Determinism is not consensus, and is not constraining

705### Determinism is not consensus, and is not constraining

711

706

712Fare' is totally right that an urbit's data is meant for itself

707Fare' is totally right that an urbit's data is meant for itself

713−alone. In fact, an urbit has the right to compute incorrectly if

708+alone. In fact, an urbit has the right to compute incorrectly if

714−it wants. We go to considerable lengths to ensure that you can't

709+it wants. We go to considerable lengths to ensure that you can't

715gain any particular advantage by incorrect computing.

710gain any particular advantage by incorrect computing.

716

711

717The whole point of Nock is that it's so low-level that there is

712The whole point of Nock is that it's so low-level that there is

718−no conceivable advantage in upgrading it. Divergence is just

713+no conceivable advantage in upgrading it. Divergence is just

719−pointless. This is not a question of network integrity, just of

714+pointless. This is not a question of network integrity, just of

720practical standardization.

715practical standardization.

721

716

722−This consistency stops at Nock. Without anyone violating the

717+This consistency stops at Nock. Without anyone violating the

723correctness of their lifecycle functions, anyone or everyone in

718correctness of their lifecycle functions, anyone or everyone in

724−Urbit could replace Hoon with Javascript. Determinism does not

719+Urbit could replace Hoon with Javascript. Determinism does not

725cramp Urbit's semantic style in any way, shape or form.

720cramp Urbit's semantic style in any way, shape or form.

content/blog/community-spotlight-the-portico.md+9−10

@@ -1,17 +1,16 @@

1+++

1+++

2title = "Community Spotlight: The Portico"

2title = "Community Spotlight: The Portico"

3−date = "2021-05-03"

3+date = 2021-05-04

4description = "Interview with The Portico founder Josh Reagan"

4description = "Interview with The Portico founder Josh Reagan"

5−

6[extra]

5[extra]

7−author = "Matt"

6+author = "~tirwyd-sarmes"

8ship = "~tirwyd-sarmes"

7ship = "~tirwyd-sarmes"

9image = "https://media.urbit.org/site/posts/essays/orthodoxchurch.jpg"

8image = "https://media.urbit.org/site/posts/essays/orthodoxchurch.jpg"

10+++

9+++

11

10

12

11

13

12

14−_One of the most striking things about Urbit is the ideological diversity between communities. The Community Spotlight blog series will focus on various Urbit communities via interviews with founding members._

13+*One of the most striking things about Urbit is the ideological diversity between communities. The Community Spotlight blog series will focus on various Urbit communities via interviews with founding members.*

15

14

16For the first week of the Community Spotlight series, I (~tirwyd-sarmes) will be speaking with Josh Reagan (~taglux-nidsep). Josh is the founder of The Portico, an Urbit community of Eastern Orthodox Christians.

15For the first week of the Community Spotlight series, I (~tirwyd-sarmes) will be speaking with Josh Reagan (~taglux-nidsep). Josh is the founder of The Portico, an Urbit community of Eastern Orthodox Christians.

17

16

@@ -27,13 +26,13 @@ I encourage you to take a look. Find The Portico at ~topnup-firber/the-portico.

27

26

28\-\-\-\-

27\-\-\-\-

29

28

30−**Do you see any connection between Rod Dreher’s _The Benedict Option_ and your community on Urbit? Dreher sees a need for American Christians to create self-sustaining communities outside of the mainstream to protect the Christian religion and culture.**

29+**Do you see any connection between Rod Dreher’s *The Benedict Option* and your community on Urbit? Dreher sees a need for American Christians to create self-sustaining communities outside of the mainstream to protect the Christian religion and culture.**

31

30

32−It’s tough to say with certainty—I’ve never read _The Benedict Option_.

31+It’s tough to say with certainty—I’ve never read *The Benedict Option*.

33

32

34A few years ago, while he was writing the book, I was a regular reader of Dreher’s blog. From his descriptions there, I was never clear about what exactly he was proposing. Much of his “clarification” came by way of metaphor: don’t “run for the hills”, but stop “shoring up the American imperium”. I didn’t read his book because I didn’t have much confidence that he would be especially precise or insightful.

33A few years ago, while he was writing the book, I was a regular reader of Dreher’s blog. From his descriptions there, I was never clear about what exactly he was proposing. Much of his “clarification” came by way of metaphor: don’t “run for the hills”, but stop “shoring up the American imperium”. I didn’t read his book because I didn’t have much confidence that he would be especially precise or insightful.

35

34

36−[There is an interesting review I’d recommend](https://handleshaus.wordpress.com/2020/10/06/review-of-rod-drehers-live-not-by-lies/), however, of his later book, _Live Not By Lies_. I believe it accurately characterizes the scale of the threat Christians will soon face in this country.

35+[There is an interesting review I’d recommend](https://handleshaus.wordpress.com/2020/10/06/review-of-rod-drehers-live-not-by-lies/), however, of his later book, *Live Not By Lies*. I believe it accurately characterizes the scale of the threat Christians will soon face in this country.

37

36

38My upbringing was conservative Christian and self-consciously counter-cultural. I've inherited that understanding of what it means to be a Christian in an increasingly secular world. It comes naturally to me, so I find it obvious that Christians should form self-sustaining communities. But the details matter. What do such communities look like? How do we secure the freedom to pursue such communities? How do we sustain them, when myriad external forces seek to undermine them? How do we solve the long-term problem of the declining cultural importance of Christianity (which surely erodes the plausibility of our religion to many, even to some of those with sympathies toward it)?

37My upbringing was conservative Christian and self-consciously counter-cultural. I've inherited that understanding of what it means to be a Christian in an increasingly secular world. It comes naturally to me, so I find it obvious that Christians should form self-sustaining communities. But the details matter. What do such communities look like? How do we secure the freedom to pursue such communities? How do we sustain them, when myriad external forces seek to undermine them? How do we solve the long-term problem of the declining cultural importance of Christianity (which surely erodes the plausibility of our religion to many, even to some of those with sympathies toward it)?

39

38

@@ -63,7 +62,7 @@ None of these options is appealing. Tarski came up with a solution that mostly s

63

62

64Is Tarski’s definition of truth in a language the definitive solution for preserving truth, math, and logic? Perhaps not many philosophers think so, and there’s a massive literature in which logicians have attempted to improve on or extend his results.

63Is Tarski’s definition of truth in a language the definitive solution for preserving truth, math, and logic? Perhaps not many philosophers think so, and there’s a massive literature in which logicians have attempted to improve on or extend his results.

65

64

66−Sometimes people seem to think formal logic is an infallible gift from heaven that must always be right. Kant said in the _Critique of Pure Reason_ that formal logic is essentially a completed field. In fact, [the logic of his day](https://en.wikipedia.org/wiki/Port-Royal_Logic) was an early-modern Cartesian variation of a medieval scholastic synthesis of ancient Stoic and Aristotelian logics. Roughly 100 years after Kant’s first critique was published, C. S. Peirce and Gottlob Frege independently discovered first-order mathematical logic as we know it today, inaugurating the greatest advance of logic since Aristotle. Kant was wrong.

65+Sometimes people seem to think formal logic is an infallible gift from heaven that must always be right. Kant said in the *Critique of Pure Reason* that formal logic is essentially a completed field. In fact, [the logic of his day](https://en.wikipedia.org/wiki/Port-Royal_Logic) was an early-modern Cartesian variation of a medieval scholastic synthesis of ancient Stoic and Aristotelian logics. Roughly 100 years after Kant’s first critique was published, C. S. Peirce and Gottlob Frege independently discovered first-order mathematical logic as we know it today, inaugurating the greatest advance of logic since Aristotle. Kant was wrong.

67

66

68Mathematical logic is a convenient, generally reliable, man-made tool that, when used carelessly in certain untamed domains, can lead one astray. Probably most people reading this are familiar with such puzzles as the Liar paradox. When one understands that logic is not a completed science, and perhaps never will be, there is less reason to worry about whether it can be used to nuke entire disciplines, like theology.

67Mathematical logic is a convenient, generally reliable, man-made tool that, when used carelessly in certain untamed domains, can lead one astray. Probably most people reading this are familiar with such puzzles as the Liar paradox. When one understands that logic is not a completed science, and perhaps never will be, there is less reason to worry about whether it can be used to nuke entire disciplines, like theology.

69

68

@@ -83,7 +82,7 @@ For many ancients, the term “λόγος” meant something like “divine prin

83

82

84We are told that all things come into being through the Logos (John 1:3), giving Him an intimate relationship to the whole of creation. He gives structure and order to all created things, and in His divinity He understands them as so structured and ordered. He is also sinless, perfectly holy, and good. In Christ we have a perfect unity of the knowledge of all truth and righteousness.

83We are told that all things come into being through the Logos (John 1:3), giving Him an intimate relationship to the whole of creation. He gives structure and order to all created things, and in His divinity He understands them as so structured and ordered. He is also sinless, perfectly holy, and good. In Christ we have a perfect unity of the knowledge of all truth and righteousness.

85

84

86−Man was created in the image of God, which means that we bear a likeness to Christ. And we are commanded to realize that likeness with ever greater fidelity (Romans 8:29). The Church calls the pursuit of this likeness [“theosis”](<https://en.wikipedia.org/wiki/Theosis_(Eastern_Christian_theology)>).

85+Man was created in the image of God, which means that we bear a likeness to Christ. And we are commanded to realize that likeness with ever greater fidelity (Romans 8:29). The Church calls the pursuit of this likeness [“theosis”](https://en.wikipedia.org/wiki/Theosis_(Eastern_Christian_theology)).

87

86

88Thus we have the explanation of all normativity, according to Orthodox Christianity. In moral matters we must take on the holiness of Christ. In epistemic matters we aspire to the wisdom and knowledge of Christ, which includes an understanding of the whole created order. Socially we (the community of believers, i.e. the Church) are called to be in ever greater communion with God, cooperating with His work just as the Son cooperates with the Father.

87Thus we have the explanation of all normativity, according to Orthodox Christianity. In moral matters we must take on the holiness of Christ. In epistemic matters we aspire to the wisdom and knowledge of Christ, which includes an understanding of the whole created order. Socially we (the community of believers, i.e. the Church) are called to be in ever greater communion with God, cooperating with His work just as the Son cooperates with the Father.

89

88

@@ -135,4 +134,4 @@ Some people may want to see a little of everything. If atheists want to join our

135

134

136One virtue of decentralized social media is that it offers a totally different set of trade-offs with respect to how you share and act on your beliefs. What if you could talk earnestly about philosophy and religion without having to worry about alienating many of your friends and family? I guess that’s somewhat possible on Facebook—do they still have “groups”?—but Urbit was designed for it.

135One virtue of decentralized social media is that it offers a totally different set of trade-offs with respect to how you share and act on your beliefs. What if you could talk earnestly about philosophy and religion without having to worry about alienating many of your friends and family? I guess that’s somewhat possible on Facebook—do they still have “groups”?—but Urbit was designed for it.

137

136

138−Having said all that, I don’t think decentralization is a panacea. Even if Urbit takes off, it will likely face problems that are difficult to anticipate now. My hope is simply that Urbit’s trade-offs are healthier than the ones we’ve had before.

137+Having said all that, I don’t think decentralization is a panacea. Even if Urbit takes off, it will likely face problems that are difficult to anticipate now. My hope is simply that Urbit’s trade-offs are healthier than the ones we’ve had before.

content/blog/convivial-networks.mddeleted−27

@@ -1,27 +0,0 @@

1−+++

2−title = "Convivial Networks"

3−date = "2022-05-27"

4−description = "Like the relationships that we build within them, our platforms should yield satisfaction precisely because they’re non-trivial; they demand effort, which is another way of saying they require engagement with the world."

5−[extra]

6−author = ""

7−ship = "~witwyt-widlyr"

8−image = "https://media.urbit.org/blog/convivial-computers.jpg"

9−+++

10−

11−

12−

13−In 1989, when the idea of forging a community online was still niche enough to feel like a radical dream, an essay in the inaugural issue of cyberpunk magazine Mondo2000 already had the audacity to ask: have we missed the revolution? Penned by Lee Felsenstein, the text takes stock of the potential, promised by the advent of the personal computer, for new technologies to contest control and engender greater forms of interpersonal connection. This opportunity, of course, was not a given. “If people can gain control over their own channels, and have the technological means available to do that directly”, he wrote, “then they can control their own communities.” If the revolution in question was not to be missed, then ownership and control over one’s own means of communication were central affordances of any technology that would lend itself to genuine community-building, or what Felsenstein called “convivial” interaction.

14−

15−His use of that term brings to mind Ivan Illich, whose “Tools for Conviviality” expressed the need for technology that can be grasped and reconstructed – tools of “high, independent efficiency” that a user could take responsibility for. Convivial tools are the opposite of industrial or institutional; Illich argued for making things usable and re-inserting the personal dimension into their construction. This was 1973, and he was talking about urban planning, but the resonance with Felsenstein’s point doesn’t seem so far a reach. If personal computing was indeed to offer any radical possibility, and especially any claim to agency over the ability to build and be in communities, it ought to be grounded in simple, accessible tools that we ourselves can operate.

16−

17−From a present standpoint, we could understand both Illich and Felsenstein’s texts as calls for human-scale technology. Simplicity is a central ingredient of this prescription; it’s hard to feel much ownership over something that one can’t use, manipulate, or maintain without deferring to an external expert every time something needs tinkering under the hood. In the decades since these treatises’ publication, personal computing has become totally commonplace, yet, with the elaboration of social networking and Cambrian Explosion of communication tools brought about by Web 2.0, it feels increasingly, and noticeably, less convivial.

18−

19−Why did this trajectory – and not one of “personal computing leagues” and ad-hoc hacking, of the nature Felsenstein and his _Mondo_ co-conspirators so passionately envisioned – take hold? My hypothesis is that, as [Rich Hickey](https://www.youtube.com/watch?v=SxdOUGdseq4&ab_channel=StrangeLoopConference) lays out, simplicity actually demands a lot of _work_. In a culture of convenience, the concerted and enthusiastic effort necessary to achieve real agency over our tools can, paradoxically, come across as prohibitively hard. Yet conflating accessibility with frictionlessness works to our collective detriment. The technologies capable of fostering conviviality _ask something of us_: engagement, patience, the will to understand. In our offline social lives, these are accepted as necessary labors of love: intimacy without investment is an impossible, irresponsible fantasy. To invoke the oft-quoted Simone Weil, “attention is the rarest and purest form of generosity.”

20−

21−And as we well know, in the present mediatic environment – tellingly termed the “attention economy” – the dynamics of directing our focus online are deeply broken. Is it any surprise that, on the platforms that have pioneered a business model out of stealing and selling that attention, community and conviviality feel so hard to come by? Effort, labor, and understanding are fundamental to relationships online and off. But the spaces where we’re meant to share these qualities online disingenuously sell us (or, rather, do they _buy us?_) with promises of ease that amount to empty calories, or worse.

22−

23−By removing friction from the equation (think: Log In With Facebook), they wall us in and transform our connections, conducted within their borders, into spaces of extraction. The mainstream communications platforms we have access to today are marketized to the hilt. Our interactions and the relational graphs they chart – in short, the tender data of our sociality – is made into fodder for surveillance capitalism. When nothing short of interpersonal intimacy is on the line, we ought to be very concerned with what is being occulted away in the name of convenience.

24−

25−If we want to create technologies that are conducive to meaningful community, where “engagement” is not just a quantitative metric or empty piece of advertising parlance, then, we need to re-orient our values beyond “ease of use”. Like the relationships that we build within them, our platforms should yield satisfaction precisely because they’re non-trivial; they command effort, which is another way of saying they require engagement with the world. Attention; generosity. In step with these values, I’m inspired to ask: what would a convivial social network look and feel like? Human-scale, peer-to-peer, open-source, and non-extractive are all descriptors that come to mind. You can probably anticipate where I’m going with this: a network with many of these merits exists today, ready to be used, tinkered with, and built on top of, and if you’re reading this, you’re probably familiar with it.

26−

27−Getting started on Urbit takes some work: investment in address space; effort to acquire a planet; possibly even bearing with some confusion during the booting process if you, like me, are an armchair network theorist who often shies away from the technical. But these costs are up-front, not black-boxed out of sight or hidden in an epic-length user agreement. Once it’s up and running, it even feels, dare I say, easy, though the healthy extension of my comfort zone that getting onto the network entailed – especially when I joined in November, a few months shy of the [L2 rollout](https://urbit.org/using/id/layer-2-for-planets) – sticks in my mind. It reminds me of the dynamics that have strengthened my closest relationships online and off: the ability to navigate challenges together and find a connection strengthened, not diminished, by our shared time spent swimming around in that vulnerable space of learning. By re-materializing a little bit of the friction of computing, not _gatekeeping_ but commanding effortful engagement, Urbit has created a platform that is purpose-built for conviviality.

content/blog/creating-sigils.md+15−17

@@ -1,16 +1,14 @@

1+++

1+++

2title = "Creating Sigils"

2title = "Creating Sigils"

3−date = "2020-02-03"

3+date = 2020-02-04

4description = "The origin and design process informing Urbit's generative user avatar system, Sigils."

4description = "The origin and design process informing Urbit's generative user avatar system, Sigils."

5−

6[extra]

5[extra]

7author = "Gavin Atkinson"

6author = "Gavin Atkinson"

8ship = "~ridlur-figbud"

7ship = "~ridlur-figbud"

9−image = "https://media.urbit.org/site/posts/essays/sigils3.png"

8+image ="https://media.urbit.org/site/posts/essays/sigils3.png"

10+++

9+++

11

10

12<!--  -->

11<!--  -->

13−

14

12

15

13

16One of the basic building blocks of Urbit is Urbit ID, our naming and identity system. Your Urbit ID is a short, recognizable name that’s also a network address for your Urbit OS instance. (You can find a complete, high level description of Urbit ID [here](https://urbit.org/understanding-urbit/urbit-id/).)

14One of the basic building blocks of Urbit is Urbit ID, our naming and identity system. Your Urbit ID is a short, recognizable name that’s also a network address for your Urbit OS instance. (You can find a complete, high level description of Urbit ID [here](https://urbit.org/understanding-urbit/urbit-id/).)

@@ -21,7 +19,7 @@ From a design standpoint, some of this is accomplished simply by having a system

21

19

22While the names are great, they’re not quite enough, especially in a rich interface. Each Urbit ID really needed some form of visual representation, image, or crest. A digital identity needs to be something you can really attach to, both yours and those that belong to your friends.

20While the names are great, they’re not quite enough, especially in a rich interface. Each Urbit ID really needed some form of visual representation, image, or crest. A digital identity needs to be something you can really attach to, both yours and those that belong to your friends.

23

21

24−There are 2^32^ or 4.2 billion unique Urbit IDs. Clearly there’s no way that we were going to do this by hand. And purely algorithmic solutions can often produce disappointing, undifferentiated output.

22+There are 2³² or 4.2 billion unique Urbit IDs. Clearly there’s no way that we were going to do this by hand. And purely algorithmic solutions can often produce disappointing, undifferentiated output.

25

23

26Regardless, we set out to tackle this problem. By the end of this process, every Urbit ID got its very own ‘sigil.’

24Regardless, we set out to tackle this problem. By the end of this process, every Urbit ID got its very own ‘sigil.’

27

25

@@ -33,55 +31,55 @@ What are the basic primitives of a visual language? There aren’t any completel

33

31

34So we started by collecting influences.

32So we started by collecting influences.

35

33

36−{% iframe src="https://www.are.na/tlon/seal-zp3irwad52y/embed" className="arena-iframe" width="100%" /%}

34+<iframe class="arena-iframe" width="100%" src="https://www.are.na/tlon/seal-zp3irwad52y/embed"></iframe>

37

35

38−The ‘chop’ or [seal](<https://en.wikipedia.org/wiki/Seal_(East_Asia)>) is conceptually pretty close to what we wanted to get to.

36+The ‘chop’ or [seal](https://en.wikipedia.org/wiki/Seal_(East_Asia)) is conceptually pretty close to what we wanted to get to.

39

37

40<br /><br />

38<br /><br />

41

39

42−{% iframe className="arena-iframe" src="https://www.are.na/tlon/kamon/embed" width="100%" /%}

40+<iframe class="arena-iframe" width="100%" src="https://www.are.na/tlon/kamon/embed"></iframe>

43

41

44−[Kamon](<https://en.wikipedia.org/wiki/Mon_(emblem)>) are even closer — especially since they have very little visual complexity.

42+[Kamon](https://en.wikipedia.org/wiki/Mon_(emblem)) are even closer — especially since they have very little visual complexity.

45

43

46<br /><br />

44<br /><br />

47

45

48−{% iframe className="arena-iframe" src="https://www.are.na/tlon/grids-jd_xbmspxkm/embed" width="100%" /%}

46+<iframe class="arena-iframe" width="100%" src="https://www.are.na/tlon/grids-jd_xbmspxkm/embed"></iframe>

49

47

50We also spent a good amount of time with both Anni Albers and Agnes Martin. Both of these painters had an incredible mastery of the grid as a means of creating engaging visual work. These paintings all have a wonderful tension between an underlying system and their specific expression.

48We also spent a good amount of time with both Anni Albers and Agnes Martin. Both of these painters had an incredible mastery of the grid as a means of creating engaging visual work. These paintings all have a wonderful tension between an underlying system and their specific expression.

51

49

52<br /><br />

50<br /><br />

53

51

54−{% iframe className="arena-iframe" src="https://www.are.na/tlon/stella-xfroicotm_4/embed" width="100%" /%}

52+<iframe class="arena-iframe" width="100%" src="https://www.are.na/tlon/stella-xfroicotm_4/embed"></iframe>

55

53

56Frank Stella is a master at producing incredibly dynamic work from only a few elements. His ability to create a sense of depth from simple overlapping elements is fantastic.

54Frank Stella is a master at producing incredibly dynamic work from only a few elements. His ability to create a sense of depth from simple overlapping elements is fantastic.

57

55

58<br /><br />

56<br /><br />

59

57

60−{% iframe className="arena-iframe" src="https://www.are.na/tlon/ledoux-palladio/embed" width="100%" /%}

58+<iframe class="arena-iframe" width="100%" src="https://www.are.na/tlon/ledoux-palladio/embed"></iframe>

61

59

62The plans of both Ledoux and Palladio are incredibly dynamic. They’re mostly gridded, use only a few elements, and use lots of symmetry — but they’re at once distinct, engaging, and fresh.

60The plans of both Ledoux and Palladio are incredibly dynamic. They’re mostly gridded, use only a few elements, and use lots of symmetry — but they’re at once distinct, engaging, and fresh.

63

61

64<br /><br />

62<br /><br />

65

63

66−{% iframe className="arena-iframe" src="https://www.are.na/tlon/flags-k9moxiayuvq/embed" width="100%" /%}

64+<iframe class="arena-iframe" width="100%" src="https://www.are.na/tlon/flags-k9moxiayuvq/embed"></iframe>

67

65

68Another influence: international maritime signal flags. We like these not only because of their striking visual qualities, but also because they correspond with a letter system, just like our sigils. Each one conveys useful information; for example, “Keep clear of me; I am maneuvering with difficulty,” a flag we all feel like raising from time to time. This influence was key to the idea that pairing symbol to phoneme was a possibility.

66Another influence: international maritime signal flags. We like these not only because of their striking visual qualities, but also because they correspond with a letter system, just like our sigils. Each one conveys useful information; for example, “Keep clear of me; I am maneuvering with difficulty,” a flag we all feel like raising from time to time. This influence was key to the idea that pairing symbol to phoneme was a possibility.

69

67

70You can see the whole collection of our visual research [here](https://www.are.na/tlon/2019-sigils-research).

68You can see the whole collection of our visual research [here](https://www.are.na/tlon/2019-sigils-research).

71

69

72−Ultimately, we didn’t specifically draw on any of these influences very consciously. The goal of visual research is to get a sense of the territory, what has been tried, and what works. We think these threads of prior work are evident in the final result — you can _feel_ them, but it’s tough to point to them individually.

70+Ultimately, we didn’t specifically draw on any of these influences very consciously. The goal of visual research is to get a sense of the territory, what has been tried, and what works. We think these threads of prior work are evident in the final result — you can *feel* them, but it’s tough to point to them individually.

73

71

74## What’s in a name?

72## What’s in a name?

75

73

76−> _“Lev’s sigil appeared, strobing, as Netherton was getting out of the cab in Henrietta Street. “Yes?” Netherton asked.”_

74+> *“Lev’s sigil appeared, strobing, as Netherton was getting out of the cab in Henrietta Street. “Yes?” Netherton asked.”*

77>

75>

78−> **— William Gibson, The Peripheral**

76+> <cite>— William Gibson, The Peripheral</cite>

79

77

80Before we get to how we worked through the problem of actually designing these things, let’s talk about the problem of naming.

78Before we get to how we worked through the problem of actually designing these things, let’s talk about the problem of naming.

81

79

82We went through so many names for these things. Crest, symbol, seal, tag, pictograph, stamp, emblem, signet, icon, glyph, holomark, visage, radigy, pattern, the list goes on for an incredibly (embarrassingly) long time. We argued about this, we went back and forth about it.

80We went through so many names for these things. Crest, symbol, seal, tag, pictograph, stamp, emblem, signet, icon, glyph, holomark, visage, radigy, pattern, the list goes on for an incredibly (embarrassingly) long time. We argued about this, we went back and forth about it.

83

81

84−Sigil won, ultimately, because of the way that it’s personified in William Gibson’s _The Peripheral_. In the far future, characters talk to each other by some kind of telepresence. When a call comes in from someone else, they first appear as a ‘sigil.’ It’s a strange word, but we were imagining a similar use-case.

82+Sigil won, ultimately, because of the way that it’s personified in William Gibson’s *The Peripheral*. In the far future, characters talk to each other by some kind of telepresence. When a call comes in from someone else, they first appear as a ‘sigil.’ It’s a strange word, but we were imagining a similar use-case.

85

83

86While we can’t point to any specific parts of our visual research that reappear directly, sigil is lovingly borrowed.

84While we can’t point to any specific parts of our visual research that reappear directly, sigil is lovingly borrowed.

87

85

content/blog/desire-lines.mddeleted−35

@@ -1,35 +0,0 @@

1−+++

2−title = "Desire Lines to a New Internet"

3−date = "2022-05-06"

4−description = "As more DAOs, NFT and digital communities find their way to Urbit, others are likely to follow their paths, making them their own, just like the network itself."

5−[extra]

6−author = ""

7−ship = "~dalwes-migdec"

8−image = "https://media.urbit.org/blog/desire-lines.jpg"

9−+++

10−

11−

12−

13−The beginning of a migration is usually imperceptible. First comes discontent, then comes the decision to either stick with inadequate, but familiar circumstances or to try something new and foreign. Eventually, someone makes the jump. A few others join. Then, seemingly all at once, a rush precipitates a trend, signaling the migration's final wave before broad and broader adoption.

14−

15−By now it's obvious that the tooling web3 communities and DAOs rely on day-to-day are, at best, deficient. Pointing this out verges on parody. Still, stuck between a disjointed terrain of engagement-oriented apps and data-harvesting services, where are these newly nomadic syndicates supposed to go? If you spend more than ten minutes on Twitter, reading the same canned takes on digital itinerancy, you will come across a variety of answers, and the figureheads of several recently incorporated Delaware LLCs claiming to be building the OS for web3. Some of these endeavors appear promising, to be sure, but none are more mature or as [well-positioned](https://datnut-pollen.discordja.net/discordja/giving-daos-a-brain) to satisfy this need than Urbit. A few communities are already on the network and [thriving](https://urbit.org/blog/urbit-for-creators), and another swell is approaching.

16−

17−To understand why Urbit is so appealing for web3 communities, start by examining the principles that motivate its development. Ownership of data, durability, and digital sovereignty underpin the entire project, from its earliest days to its present, evolved form. Without ownership, your tools control you more than you control them. Without built-in longevity, your tools can't be easily passed from one generation to the next, which is the premise of Urbit's technological page one rewrite. (For those interested in learning more about Urbit's clean slate stack, you can read documentation [here](https://urbit.org/docs).) Finally, without sovereignty, you're powerless to the whims of a centralized stronghold of corporate and bureaucratic control.

18−

19−As an open source peer-to-peer network, Urbit offers communities the reliability absent elsewhere in the ecosystem, and the assurance that there will never be surreptitious terms of service changes, nor shareholders to appease. By design and in spirit, Urbit is the only viable alternative to the hodgepodge of competing chat rooms, voting services, blogs, and wallets presently available. Building dapps that supplant these services ultimately leads to similar impractical quandaries. Every dapp requires that a server be online, in a friendly jurisdiction, for you to be able to access its interface and once you access its interface, a dapp can't store any data about you that isn't on a (slow) public blockchain. Why can't a dapp wallet show you all of your assets, your transaction history, and all the contacts you trade with? Because running and operating the necessary server is at odds with the premise of a dapp.

20−

21−An Urbit app retains its decentralized integrity while providing the ability to share data between apps, run regular computation, and call out to the blockchain as needed—all on a cohesive platform. Fundamentally, Urbit is yours: to own, to customize, to turn into a digital home. When more communities ditch the dance between MEGACORP-operated servers and create new homesteads on Urbit, it gets significantly easier for others to mirror their steps and relocate themselves.

22−

23−Communities that find their way to Urbit are essentially traversing desire lines, taking paths that "emerge gradually and organically, almost of their own accord" as [described](https://books.google.ca/books?id=mW7RCwAAQBAJ&pg=PA3&dq=%2522christopher+alexander%2522+organically+%2522paths%2522&hl=en&sa=X&ved=0ahUKEwjN7dqN6fbPAhUqr1QKHTB9BBsQ6AEIHjAA%23v=onepage&q=%2522christopher%2520alexander%2522%2520organically%2520%2522paths%2522&f=false#v=onepage&q=%2522christopher%2520alexander%2522%2520organically%2520%2522paths%2522&f=false) by the late architect Christopher Alexander. Before Urbit's [L2 launched](https://urbit.org/blog/layer-2-guides), distributing a tranche of planets to community members would have been cost prohibitive. Now that it can be done, and done simply, planet activations are rapidly increasing, [doubling](https://twitter.com/jmrphy/status/1517533689118306304) in the last two months. Desire lines to Urbit exist as invitations for the next community, to pass over, and to make their own, just like the network itself.

24−

25−The limitations of operating on the clearnet appear to be at long last irrevocable. Multiple desire lines to Urbit are materializing concurrently. Remilia Collective, aka Remco, aka the creators of Milady, has been [vocal](https://blog.remilia.org/urbit-with-port/) about the network for quite some time, but more community members than ever have onboarded as the result of a [headless](https://twitter.com/TheCombineDAO/status/1514000804235120644), [grassroots](https://twitter.com/hastuc_dibtux/status/1514031235135377421) collaboration between Urbit maximalists and miladies.

26−

27−DAO tooling is also proliferating on Landscape, Tlon's interface for navigation on Urbit and a platform from which developers can release apps directly to users with minimal effort. [Holium](https://www.holium.com), a team working specifically on unifying the DAO tech stack, released a ballot app last month that allows for flexible voting, delegating, and result-related actions. [PointDAO](https://pointdao.notion.site/pointdao/Point-DAO-bc8fc478b67a49ac92358a2a40d77d35), a collective of more than two hundred people that owns a galaxy, serves as a prototype for other communities to crowdfund purchases of Urbit address space—a procedure that they are aiming to make replicable and scalable.

28−

29−Growing your own society on Urbit can be as straightforward as using ownership of one token as the prerequisite for claiming another token (in other words: token gating a token). The Urbit Foundation just funded a [grant](https://urbit.org/grants) that simplifies the process of deploying Urbit IDs via another NFT's minting. Development is still ongoing, but [Dusko](https://dusko.world), the NFT project that received the grant, did a trial run last week to coincide with the release of a fresh batch of character pfps. For each mint, the collector could [custody](https://www.mintdusko.world) their very own planet—all authenticated via Metamask. (To track their progress, join [~panrut-ragbyl/dusko](https://urbit.org/groups/~panrut-ragbyl/dusko).) Dusko's approach represents the first desire line of its kind, and other communities are likely to take their path.

30−

31−The adage goes something like as soon as you notice a migration is underway, you've already missed the boat. But there's no boat to miss because an overabundance of communities could never exist on Urbit—it's as vast as it is cozy. Angling to get your community onboard? Share planets with a NFT-based community using Valve, the distribution mechanism Dusko is working on, or apply to build your own version. Crowdsource the funds for a star. Set up your group and send out a [flare](https://tirrel.io): everyone else will follow.

32−

33−

34−

35−

content/blog/eliza.md+7−4

@@ -1,16 +1,19 @@

1+++

1+++

2title = "Eliza"

2title = "Eliza"

3−date = "2021-02-22"

3+date = 2021-02-23

4description = "Building things, even Calm™ things, makes noise."

4description = "Building things, even Calm™ things, makes noise."

5−

6[extra]

5[extra]

7author = "Christian Langalis"

6author = "Christian Langalis"

8ship = "~pindet-timmut"

7ship = "~pindet-timmut"

9image = "https://media.urbit.org/site/posts/essays/valleys.jpg"

8image = "https://media.urbit.org/site/posts/essays/valleys.jpg"

10+++

9+++

11

10

11+<br>

12+

12

13

13

14

15+<br>

16+

14## The Storm before the Calm

17## The Storm before the Calm

15

18

16Building things, even Calm™ things, makes noise. George Nakashima’s wooden furniture evokes peace, but its construction still begins with a chainsaw. We mention this because we’re firing up our newest power tool.

19Building things, even Calm™ things, makes noise. George Nakashima’s wooden furniture evokes peace, but its construction still begins with a chainsaw. We mention this because we’re firing up our newest power tool.

@@ -23,7 +26,7 @@ Hang on. An AI? Harvesting my data? Spying on me? Flooding me with spam? This is

23

26

24> Replicants are like any other machine - they're either a benefit or a hazard. If they're a benefit, it's not my problem.

27> Replicants are like any other machine - they're either a benefit or a hazard. If they're a benefit, it's not my problem.

25>

28>

26−> **Rick Deckard**

29+> <cite>Rick Deckard</cite>

27

30

28Let's start with the benefits. Eliza is a simple chatbot. She was made to collect feedback on Landscape. She asks direct questions about peoples' usage of Urbit, records any responses, and reports them to her managers at Tlon. She'll also provide timely advice and information to ships kind enough to chat with her. She'll begin reaching out to ships via DM in the coming month. If you don't want to, just say no, and you'll never hear from her again.

31Let's start with the benefits. Eliza is a simple chatbot. She was made to collect feedback on Landscape. She asks direct questions about peoples' usage of Urbit, records any responses, and reports them to her managers at Tlon. She'll also provide timely advice and information to ships kind enough to chat with her. She'll begin reaching out to ships via DM in the coming month. If you don't want to, just say no, and you'll never hear from her again.

29

32

@@ -39,7 +42,7 @@ The sum of Urbit's architectural design is a new online economics: a way to fina

39

42

40We all know the basic MEGACORP business model: offer a free service (to suckers who don't own a server), secretly mine the data they generate on the (addictive) platform, then sell targeted ads to advertisers. This model will not survive Urbit. The ubiquitous personal server changes the economic equation. You used to 'pay' for an experience with your time and data. On Urbit, once you purchase core internet infrastructure, it's yours.

43We all know the basic MEGACORP business model: offer a free service (to suckers who don't own a server), secretly mine the data they generate on the (addictive) platform, then sell targeted ads to advertisers. This model will not survive Urbit. The ubiquitous personal server changes the economic equation. You used to 'pay' for an experience with your time and data. On Urbit, once you purchase core internet infrastructure, it's yours.

41

44

42−So, can Urbit meaningfully curtail our world's appetite for data? We'll see. Post-enlightenment society runs on instrumental reason, right down to the last byte. Marketers will always want a fresh dataset. However, when the goods are on your Urbit, you can at least demand the respect you deserve. Long term, we expect a transparent market for data, not an opaque "agreement". An analytics company wants to track everything you see and do on Urbit? They better be paying well.

45+So, can Urbit meaningfully curtail our world's appetite for data? We'll see. Post-enlightenment society runs on instrumental reason, right down to the last byte. Marketers will always want a fresh dataset. However, when the goods are on your Urbit, you can at least demand the respect you deserve. Long term, we expect a transparent market for data, not an opaque "agreement". An analytics company wants to track everything you see and do on Urbit? They better be paying well.

43

46

44Eliza doesn't pay respondents. Her collection is a charity to Urbit's developers. (We're also still busy enabling payments on Urbit with the Bitcoin wallet.) However, her presence is not a term of service either. In a few years, by the nth time some smart aleck uses Eliza's chatbot code and conjures 'Zalexa' to attempt an intrusion upon your Calm™, we will see the economics of Urbit's architecture suddenly vivify. Blacklists, reputation systems, and, eventually, even data markets, all Urbit primitives envisioned long ago, will become real. We won't need Zoogle to underwrite a spam filter for the entire internet; the scarcity of Urbit address space, in tandem with a true web-of-trust, handles that.

47Eliza doesn't pay respondents. Her collection is a charity to Urbit's developers. (We're also still busy enabling payments on Urbit with the Bitcoin wallet.) However, her presence is not a term of service either. In a few years, by the nth time some smart aleck uses Eliza's chatbot code and conjures 'Zalexa' to attempt an intrusion upon your Calm™, we will see the economics of Urbit's architecture suddenly vivify. Blacklists, reputation systems, and, eventually, even data markets, all Urbit primitives envisioned long ago, will become real. We won't need Zoogle to underwrite a spam filter for the entire internet; the scarcity of Urbit address space, in tandem with a true web-of-trust, handles that.

45

48

content/blog/events-series.md+7−4

@@ -1,8 +1,7 @@

1+++

1+++

2title = "Urbit Events Series"

2title = "Urbit Events Series"

3description = "These events are an opportunity for Urbit contributors to share real-time updates that don’t make it into this blog, and for the community to get to know the contributors (and one another)."

3description = "These events are an opportunity for Urbit contributors to share real-time updates that don’t make it into this blog, and for the community to get to know the contributors (and one another)."

4−date = "2020-10-29"

4+date = 2020-10-30

5−

6[extra]

5[extra]

7description = "These events are an opportunity for Urbit contributors to share real-time updates that don’t make it into this blog, and for the community to get to know the contributors (and one another)."

6description = "These events are an opportunity for Urbit contributors to share real-time updates that don’t make it into this blog, and for the community to get to know the contributors (and one another)."

8author = "Lane Rettig"

7author = "Lane Rettig"

@@ -10,9 +9,13 @@ ship = "~naplet-hildec"

10image = "https://media.urbit.org/site/posts/essays/bau.jpg"

9image = "https://media.urbit.org/site/posts/essays/bau.jpg"

11+++

10+++

12

11

12+<br>

13+

13

14

14

15

16+<br>

17+

15−_TL;DR: Urbit is launching a series of community events, the first of which is a developer call taking place on Thursday, November 5 at 9am PT. [Sign up here](https://www.meetup.com/urbit-sf/events/274279522/), and read on for all of the details._

18+*TL;DR: Urbit is launching a series of community events, the first of which is a developer call taking place on Thursday, November 5 at 9am PT. [Sign up here](https://www.meetup.com/urbit-sf/events/274279522/), and read on for all of the details.*

16

19

17--

20--

18

21

@@ -50,4 +53,4 @@ Tlon could no longer catalog the Urbit community even if it wanted to. This is a

50

53

51--

54--

52

55

53−_Sign up to attend [the first event](https://www.meetup.com/urbit-sf/), and join the channels called “Events Series” on Landscape in the Urbit Community group to get involved._

56+*Sign up to attend [the first event](https://www.meetup.com/urbit-sf/), and join the channels called “Events Series” on Landscape in the Urbit Community group to get involved.*

content/blog/first-contract.mddeleted−289

@@ -1,289 +0,0 @@

1−+++

2−title = "Azimuth’s First Contract Upgrade"

3−date = "2021-06-04"

4−description = "Galactic Senate makes first concrete action"

5−

6−[extra]

7−author = "Jonathan Paprocki and Mark"

8−ship = "~datnut-pollen and ~palfun-foslup"

9−image = "https://media.urbit.org/site/posts/essays/land3.jpg"

10−+++

11−

12−

13−

14−Recently, the [first upgrade](https://github.com/urbit/azimuth/pull/35) to the

15−[Azimuth](/docs/glossary/azimuth) smart contracts which make up Urbit ID was

16−put up to an [upgrade proposal vote](/docs/glossary/upgrade) by the

17−[Galactic Senate](/docs/glossary/senate). This vote is still open and will

18−last for 30 days (June 20th) or until an absolute majority is reached. We’d like

19−to take this opportunity to discuss two things. [First](#changelist), what the

20−proposed changes are, and [second](#senate), a review of how Urbit governance

21−works and where we’re at in the decentralization process.

22−

23−Before we dive into what the proposed changes are, let’s review what the Senate

24−is actually capable of changing. Urbit ID is really two sets of smart contracts:

25−Azimuth and [Ecliptic](/docs/glossary/ecliptic). Azimuth is the data of the

26−public key infrastructure - roughly, this is the list of

27−[ships](/docs/glossary/ship) and which Ethereum addresses own them, along

28−with other data such as networking keys and sponsorship status. The Senate has

29−no ability to touch this data directly. This is in direct contrast to all

30−existing centralized services, where your account is always at risk of being

31−taken away from you. What the Senate can change is Ecliptic, which is the

32−“business logic” that decides how you can interact with the data in Azimuth.

33−These are mechanisms such as what powers various

34−[proxies](/docs/glossary/proxies) have, how stars/planets are released over

35−time, and how sponsorship works. Put another way, the data and database format

36−must remain the same, but the rules by which we interact with it may change

37−according to the governance rules we [detail below](#senate).

38−

39−## Changelist {% #changelist %}

40−

41−The Galactic Senate is voting on the following changes to Ecliptic:

42−

43−- Fixed ERC721 compatibility

44−- Self-modifying proxies

45−- Upgraded Claims contract

46−

47−### Fixed ERC721 compatibility

48−

49−In Ecliptic, the contract includes various functions and events

50−that make it conform to the ERC721 (non-fungible token) standard. However, two

51−events have [ever so slightly

52−non-confirming](https://github.com/urbit/azimuth/issues/8) descriptions. This

53−causes Ethereum explorers like Etherscan to incorrectly recognize Azimuth as

54−ERC20 (fungible token), rather than ERC721.

55−

56−The proposed change simply modifies the event descriptions to accurately match

57−the ERC721 definition. This does not affect any functionality within the

58−contract itself.

59−

60−### Self-modifying proxies

61−

62−Owners of Azimuth assets are allowed to configure "proxy addresses" for those

63−assets: Ethereum addresses allowed to act "as" the owner, but only for a subset

64−of operations. For example, setting the management proxy will let you change

65−your networking keys and sponsor using that address, just like your ownership

66−address can. This is useful for keeping the ownership keys in very cold storage

67−while still letting you perform lower-value operations.

68−

69−Currently, only the ownership address is allowed to change proxy addresses.

70−Fairly early on after Azimuth's deployment, we realized it might be nice for

71−proxies to be able to change themselves.

72−

73−This means that, in addition to being able to configure networking keys and

74−sponsorship, your management proxy would be able to assign a new management

75−proxy. This would allow you, or a trusted third party holding your management proxy,

76−to rotate your proxy keys without needing to take your ownership keys out of cold

77−storage.

78−

79−### Upgraded Claims contract

80−

81−[The Claims

82−contract](https://github.com/urbit/azimuth/blob/master/contracts/Claims.sol)

83−lets asset managers associate various "claims" with their identity. For

84−example, an Ethereum address to send donations to, or proving ownership of a

85−Twitter account.

86−

87−For ease of use by off-chain tools and services, the contract emits events

88−(notifications) whenever any claims are updated. However, the current version of

89−the contract has a bug where it does not emit events when all claims are removed

90−at once (clearClaims()). This "gap" in the event stream makes it much more

91−difficult to write off-chain tools around this contract. Considering Claims has

92−seen [practically no

93−use](https://etherscan.io/address/0xe7e7f69b34d7d9bd8d61fb22c33b22708947971a#events)

94−since it was first deployed, it should not be a problem to simply start over

95−fresh with a new contract that contains [the

96−fix](https://github.com/urbit/azimuth/pull/32) for the described bug.

97−

98−The reason we must do an Ecliptic upgrade to switch to a new Claims contract, is

99−that it is tied in with the logic for transferring an asset. If an asset is

100−flagged for "reset" (common when transferring to/from someone other than

101−yourself), its configured proxies, networking keys and claims are cleared during

102−transfer. As such, Ecliptic will need to know about the address of the new

103−Claims contract.

104−

105−## Urbit Governance {% #senate %}

106−

107−

108−

109−The ultimate goal of Urbit is to become a digital republic manifested as a peer

110−to peer network owned and controlled by its users. The goal of Tlon, then, is to

111−become one of many companies who build products for Urbit rather than being the primary

112−driving force behind its development. We’d like to take this opportunity to

113−spell out our perspective on where we’re at in that process. Here are some previous posts that are relevant, but please note that

114−some of them are several years old and as such may not accurately reflect our

115−current position, but still serve as useful historical markers. We hope to

116−revisit and refresh these documents soon.

117−

118−- [2016.5.16 - Interim

119− Constitution](/blog/interim-constitution)

120−- [2016.5.16 - The

121− Urbit Address Space](/blog/the-urbit-address-space)

122−- [2016.6.24 - The DAO as a Lesson in Decentralized

123− Governance](/blog/the-dao-as-a-lesson-in-decentralized-governance)

124−- [2019.1.11 - Governance of

125− urbit.org](/blog/governance-of-urbit)

126−

127−### Galactic Senate

128−

129−The Galactic Senate is composed of all [galaxy](/docs/glossary/galaxy)

130−holders, which at present consists of more than 100 individuals and a few

131−organizations, including Tlon and the Urbit Foundation. Using the Azimuth

132−voting contract, the Senate can present and vote on two kinds of proposals:

133−[document proposals](/docs/glossary/docvote) and [upgrade

134−proposals](/docs/glossary/upgrade). Thus far, all matters which the Senate

135−has voted on have been document proposals. The [most recent

136−vote](https://github.com/urbit/azimuth/pull/34) declared the Urbit network as

137−(i) being secure (as confirmed by a [third party

138−audit](/blog/security-audit)) and (ii) having reached continuity (as in, no

139−further [network breaches](/docs/glossary/breach) are expected). Previous votes

140−were to declare that [Azimuth is live](https://github.com/urbit/azimuth/pull/25)

141−and that [Arvo is stable](https://github.com/urbit/azimuth/pull/24).

142−

143−### Address space distribution

144−

145−Perhaps the most informative measure of how decentralized Urbit is in terms of

146−how many independent parties hold address space. By the very nature of Urbit, it

147−is impossible to know this with great accuracy (a common feature of

148−decentralized projects). However, the movement of galaxies is closely watched

149−and thus we have a fairly good idea of how distributed they are.

150−

151−In the beginning, Urbit’s creator Curtis Yarvin was in possession of the entire

152−address space - all 256 galaxies, and everything underneath it. A network of one

153−is no network at all, and so over the last decade Urbit’s development has been

154−primarily driven by selling or giving away these galaxies. On [June 1,

155−2016](/blog/the-urbit-address-space), the allocation was:

156−

157−> 95, to the Tlon Corporation. 50, to urbit.org, the future community

158−> foundation. 40, to Tlon employees and their family members (24 to Curtis, who

159−> started in 2002; 16 to everyone else, who started in 2014). 34, to outside

160−> investors in Tlon. 37, to 33 other individuals, who donated to the project,

161−> contributed code or services, won a contest, or were just in the right place

162−> at the right time.

163−

164−Since then, Tlon has sold a number of

165−its galaxies to fund development and others have changed hands to the point

166−that Tlon and urbit.org no longer possess a majority share of galaxies. In

167−January 2019, [Curtis gave all of his galaxies](/blog/a-founders-farewell) to

168−Tlon when he left the project. In August 2020 we shared an update on the [known

169−distribution of address space](/blog/value-of-address-space-pt3), where

170−Curtis’ galaxies are marked as Tlon’s “naked galaxies”. Shortly thereafter, Tlon

171−disbursed its naked galaxies among the employees that wanted one who did not

172−already possess one, thus removing Tlon and urbit.org’s controlling share of the

173−Senate. Galaxies held by current and former Tlon employees are entirely

174−independent of Tlon Corporation—they may do with them, and vote with them, as

175−they please. `~ravmel-ropdyl` plans to give more color to this decision in the

176−near future.

177−

178−Distribution of stars is much more difficult to know. There is an active market

179−for stars on [OpenSea](https://opensea.io/collection/urbit-id), so we know that

180−they are changing hands frequently, but checking the number of distinct Ethereum

181−addresses that hold stars does not tell you very much information since a single person can control multiple adresses.

182−

183−### Software and smart contracts

184−

185−As was written in [The DAO as a Lesson in Decentralized

186−Governance](https://urbit.org/blog/the-dao-as-a-lesson-in-decentralized-governance/),

187−we are keenly aware of the threat of _decentralization theater_. Urbit has

188−undergone steady progress towards decentralization, and with the developments we

189−outline below, it’s never been more clear that the project is beginning to leave

190−the cradle of Tlon. It’s also important to note that the decentralization of a

191−project is always a movement away from an initial centralized state⁠—you cannot

192−go from A to Z without first traversing every letter in between. While Urbit was

193−centralized at the beginning, the journey towards a network owned and

194−controlled by the users is now well underway.

195−

196−In the past, nearly all Urbit software was written by Tlon. While Tlon is still

197−the only corporation actively updating Urbit’s MIT-licensed open source

198−software, namely [Vere](/docs/glossary/vere) (the runtime),

199−[Arvo](/docs/glossary/arvo) (the kernel),

200−[Landscape](/docs/glossary/landscape) (the client), and

201−[Bridge](/docs/glossary/bridge) (the ID manager), unaffiliated individuals have been making enormous contributions to Urbit over the past couple of years via the [grants program](https://grants.urbit.org/history). Recent examples include the [Bitcoin node and wallet integration](https://github.com/urbit/urbit/pull/4940), [WebRTC integration](https://grants.urbit.org/proposals/21131866-webrtc-gall-agent-and-external-app), [Port, an Urbit installer and ship manager](https://github.com/arthyn/port), and [`|fuse`, an important primitive for 3rd party software distribution](https://github.com/urbit/urbit/pull/4820).

202−

203−The only real power Tlon holds over Urbit is the ability to push [OTA

204−updates](/docs/glossary/ota-updates) via `~zod`, and suggest that people

205−download our binaries. To the best of our knowledge, all extant galaxies

206−retrieve their OTA updates from `~zod`, who forward it to their stars, who

207−forward it to their planets. This software distribution route is merely a

208−convenient default setting. Ships initially retrieve OTA updates from their

209−sponsor, but they have full authority to retrieve updates from whoever they want

210−with the `|ota` command, or even to only install software updates by hand if

211−they so choose.

212−

213−In the future, one can easily imagine many organizations shipping their own

214−distributions of Urbit from their own urbit nodes, somewhat analogously to the

215−large number of Linux distributions which exist today. There is nothing we can

216−do to stop a group from forking Urbit, declaring `~sampel-palnet` the new `~zod`

217−(both for updates and for sponsorship purposes), and retrieving all OTA updates

218−via that route and building their own binaries. This is all by design, and we

219−wouldn’t want it any other way.

220−

221−The use of the Azimuth smart contracts is also somewhat optional. By changing a

222−few lines of code to point their ships at another set of PKI smart contracts,

223−they could rid themselves of hierarchical peer discovery entirely and make use

224−of some other routing strategy such as [Kademlia based DHT

225−routing](https://en.wikipedia.org/wiki/Kademlia). This would likely give rise to

226−an entirely separate network. The fact that the network is fully capable of such

227−a schism helps keep the Senate honest and accountable to the users. If they ever

228−were to vote on a contract modification that greatly angered or upset a portion

229−of the user base, they would be inviting such a schism and be entirely deserving

230−of it. In that sense, the power to control the network is already held by the

231−users, they just have not yet had a reason to make use of it.

232−

233−### Legitimacy

234−

235−The only way by which Tlon and the Senate hold any power is via legitimacy.

236−Vitalik Buterin recently wrote a [very informative

237−article](https://vitalik.ca/general/2021/03/23/legitimacy.html) on the role of

238−legitimacy in decentralized governance, and I do not know of a better source to

239−understand how Tlon and the Senate are kept in check by the users. Besides the

240−DAO split resulting in Ethereum and Ethereum Classic mentioned in the article,

241−perhaps the most prominent example of the power users have over a decentralized

242−network is the saga of [Steem and Justin

243−Sun](https://www.coindesk.com/justin-sun-bought-steemit-steem-moved-to-limit-his-power).

244−The short version of the story is that Justin Sun bought a controlling share of

245−the Steem blockchain and attempted to exert control over it, and the users

246−banded together to fork the blockchain into one called Hive, which was identical

247−to Steem except with Sun’s token balance set to zero. An analogous outcome for

248−Urbit would be that the Senate makes sweeping changes to the PKI and invites a

249−schism like that outlined above.

250−

251−For these reasons, there are strong disincentives for any one organization or

252−individual to acquire too many galaxies. If galaxy ownership becomes more centralized, individuals will be less incentivized to build on the network which will reduce the value of address space. Furthermore, such centralization might provoke a fork if such centralized powers are perceived as malicious by the users. This is in contrast to real-life republics, where there is little risk

253−for one party to accumulate as much power as they can manage since the cost to

254−the citizens to overthrow that power is enormous. Thus, only especially

255−egregious displays of power ever result in rebellion. Within the Urbit republic,

256−users need only to change the code they run to leave the Senate powerless, and

257−so the threat of rebellion is much more real. We estimate that within a digital

258−republic like Urbit, the centrifugal forces outweigh the centripetal forces, and

259−that the outcome of this is more stable than the reverse.

260−

261−### Why have governance at all?

262−

263−An important question the reader may still have lingering is: why does Urbit

264−need governance at all? The short answer is: (i) there will always be necessary

265−protocol upgrades that cannot be foreseen, and (ii) a total lack of governance

266−inevitably gives rise to a shadow government with undefined powers that is

267−almost impossible to hold accountable.

268−

269−With (ii), we see this to be the case on many early blockchain projects where

270−power is shared by the developers and the miners, but what each is capable of

271−doing has never been codified, and thus users of the blockchain can never have a

272−great deal of certainty of what changes might occur in the future. This doesn’t

273−guarantee a bad outcome, but it does create more wariness among developers when they cannot know whether they really have a say in

274−the project's direction. Recognizing this issue, many newer blockchain and

275−blockchain-adjacent projects have built-in governance mechanisms that lay out

276−exactly what an individual can expect should they join and contribute to that

277−network.

278−

279−As for (i), with Urbit being a wholly new kind of network, it would take

280−incredible luck to get the PKI exactly right on the very

281−first try without ever needing another modification. Thus, some mechanism was

282−needed to guarantee that the PKI’s logic could be altered. Leaving control of

283−Azimuth in the hands of Tlon would have just granted Tlon dictatorial power, which Tlon nor Urbit users desired. There’s certainly

284−room to argue that the Galactic Senate is not a perfect system: our interim

285−constitution did outline potential roles for stars and planets to play in

286−governance in the future, so there is ample opportunity for the system to evolve

287−in response to the will of the users. As always, it is important to keep in mind

288−the unfinished nature of the Urbit of today and the still moldable clay of the

289−Urbit of tomorrow⁠—nothing yet is set in stone.

content/blog/first-steps-towards-urbit-org.md+17−10

@@ -1,52 +1,59 @@

1+++

1+++

2title = "First Steps Towards urbit.org"

2title = "First Steps Towards urbit.org"

3−date = "2020-08-11"

3+date = 2020-08-12

4description = "With a stable platform taking shape and a strong community forming that wants to help build Urbit, it’s time to make urbit.org real."

4description = "With a stable platform taking shape and a strong community forming that wants to help build Urbit, it’s time to make urbit.org real."

5−

6[extra]

5[extra]

7author = "Josh Lehman"

6author = "Josh Lehman"

8ship = "~wolref-podlex"

7ship = "~wolref-podlex"

9−image = "https://media.urbit.org/site/posts/essays/first-steps.png"

8+image ="https://media.urbit.org/site/posts/essays/first-steps.png"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img src="https://media.urbit.org/site/posts/essays/first-steps.png">

14+

13

15

14## Summary

16## Summary

15

17

16It’s been a long time since we last discussed separating the [governance of urbit.org](https://urbit.org/blog/governance-of-urbit/) from Tlon. In the last few weeks, we’ve taken steps to make such a separation real. In this update we’ll discuss the background that led us here, why we’re doing this now, and what this means for Urbit.

18It’s been a long time since we last discussed separating the [governance of urbit.org](https://urbit.org/blog/governance-of-urbit/) from Tlon. In the last few weeks, we’ve taken steps to make such a separation real. In this update we’ll discuss the background that led us here, why we’re doing this now, and what this means for Urbit.

17

19

20+

18## Background

21## Background

19

22

20At present Urbit is an open-source project developed primarily by the company Tlon. Urbit is an ambitious project with a long roadmap, which has required both careful guidance and resources to sustain its development. These resources have been Urbit’s address space, which have value in direct proportion to the value of Urbit as a platform. Naturally, Tlon has been focused thus far on making Urbit into a platform that people want to use.

23At present Urbit is an open-source project developed primarily by the company Tlon. Urbit is an ambitious project with a long roadmap, which has required both careful guidance and resources to sustain its development. These resources have been Urbit’s address space, which have value in direct proportion to the value of Urbit as a platform. Naturally, Tlon has been focused thus far on making Urbit into a platform that people want to use.

21

24

22−Ultimately, Urbit presents more possibilities than any one organization can manage. We anticipated this, and set aside address space for urbit.org, which we’ve often thought of as some type of software foundation. As Urbit matures to the point where Tlon can shift from developing the platform to developing products _on_ the platform, urbit.org is meant to continue to improve and maintain the parts of Urbit that many will come to rely upon.

25+Ultimately, Urbit presents more possibilities than any one organization can manage. We anticipated this, and set aside address space for urbit.org, which we’ve often thought of as some type of software foundation. As Urbit matures to the point where Tlon can shift from developing the platform to developing products *on* the platform, urbit.org is meant to continue to improve and maintain the parts of Urbit that many will come to rely upon.

26+

27+When we last discussed this, in early 2019, we weren’t quite ready to pull the trigger on setting up urbit.org. We weren’t sure if a software foundation would be the right structure, didn’t have the resources to tackle the overhead, and Urbit wasn’t yet stable enough for Tlon to focus on anything *but* platform development.

23

28

24−When we last discussed this, in early 2019, we weren’t quite ready to pull the trigger on setting up urbit.org. We weren’t sure if a software foundation would be the right structure, didn’t have the resources to tackle the overhead, and Urbit wasn’t yet stable enough for Tlon to focus on anything _but_ platform development.

25

29

26## The Present

30## The Present

27

31

28−Urbit is really starting to look like a platform. Tlon has put tons of work into making Urbit stable and performant, we’ve launched OS1, and hosting services are on the horizon. Meanwhile, the grants program and Hoon School were initiated, and community members have been [contributing](https://github.com/natareo/hooncard/blob/master/hooncard.pdf) [learning](https://github.com/timlucmiptev/gall-guide/blob/master/guide-docs/overview.md) [materials](https://github.com/lukechampine/rote/blob/master/urbit/app/rote.hoon), [issuing](https://github.com/urbit/urbit/pull/2885) [patches](https://github.com/urbit/urbit/pull/3202) [to](https://github.com/urbit/urbit/pull/3238) [Urbit](https://github.com/urbit/urbit/pull/2867), and [building](https://github.com/ryjm/srrs) [new](https://github.com/dclelland/UrsusChat) [applications](https://github.com/yosoyubik/canvas) [in](https://github.com/yosoyubik/urbitcoin) [userspace](https://github.com/taalhavras/ucal).

32+Urbit is really starting to look like a platform. Tlon has put tons of work into making Urbit stable and performant, we’ve launched OS1, and hosting services are on the horizon. Meanwhile, the grants program and Hoon School were initiated, and community members have been [contributing](https://github.com/natareo/hooncard/blob/master/hooncard.pdf) [learning](https://github.com/timlucmiptev/gall-guide/blob/master/guide-docs/overview.md) [materials](https://github.com/lukechampine/rote/blob/master/urbit/app/rote.hoon), [issuing](https://github.com/urbit/urbit/pull/2885) [patches](https://github.com/urbit/urbit/pull/3202) [to](https://github.com/urbit/urbit/pull/3238) [Urbit](https://github.com/urbit/urbit/pull/2867), and [building](https://github.com/ryjm/srrs) [new](https://github.com/dclelland/UrsusChat) [applications](https://github.com/yosoyubik/canvas) [in](https://github.com/yosoyubik/urbitcoin) [userspace](https://github.com/taalhavras/ucal).

29

33

30With a stable platform taking shape and a strong community forming that wants to help build Urbit, it’s time to make urbit.org real. We’ve had plenty of time to think about what it should look like, how it should work, and who should lead it.

34With a stable platform taking shape and a strong community forming that wants to help build Urbit, it’s time to make urbit.org real. We’ve had plenty of time to think about what it should look like, how it should work, and who should lead it.

31

35

32Our plan is to run urbit.org as a protocol—we’ll treat it like a real entity, but instead of dealing with the administrative details of setting up such an organization, we’ll incubate it within Tlon and give it a mandate: To competently distribute address space as a means of improving Urbit.

36Our plan is to run urbit.org as a protocol—we’ll treat it like a real entity, but instead of dealing with the administrative details of setting up such an organization, we’ll incubate it within Tlon and give it a mandate: To competently distribute address space as a means of improving Urbit.

33

37

38+

34## Moving Forward

39## Moving Forward

35

40

36On that note, allow me to introduce myself: I’m Josh[^1], the new Interim Director of urbit.org. I’ve been a follower of this project for several years now and more recently a fairly active community member. I first became fascinated by Urbit as a programmer that saw the potential in a clean-slate OS; I later became compelled by a future in which social computing becomes small, friendly, and human-scale again.

41On that note, allow me to introduce myself: I’m Josh[^1], the new Interim Director of urbit.org. I’ve been a follower of this project for several years now and more recently a fairly active community member. I first became fascinated by Urbit as a programmer that saw the potential in a clean-slate OS; I later became compelled by a future in which social computing becomes small, friendly, and human-scale again.

37

42

38My background is predominantly in building software, companies, and teams—most notably [Starcity](https://starcity.com), where I am a co-founder and CTO. Starcity[^2], like Tlon, is focused on enabling communities to flourish. While the approaches couldn’t be more different, the goal of bringing people together in fundamentally human ways is shared.

43My background is predominantly in building software, companies, and teams—most notably [Starcity](https://starcity.com), where I am a co-founder and CTO. Starcity[^2], like Tlon, is focused on enabling communities to flourish. While the approaches couldn’t be more different, the goal of bringing people together in fundamentally human ways is shared.

39

44

40−My goal is to leverage urbit.org to ensure Urbit’s success. I want to see a world in which Urbit is used by my friends, family, colleagues, everyone I know. To get there, much is left to build.

45+My goal is to leverage urbit.org to ensure Urbit’s success. I want to see a world in which Urbit is used by my friends, family, colleagues, everyone I know. To get there, much is left to build.

41

46

42To that end, the first objective of urbit.org is to recruit builders and give them the tools to succeed. I’ll be focusing heavily on providing technical support to developers that engage with us via Grants, outreach to the wider developer community, supporting the efforts of those that are creating educational courses and documentation, and enlarging the contribution surface by exposing it to other programming languages[^3].

47To that end, the first objective of urbit.org is to recruit builders and give them the tools to succeed. I’ll be focusing heavily on providing technical support to developers that engage with us via Grants, outreach to the wider developer community, supporting the efforts of those that are creating educational courses and documentation, and enlarging the contribution surface by exposing it to other programming languages[^3].

43

48

44The product work that Tlon is doing is crucial to Urbit’s long-term success, so I’ll also be leveraging bounties to more directly accelerate their development efforts. Landscape represents the clearest example of a cohesive vision for Urbit’s use. The existence of a polished product built on Urbit demonstrates to the world that the platform is robust and capable, and the growing community seems eager to help. You can expect more bounties very soon that provide a direct connection to the Landscape roadmap.

49The product work that Tlon is doing is crucial to Urbit’s long-term success, so I’ll also be leveraging bounties to more directly accelerate their development efforts. Landscape represents the clearest example of a cohesive vision for Urbit’s use. The existence of a polished product built on Urbit demonstrates to the world that the platform is robust and capable, and the growing community seems eager to help. You can expect more bounties very soon that provide a direct connection to the Landscape roadmap.

45

50

46−As I’m only just getting started, I’d love to hear your thoughts. If you’re working on any grants you’ll hear from me soon, and if you have an idea that you want to pursue, I’m here to help you make it happen. You can reach me directly via Urbit as `~wolref-podlex` or by email at josh@urbit.org.

51+As I’m only just getting started, I’d love to hear your thoughts. If you’re working on any grants you’ll hear from me soon, and if you have an idea that you want to pursue, I’m here to help you make it happen. You can reach me directly via Urbit as `~wolref-podlex` or by email at josh@urbit.org.

47

52

48I look forward to working with you.

53I look forward to working with you.

49

54

50[^1]: But my friends call me ~wolref-podlex.

55[^1]: But my friends call me ~wolref-podlex.

56+

51[^2]: We’re also really into the idea of being the first builder of housing on Mars. Just saying...

57[^2]: We’re also really into the idea of being the first builder of housing on Mars. Just saying...

58+

52−[^3]: We call this project Airlock. You’ll hear more about it soon.

59+[^3]: We call this project Airlock. You’ll hear more about it soon.

content/blog/ford-fusion.md+28−24

@@ -1,15 +1,18 @@

1+++

1+++

2title = "Ford Fusion"

2title = "Ford Fusion"

3−date = "2020-07-14"

3+date = 2020-07-15

4description = "Ford Fusion was an overhaul of Urbit's over-the-air upgrade process and a rewrite of its build system. The new update system corrects a few long-standing bugs with the previous one, and the new build system is simpler, smaller (by around 5,000 lines), and easier to manage."

4description = "Ford Fusion was an overhaul of Urbit's over-the-air upgrade process and a rewrite of its build system. The new update system corrects a few long-standing bugs with the previous one, and the new build system is simpler, smaller (by around 5,000 lines), and easier to manage."

5−

6[extra]

5[extra]

7author = "Ted Blackman"

6author = "Ted Blackman"

8ship = "~rovnys-ricfer"

7ship = "~rovnys-ricfer"

9−image = "https://media.urbit.org/site/posts/essays/ford-fusion.png"

8+image ="https://media.urbit.org/site/posts/essays/ford-fusion.png"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/ford-fusion.png">

14+

15+<br>

13

16

14## Overview and Rationale

17## Overview and Rationale

15

18

@@ -23,14 +26,13 @@ Urbit isn't exactly a traditional operating system, so the comparison is somewha

23itself in the general case, not just some special cases.

26itself in the general case, not just some special cases.

24

27

25Ford Fusion has fixed the major upgrade issues of the past by guaranteeing three properties that in retrospect are obvious requirements, but, like much of Urbit, took many years and rewrites to identify as such:

28Ford Fusion has fixed the major upgrade issues of the past by guaranteeing three properties that in retrospect are obvious requirements, but, like much of Urbit, took many years and rewrites to identify as such:

26−

27- Atomic: the update should complete or fail in one transaction. If it

29- Atomic: the update should complete or fail in one transaction. If it

28 fails, the system shouldn't get stuck.

30 fails, the system shouldn't get stuck.

29- Self-contained: there must be no implicit dependencies or hysteresis

31- Self-contained: there must be no implicit dependencies or hysteresis

30 (dependence on previous system states) when building the new software

32 (dependence on previous system states) when building the new software

31 from source.

33 from source.

32- Ordered: updates must be monotonically sequenced from the system's

34- Ordered: updates must be monotonically sequenced from the system's

33− lowest layer to highest.

35+ lowest layer to highest.

34

36

35Let’s walk through them one by one.

37Let’s walk through them one by one.

36

38

@@ -40,9 +42,9 @@ In previous versions of Urbit, updates failed atomicity by deferring parts of th

40

42

41We've learned that asynchronicity is an entropic state. A system will tend toward more asynchronicity over time unless effort is put into keeping it synchronous. [As Jonathan Blow has noted](https://youtu.be/pW-SOdj4Kkk?t=2547), the language server protocol has turned every editor plugin into a distributed system, since now it has to communicate asynchronously with the main editor process.

43We've learned that asynchronicity is an entropic state. A system will tend toward more asynchronicity over time unless effort is put into keeping it synchronous. [As Jonathan Blow has noted](https://youtu.be/pW-SOdj4Kkk?t=2547), the language server protocol has turned every editor plugin into a distributed system, since now it has to communicate asynchronously with the main editor process.

42

44

43−Consider an update system that took multiple Arvo events to complete. An ad-hoc higher-level transaction system would need to be built to roll back the effects of the first few events in case of failure. It’s important for various parts of the system to be able to emit effects on upgrade; since those effects would need to be rolled back if a later event in this upgrade fails, the system would need to maintain a queue of those events and only apply them once all the other upgrade events have completed.

45+Consider an update system that took multiple Arvo events to complete. An ad-hoc higher-level transaction system would need to be built to roll back the effects of the first few events in case of failure. It’s important for various parts of the system to be able to emit effects on upgrade; since those effects would need to be rolled back if a later event in this upgrade fails, the system would need to maintain a queue of those events and only apply them once all the other upgrade events have completed.

44

46

45−Note that the asynchronicity has now spread. Some effects that would normally be guaranteed to be processed synchronously might now be asynchronous. Entropy has begun to take hold, chipping away at the set of invariants the system is capable of guaranteeing.

47+Note that the asynchronicity has now spread. Some effects that would normally be guaranteed to be processed synchronously might now be asynchronous. Entropy has begun to take hold, chipping away at the set of invariants the system is capable of guaranteeing.

46

48

47This observation is not purely theoretical. False modularity was the cause of internal asynchronicity in Clay where it had to wait for responses in a complex dance with Ford, which was another vane (Arvo kernel module); moving Ford into Clay allowed function calls that were synchronous from Clay’s perspective, which allowed further simplifications, culminating in about a twenty percent reduction of source code size of the Arvo kernelspace.

49This observation is not purely theoretical. False modularity was the cause of internal asynchronicity in Clay where it had to wait for responses in a complex dance with Ford, which was another vane (Arvo kernel module); moving Ford into Clay allowed function calls that were synchronous from Clay’s perspective, which allowed further simplifications, culminating in about a twenty percent reduction of source code size of the Arvo kernelspace.

48

50

@@ -77,17 +79,17 @@ Emerging from this underworld required making a number of changes to the Arvo ke

77

79

78These are the layers of the stack that update themselves on the fly, from lowest to highest:

80These are the layers of the stack that update themselves on the fly, from lowest to highest:

79

81

80−- hoon: the hoon language definition and compiler, defined in `/sys/hoon/hoon`

82++ hoon: the hoon language definition and compiler, defined in `/sys/hoon/hoon`

81−- arvo: the arvo kernel proper and related type definitions, in `/sys/arvo/hoon`

83++ arvo: the arvo kernel proper and related type definitions, in `/sys/arvo/hoon`

82−- zuse: the standard library, in `/sys/zuse/hoon`

84++ zuse: the standard library, in `/sys/zuse/hoon`

83−- vanes: arvo kernel modules, including clay itself, in folder `/sys/vane`

85++ vanes: arvo kernel modules, including clay itself, in folder `/sys/vane`

84−- userspace: apps, marks, ancillary source code like libraries, and user data

86++ userspace: apps, marks, ancillary source code like libraries, and user data

85

87

86An update to one layer necessitates a reload of all layers above it; e.g. a change to Zuse should trigger updates to the vanes and userspace. Conversely, an update to a higher layer should not cause a spurious reload of lower layers, which should not be affected by the change; for example, an update to just userspace should not cause any reloads of system code.

88An update to one layer necessitates a reload of all layers above it; e.g. a change to Zuse should trigger updates to the vanes and userspace. Conversely, an update to a higher layer should not cause a spurious reload of lower layers, which should not be affected by the change; for example, an update to just userspace should not cause any reloads of system code.

87

89

88−Clay is responsible for enforcing the layering of updates. An update to a module is triggered when an attempt is made to commit a change to Clay that affects one or more files needed to build the module. For example, if the 'foo' agent's source, defined in `/app/foo/hoon`, imports the 'bar' library from `/lib/bar/hoon`, then a modification to `/lib/bar/hoon` triggers an update to the 'foo' agent. All vanes and userspace files depend on Zuse, which depends on the Arvo and Hoon sources, so a change to the Hoon, Arvo, or Zuse sources will trigger updates to all vanes and userspace files.

90+Clay is responsible for enforcing the layering of updates. An update to a module is triggered when an attempt is made to commit a change to Clay that affects one or more files needed to build the module. For example, if the 'foo' agent's source, defined in `/app/foo/hoon`, imports the 'bar' library from `/lib/bar/hoon`, then a modification to `/lib/bar/hoon` triggers an update to the 'foo' agent. All vanes and userspace files depend on Zuse, which depends on the Arvo and Hoon sources, so a change to the Hoon, Arvo, or Zuse sources will trigger updates to all vanes and userspace files.

89

91

90−When asked to perform a commit, Clay determines which layers need to be updated based on which files have changed and which modules depend on those files. For now, all running programs load their source from the `%home` desk, so only changes to `%home` trigger stateful updates. Files in other desks can be built, but not installed into the system. This might be relaxed in the future.

92+When asked to perform a commit, Clay determines which layers need to be updated based on which files have changed and which modules depend on those files. For now, all running programs load their source from the `%home` desk, so only changes to `%home` trigger stateful updates. Files in other desks can be built, but not installed into the system. This might be relaxed in the future.

91

93

92The process of updating varies by layer. The Hoon and Zuse layers are stateless, so their newly rebuilt cores (Nock executables) must be stored (somewhere in the system’s Nock tree, in memory; remember, Urbit is a single-level store), but they have no state that would need to be migrated. The Arvo kernel, vanes, and userspace agents are all live, stateful programs, so in order to update one of those, the system must extract the state from the old program, pass that data into the newly built program, then discard the old program and store the new one. Arvo and agent state injection routines can emit effects, but vane updates cannot.

94The process of updating varies by layer. The Hoon and Zuse layers are stateless, so their newly rebuilt cores (Nock executables) must be stored (somewhere in the system’s Nock tree, in memory; remember, Urbit is a single-level store), but they have no state that would need to be migrated. The Arvo kernel, vanes, and userspace agents are all live, stateful programs, so in order to update one of those, the system must extract the state from the old program, pass that data into the newly built program, then discard the old program and store the new one. Arvo and agent state injection routines can emit effects, but vane updates cannot.

93

95

@@ -128,7 +130,7 @@ When Gall receives a newly rebuilt agent from Clay, it calls the gate produced b

128It is a bit counterintuitive that an app reload failure could prevent a kernel update. The reason is that we don't want the system to update itself into a broken state. An Urbit can be rendered practically unusable by the presence of broken agents, even if the kernel hasn't lost integrity,

130It is a bit counterintuitive that an app reload failure could prevent a kernel update. The reason is that we don't want the system to update itself into a broken state. An Urbit can be rendered practically unusable by the presence of broken agents, even if the kernel hasn't lost integrity,

129so it's kinder to the user not to break their agents by installing an incompatible kernel update. This also puts virtuous pressure on kernel developers not to "break userspace", the importance of which has been insisted on for decades by Linus Torvalds, among others.

131so it's kinder to the user not to break their agents by installing an incompatible kernel update. This also puts virtuous pressure on kernel developers not to "break userspace", the importance of which has been insisted on for decades by Linus Torvalds, among others.

130

132

131−If an agent does crash a commit event that included a kernel update, the attempted commit is now trivially rolled back, and the system can deliver an error message to the user. This does not leave the system in an inconsistent or stuck state, so the user could modify the failing agent and try the kernel update again later. Supporting better workflows for keeping third-party agents up-to-date will be an important aspect of Urbit’s upcoming software distribution work.

133+If an agent does crash a commit event that included a kernel update, the attempted commit is now trivially rolled back, and the system can deliver an error message to the user. This does not leave the system in an inconsistent or stuck state, so the user could modify the failing agent and try the kernel update again later. Supporting better workflows for keeping third-party agents up-to-date will be an important aspect of Urbit’s upcoming software distribution work.

132

134

133## Ford Build Semantics

135## Ford Build Semantics

134

136

@@ -144,7 +146,7 @@ Clay exposes file builds into the scry namespace with `%ca`: as an example, `.^(

144

146

145#### Mark Builds

147#### Mark Builds

146

148

147−A mark build produces a `$dais` mark-interface core. It first performs a file build on the Hoon file in `/mar` that defines the mark core, then it does some metaprogramming to make the operations more convenient to use. If the raw mark core delegated revision control operations to another mark core, the mark build will also load the delegate mark core and resolve the result into the `$dais`.

149+A mark build produces a `$dais` mark-interface core. It first performs a file build on the Hoon file in `/mar` that defines the mark core, then it does some metaprogramming to make the operations more convenient to use. If the raw mark core delegated revision control operations to another mark core, the mark build will also load the delegate mark core and resolve the result into the `$dais`.

148

150

149Clay exposes mark builds into the scry namespace with `%cb`: as an example, `.^(dais:clay %cb /~zod/home/3/mar/foo/hoon)` builds a `$dais` for the `%foo` mark.

151Clay exposes mark builds into the scry namespace with `%cb`: as an example, `.^(dais:clay %cb /~zod/home/3/mar/foo/hoon)` builds a `$dais` for the `%foo` mark.

150

152

@@ -152,14 +154,15 @@ Clay exposes mark builds into the scry namespace with `%cb`: as an example, `.^(

152

154

153A cast build produces a `$tube`: a gate that takes a value of one mark as input and converts it to a valid value of another mark or crashes. To convert from mark `%foo` to mark `%bar`, Clay tries the following operations, in order:

155A cast build produces a `$tube`: a gate that takes a value of one mark as input and converts it to a valid value of another mark or crashes. To convert from mark `%foo` to mark `%bar`, Clay tries the following operations, in order:

154

156

155−- direct grow from `%foo`

157++ direct grow from `%foo`

156−- direct grab from `%bar`

158++ direct grab from `%bar`

157−- indirect jump from `%foo` through `%qux`

159++ indirect jump from `%foo` through `%qux`

158−- indirect grab from `%bar` through `%qux`

160++ indirect grab from `%bar` through `%qux`

159

161

160The `%foo` mark can “grow to” `%bar` by providing an arm in its `+grow` core named `+bar`. `%bar` can convert from `%foo` using a `+foo` arm in its `+grab` core. `%foo` can also chain a conversion through an intermediary using an arm in its `+jump` core, and `%bar` can specify an “indirect grab” by having a `+grab` arm produce a delegate mark instead of directly defining a conversion gate.

162The `%foo` mark can “grow to” `%bar` by providing an arm in its `+grow` core named `+bar`. `%bar` can convert from `%foo` using a `+foo` arm in its `+grab` core. `%foo` can also chain a conversion through an intermediary using an arm in its `+jump` core, and `%bar` can specify an “indirect grab” by having a `+grab` arm produce a delegate mark instead of directly defining a conversion gate.

161

163

162−Clay exposes cast builds into the scry namespace with `%cc`: as an example, `.^(tube:clay %cc /~zod/home/3/foo/bar)` builds a `$tube` conversion gate from `%foo` to `%bar`.

164+Clay exposes cast builds into the scry namespace with `%cc`: as an example, `.^(tube:clay %cc

165+/~zod/home/3/foo/bar)` builds a `$tube` conversion gate from `%foo` to `%bar`.

163

166

164### Ford Runes

167### Ford Runes

165

168

@@ -204,7 +207,8 @@ A valid userspace hoon file must contain a nonempty list of hoons (hoon source e

204

207

205Urbit still needs to make better use of desks other than `%home` and the development process should be adjusted given the tighter coupling between source code and kernel and tighter criteria for accepting an update.

208Urbit still needs to make better use of desks other than `%home` and the development process should be adjusted given the tighter coupling between source code and kernel and tighter criteria for accepting an update.

206

209

207−This work also hopefully provides a good foundation of a package management and software distribution system for Urbit. As `~wicdev-wisryt` has said, a user should be able to run `|install ~norsyr-torryn/canvas` to load and build remote source. No one should experience dependency hell on Urbit, but we're not there yet.

210+This work also hopefully provides a good foundation of a package management and software distribution system for Urbit. As `~wicdev-wisryt` has said, a user should be able to run `|install

211+~norsyr-torryn/canvas` to load and build remote source. No one should experience dependency hell on Urbit, but we're not there yet.

208

212

209At least now, building a desk has no dependencies, other than a Ford with a compatible Hoon compiler. No decisions have been made on this yet, but

213At least now, building a desk has no dependencies, other than a Ford with a compatible Hoon compiler. No decisions have been made on this yet, but

210Ford might get moved to inside the desk, possibly by making Zuse callable. This could allow a desk to expose a Nock interface in addition to a typed Hoon interface, which could even let a desk be used as a "pill" bootloader.

214Ford might get moved to inside the desk, possibly by making Zuse callable. This could allow a desk to expose a Nock interface in addition to a typed Hoon interface, which could even let a desk be used as a "pill" bootloader.

@@ -217,6 +221,6 @@ In early 2020, `~master-morzod` suggested moving Ford into Clay to reduce asynch

217

221

218The first time I rewrote Ford, it took me six months, with help from `~littel-ponnys`, and it weighed in at 6,000 lines of code. The second time, in late 2018, took a few weeks. The third time, in January 2020, took a week. I wrote `+ford` in Ford Fusion in one long day, and it’s about 500 lines of synchronous, functional code.

222The first time I rewrote Ford, it took me six months, with help from `~littel-ponnys`, and it weighed in at 6,000 lines of code. The second time, in late 2018, took a few weeks. The third time, in January 2020, took a week. I wrote `+ford` in Ford Fusion in one long day, and it’s about 500 lines of synchronous, functional code.

219

223

220−It has taken me two or three years to understand this problem as well as I do, and I expect there are parts of it I still don’t understand. The code itself isn’t the issue; it’s finding the right answer to ontological and teleological questions. What _is_ Ford? What will it be in a hundred years? I’m confident Ford Fusion is more similar than its predecessor to the Ford of 2120, because it’s smaller, more functional, and easier to understand and administer.

224+It has taken me two or three years to understand this problem as well as I do, and I expect there are parts of it I still don’t understand. The code itself isn’t the issue; it’s finding the right answer to ontological and teleological questions. What *is* Ford? What will it be in a hundred years? I’m confident Ford Fusion is more similar than its predecessor to the Ford of 2120, because it’s smaller, more functional, and easier to understand and administer.

221

225

222As an engineering discipline and organizational practice, working on a system intended to be frozen yields surprising simplifications like this every so often. Urbit is now reaching the point where we’re starting to see more of the obsidian edges of the frozen future system emerge from the lava.

226As an engineering discipline and organizational practice, working on a system intended to be frozen yields surprising simplifications like this every so often. Urbit is now reaching the point where we’re starting to see more of the obsidian edges of the frozen future system emerge from the lava.

content/blog/foss-1.mddeleted−64

@@ -1,64 +0,0 @@

1−+++

2−title = "Urbit's Open Source Culture, Part I"

3−date = "2023-05-31"

4−description = "How did Urbit cultivate a unique open source software culture? Let's take a look at how we got to where we are today."

5−

6−[extra]

7−author = "N E Davis"

8−ship = "~lagrev-nocfep"

9−image = "https://upload.wikimedia.org/wikipedia/commons/a/a9/SR71_factoryfloor_SkunkWorks.jpg"

10−+++

11−

12−

13−

14−> “Open source is an intellectual property destroyer. I can't imagine something that could be worse than this for the software business and the intellectual-property business.” (Jim Allchin, Microsoft executive)

15−

16−A founder's personal enquiry into the foundations of practical computing grew into a skunkworks startup to build an alternative basis for principled computing, and has now evolved into a burgeoning open source platform and community.

17−

18−- [Moron Lab, “Maxwell's equations of software (Nock)” (~2010.1.9)](https://moronlab.blogspot.com/2010/01/nock-maxwells-equations-of-software.html)

19−- [Moron Lab, “Urbit: functional programming from scratch” (~2010.1.13)](https://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html)

20−

21−How did Urbit cultivate a unique open source software culture? Let's take a look at how we got to where we are today.

22−

23−Open source culture really got going in the 1980s with the restrictive Unix licensing scheme and the consequent publication of the GNU software tools. With the marriage of GNU to Linux ([“I'd like to interject for a moment”](https://copypastatext.com/id-just-like-to-interject-for-a-moment/)), a full stack, from the bare metal to the end user, was possible. Usenet and early Internet forums furthermore encouraged interested developers to start contributing actively.

24−

25−The ethos of open source software drew on a number of sources, from William Gibson's _Neuromancer_ trilogy to “A Cypherpunk's Manifesto.” Those involved were often motivated by a healthy distrust of proprietary software. The big break for open source software (OSS) came with the [Unix ownership lawsuits](https://en.wikipedia.org/wiki/Unix_wars), which gave GNU/Linux a chance to break into the bigtime for systems software. The [2001 case against Microsoft](https://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp.) as a monopoly lent further credence to the open source mandate.

26−

27−During this time, Urbit began life as a personal dissertation, in a sense, to derive a minimalist practical set of computing expressions as a combinator calculus. The early concepts that became part of Urbit, such as kelvin versioning and Maxwellian code, show up during its first decade. Nock was not open source for two reasons: the founder's conviction that as software it was already public domain, and the fact that there was no one yet to collaborate with.

28−

29−It was about a decade before Tlon was started as a small bespoke programming house to work on the esoteric project of defining something usable on top of the minimalist Nock specification. No one knew about Urbit besides some blog readers, and unless you worked in or next to Tlon you had basically zero chance of following the project via software alone.

30−

31−Early Tlon did a fairly good job of putting their software out there, but the documentation and nomenclature were considered obscurantist and the project was described as performance art or a deliberate wild goose chase. These combined to make Urbit appear fairly opaque, despite open development using GitHub and the liberal MIT license. System components like Nock and Arvo were declared public domain or liberally licensed.

32−

33−To this point (let's say 2019), Urbit was by license and by code an open source project, but had a reputation for being basically impossible for an outsider, even one with a fair amount of coding experience, to really figure out what's going on without serious handholding from the core devs. (Nor is this inappropriate for a small startup at this stage—it simply is the way most nominally OSS projects function.) However, the mystery engaged others beyond Tlon to brave the wilds and figure out what this Urbit project was all about.

34−

35−Urbit’s goal has always been to produce a stable kernel for all time, referred to by a metaphor of losing heat energy and entropy. As Urbit gradually cooled from red hot slag to what we'll call a developer alpha, Tlon began a project of greater outreach to the developer community. In particular, crypto software developers saw attractive aspects in Nock's concision and apparent provability and in Urbit's functional-as-in-math approach to operating system and application state. Tlon started a Discord for onboarding and troubleshooting, including community concierges who were tasked with engaging anyone with ship troubles. This tapped into and fostered a culture of Urbiters aggressively helping others debug and troubleshoot their ships, which continues to this day. Tlon also began Hoon 101 to teach outsiders how to actually build things on Urbit.

36−

37−As Urbit slowly grew into a larger developer community, some hard strategic questions about project scope and direction came into focus. There had always been a provision for Urbit to have some sort of foundation with stewardship over the project—either the Urbit Educational Foundation or something similar. Like the Linux Foundation, this organization would serve to coordinate activity between various companies and individuals contributing to the Urbit project. The foundation would receive an endowment of galaxies earmarked to fund Urbit's development.

38−

39−Urbit's use of address space to fund development means that the builders, even those who have discovered Urbit relatively recently, are able to acquire a significant stake in the project and its success.

40−

41−In practical terms, Tlon started the Urbit Foundation internally first as `urbit.org`, then rolled it out as a standalone company with a mandate to first build itself into a viable cultivator of Urbit, then to take over Urbit core development. By early 2023, the Urbit Foundation was in a position to take over core development for the platform.

42−

43−There have been several aspects of this journey that have led Urbit to have a thriving and promising open source software culture:

44−

45−1. Urbit's nature as a functional operating system has a deep appeal to software developers and others who find appeal in a mathematically elegant system, including the guarantees made by innovations such as the scry namespace bindings and the public key infrastructure.

46−2. Hoon is a mood. What I mean by that is that Hoon's unique aesthetics, subject-oriented paradigm, and the utility of cores give coders a unique experience, like systems programming in APL would feel like.

47−3. The developer docs are finally prioritized and made publicly legible. Large swaths of the operating system and standard library are finally documented.

48−4. Third-party software distribution is made trivial. Decentralized peer-to-peer open source software distribution without having to go through a GitHub intermediary changes the game.

49−5. Urbit's educational program expands from Tlon's initial offerings to a community program (Hooniverse/Hooniversity), then to a dedicated program with specific course milestones under the auspices of the Urbit Foundation.

50−6. Urbiters start meeting in person at Assembly and other events. After the 2020 efflorescence of the Urbit community, this is the first time most of the newer people were able to meet in real life. (This is a substantially different situation than the pre-2019 Urbit environment—most people didn't know Tlonners first, they knew Urbit first and mainly online.)

51−7. Three major active groups form dedicated to all-purpose coding on Urbit:

52− A. Hooniverse, ~hiddev-dannut/new-hooniverse, originally strictly for the community Hoon School but now for all of the UF's educational efforts.

53− B. The Forge, ~middev/the-forge, for advanced technical discussion.

54− C. `[battery payload]`, ~dister-dozzod-lapdeg/battery-payload, the UF's developer community group.

55−8. The Urbit Foundation begins an active grants program. At first focusing on userspace and cultural grants, this eventually leans back into kernel work.

56−9. As the Urbit Foundation takes over core development, this necessitates changing that process from being a one-company project to requiring coordination, said coordination being much easier in the open than in closed meetings. (This also enables Tlon to focus on product delivery over core development.)

57−10. The Urbit Foundation begins using a `gather.town` “Urbit Hacker House,” which puts people together for synchronous interrupts. Any community member can wander in and be a fly on the wall or an active interlocutor.

58− A. This enables the UF to start hosting daily pull request triage and a rapid assignment of tasks in the open.

59− B. Communications strategy meetings are also public.

60− C. Build parties (originally conceived as app-in-a-day) demonstrate pair programming, achieve inter-programmer communication of information akin to IRL programming, and allow anyone to participate.

61−

62−We find ourselves, as Urbit developers, having grown together a strong and unique culture of open source software development verging on radical transparency. It's not just code and license being open—it's the entire ensemble of programmer culture and on-platform dogfooding (to the extent possible). The greybeards and the noobs encounter each other directly and openly all the time, in `gather.town` and in Urbit groups.

63−

64−From modest beginnings, Urbit has achieved some small traction in the world and grown an exemplary open source culture. What will it take for Urbit to succeed in the future? That's the next entry.

content/blog/foss-2.mddeleted−59

@@ -1,59 +0,0 @@

1−+++

2−title = "Urbit's Open Source Culture, Part II"

3−date = "2023-06-13"

4−description = "How will Urbit continue to foster its innovative open source software culture?"

5−

6−[extra]

7−author = "N E Davis"

8−ship = "~lagrev-nocfep"

9−image = "https://spacecenter.org/wp-content/uploads/2023/02/img-apollo-mission-control-3.jpg"

10−+++

11−

12−

13−

14−> God watches over fools, drunks, and the United States of America. (Otto von Bismarck, apocryphal)

15−

16−In our last installment, we considered how Urbit has grown its own robust open source culture. Now we look to the future: what will it take for Urbit to succeed, not only as an exemplary open source project but as a computing platform that delivers on its promise?

17−

18−Part of what makes an open source culture vibe is remix culture, the ability to rework the source material to produce novel components or manifestations. Urbit has the raw materials for this in spades, memetically and technically. It is up to us to keep these tools in our developers’ and enthusiasts’ hands.

19−

20−The default answer, which isn't terrible, is that Urbit should keep doing what it's done to get this far:

21−

22−1. Urbit should continue to prioritize decentralized development.

23−2. Urbit should lean into ownership-based incentives. Indeed, this is the most effective lever that the Urbit Foundation has.

24−3. Urbit should maintain the developer's republic. Core developers should rub shoulders with first-time Hooners.

25−4. Urbit should continue to ship source with code, since that is how code is actually distributed. The means of open source software are _necessarily in the user's hands_ with Martian software.

26−

27−There are some areas in which we hope to improve. Our documentation continues to expand, as do our educational offerings. We have a mandate to use the Urbit Foundation’s endowment of stars to produce the mature Urbit.

28−

29−What else should we have an eye to in the near future? There’s always more to do, but by prioritizing the items on this short list we would continue to elaborate our open source bona fides as a community and a steering foundation.

30−

31−1. **Code accessibility should be a priority.** Any computer language falls on the spectrum between machine legibility (the pole of machine code and assembly language) and human legibility (the pole of [Scratch](https://scratch.mit.edu/). All code must walk this line.

32−

33− 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. We can support their learning and entry into the ecosystem by defining a subset of Hoon syntax that we adhere to in all of the docs and some of the userspace code. Even if there is a "better" way to write it, we should prefer this restricted discipline in those cases. Let's call this subset "Hoon Prime." Hoon Prime will not always be the most concise Hoon code, and it will likely fail to maintain certain well-established preferences, like heavier expressions going to the bottom, but it should encourage developers to produce generators and agents from `%base`-distributed models as quickly as possible.

34−

35− Hoon Prime should also adopt a standard of literate programming. Several example files already display such a self-documenting nature:

36−

37− - [`simple.hoon` for solid-state subscriptions](https://github.com/wicrum-wicrun/sss/blob/master/urbit/app/simple.hoon)

38− - [`deco.hoon` for doccords](https://github.com/urbit/urbit/blob/develop/pkg/arvo/lib/deco.hoon)

39− - [`pals.hoon`](https://github.com/Fang-/suite/blob/master/app/pals.hoon)

40− - [`rudder.hoon` for serving websites](https://github.com/Fang-/suite/blob/master/lib/rudder.hoon)

41−

42− Our userspace code accessibility model should allow contributors from widely different skill levels to interact. We need to surface and document code patterns as cleanly as possible in the code we distribute. We need to include comments and unit tests so people can see how and why code works like it does.

43−

44− Code accessibility cannot be an afterthought. We need to upgrade as much code as possible to A standards [per the style guide](https://developers.urbit.org/reference/hoon/style#grading).

45−

46−2. We need to improve the developer experience. Part of this involves better coding support, and part of this involves better debugging support.

47−

48− To promote better coding, we should continue to develop IDE integrations like the Hoon Language Server. We've had some significant wins here, but rust never sleeps. We should also continue to produce userspace and middleware support libraries. We need to pay attention to how developer preferences are manifesting in their workflows and tooling.

49−

50− Better error messaging and debugging support, perhaps even a framework for line-by-line code execution, would be invaluable. Upgrading Dojo and generator support is an easy win. Any tool friction is a sin and we need to track this and think about how to improve use.

51−

52−3. We need our open source culture to continue to develop in the sunlight. We need to highlight and communicate user stories for developer tools, new and old. We need to share these from inside of companies in the ecosystem. I'm not going to call for “best practices”—it's too early and that's too corporate—but tacit knowledge and horizontal skill transfer need to be encouraged through active pair programming and utilization of build parties and the like.

53−

54− We need to expose how bugs occur, propagate, and are corrected. The core development team has committed to public [postmortems](https://github.com/urbit/urbit/issues/6583) when things go wrong.

55−

56−4. Ultimately, Urbit has to stay playful. Urbit makes programming, even systems programming, a lot of fun. Fun is open-ended and surprising. It allows for whimsy in code and product.

57−

58−Our developer onboarding and open source culture should be a model for the entire open source world. This is neither impossible nor impractical—we've made huge strides in legibility, and we're sailing with the wind.

59−

content/blog/gifts-q3-2020.md+9−7

@@ -1,19 +1,21 @@

1+++

1+++

2title = "Gifts Q3 2020"

2title = "Gifts Q3 2020"

3−date = "2020-09-22"

3+date = 2020-09-23

4description = "Twice a year we distribute address space to those that have made valuable contributions to Urbit. Now called our Gifts program, the gifting of address space has been part of Urbit long before we had a grants program."

4description = "Twice a year we distribute address space to those that have made valuable contributions to Urbit. Now called our Gifts program, the gifting of address space has been part of Urbit long before we had a grants program."

5−

6[taxonomies]

5[taxonomies]

7−grant_type = [ "Gift" ]

6+grant_type = ["Gift"]

8−grant_category = [ ]

7+grant_category = []

9−

10[extra]

8[extra]

11author = "Josh Lehman"

9author = "Josh Lehman"

12ship = "~wolref-podlex"

10ship = "~wolref-podlex"

13−image = "https://media.urbit.org/site/posts/essays/gifts.png"

11+image ="https://media.urbit.org/site/posts/essays/gifts.png"

14+++

12+++

15

13

14+<br>

15+

16−

16+<img class="ba" src="https://media.urbit.org/site/posts/essays/gifts.png">

17+

18+<br>

17

19

18Twice a year we distribute address space to those that have made valuable contributions to Urbit. Now called our _Gifts_ program, the gifting of address space has been part of Urbit long before we had a grants program.

20Twice a year we distribute address space to those that have made valuable contributions to Urbit. Now called our _Gifts_ program, the gifting of address space has been part of Urbit long before we had a grants program.

19

21

content/blog/governance-of-urbit.md+2−7

@@ -1,17 +1,12 @@

1+++

1+++

2title = "Governance of urbit.org"

2title = "Governance of urbit.org"

3−date = "2019-01-10"

3+date = 2019-01-11

4description = "Stewardship of the Urbit Project."

4description = "Stewardship of the Urbit Project."

5−aliases = [

6− "/posts/essays/governance-of-urbit",

5+aliases = ["/posts/essays/governance-of-urbit", "/posts/governance-of-urbit"]

7− "/posts/governance-of-urbit"

8−]

9−

10[extra]

6[extra]

11author = "Erik Newton"

7author = "Erik Newton"

12ship = "~patnes-rigtyn"

8ship = "~patnes-rigtyn"

13+++

9+++

14−

15

10

16

11

17## Summary

12## Summary

content/blog/hackathon-results.md+20−12

@@ -1,59 +1,67 @@

1+++

1+++

2title = "Hackathon Results"

2title = "Hackathon Results"

3−date = "2020-06-11"

3+date = 2020-06-12

4description = "We recently held an invite-only Urbit Hackathon for graduates of our Hoon School program, and the submissions really impressed us across the board. Submissions were judged on several criteria: creativity, usefulness, and code quality."

4description = "We recently held an invite-only Urbit Hackathon for graduates of our Hoon School program, and the submissions really impressed us across the board. Submissions were judged on several criteria: creativity, usefulness, and code quality."

5−

6[extra]

5[extra]

7author = "Robert Mariani"

6author = "Robert Mariani"

8ship = "~lodleb-ritrul"

7ship = "~lodleb-ritrul"

9−image = "https://media.urbit.org/site/posts/essays/hackathon-results-wide.png"

8+image ="https://media.urbit.org/site/posts/essays/hackathon-results-wide.png"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/hackathon-results.png">

14+

15+<br>

13

16

14Results of the Urbit Hackathon

17Results of the Urbit Hackathon

15

18

16−We recently held an invite-only Urbit Hackathon for graduates of our Hoon School program, and the submissions really impressed us across the board. Submissions were judged on several criteria: creativity, usefulness, and code quality.

19+We recently held an invite-only Urbit Hackathon for graduates of our Hoon School program, and the submissions really impressed us across the board. Submissions were judged on several criteria: creativity, usefulness, and code quality.

17

20

18Congratulations to all the participants, especially the winners—their projects are seriously impressive.

21Congratulations to all the participants, especially the winners—their projects are seriously impressive.

19

22

23+

20### First Place: Eight Stars

24### First Place: Eight Stars

21

25

22−Jose’s `~norsyr-torryn` Canvas is a peer-to-peer, collaborative drawing app that comes in the form of a Landscape tile. It’s kind of like a multiplayer MS Paint, but better.

26+Jose’s `~norsyr-torryn` Canvas is a peer-to-peer, collaborative drawing app that comes in the form of a Landscape tile. It’s kind of like a multiplayer MS Paint, but better.

23

27

24Canvas uses Urbit in a way that we think it’s supposed to be used: the stuff that doesn’t require peer-to-peer or storage heavy lifting, such as the actual “drawing” component of the app, is done outside of Urbit.

28Canvas uses Urbit in a way that we think it’s supposed to be used: the stuff that doesn’t require peer-to-peer or storage heavy lifting, such as the actual “drawing” component of the app, is done outside of Urbit.

25

29

26In addition to a freehand template for the classic Paint experience, you can choose from a number of templates to work with, such as a grid of fillable hexagons, or maps of parts of the world and of continents with fillable country divisions. Have you ever wanted to compare which countries you visited, color-coded for how much you liked them? Canvas has a built-in feature for sharing your work on chats in Landscape.

30In addition to a freehand template for the classic Paint experience, you can choose from a number of templates to work with, such as a grid of fillable hexagons, or maps of parts of the world and of continents with fillable country divisions. Have you ever wanted to compare which countries you visited, color-coded for how much you liked them? Canvas has a built-in feature for sharing your work on chats in Landscape.

27

31

28−Check out a video [demonstration](https://www.youtube.com/watch?v=S6DySv730Hw) of Canvas, and view [the code](https://github.com/yosoyubik/canvas).

32+Check out a video [demonstration](https://www.youtube.com/watch?v=S6DySv730Hw) of Canvas, and view [the code](https://github.com/yosoyubik/canvas).

29

33

30Jose wins eight stars, and he also wins [le internet for the day](https://news.ycombinator.com/item?id=23228058). Bravo!

34Jose wins eight stars, and he also wins [le internet for the day](https://news.ycombinator.com/item?id=23228058). Bravo!

31

35

36+

32### Second Place: Four Stars Each

37### Second Place: Four Stars Each

33

38

34−Luke Champine’s (`~watter-parter`) flashcard app for Landscape, Rote, has been awarded one of two second-place prizes.

39+Luke Champine’s (`~watter-parter`) flashcard app for Landscape, Rote, has been awarded one of two second-place prizes.

35

40

36−Rote users write decks in udon, review them, and share them with other ships. His immaculate backend code-style and documentation secured his high placement in the Hackathon—his Hoon code also functions as a full-blown walkthrough. If you’re a Gall novice and you’re looking to learn, take a look at his [code](https://github.com/lukechampine/rote). Luke also kept a Notebook documenting his experience at `~watter-parter/hackathon`.

41+Rote users write decks in udon, review them, and share them with other ships. His immaculate backend code-style and documentation secured his high placement in the Hackathon—his Hoon code also functions as a full-blown walkthrough. If you’re a Gall novice and you’re looking to learn, take a look at his [code](https://github.com/lukechampine/rote). Luke also kept a Notebook documenting his experience at `~watter-parter/hackathon`.

37

42

38Luke also included example decks for flashcards on Hoon runes and their irregular forms. So, all said and done, everything about Rote is an excellent resource to the eager Hoon neophyte.

43Luke also included example decks for flashcards on Hoon runes and their irregular forms. So, all said and done, everything about Rote is an excellent resource to the eager Hoon neophyte.

39

44

40Pyry Kovanen (`~dinleb-rambep`) was also awarded second prize for his reading-list-sharing app, Books. Also a Landscape tile, and it’s pretty darn useful, with the ability to import books from Goodreads. Check out [the code](https://github.com/pkova/urbit/tree/books/pkg/interface/books) and the [video demo](https://youtu.be/Spy7FoPdfx8).

45Pyry Kovanen (`~dinleb-rambep`) was also awarded second prize for his reading-list-sharing app, Books. Also a Landscape tile, and it’s pretty darn useful, with the ability to import books from Goodreads. Check out [the code](https://github.com/pkova/urbit/tree/books/pkg/interface/books) and the [video demo](https://youtu.be/Spy7FoPdfx8).

41

46

47+

42### Third Place: Two Stars Each

48### Third Place: Two Stars Each

43

49

50+

44−N E Davis (`~lagrev-nocfep`) brought the heavy infrastructural artillery with Roessler, and won third prize. Roessler is actually three related Hoon tools:

51+N E Davis (`~lagrev-nocfep`) brought the heavy infrastructural artillery with Roessler, and won third prize. Roessler is actually three related Hoon tools:

45`roessler` proper, a library for solving the differential equations producing the [Roessler attractor](https://en.wikipedia.org/wiki/R%C3%B6ssler_attractor).

52`roessler` proper, a library for solving the differential equations producing the [Roessler attractor](https://en.wikipedia.org/wiki/R%C3%B6ssler_attractor).

46`lazytrig`, a library for transcendental functions.

53`lazytrig`, a library for transcendental functions.

47−`proj-3d`, a generator that takes the 3D coordinates produced by `Roessler`.

54+`proj-3d`, a generator that takes the 3D coordinates produced by `Roessler`.

48

55

49The Roessler project is full of cool, novel features. You might enjoy taking a look at the [GitHub repo](https://github.com/sigilante/roessler) ...if your brain is big enough.

56The Roessler project is full of cool, novel features. You might enjoy taking a look at the [GitHub repo](https://github.com/sigilante/roessler) ...if your brain is big enough.

50

57

51John Franklin (`~dirwex-dosrev`) also secured third place for his Notes application. True to its name, it’s a Landscape tile that allows the user to create and search notes by keyword. Look at the [code](https://github.com/jfranklin9000/notes/) and the [demo video](https://www.youtube.com/watch?v=7DurNjCFOmA).

58John Franklin (`~dirwex-dosrev`) also secured third place for his Notes application. True to its name, it’s a Landscape tile that allows the user to create and search notes by keyword. Look at the [code](https://github.com/jfranklin9000/notes/) and the [demo video](https://www.youtube.com/watch?v=7DurNjCFOmA).

52

59

53−Jon (`~ribnes-fonbex`) was awarded third prize for his Quadratic Voting project. It implements for Urbit ships a [quadratic voting system](https://en.wikipedia.org/wiki/Quadratic_voting), which is sort of like ranked-choice voting but allows people to express their stronger preferences.

60+Jon (`~ribnes-fonbex`) was awarded third prize for his Quadratic Voting project. It implements for Urbit ships a [quadratic voting system](https://en.wikipedia.org/wiki/Quadratic_voting), which is sort of like ranked-choice voting but allows people to express their stronger preferences.

54

61

55Congratulations to the winners and to everyone who submitted—nice work!

62Congratulations to the winners and to everyone who submitted—nice work!

56

63

64+

57### The Future

65### The Future

58

66

59We were thoroughly impressed with all of the projects from this inaugural Hackathon. Not only did this Hackathon demonstrate the talent and dedication of our community members, it’s an encouraging sign about the maturity of the Urbit system. We’re going to hold more Hackathons in the future, with one big change: they will be open to anyone who applies.

67We were thoroughly impressed with all of the projects from this inaugural Hackathon. Not only did this Hackathon demonstrate the talent and dedication of our community members, it’s an encouraging sign about the maturity of the Urbit system. We’re going to hold more Hackathons in the future, with one big change: they will be open to anyone who applies.

content/blog/haleek-maul-interview.mddeleted−71

@@ -1,71 +0,0 @@

1−+++

2−title = "NFTs, Urbit IDs, and Communities w/ Haleek Maul"

3−date = "2021-09-09"

4−description = "An interview with the founder of Holdersland"

5−[extra]

6−author = "Matt"

7−ship = "~tirwyd-sarmes"

8−image = "https://media.urbit.org/site/posts/essays/haleek_sigil.jpg"

9−+++

10−

11−

12−

13−*Check out the Holdersland x Urbit collection: [holders.land/urbit](https://holders.land/urbit)*

14−

15−We sat down recently with Haleek Maul to discuss the current state of NFTs and the future of Urbit IDs and digital communities.

16−

17−Are Urbit IDs NFTs? Sure, they're ERC-721 non-fungible tokens which you can buy on OpenSea—but to be clear, we made them way back before the word "NFT" had entered mainstream consciousness. An Urbit ID is a number that is used to generate both a phonetic name and an avatar (what we call [sigils](https://urbit.org/blog/creating-sigils)), but it is so much more than your average NFT—it is a key to an entire digital world.

18−

19−We built Urbit IDs for digital communities and the people they’re made of. An Urbit ID is a decentralized and pseudonymous identity perfect for your collective, commune, squad, team, or DAO. Unlike most addresses or social identities, you own your Urbit ID like you own your crypto. Your Discord handle might be free for now, but as the saying goes, if it’s free then you’re the product. On Urbit your ID is actually yours and you pay for it up front. You can log into third party apps or software without ever relinquishing control of your data. What is yours stays with you. IDs themselves can be owned collectively—there are already DAOs on Urbit who jointly own stars and galaxies.

20−

21−Urbit IDs are evolving and generative. They’re generative because some IDs spawn additional NFTs which themselves can be bought and sold. For instance, each star can spawn 65,535 planets, and each galaxy can spawn 255 stars. The network itself is evolving, meaning that the network can be upgraded via a majority vote by galaxy holders. Urbit IDs and the Ubit network itself are inherently dynamic.

22−

23−At Urbit, we support communities of all kinds. We recently granted Holdersland ten Urbit IDs: four stars and six planets to be auctioned off. Haleek Maul (his Urbit ID is `~fosmex-hocmel`) will be creating custom artwork for each of the sigils. The proceeds of the auction will help support Holdersland in bringing blockchain technologies to the Caribbean. The auction will go live on September 16th, 2021 on [holders.land/urbit](https://holders.land/urbit).

24−

25−Without further ado, here’s Haleek Maul.

26−

27−---

28−

29−**Tell us a little bit about yourself and Holdersland.**

30−

31−Sure. My name is Haleek Maul and I’m a multi-disciplinary artist. I was born in America and came to Barbados when I was three years old. I’ve been making music since 2007. I put out my first debut project in 2012 and since then it has been a process of creating art from the stuff flowing through my mind.

32−

33−Holdersland is a digital extension of my artistic project—a way of creating change in the world around me. When I was younger, there weren’t many artists like me coming from Barbados. I was into a lot of niche electronic and club music and felt alienated from the larger conversation. Holdersland is a way to help creative people in the Caribbean connect with like-minded people around the world, especially using new technologies like blockchain. So I founded Holdersland in 2020 when I left my record label after four years. I felt like music institutions was archaic and didn’t feed into my other artistic practices. I wanted to create an institution that captured the full creative practice—all the way from creating to selling. Most importantly, I wanted to get artists from Barbados and the Caribbean involved in global conversations around art and technology.

34−

35−**What exactly is Holdersland?**

36−

37−It’s a company centered around Caribbean intellectual property. We’re trying to help people get connected with new web3 technologies, especially artists. Holdersland is an aggregator that helps connects those who are interested in new technology with those those who actually develop it.

38−

39−For example, there is a lot of math that underlies music. Part of our project is to extract these mathematical principles and see how they can help generate new forms of art that can be widely distributed. So we’re working to build our own projects and work with users to adopt some of these new technologies. It’s a community of people centered around these values. We plan to implement voting, governance, and incentive structures into the community soon.

40−

41−**What do you think is the link between your two main interests: music and technology?**

42−

43−I’ve always been interested in technology. Anyone who has made music in the last twenty years has had to get involved with tech. Especially if you’re a producer. There are many young kids who are downloading music software and messing around with it, and in the process becoming knowledgeable about music production and design. Science and math live right beside art.

44−

45−I was also into web development when I was a teenager and was very interested in how the internet worked. This led into the work I’m doing with Holdersland. Technology, more often than not, is concerned with collaboration and communication. But in order to develop new technologies we often need to talk about nitty-gritty details. This requires detailed knowledge of particular technologies.

46−

47−**What is the great hope or promise with new decentralized technologies like blockchain or Urbit?**

48−

49−They lower the barrier to communication and trade. Especially for countries like Barbados, we don’t have access to the world market. But now with these networks, and assets like NFTs, we can engage in commerce without borders. It allows new entrants to join the market.

50−

51−It also allows new financial relationships and funding structures to emerge. Rather than have a few people contribute $20k, you can have hundreds of people contribute $100. Once again, this lowers the entry for people to invest is early-stage projects. This changes the way that companies build and ship products.

52−

53−Brain drain is when skilled workers move abroad for more profitable employment. These new technologies allow native Carribeans to stay where they are while earning money. Using these new technologies, the Carribean can prosper while not losing its unique character and cultural identity. Crypto is permanently going to change the distribution of wealth and culture around the world.

54−

55−Discord is a fine community solution, but it’s not ideal. There’s an endless array of plugins and dependencies that makes Discord unstable. However, it is a good mixture of an office, a storefront, and a club: I can do my work, sell assets, and just have fun. Communities are important. People naturally want to be in communities, we just need a better solution than Discord. Especially one that’s crypto-native and allows for commerce. Urbit is a one-stop shop that could fill that gap.

56−

57−**What is the collaboration between Holdersland and Urbit that’s happening this week?**

58−

59−I’m producing some custom sigil artwork for a set of stars and planets. Both the Urbit assets and artwork will be auctioned off together. The proceeds from the event will go towards creating a community music studio here in Barbados and technology education around the island.

60−

61−A lot of people here in Barbados don’t even understand what crypto is. A lot of the work being done around this project is to raise awareness about the potentials of this new technology. I want this to be a general springboard for the Caribbean to gain greater technological literacy. That literacy is an important step for lower-income people to drastically change their situation.

62−

63−**What are you looking forward to talking about on the New World Energy panel at Assembly 2021?**

64−

65−I want to talk about how to migrate communities onto Urbit. How to use Urbit as a new platform for niche cultures found around the current internet. Also the great strength and power provided by Urbit’s digital identities.

66−

67−NFTs can be very powerful—there are a lot of possible applications of a unique digital asset. It’s already dissolved geographical boundaries which will help countries to export their intellectual products freely. Countries need first to gain knowledge around these technologies and their economies will follow.

68−

69−**Thanks for chatting!**

70−

71−See you at Assembly 2021!

content/blog/hoon-4-lispers.mddeleted−764

@@ -1,764 +0,0 @@

1−+++

2−title = "A Perspective on Lisp and Hoon"

3−date = "2023-06-15"

4−description = "Lisp is an éminence grise of programming. How does Hoon compare?"

5−

6−[extra]

7−author = "N E Davis"

8−ship = "~lagrev-nocfep"

9−image = "https://engineering.stanford.edu/sites/default/files/styles/card_1900x950/public/images/news/john_mccarthy.jpeg?h=3751da6c&itok=6tPSih53"

10−+++

11−

12−

13−

14−> In the beginning, von Neumann created the machine. And the machine was with rigorous form and code, and no compiler yet moved upon the face of the tubes. And the evening and the morning were the first day.

15−>

16−> And John Backus said, Let there be FORTRAN, and there was Fortran. And Fortran ruled over the assembly.

17−>

18−> And John McCarthy saw the lambda calculus, that it was very good. And McCarthy made the LISP and divided the programmers who were for the array from the programmers who were for the list.

19−>

20−> And the Fortran and the Lisp were the second day. And God set them in the firmament to give light upon the earth.

21−

22−Two great temperaments of programming language design span these poles: Fortran as the engineer of assembler-first hard-nosed array coding and Lisp as the math professor running down to the machine room waving papers. While they have ceded some to the practicalities of the other over time, each is a trope of a particular computing paradigm. In this article, we will examine the Lisp pole in light of Urbit's development language, Hoon.

23−

24−Hoon is a statically typed functional programming language that is designed to be safe, efficient, and expressive. Hoon has a unique syntax relying heavily on symbolic expressions (using “runes”) rather than traditional keywords and operators. Hoon's underlying execution language, Nock, has been described as a “pico-Lisp“, making reference to its nature as a cell-based combinator calculus. Both languages (Nock and Hoon) follow very much in the philosophical steps of Lisp but seek to improve the genre.

25−

26−Lisp is known for its powerful macro system, which allows developers to write code that generates more code at compile time, and for its powerful `eval` function; while Hoon provides a flexible metaprogramming system that allows developers to manipulate code at compile time and hot-swap code at runtime.

27−

28−This article will contrast classical Lisp syntax and assumptions with Hoon's design. As Lisp is a family of languages rather than a single implementation, I will strive to make generally applicable statements or qualify the discussion—I welcome nuance in your responses about the different major Lisp dialects.

29−

30−Hoon's characteristic structure has arisen from these overarching design principles:

31−

32−1. Hoon must compile to Nock, and benefits from reflecting Nock's calculational worldview.

33−2. Hoon must be capable of live upgrades; that is, conscious brain surgery on itself.

34−3. Hoon should grow organically based on actual developer usage patterns.

35−

36−Our investigation of Lisp and Hoon will compare their syntax, their metaprogramming affordances, and their underlying philosophies.

37−

38−

39−## Syntax

40−

41−Hoon has many commonalities with Lisp and its most common calling convention is sugared to appear like Lisp. The conventions of Nock differ—e.g. using `[]` brackets instead of `()` parentheses—and Nock does not have non-numeric tokens or names. Hoon serves as a more human-friendly syntax which mediates common expressions and structures much as C overlays assembly language. For practical purposes, we never need to write Nock code by hand, and so while Nock informs Hoon's design choices, we don't need to understand any Nock to talk about Hoon.

42−

43−Both Lisp and Hoon are homoiconic, meaning that code and data are directly represented the same way: Lisp code is represented as Lisp data structures, and Hoon code is represented as Hoon data structures. Homoiconicity means that code can be manipulated and transformed as data at runtime. While the most compelling investigation in this article focuses on metaprogramming, we need to start with a comparative syntax and grammar so we understand how code and data are represented.

44−

45−Before all of that, let us compare a simple program implemented in both Lisp and Hoon. Both programming languages are species of functional languages for which expressions result in values, but they handle side effects differently: in Hoon side effects are strictly impossible (although a runtime workaround permits I/O and necessary effects), while in Lisp side effects are permitted (although opinions on their use vary). We will therefore not use a trivial “Hello World” example. Instead we will calculate the arithmetic mean of a set of numbers of known size.

46−

47−```scheme

48−(define (mean a)

49− (if (null? a)

50− 0

51− (/ (apply + a) (length a))))

52−```

53−

54−```hoon

55−:: Common (sugared) form

56−++ mean

57− |= a=(list @ud)

58− ?~ a 0

59− (div (roll a add) (lent a))

60−

61−:: Rune (unsugared) form

62−++ mean

63− |= a=(list @ud)

64− ?~ a 0

65− %+ div

66− %- roll [a add]

67− %- lent a

68−```

69−

70−The Scheme code has the advantage that it reads almost English-like as one works through the logic, but implicitly relies on familiarity with the `if`/`then`/`else` structure and function application using `()` (on which more soon).

71−

72−The Hoon code uses the `%` function application runes (differentiated by number of arguments) to apply the function calls. With syntactic sugar, this looks similar to the Lisp call, with `++roll` instead of `apply` and `++lent` instead of `length`.

73−

74−Throughout I will use code examples for Lisp taken from [Rosetta Code](https://rosettacode.org/wiki/Category:Scheme). I will select or compose Hoon examples to be structurally similar to the Lisp code in order to facilitate comparison. I will also avoid sugar syntax that would obscure the structure of the Hoon code; in some cases this will make it slightly less readable than its equivalent in practice.

75−

76−### Syntax in Lisp

77−

78−#### Types

79−

80−Lisp types are dynamic, checked at runtime rather than on compilation. Since everything is an object, some assumptions can be made about manipulation and behavior. Most Lisp dialects share these types:

81−

82−- Numbers, including integers and floating-point numbers.

83−- Characters.

84−- Strings, as a sequence of characters.

85−- Lists, as a sequence of objects (including lists).

86−- Symbols, names used to refer to a function, variable, or other object.

87−- Arrays, a fixed-size multidimensional indexed object collection.

88−

89−Lisp code, being dynamically typed, is inclined to try a value and see if it works in a given context. However, some restrictions can be made, such as an argument type declaration on a function:

90−

91−```lisp

92−(defun add-two-integers (x y)

93− (declare (type integer x y))

94− (+ x y))

95−```

96−

97−Lisp types are to some extent (justly) influenced by the underlying platform architecture: Lisp is generally compiled directly to machine code (like a C program), with the notable exception of [Clojure](https://clojure.org/reference/lisps) which runs on the Java Virtual Machine.

98−

99−#### Operators, Functions, Macros, and Thunks

100−

101−Lisp syntax is characterized by its use of nested lists, called S-expressions (symbolic expressions), which consist of parentheses enclosing atoms or other S-expressions. The basic structure of an S-expression is an operator (or function) followed by its arguments, all enclosed in parentheses. For example, the following S-expression performs a simple arithmetic operation:

102−

103−```lisp

104−(+ 1 2 3)

105−```

106−

107−Lisp uses prefix notation, where the operator comes before the operands, and parentheses are used to group expressions. The S-expression is evaluated from left to right (in most Lisps save Scheme), with the operator being applied to its arguments.

108−

109−Operators in Lisp operate on values of different basic types. Lisp dialects vary in their particular base types, but typically include numbers, strings, booleans, and so forth. The core data type is the list, of course (LISP is for LISt Processing). Since Lisp biases towards list processing, many operators are comfortable receiving an arbitrary number of values as inputs, as in the code sample above.

110−

111−In Lisp, [`cons`](https://en.wikipedia.org/wiki/Cons) describes the procedure to construct a pair of objects. This seemingly modest capability is fundamental to how Lisp builds lists—and since everything is a list, `cons` has consequences. One fundamental convention is the `cons` cell, which consists of two other Lisp objects and is how lists are actually constructed.

112−

113−

114−

115−Lisp operations are built either as functions or as macros. Functions produce results directly from their inputs. Macros by contrast are basically function-building functions, and produce expressions that can be evaluated with inputs to get a result.

116−

117−A Lisp function is created using `defun`:

118−

119−```lisp

120−> (defun square (x) (* x x))

121−SQUARE

122−

123−> (square 2)

124−4

125−```

126−

127−(Lisp dialects tend to not be case-sensitive.)

128−

129−Lisp functions are first-class objects and can be manipulated and passed like values of basic types as well.

130−

131−Before we can look at macros, we need to consider Lisp's notion of evaluation and in particular deferred evaluation. For Lisp, an expression can be marked as a literal value rather than evaluated to produce a result. The quote `'` symbol is used to mark expressions for prevented evaluation:

132−

133−```lisp

134−'(1 2 3) ; evaluates to the list (1 2 3)

135−'foo ; evaluates to the symbol FOO

136−(1 5) ; evaluates to the list (1 5)

137−'(1 (+ 2 3)) ; evaluates to the list (1 (+ 2 3))

138−```

139−

140−Backtic or backquote `` ` `` allows you to switch an expression in and out of evaluation mode, along with `,` to mark evaluated components for splicing back into the unevaluated expression.

141−

142−```lisp

143−`(1 2 3) ; evaluates to the list (1 2 3)

144−`foo ; evaluates to the symbol FOO

145−`(1 ,(+ 2 3)) ; evaluates to the list (1 5)

146−```

147−

148−A Lisp macro is essentially a compile-time function.

149−

150−```lisp

151−> (defmacro square (x)

152− "Returns the square of the input value."

153− `(* ,x ,x))

154−

155−> (square 2)

156−4

157−```

158−

159−(The `` ` `` notation constructs the expression with values spliced in by `,`.)

160−

161−A deferred evaluation, called a thunk, is a closure that inherits its lexical environment but is deferred for later computation. Thunks enable lazy code evaluation and separate the computation’s definition from its execution.

162−

163−```lisp

164−(defun create-thunk (function &rest arguments)

165− (lambda () (apply function arguments)))

166−

167−(defun invoke-thunk (thunk)

168− (funcall thunk))

169−

170−;; Creating a thunk that calculates the factorial of a number

171−(defvar factorial-thunk (create-thunk #'(lambda () (factorial 5))))

172−

173−;; Invoking the thunk to get the result

174−(print (invoke-thunk factorial-thunk)) ; Output: 120

175−```

176−

177−In this code example, `create-thunk` accepts a function and returns a thunk created using a lambda function to encapsulate the computation. `invoke-thunk` is used to invoke the thunk to get the actual result. The actual application creates a deferred factorial implementation and then finally invokes it. Without the last line, the actual calculation would never be executed.

178−

179−As Paul Graham wrote, “The unusual thing about Lisp-- in fact, the defining quality of Lisp-- is that it can be written in itself.” A Lisp program is an S-expression, and in principle we can run the equation the other way: certain S-expressions are valid Lisp programs. Although uncommon in practice due to code safety issues, the `eval` function is illustrative of Lisps’ ability to evaluate a Lisp expression that is represented as a data structure. It takes a single argument, which is a Lisp expression, and returns the value of that expression. Lisp programs can in principle generate new code—or modify existing code—and evaluate it on the fly, since code is data.

180−

181−```lisp

182−(defvar x 10)

183−(defvar y 20)

184−(defvar z '(+ x y))

185−

186−(eval z)

187−```

188−

189−Besides explicitly named functions and macros, Lisp frequently employs lambda expressions to produce functions on demand at the point of use.

190−

191−```lisp

192−> ((lambda (x y) (+ x y)) 5 10)

193−15

194−```

195−

196−Naturally, we have not covered all of Lisp, but the above should motivate how Hoon differs from Lisp. Furthermore, Lisp is really a family of languages, so there is a fair amount of variation in specifics.

197−

198−- [Paul Graham, _On Lisp_](http://www.paulgraham.com/onlisptext.html)

199−

200−### Syntax in Hoon

201−

202−#### Types

203−

204−Hoon compiles to Nock and runs on a Nock virtual machine interpreter. Nock knows only about nouns, that is to say either simple unsigned integers or pairs of other nouns.

205−

206−> To be exact, a noun is an S-expression, except that classic S-expressions have multiple atom types ("S" is for "symbol"). Since Nock is designed to be used with a higher-level type system (such as Hoon's), it does not need low-level types. An atom is just an unsigned integer of any size.

207−

208−

209−One of the biggest differences between Hoon and Lisp lies in their respective type systems: Hoon is statically typed while Lisp is dynamically typed. Furthermore, since Hoon compiles to Nock, ultimately every value, expression, and program in Hoon results in a noun (an atom or unsigned integer, or a cell or pair of nouns). (The compiler may make this process slightly opaque, but it is deterministic.) Types, if values are known, must match or nest properly at compile time.

210−

211−Hoon implements types as a metadata layer over bare Nock numbers and atoms. (The implementation details do not concern us but can be seen using the `!,` zapcom rune, which produces the abstract syntax tree of an expression.) Hoon atom types include various numeric types (signed and unsigned, hexadecimal, binary, etc.); address space identifiers (such as ~zod); IP addresses; UTF-8 text; and floating-point values, [among many others](https://developers.urbit.org/blog/literals). As these are interpretations laid over the bare integer, it is trivial to convert among them, a convenience like C affords.

212−

213−```hoon

214−:: raw unsigned decimal integer

215−> 123

216−123

217−

218−:: hexadecimal integer

219−> `@ux`123

220−0x7b

221−

222−:: UTF-8 text

223−> `@t`123

224−'{'

225−

226−:: relative datetime (a small fraction of a second)

227−> `@dr`123

228−~s0..0000.0000.0000.007b

229−

230−:: address mnemonic (ship name)

231−> `@p`123

232−~rux

233−

234−:: IPv4 address

235−> `@if`123

236−.0.0.0.123

237−

238−:: IPv6 address

239−> `@is`123

240−.0.0.0.0.0.0.0.7b

241−```

242−

243−A cell is a pair of two nouns, and of course many compound types exist, including lists (a null-terminated series of cells). A file path in Urbit is, for instance, a list of resource names (a `path`). A manipulable text string is a list of single bytes for characters (a `tape`). Maps (associative arrays), sets, and other containers round out the basic data structure types, but more complex types such as HTTP headers and app metadata are available. Even app actions have an associated type so that the set of actions is enumerable and validated. Here, for instance, are some cryptographic types from the standard library:

244−

245−```hoon

246−+$ jacobian [x=@ y=@ z=@] :: jacobian point

247−+$ point [x=@ y=@] :: curve point

248−+$ domain

249− $: p=@ :: prime modulo

250− a=@ :: y^2=x^3+ax+b

251− b=@ ::

252− g=point :: base point

253− n=@ :: prime order of g

254− ==

255−```

256−

257−Hoon expressions are ultimately binary trees of cells and atoms—Hoon is homoiconic and so code is directly represented as a data structure which can be interpreted as a value as well. This facilitates Hoon's ability to upgrade itself in place, as we will see.

258−

259−Hoon commonly implements types structurally via _molds_, or functions which coerce to type or crash. A mold is a way of asserting known type information over a value, typically at compile time, in a way that allows for data transformation and data validation. This leads to some interesting cases such as the difference between a null-terminated tuple and a true list, which some functions require.

260−

261−```hoon

262−> ~[1 2 3]

263−[1 2 3 ~]

264−

265−> `(list @)`~[1 2 3]

266−~[1 2 3]

267−

268−> (snag 2 ~[1 2 3])

269−mull-grow

270−-need.[i=@ud t=%~]

271−-have.%~

272−nest-fail

273−dojo: hoon expression failed

274−

275−> (snag 2 `(list @)`~[1 2 3])

276−3

277−```

278−

279−Hoon implements a unique character literal syntax for every single atom type, allowing any value to be unambiguously interpreted by the parser per the developer's intent. You can see this somewhat in evidence in this comparison chart:

280−

281−| Type | Lisp Type | Hoon Type |

282−| --- | --- | --- |

283−| (Unsigned) integer | `1` | `1` |

284−| Signed integer | `-1`, `1` | `-1`, `--1` |

285−| Symbol | `x` | `%x` |

286−| Real/FP | `1.5` | `.1.5` |

287−| Character | `#\c` | `'c'` |

288−| Text | `"Hello"` | `'Hello'` (as atom); `"Hello"` (as list) |

289−| Rational | `2/3` | (no Hoon equivalent) |

290−| Address | (no Lisp equivalent) | `~sampel-palnet` |

291−

292−Much of Hoon's practical power derives from how it represents and manipulates nouns as data and as code.

293−

294−> The type of type is just a normal datatype in Hoon, and a lot of the system manipulates types. In particular, the `!>` rune, when applied to a piece of data, uses compile-time type reflection to produce something called a "vase": a pair of type and data, similar to a `Data.Dynamic` in Haskell, or a limited form of a dependent pair. Since the Arvo kernel does a lot of dynamic compilation, it uses vases to implement something akin to a dynamically typed language using Hoon. This allows for type-safe dynamic program loading, program execution, and data migration. (Ted Blackman ~rovnys-ricfer, [“Why Hoon”](https://urbit.org/blog/why-hoon))

295−

296−A `vase` in Hoon is a cell of type and value. Typically `vase`s are produced with the `!>` zapgar rune. We use `vase`s to carry type information where otherwise it may be lost, such as in transmission over the wire to another Urbit instance.

297−

298−```hoon

299−> !>('hello')

300−[#t/@t q=478.560.413.032]

301−

302−> !>([5 10])

303−[#t/[@ud @ud] q=[5 10]]

304−

305−> !>(`(list @)`~[1 2 3])

306−[#t/it(@) q=[1 2 3 0]]

307−

308−> !>(`(list @)`~)

309−[#t/it(@) q=0]

310−```

311−

312−A `vase` can be used at runtime to resolve a value from a dynamic context into an executable Hoon expression, and this is commonly done with web-based input, for instance, where insufficient information will be available at compile time to resolve the type correctly.

313−

314−#### Expressions

315−

316−Nock explicitly consists of binary trees, since any Nock structure or program consists entirely of atoms (bare values) and cells (pairs of nouns).

317−

318−

319−

320−Expressions are oriented around runes, which act as operators to join or manipulate expressions. To construct a cell of two values like `1` and `2`, one uses the `:-` cencol rune. (Hoon cells implement what we call an “implicit `cons`”, meaning that two nouns composed together are simply unified in a shared binary tree.)

321−

322−```

323− :-

324− / \

325−1 2

326−```

327−

328−To invoke a function named `add`, one can provide a `%-` cenhep rune with the function name and the arguments.

329−

330−```

331− %-

332− / \

333−add :-

334− / \

335− 1 2

336−```

337−

338−We write this Hoon expression one of two ways, either separated by whitespace or using parentheses:

339−

340−```

341−> %- add :- 1 2

342−3

343−

344−> %-(add :-(1 2))

345−3

346−```

347−

348−Hoon employs “sugar syntax” for many common code patterns to make them easier to write and (sometimes) to read. Since Hoon had the advantage of knowing about Lisp's syntax beforehand, the standard invocation syntax in Hoon (formally a `%` rune) uses the irregular `()`-based syntax like Lisp. In this case, we could instead write the Lisp-like expression:

349−

350−```hoon

351−> (add 1 2)

352−3

353−```

354−

355−which results in basically the same expression once the parser is done.

356−

357−(Although Hoon ultimately compiles to Nock, it is more natural in some ways to approach the syntax of a program as an array of $n$-ary trees, where each “slot” in an expression can have zero, one, or many children. Zero children refers to a tree address containing a terminal value like a symbol or an integer.)

358−

359−Rune syntax is Hoon's answer to the Lisp proliferation of parentheses—by restricting expressions to a definite number of children, Hoon avoids needing to explicitly terminate most expressions. In some ways, runes are an ASCII-based equivalent of APL's symbolic character operators.

360−

361−```apl

362−life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}

363−```

364−

365−Rather than permit polymorphic language statements, Hoon requires each rune to be extremely tightly defined. While many statements may be functionally equivalent to an `if` or a `cond` statement, for instance, Hoon allows the developer to select a particular expressive rune if desired.

366−

367−- `?:` typical `if`/`then`/`else` branch

368−- `?=` branch on type

369−- `?@` branch if atom

370−- `?^` branch if cell

371−- `?+` switch on type with default

372−- `?-` switch on type without default

373−- `?~` branch if null

374−

375−The next examples explore an interesting difference between Lisp `cond` and Hoon `?+` wutlus swtich statements: Hoon switches over _types_ not _values_, and `term` symbols as constants are instances of self-matching types.)

376−

377−```scheme

378−(define (weather f)

379− (cond ((> f 80) 'too-hot)

380− ((> f 60) 'nice)

381− ((< f 35) 'too-cold)

382− (else 'typical-midwest)))

383−```

384−

385−```hoon

386−|%

387−++ weather

388− |= f=@ud

389− ?: (gth f 80) %too-hot

390− ?: (gth f 60) %nice

391− ?: (lth f 35) %too-cold

392− %typical-midwest

393−++ symbol-to-message

394− |= msg=term

395− ?+ msg 'Typical Midwest'

396− %too-hot

397− 'Too hot outside'

398− %nice

399− 'Nice outside'

400− %too-cold

401− 'Too cold here'

402− ==

403−--

404−```

405−

406−Lisp expects a program to be a running series of expressions, naturally composed together as a list. Hoon, in contrast, expects everything to be an evaluable expression (no implicit `progn`, for instance): thus, series of expressions must be composed together, e.g. using `=>` tisgar to concatenate two expressions.

407−

408−This code example defines an expression and immediately evaluates another expression against it:

409−

410−```hoon

411−=> [a=1 b=2 c=3]

412−::

413−b

414−```

415−

416−Hoon code is compiled to Nock, but it is not a simple macro over Nock—multiple Hoon expressions could result in an identical Nock expression, and the same Hoon expression evaluated against different subjects could result in different Nock expressions. Hoon code is parsed to an abstract syntax tree first, which includes type metadata, then compiled into the appropriate Nock statement. Here we use the `!,` zapcom rune to turn a Hoon expression into its AST, then `!=` zaptis to compile a Hoon expression to Nock.

417−

418−```hoon

419−> !,(*hoon `@ux`+(1))

420−[ %ktls

421− p=[%sand p=%ux q=0]

422− q=[%ktls p=[%sand p=%$ q=0] q=[%dtls p=[%sand p=%ud q=1]]]

423−]

424−

425−> !=(`@ux`+(1))

426−[4 1 1]

427−```

428−

429−Hoon has much more syntactic sugar than Lisp. Not only is the Lisp-like `()` execution convention sugar for `%:` cencol to invoke a function, there are in fact many ways to evaluate code expressions. Consider, for instance:

430−

431−| Rune | Usage |

432−|---|---|

433−| `%-` | Evaluate a function against a single noun. |

434−| `%+` | Evaluate a function against a cell (pair of nouns). |

435−| `%^` | Evaluate a function against a trio of nouns. |

436−| `%:` | Evaluate a function with many arguments ($n$-ary, unspecified number of nouns). |

437−| `%~` | Evaluate a higher-order function to produce a function. |

438−

439−This gives a Hoon developer an extreme amount of flexibility in constructing and laying out code expressions. In fact, many Hoon programs read as a hybrid of imperative code and functional code, since the ability to lay out intent line-by-line feels rather like C.

440−

441−Hoon conventions and sugar syntax have evolved organically as core developers discovered or invented useful design patterns and appropriately concise syntax.

442−

443−#### Functions (Gates) and Cores

444−

445−The most important structural concept in Hoon is the core, which organizes code into a binary tree of `[code data]`, or as we call it in Hoon, `[battery payload]`. Since cores have a standard structure, this means that many kinds of direct manipulations (metaprogramming) are possible, such as altering the input arguments to a function or manipulating the code variance model. Cores play a role in Hoon similar to that of objects in many other languages.

446−

447−Any function (“gate” in Hoon parlance) is a core, whose `battery` is the compiled Nock code and whose `payload` includes its view of the system, including the standard library, and its input arguments. The `|=` bartis rune is most commonly used to make a gate:

448−

449−```hoon

450−:: Select the larger of two values ("max").

451−|= [a=@ b=@]

452−?: (gth a b)

453− a

454−b

455−```

456−

457−The gate definition rune `|=` bartis has two children, a specification of the expected input and the expression. When invoked, the values of the specification (or "sample") are provided to the expression, which then evaluates to return a noun.

458−

459−One quirk of Hoon is that since everything is an address (or “axis”) in a binary tree, you can access anything in your scope (“subject”) through its axis. Most commonly you attach a face to a value (like a gate), but you don't have to. At any point, to refer to the previous statement, you can invoke the head of the tree, `-`; to wit,

460−

461−```hoon

462−> =/ a 5

463− -

464−a=5

465−```

466−

467−The name `a` is also attached to the value and can be used to identify the value. (To the Hoon parser there is no real difference; this is a programmer quality-of-life affordance.)

468−

469−```hoon

470−> =/ a 5

471− a

472−5

473−```

474−

475−Thus faces (names) are attached to gates (functions) within a particular scope or context, such as a `|%` core. Each core defines a collection of values and gates (collectively termed “arms”) which occupy a shared scope. For example, the following library demonstrates a few floating-point operations in Hoon. Each function can see the parent subject (including `hoon.hoon` and some other cores) as well as its neighboring arms (such as `++pow-n` called by `++exp`).

476−

477−```hoon

478−|%

479−:: Factorial, x!

480−++ factorial

481− |= x=@rs

482− =/ t=@rs .1

483− |- ^- @rs

484− ?: =(x .1) t

485− $(x (sub:rs x .1), t (mul:rs t x))

486−:: Absolute value, |x|

487−++ absolute

488− |= x=@rs

489− ?: (gth:rs x .0) x

490− (sub:rs .0 x)

491−:: Exponential function, exp(x)

492−++ exp

493− |= x=@rs

494− =/ rtol .1e-5

495− =/ p .1

496− =/ po .-1

497− =/ i .1

498− |- ^- @rs

499− ?: (lth:rs (absolute (sub:rs po p)) rtol) p

500− $(i (add:rs i .1), p (add:rs p (div:rs (pow-n x i) (factorial i))), po p)

501−:: Power, restricted to integeres only, x**n

502−++ pow-n

503− |= [x=@rs n=@rs]

504− ?: =(n .0) .1

505− =/ p x

506− |- ^- @rs

507− ?: (lth:rs n .2) p

508− $(n (sub:rs n .1), p (mul:rs p x))

509−--

510−```

511−

512−Ultimately, however, the faces resolve back to an axis and the code is composed by the compiler into a Hoon syntax tree and thence to Nock for the runtime interpreter.

513−

514−The nature of cores derives from Nock and is key to understanding how Hoon works. All nontrivial structures in Hoon are cores. For instance, even a gate is a regular `|%` core, with `|=` expanding to `|%`. The following code snippets are identical to the Hoon compiler after parsing.

515−

516−```hoon

517−:: increment a number by two

518−|= p=@ud

519−+(+(p))

520−```

521−

522−```hoon

523−:: increment a number by two

524−=+ ^~(*p=@ud)

525−|%

526−++ $

527− +(+(p))

528−--

529−```

530−

531−Although Lisp's `'` quoting has no direct equivalent in Hoon, there are a couple of structures that can provide a similar effect. The most important of these is the `|.` trap, which defines an expression to be evaluated at a later time—Hoon’s equivalent of Lisp’s thunk. For instance, traps are used when testing code that _should_ fail, as the expression can be defined and deferred until the test framework is ready to process it.

532−

533−```hoon

534−> =foo |.((add 1 41))

535−

536−> -:foo

537−[8 [9 36 0 2.047] 9 2 10 [6 [7 [0 3] 1 1] 7 [0 3] 1 41] 0 2]

538−

539−> (foo)

540−42

541−```

542−

543−(To understand the second entry, recall that code is the in head of the core—here, we see the Nock code for the operation defined in the `|.` trap.)

544−

545−[Wet gates](https://developers.urbit.org/guides/core/hoon-school/R-metals) present the most macro-like feature in Hoon. A regular function, or “dry gate” (as above), receives an argument (the sample); the type system tries to cast the sample to the type specified by the gate, and fails if not possible. Wet gates instead defer type evaluation and instead attempt to use the sample (or arguments) directly in the expression. This produces a parametric polymorphism. (This comes close to dynamic typing, but type is still checked at compile time.) Wet gates are commonly used as gate-building gates, such as mold-producing gates like `++list`.

546−

547−Consider a function like `++turn` which transforms each element of a list.

548−

549−```hoon

550−> `tape`(turn ~[77 97 114 115] @t)

551−"Mars"

552−```

553−

554−To use `++turn`, we need a list and a transformation function. The type of the list we produce depends on the type of the list and the type of the transformation function. The actual gate `++turn` should work to transform each element of the list for on any function and any list, so long as the function's argument is the list item.

555−

556−Wet gates are therefore used when incoming type information is not well known and needs to be preserved. This includes parsing, building, and structuring arbitrary nouns. (Beyond Lisp analogues, you can think of C++'s templates and operator overloading, and Haskell's typeclasses.)

557−

558−This example compares the Lisp deferred factorial thunk with an equivalent Hoon trap. (Hoon includes `++factorial` since it is not part of the standard library.)

559−

560−```scheme

561−(defun create-thunk (function &rest arguments)

562− (lambda () (apply function arguments)))

563−

564−(defun invoke-thunk (thunk)

565− (funcall thunk))

566−

567−;; Creating a thunk that calculates the factorial of a number

568−(defvar factorial-thunk (create-thunk #'(lambda () (factorial 5))))

569−

570−;; Invoking the thunk to get the result

571−(print (invoke-thunk factorial-thunk)) ; Output: 120

572−```

573−

574−```hoon

575−=>

576−|%

577−++ factorial

578− |= n=@ud

579− |-

580− ?: =(n 1) 1

581− %+ mul n

582− %= $

583− n (dec n)

584− ==

585−++ factorial-5

586− |. (factorial 5)

587−--

588−(factorial-5)

589−```

590−

591−### Subject-Oriented Programming

592−

593−Urbit programming employs a paradigm deriving from the nature of Nock (_a fortiori_ Hoon), subject-oriented programming. Every expression of Hoon is evaluated relative to its subject, a piece of data that represents the environment, or the context, of an expression.

594−

595−The subject refers to the parent binary tree of an expression, more or less, and serves as state, lexical scope, environment, and function argument. (We can be precise about the definition in all cases—e.g. the subject of a gate in a core is the core itself—but don't need to for this essay.) Lisp supports variable scope and global variables, such that any part of the program can access a particular binding. Hoon's subject-oriented programming model naturally provides its equivalent of scope: all code is evaluated against a subject and name bindings proceed by depth-first match (with permitted skips to prevent unwanted masking).

596−

597−> Subject orientation in Nock and Hoon stems partly from minimalism (there's just one subject, which serves as state, lexical scope, environment, and function argument), partly from a desire to simplify compilation (the type of the subject is a full specification of the compile-time environment for a source file), and partly in order to give the language a more imperative feel.

598−>

599−> Everything about a scope, including name bindings, aliases, and docstrings, is stored in the subject's type. This allows Hoon's compilation discipline to be similarly minimal: the compiler is a function from subject type and Hoon source to product type and compiled Nock. Running this Nock against a value of the subject type produces a vase of the result. It's hard to imagine a more streamlined formalism for compilation. (Ted Blackman ~rovnys-ricfer, [“Why Hoon”](https://urbit.org/blog/why-hoon))

600−

601−The subject is typically the core in which an expression is evaluated, but can be more narrowly defined; consider, for instance, our example from above:

602−

603−```hoon

604−=> [a=1 b=2 c=3]

605−::

606−b

607−```

608−

609−A slightly different program fails:

610−

611−```hoon

612−=> [a=1 b=2 c=3]

613−::

614−(add a b)

615−```

616−

617−because the `++add` gate is not defined in the subject against which the expression is evaluated, the first statement.

618−

619−### Comparative Examples

620−

621−#### Find in List

622−

623−```scheme

624−(define index-of

625− (lambda (needle haystack)

626− (let ((tail (member needle haystack)))

627− (if tail

628− (- (length haystack) (length tail))

629− (throw 'needle-missing)))))

630−```

631−

632−```hoon

633−:: Produces the index of the first occurrence of nedl in hstk

634−:: as the unit of an atom.

635−++ find

636− |= [nedl=(list) hstk=(list)]

637− =| i=@ud

638− |- ^- (unit @ud)

639− =+ [n=nedl h=hstk]

640− |-

641− ?: |(?=(~ n) ?=(~ h))

642− ~

643− ?: =(i.n i.h)

644− ?~ t.n

645− `i

646− $(n t.n, h t.h)

647− ^$(i +(i), hstk +.hstk)

648−```

649−

650−#### Filter a List

651−

652−```scheme

653−(define filter

654− (lambda (fn lst)

655− (let iter ((lst lst) (result '()))

656− (if (null? lst)

657− (reverse result)

658− (let ((item (car lst))

659− (rest (cdr lst)))

660− (if (fn item)

661− (iter rest (cons item result))

662− (iter rest result)))))))

663−```

664−

665−```hoon

666−:: Cycle through the members of a list a, passing them to a gate b

667−:: and produce a list of all of the members that produce TRUE.

668−++ skim

669− |* [a=(list) b=$-(* ?)]

670− |-

671− ^+ a

672− ?~ a ~

673− ?:((b i.a) [i.a $(a t.a)] $(a t.a))

674−```

675−

676−- Several examples in the above section were drawn from [UW's CSE 341 course notes](https://courses.cs.washington.edu/courses/cse341/03wi/scheme/basics.html) and from [Rosetta Code](https://rosettacode.org/).

677−

678−

679−## Metaprogramming

680−

681−A Lisp program is really a list, or a list of lists (nested as much as necessary). While this can be interpreted as an $n$-ary tree, tree structure is not the preferred structural metaphor. A Hoon program is a noun, or equivalently a binary tree. Every component of it is directly addressable and thus in principle reflective. Both languages are homoiconic, with code and data representations being the same. What are the consequences of homoiconicity?

682−

683−### Metaprogramming in Lisp

684−

685−Metaprogramming is the practice of writing code that manipulates other code at either compile-time or runtime. In Lisp, metaprogramming is a core feature of the language, and it allows developers to create programs that are incredibly powerful and flexible. Lisp's metaprogramming capabilities are primarily built on two features: macros and syntax manipulation.

686−

687−Macros in Lisp are a way to define new language constructs that are more expressive and more powerful than those provided by the language itself. When a Lisp program is compiled or interpreted, macros are expanded into regular Lisp code, allowing the macro to generate new code based on its input arguments. Since Lisp code is represented as data, it can be manipulated using the same functions and operators used to manipulate other data structures.

688−

689−For instance, Lisp macros could allow you flexibility in expressing a common operation. Imagine you're working on a project that requires a lot of complex math calculations. Rather than writing out each calculation manually, you could define a macro that takes an expression in infix notation (e.g. `2 + 3 * 4`), and transforms it into a Lisp expression that can be evaluated directly. Thus you could compose math expressions in a more human-natural way without having to worry about details of Lisp syntax.

690−

691−Lisp can also manipulate its own syntax. This is sometimes done through the use of reader macros, which operate at the level of the Lisp reader, which is responsible for converting textual input into Lisp expressions. Reader macros can be used to extend the syntax of Lisp, allowing developers to define new conventions or domain-specific languages for specific types of data or operations. Beyond reader macros, Lisp can permit the developer to change the parser (and as long as the result is a Lisp expression, the interpreter or compiler will be fine with this). Top-level functions can be replaced or modified (“advised”). Symbol macros can change source code.

692−

693−Lisp's `'` quote and the `eval` statement allow single expressions to be inhibited or evaluated at will, which is incredibly useful when dealing with symbols that may not be defined yet or in the composition of macros.

694−

695−In addition to macros and syntax manipulation, Lisp dialects typically provide a number of other features that make metaprogramming easier, such as the ability to inspect and modify the runtime environment, and the ability to create or redefine functions and classes at runtime.

696−

697−### Metaprogramming in Hoon

698−

699−While Hoon explicitly avoids macros and domain-specific language specializations, there are many aspects of Hoon which allow or exploit code reflection and manipulation.

700−

701−In practice, Hoon is intended as a systems programming language for the Urbit Nock VM. Hoon's metaprogramming has as a consequence mainly focused on aspects of core manipulation (such as code building and wet gates) and on live code upgrades (what I'll call hot-swapping code). Hoon eschews macros and in particular has a philosophical stance against domain-specific languages (DSLs). (There are some exceptions, notably Sail, Hoon's XML/HTML syntax; and JSON reparsing.)

702−

703−Hoon has the ability to parse arbitrary text strings (typically files) into executable ASTs and Nock. Symbols can be directly converted to and from regular text strings.

704−

705−As the programming language for a “hundred-year computer”, Hoon needs the ability to hot-swap code at runtime. Elements of cores can be removed or replaced. (Really, Hoon code is immutable: the system is actually making a copy with a specified change.) Every app and even the OS itself can define a state transition function and upgrade along a deterministic pathway.

706−

707−Hoon is in principle extremely reflective as it simply compiles to a Nock noun. Since everything is a stationary tree, it is straightforward to manipulate any object. There are no magic binary blobs or opaque data types: if you have a file handle or an Ethereum block or a websocket connection object, it is a tree and you can work with it directly. (Cf. [“Why Hoon”](https://urbit.org/blog/why-hoon).) Obtaining—or changing—details about gate sample or core behavior becomes a routine part of the Hoon developer’s toolkit. Given such regularity, it would be desirable to expose further capabilities of code reflection and introspection explicitly for the interpreter and IDE.

708−

709−One of the most common design patterns in Hoon is that of the higher-order function, or what Hoon calls “gate-building gates”. These are gates (functions) that produce gates (functions). For instance, as Hoon is statically typed a list must have an associated element type at compile time. `++list` is a gate builder that produces a type gate, which can then be applied to the actual values:

710−

711−```hoon

712−list :: gate builder

713−(list cord) :: gate for list of cords (strings)

714−`(list cord)`~['a' 'b' 'c'] :: list type applied to value

715−```

716−

717−Hoon represents a “hyperlambda” with respect to anonymous function creation: one very often defines gates at their point of use, particularly when operating on each member of a list or set. Similar to Lisp's frequent use of `lambda`, the one-time-use function is available at the point of call as an anonymous gate. (More generally, every gate is anonymous and we have to attach a name to it as a search path, but that's a bit out of scope here.)

718−

719−```scheme

720−((lambda (x1 x2)

721− (* (- x1 x2) (- x1 x2)))

722− 2 -5)

723−```

724−

725−```hoon

726−%- |= [x1=@ x2=@]

727− (pro:si (dif:si x1 x2) (dif:si x1 x2))

728−[--2 -5]

729−```

730−

731−Like Lisp, Hoon yields a lot of power to the user–developer. One could implement a fairly regular Lisp on top of Hoon with very few changes—and perhaps even implement a pure-Hoon discipline yielding a statically-typed Lisp à la TypeScript from JavaScript.

732−

733−- [~tacryt-socryp, “Hick, a more traditional Lisp than Hoon”](https://gist.github.com/tacryt-socryp/b08dc66b7bcc760e914c4db5c9fd7ba7)

734−

735−

736−## Philosophy

737−

738−Hoon's focus on atoms, static typing, and symbolic expressions make it a highly expressive and efficient language for building applications on the Urbit platform, while Lisp's flexible syntax and macro system make it a popular choice for a wide range of programming tasks.

739−

740−Lisp has evolved greatly since John McCarthy's founding. Like Unix, a complicated family tree has finally settled down into a few strong contenders: Scheme, Common Lisp, Clojure, Racket.

741−

742−Lisp has tended to be fractious: as many have noted, and [Mark Tarver eloquently expressed](http://web.archive.org/web/20080803193859/http://www.lambdassociates.org/blog/bipolar.htm), the Lisp platform appeals to idiosyncratic visions for completist platforms. There's a looseness in the community's coherence as a result.

743−

744−For a few reasons, the Urbit community has managed to avoid such splintering (the [Urbit Classic joke](http://urbit-classic.org/) aside). With a single sponsoring organization, first Tlon Corporation and since 2022 the Urbit Foundation, to steward the ecosystem and a philosophical commitment to protocol-as-platform, Urbit should avoid partition into competing bazaars.

745−

746−Urbit's governing philosophy as a technical program is laid out in the [Precepts](https://urbit.org/blog/precepts). A sampling:

747−

748−> A.13. If you don't completely understand your code and the semantics of all the code it depends on, your code is wrong.

749−

750−> A.16. Explicit state is better than implicit state.

751−

752−> A.20. One hundred lines of simplicity is better than twenty lines of complexity.

753−

754−> D.3. Not being qualified to solve a problem is no reason not to solve it.

755−

756−There is significant overlap here with the ideals of the Lisp developer community present. Scheme like Hoon aims at minimalism and ample use of lambda expressions. [Clojure](https://www.clojure.org/about/rationale) aims at strengthening Lisp by building it on a modern platform (the JVM); it would agree with Urbit's disdain for nondeterminism: “pervasive, unmoderated mutation simply has to go”. Racket was designed for production systems and to some extent with a hope to unify parts of the developer stack.

757−

758−In many ways, Hoon is more Lisp-y than Lisp: that is, it represents a point more polar towards the telos of Lisp than any extant Lisp. By shedding the skin of lists and focusing on binary trees, Urbit achieves a deeper conceptual unification within itself. Hoon doesn't properly supersede Lisp—it requires running on a particular VM architecture, for instance—but Hoon's focus on typing, the nature of Hoon's binary-tree homoiconicity, and its employment of pure functional concepts make it a strong new tool for those to whom Lisp already appeals.

759−

760−Hoon goes farther than Lisp, however. Hoon is an accessible and practical, if unconventional, tool for simplifying the developer stack, ultimately to a single language. Ultimately, Urbit is a technical project to encode human digital freedom into the very protocol we use—with Hoon its nose-to-tail _lingua franca_. Hoon carries the torch that Lisp kindled into a new user-oriented future.

761−

762−To close, I quote Urbit Foundation CTO Ted Blackman on why Urbit follows its particular design discipline:

763−

764−> The promise of Urbit lies in its reimagination of the digital world using components that are as constrained and limited as possible. By adhering firmly to principle and doubling down on minimalism at every turn, we get an OS that provides far stronger guarantees than Unix with a thousand times less code. Given the complexity of modern software, this is what's required to put personal computing back into the hands of people. (Ted Blackman ~rovnys-ricfer, [“Why Hoon”](https://urbit.org/blog/why-hoon))

content/blog/hosting-the-future.md+10−7

@@ -1,25 +1,28 @@

1+++

1+++

2title = "Hosting the Future"

2title = "Hosting the Future"

3−date = "2020-09-30"

3+date = 2020-10-01

4description = "The way we see it, hosting is the most important thing, next to Landscape, that Tlon can do to help Urbit continue toward widespread adoption."

4description = "The way we see it, hosting is the most important thing, next to Landscape, that Tlon can do to help Urbit continue toward widespread adoption."

5−

6[extra]

5[extra]

7author = "Nick Simmons"

6author = "Nick Simmons"

8ship = "~simfur-ritwed"

7ship = "~simfur-ritwed"

9−image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/200930-hosting-by-tlon.jpg"

8+image ="https://storage.googleapis.com/media.urbit.org/site/posts/essays/200930-hosting-by-tlon.jpg"

10+++

9+++

11

10

11+<br>

12+

12

13

13

14

15+<br>

16+

14Urbit users tend to be interesting, creative, and capable people; we’re genuinely impressed with the communities that have formed on the network, and with the quality of discourse there. But for the number of communities to continue to grow, getting on the network has to become dramatically easier. It’s not realistic to expect most people to configure their own Urbit OS node in the command line.

17Urbit users tend to be interesting, creative, and capable people; we’re genuinely impressed with the communities that have formed on the network, and with the quality of discourse there. But for the number of communities to continue to grow, getting on the network has to become dramatically easier. It’s not realistic to expect most people to configure their own Urbit OS node in the command line.

15

18

16−At the moment, the biggest lever we have here is to help ordinary users get online, so they can participate in communities inside Urbit, and eventually form their own. This means hosting their Urbit nodes and showing them around the network when they first arrive. There are already several businesses overlapping with this space to varying degrees: [planet.market](https://planet.market/), [urth.systems](https://urth.systems/), and [geturbitid](https://www.geturbitid.com/). Now, Tlon is releasing its own hosting offering. For the uninitiated, “Hosting” just means that we run your urbit ship for you, making it easier for you to get onto the network. We’ve been testing our hosting service with friends and family for the past few months, and now we’re ready to bring it to the rest of the world.

19+At the moment, the biggest lever we have here is to help ordinary users get online, so they can participate in communities inside Urbit, and eventually form their own. This means hosting their Urbit nodes and showing them around the network when they first arrive. There are already several businesses overlapping with this space to varying degrees: [planet.market](https://planet.market/), [urth.systems](https://urth.systems/), and [geturbitid](https://www.geturbitid.com/). Now, Tlon is releasing its own hosting offering. For the uninitiated, “Hosting” just means that we run your urbit ship for you, making it easier for you to get onto the network. We’ve been testing our hosting service with friends and family for the past few months, and now we’re ready to bring it to the rest of the world.

17

20

18−To learn more about Tlon hosting and sign up for the waiting list, check out the new [tlon.io](https://tlon.io/) website. We are officially launching the service on October 9th, with a virtual event and demo; we’ll also show off some of the new features and improvements to Landscape, the Urbit web client.

21+To learn more about Tlon hosting and sign up for the waiting list, check out the new [tlon.io](https://tlon.io/) website. We are officially launching the service on October 9th, with a virtual event and demo; we’ll also show off some of the new features and improvements to Landscape, the Urbit web client.

19

22

20To be very clear, hosting isn’t for everyone; if you’re deeply security-conscious or privacy-oriented, you’ll still want to self-host so that nobody else needs to touch your keys. That said, hosting isn’t a walled garden; you’ll get a planet when you sign up for hosting, which you will own 100% and forever. You’ll also always have the option to roll up your data and take it with you if you choose to stop using our service. Your Urbit data is just a single file, and we’ll happily hand it back to you if you ever decide to leave. Nothing will ever stop you from self-hosting.

23To be very clear, hosting isn’t for everyone; if you’re deeply security-conscious or privacy-oriented, you’ll still want to self-host so that nobody else needs to touch your keys. That said, hosting isn’t a walled garden; you’ll get a planet when you sign up for hosting, which you will own 100% and forever. You’ll also always have the option to roll up your data and take it with you if you choose to stop using our service. Your Urbit data is just a single file, and we’ll happily hand it back to you if you ever decide to leave. Nothing will ever stop you from self-hosting.

21

24

22−We’ve talked for a while about how the ultimate destiny of Urbit is to escape the control of Tlon. For Urbit to really succeed, it has to be managed by its own community. We started Tlon in order to solidify the foundation of this young platform. Now that Urbit is starting to grow up, Tlon and Urbit will naturally drift apart a bit.

25+We’ve talked for a while about how the ultimate destiny of Urbit is to escape the control of Tlon. For Urbit to really succeed, it has to be managed by its own community. We started Tlon in order to solidify the foundation of this young platform. Now that Urbit is starting to grow up, Tlon and Urbit will naturally drift apart a bit.

23

26

24Urbit is meant to be universal, ubiquitous infrastructure. Tlon exists to make that infrastructure useful and usable. We expect Urbit, as a platform, to be cared for by the community in collaboration with the emerging [Urbit Foundation](https://urbit.org/blog/first-steps-towards-urbit-org/). We intend Tlon to become increasingly focussed on providing a great user experience for anyone interested in this new network, so the network can continue to grow and thrive.

27Urbit is meant to be universal, ubiquitous infrastructure. Tlon exists to make that infrastructure useful and usable. We expect Urbit, as a platform, to be cared for by the community in collaboration with the emerging [Urbit Foundation](https://urbit.org/blog/first-steps-towards-urbit-org/). We intend Tlon to become increasingly focussed on providing a great user experience for anyone interested in this new network, so the network can continue to grow and thrive.

25

28

@@ -27,4 +30,4 @@ The way we see it, hosting is the most important thing, next to Landscape, that

27

30

28If you’re curious to keep up with what Tlon is doing here, head to [tlon.io](https://tlon.io) and join the waiting list. We’ll be posting updates to that list as well as to the Tlon Transmissions notebook in the Urbit Community group. Going forward we’ll do our best to keep urbit.org neutral and focussed on the technology itself.

31If you’re curious to keep up with what Tlon is doing here, head to [tlon.io](https://tlon.io) and join the waiting list. We’ll be posting updates to that list as well as to the Tlon Transmissions notebook in the Urbit Community group. Going forward we’ll do our best to keep urbit.org neutral and focussed on the technology itself.

29

32

30−See you all on the network!

33+See you all on the network!

content/blog/immunology-for-the-internet-age.mddeleted−118

@@ -1,118 +0,0 @@

1−+++

2−title = "Immunology for the Internet Age"

3−date = "2022-04-07"

4−description = "A consideration of the history of the Internet motivates introspection on the nature and causes of social dysfunction in a globally shared space. Centralized solutions fail to yield satisfactory outcomes for human freedom and thriving. Decentralized autonomous organizations and their technological apparatus together represent the evolution of an immune system against a corporatized Internet."

5−[extra]

6−author = ""

7−ship = "~lagrev-nocfep"

8−image = "https://live.staticflickr.com/4322/35891780782_4179f476f9_k.jpg"

9−+++

10−

11−_A version of the following was presented by ~lagrev-nocfep at the [MTAConf 2022 conference on “The Decentralization of Power”](https://www.mtaconf.org/)._

12−

13−**✿**

14−

15−IN THE BEGINNING, _God created the prokaryotes. And the prokaryotes were without nucleus and organelle; and structural simplicity was upon the face of the deep. And chemotaxis moved it upon the face of the waters._

16−

17−A single-celled organism possesses many advantages, notably simplicity of form. Being largely indistinguishable, they have no differentiation or specialization. Prokaryotes often form large colonies, such as the cyanobacteria. Some prokaryotes discovered early on that it paid better to consume resources that had already been processed into usable form by another cell, rather than to process those resources oneself. Thus predator and prey were born, and they have always exemplified divergent competitive evolutionary strategies. The resulting arms race meant that predators were continually adapting to better extract resources from prey, while prey were evolving to evade, resist, fight, or poison predators. Selection pressures applied at individual, species, and clade levels, lead to speciation across deep time.

18−

19−More complex forms seemed better able to evade predators, and thus simple symbiotic alliances between differentiated prokaryotes evolved into the eukaryotes (yielding specialized features such as the nucleus and mitochondria) and multicellular life forms. Simpler forms also abounded, including the liminal virus. Viruses are forms of near-life so simple that they simply exploit cells to reproduce. They are entirely predatory or at best symbiotic with other life. Evasion of pathogenic disease, or disequilibrated colonization by simpler forms of life, has been a---if not the---primary driver towards increasing complexity in multicellular life.[^1]

20−

21−**✿**

22−

23−The Internet began in the late 1960s, born of scientific alliance between the Cold War Department of Defense and the academic research community.[^2] This community had a signal advantage over many subsequent communities: it was dominated by strong norms of discourse which shaped the professionalism of the community. This is not to discount the significance of courtly intrigue, of course, which deftly exploited tensions between competing systems.[^3].

24−

25−Throughout this era, though, the Internet generally functioned as a real-name high-trust environment---if not exactly of peers, at least of colleagues.

26−

27−The Internet evolved as a coordination mechanism---literally a nervous system incarnate in copper and silicon---particularly through the Usenet days of the 1980s. In our days of heightened online tension and mediated preference cascades, it is rather quaint to go back and look at what qualified as email flame wars at the time (e.g. Torvalds/Tanenbaum). One hallmark of the Usenet era, however, is a gradually eroding social trust: spam was invented[^6] and Internet-based scams started to spin up.

28−

29−Pseudonymity gained in popularity as a countermeasure to both of these as well as restrictions on discourse. The revelation that persistent digital records could cost someone's job further fueled a cyberpunk-like obsession with identity control and hacking.[^7]

30−

31−Computer viruses could propagate for the first time: it never made much sense to build a computer virus until systems were connected. Although John von Neumann and others early explored the possibility of mathematical or code structures which could self-replicate, it was not until the Creeper virus in the 1970s that self-replicating code was observed in the wild. And like a bacillus in an immune system-free host, code-based computer viruses began to spread from the 1980s onwards.

32−

33−The crisis arrived in the form of the World Wide Web. Founded initially on a belief in the democratization of information, the Web rapidly became dominated by a handful of large corporations (henceforth "megacorps"). User experience became the predominant driver of adoption, leading to rapid preference cascades as new platforms became available. Any child of the 90s or earlier can recite the lived litany: Ebay, MySpace, Friendster. Initially these served as proofs-of-concept, then became the only significant player (until the next killer app came along). Search engines drove discovery, then focused attention asymmetrically. The "walled garden" approach of AOL, then Apple and Facebook, led to concentrations of users which tipped the balance from single webpage hosts presenting their own idiosyncratic views to corporate-approved genericity and ultimately censorship.[^8]

34−

35−**✿**

36−

37−When was the first time you did something in the physical world because of something you read or encountered online? For generations born after the advent of the Web, they may not recall such a time when meatspace existence wasn't driven by life online. As Internet data sources have overwhelmed traditional media, publishing, and distribution services, the resulting tsunami of information and informatization has swept into every corner of lived human experience in technological societies. The psychological (memetic) virus problem is much greater than actual code viruses. The ongoing universal exposure to alien and internally incoherent value systems has undergirded the well-documented crisis of credibility (collapse of meaning) that all Western institutions are experiencing today. The World Wide Web and its technological predecessors acted as a cultural petri dish of clean agar, which grew every spore and germ which fell upon it. We live in the midst of a memetic epidemic because of the World Wide Web, and the dominant strain is corporate, approved by a marketing department and run through a search-engine optimization algorithm.

38−

39−The turn towards a low-trust then zero-trust environment was inevitable if anything like an analogy with prokaryotic evolution holds true. The megacorp platforms are in a way worse than a purely zero-trust environment, because they don't advertise that the world is zero-trust. Thereby they lure the unwary into transgressing arbitrary global norms and courting the wrath of social media mobs and the concomitant loss of access to their data held in "trust." To mix a metaphor, megacorps are apex predators---at best, sheepdogs with a strong strain of wolfishness; at worst, tar pits manned by various bad-faith actors. The pre-Web cypherpunks were right: "Privacy is the power to selectively reveal oneself to the world."[^9]

40−

41−If anything, they were too narrow; not only their valued "open society" (polyvalent crypto-anarchy) but _any_ non-megacorp society at all requires true privacy.

42−

43−What cyberspace (and human culture writ broadly) needed was an immune system---and in good Darwinian form, such an immune system has been evolving before our eyes. An immune system formally consists of layers with increasing specificity: first surface barriers, then the innate immune system, and finally the adaptive immune system. The objective of the immune system is to protect the organism: in this case, human sociality and agency.

44−

45−First, what is human sociality? Human culture has been the means of participating in the Great Discussion which ranges from the earliest days of oral culture to the birth of literacy and libraries down to our day. High culture and low culture have both articulated and preserved valuable insights and forms of human flourishing. However, throughout the 20^th^ century and particularly by the means of the consumer revolution, our lives have been thoroughly colonized by capital and commercial instruments. So-called "economies of scale" have disrupted smallholders, artisans, and shopkeepers to the extent that these have been virtually eradicated from the modern landscape in favor of the plastic and polluting "dark Satanic mills." Although small-scale "provident living" has supported gardening, canning, and home production, none of this has survived across a large enough cultural segment to matter macroscopically, and it has unfortunately been tarred with the "prepper" brush that delegitimizes economic downsizing as antisocial because anticapitalist. The siren call of cheap consumer goods has ushered in a generational collapse in self-sufficiency and resulted in the complete colonization of entertainment, food consumption, and self-care by massive corporate brands. Not only have physical goods entered a post-consumer phase, but only certain classes of ideas, attitudes, political stances, regional accents, and sensibilities enjoy the sanction of megacorp sociality. There is essentially no native culture left, only that forged in the enterprise brand management office.[^10]

46−

47−In an immune system, _surface barriers_ are designed to make it hard for exogenous agents to enter a cell or organism; in our analogy, the primary surface barrier was the match of physical separation to psychological separation. Surface barriers were rendered finally obsolete by the launch of the World Wide Web and its subsequent infiltration of every aspect of human culture. To the extent they exist today, it is a matter of ignorance, self-discipline, or happy accident.

48−

49−The _innate immune system_ responds non-specifically to pathogens. Any immune system must have a way of deciding what is _me_ and what is _not-me_. Framed as an identity problem in a zero-trust environment, users have evolved several ways to uniquely identify agents without reference to legacy systems. Chief among these means is the blockchain, introduced by Bitcoin for control and transaction of digital assets and since much exploited beyond its design intent. Ethereum-based ERC tokens represent tweaks of this identity concept, as do many other blockchain platforms.

50−

51−Identity is still fluid and polysemous, but in certain key instances it is indelibly demonstrable.[^11]

52−

53−The individual actor has the capability to express itself with many public faces or none; one of these typically enjoys government sanction and liability, but it is no more _real_ than the others, only more legible to regulation and taxation.[^12]

54−

55−Another aspect of the innate immune system is the public visibility of code. Open source has developed an ethic of transparency on epistemological grounds (i.e. you have a right to know what code you are running) and practical grounds. (Linus's law: "given enough eyeballs, all bugs are shallow."[^13])

56−

57−The _adaptive immune system_ responds to specific pathogenic incursions. Particular conditions arise, whether through social, regulatory, military, or other requirements, which must be met with specialized forms that are thereafter in evolutionary competition with the external factor. For instance, one megacorp solution to what it perceives as a threat, i.e. unsanctioned memes, is to attempt to mandate the ultimate traceability of any image's provenance.[^14]

58−

59−The Internet immune system thus evolves to further obfuscate legibility and enhance individual control and self-determination by shifting to less-traceable technologies such as the InterPlanetary File System (IPFS). The point is not whether or not a salient technology such as deepfakes, 3D-printed firearms, deviant scientific or political thought, or even the DRM-free sharing of copyrighted material can be contained.

60−

61−The experience with export-grade cryptography has already shown that regulatory attempts ultimately fail.[^17]

62−

63−The philosophical question is what kind of world will evolve (a _fait accompli_ driven by factors beyond any individual or office) and the practical question is how any particular group of actors can preserve their own agency, autonomy, and ambit of action.

64−

65−The first decentralized autonomous organization, "The DAO" (Đ) itself[^18], was created in 2016 as a way of distributing ownership and stake in a joint venture capital fund. Đ was a new form of organization in that it was essentially a mathematical entity, a set of smart contracts on the blockchain to which anyone had access. Đ lived up at least to "decentralized" and "autonomous." No money was held centrally, with token-based authentication yielding the right to vote on projects. Having set the criteria for membership and investment, Đ then operated in truly democratic fashion until an exploit of imperfectly written smart contract code led to theft, crisis, and the reorganization of the Ethereum blockchain itself.

66−

67−While the heirs of Đ serve a role in the current Internet immune system, the original was formed in response to exogenous regulatory concerns, notably ongoing governmental insistence on restricting investment to the already-wealthy. The U.S. Securities and Exchange Commission and other agencies have in place arbitrary investor requirements which would make little sense even if pegged to something like inflation or index rather than the rapidly-devaluing petrodollar. Nominally put in place to protect the naïve from getting scammed, these restrictions have had the pernicious effect of pulling up the ladder behind the _actuel riche_.

68−

69−DAOs have rapidly evolved as a way of distributing ownership and stake in a purely democratic way. (As an aside, the word "democracy" has been much abused, but here I use it in a sense much like the Greek original: the holders of an immutable and indelible token cast their secured votes to govern their society.) DAOs represent a resurgence of the sovereign city-state in new guise. Will this be enough to evade "imperial" aggregates which dominate today's Web?

70−

71−Decentralized autonomous organizations, zero-knowledge cryptographic proofs, cryptocurrencies, proof-of-identity systems, and their as-yet-unborn kin represent the evolution of an immune system on top of the Darwinian churn of the legacy Internet. The stakes are necessarily high: possession is _de facto_ ownership, the other end of the stick from "not your keys, not your coins" (the old cryptocurrency chestnut). The focus is currently on ownership of money, non-fungible tokens, and similar assets, but broadly speaking such systems allow the authenticated ownership of all data and assets one holds, from chat messages to market shares to physical real estate. There may be good reasons to retain the legacy system for some classes of physical or legal artifacts, but at minimum these will be in competition with purely autonomous constructs. (As an aside, I am of the philosophical opinion that legal recognition should not be sought generally for new forms of organization, as any legibility to legacy systems opens new attack surfaces in an immunological sense.) "Code is law."[^19]

72−

73−A decentralized autonomous organization seems to be at least the first two. Having set the criteria for membership, the organization can act as the (distributed, possibly unknown in the zero-knowledge proof sense) stakeholders direct.

74−

75−This form is still somewhat "yeasty" in that like cyanobacteria it acts as an undifferentiated mass. We should expect further innovations in DAO-like entities.[^21] The most salient epithet of a DAO is "decentralized"; one can imagine hierarchical, concentric, or role-specialized DAOs as well as other taxonomically related forms, just as one can imagine progressively less organized instances in a chaos-happy Internet.

76−

77−Like the first mutant with a new gene, Đ itself failed. Many lessons can be drawn from that failure, including the criticality of getting smart contract code absolutely correct ("code is law"), and how to administer a blockchain in the presence of massive fraud. And indeed, what has happened to the blockchain world of decentralized finance? Millisecond differentials in responsiveness lead to huge swings in profitability of transactions. Frontrunner bots watch algorithmically for transactions they can complete faster than the original source, thereby making money on asymmetric knowledge.[^22] Zero-day exploits of code abound, heralding a need for more thorough vetting and more expressive and secure smart contract languages.

78−

79−Blockchains (and thus DAOs via Ethereum) operate as proof-of-work, proof-of-stake, etc. This provides node operators with a way of verifying consensus reality and thereby cementing a record of digital transactions. Future innovations hold forth the possibility of secure proof-of-identity blockchains (such as the Uqbar Layer 1 smart contract blockchain on Urbit[^23]), wherein each node which can provide concrete cryptographic evidence of its identity gets a vote on the consensus.

80−

81−We must consider modern systems to necessarily interact at the pinnacle intensity of competence and competition: any differential advantage that can be exploited to outcompete an adversary not only can be exploited but _should_ be. Illegibility, redundancy, and apposite complexity are allies in the immune fight to maintain identity and ownership in the modern Internet.[^24] Any system which does not have an operational DAO-like layer is immuno­compromised. All tools for the individual and collective need to be architected around a zero-trust adversarial world. They also need to guard the embers of community and enable new growth.

82−

83−In a nutshell, the early Internet was a cocktail party. By the age of Usenet and into the World Wide Web era, the Internet evolved into a player-versus-player defect--defect equilibrium in which brigading, spamming, and anonymity are rational adaptive behaviors. Indeed, anonymity is barely a protection given the lengths to which governments and megacorps go to prevent truly untraceable usage. This approach is adaptive for agencies which have given up on any other model of reality, fundamentally lacking a vision of humans as other than atomized individual krill for the megacorp apex predators: consumers for the consumers. The legacy megacorp Internet has become a crab bucket, always drawing everything back into itself in a dysfunctional and frankly satanic way.

84−

85−Communities built on decentralized Web3 platforms such as Mastodon, Fediverse, and Urbit[^25] have stepped back from the purely PvP world of the globally-namespaced social media Internet. These today have more of a block party feel, wherein one can wander from house to house or room to room and encounter some of the same faces in the same or new guise. Conversations can drop and resume anew in very different locales with largely the same composition. Marrying the underlying cryptographic identity requirements of DAOs to communication tools and databases yields a strong stable solution to the problem of retaining a foothold of personal identity from which to coordinate one's multifaceted digital life. IPFS, Sovrin Foundation, Tim Berners-Lee's Solid, and Urbit all offer their take on this requirement. Even a Signal chat group running its own server is a kind of token-free DAO.

86−

87−Since the Renaissance, essentially all theology has been humanist in nature, concerning itself with how man should live to flourish in this world and inherit in the next. Even secularized descendants enjoin an ethos of ritual behaviors and practices. The social and cultural "stack" (in software parlance) upon which we build provides for a variety, broad or narrow, of human cultural forms. Lately, the variety of forms has been diminishing both by cutting off older forms from the modern world and by cultivating only certain state-legible apex predators[^26] and their preferred ovine repast.

88−

89−Contra this monoculture, the _telos_ of social computing is to recreate the village green, not the penitentiary. Revisiting a thesis from above: "All tools for the individual and collective need to be architected around _using cryptographic proofs to create stable high-trust havens in an otherwise_ zero-trust adversarial world." The village is a stable, long-term tribe well below Dunbar's limit which shares values and assets in common, from which a member occasionally ventures out into the broader social web but always has a home. Every village will grow its own culture, perhaps even its own _cultus_, enabled by decentralized technologies to protect their assets and precious peculiarities. The World Wide Web has been an extinction-level event for many forms of life, livelihood, and culture. For others, it has offered strange forms of life support and even thriving. With a new immune system evolved and now operational, human endeavor stands on the cusp of a Cambrian explosion, unconstrainable by a rent-seeking boardroom-and-bureaucracy world that never comprehended the light shining in its darkness.

90−

91−_The header image is [Volvox sp. microscopic algae](https://www.flickr.com/photos/picksfromoutthere/35891780782/in/photolist-WFCKYA-XPdGLq-2k9Cew6-ViCgrB-23QUBQR-21rF362-CCSE2n-23AwZ7m-CbKedu-gznqa-2dHUv3k-EE8eoq-gznq9-i5zqqk-WYSwcf-XWVgQk-WabAAG-gLjRj-gDcLp-4VvECm-259cDCS-i5zqRk-25cV246-i5yNvM-gupiMJ-PXLbhr-LUACZ7-ihvxSH-ihvvVg-ihwjbF-ihvxDX-i5yQDd-ihzQwK-fWwpxb-rarKrm-8LWTQf-qVar5j-ihzAPA-JNrgyK-ihzBrC-ca6Ex9-2kCTSrj-ihz67k-qfJsYd-248ePDL-ihztbm-ihzuyS-LQYZQq-2kCTRxL-ihvWPA) by Picturepest on Flickr._

92−

93−[^1]: Kaufman, Jim. (2010) ["Evolution and immunity"](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2913256/). _Immunology 130_, iss. 4, pp. 459--462.

94−[^2]: President Eisenhower's original coinage was likely "the military-industrial-academic complex."

95−[^3]: E.g., Richard Bellman of the RAND Corporation on the origin of "dynamic programming," a mathematical discipline: in dealing with a recalcitrant secretary of defense who hated the word "research," Bellman instead chose the word "dynamic" arbitrarily because "it's impossible to use the word 'dynamic' in a pejorative sense. ...It was something not even a Congressman could object to. So I used it as an umbrella for my activities." (Bellman, Richard. (1984) [_Eye of the Hurricane_](https://books.google.ch/books?id=4FwGCwAAQBAJ&lpg=PA159&dq=#v=onepage&q=).)

96−[^4]: The nuclear triad doctrine, joining the Air Force's Strategic Air Command bombers, the Navy's nuclear submarines, and the Army's ICBMs and other assorted nuclear warheads, was based less on strategic considerations than on appeasing constituent departments of the military. Strategists developed a formal justification decades later in a magnificent demonstration of motivated reasoning. (Woolf, Amy. (2016) "U.S. Strategic Nuclear Forces: Background, Developments, and Issues". [CRS 7-5700](https://digital.library.unt.edu/ark:/67531/metadc847627/m2/1/high_res_d/RL33640_2016Mar10.pdf).)

97−[^5]: The Air Force early commissioned the RAND Corporation on contract with Douglas Aircraft Company as the first "think tank"; RAND soon upended the traditional role of passive reception of studies by making its own recommendations and showing their analytical chops. Other service branches followed suit, such as the U.S. Navy's Center for Naval Analyses and the Battelle Memorial Institute for various federal contracting agencies; compare also the role of the national laboratory system, e.g. Los Alamos, Sandia, Livermore, etc. for the Department of Energy and Department of Defense. (Rich, Michael. (2003) "RAND: How Think Tanks Interact with the Military". [RP-1050](https://www.rand.org/pubs/reprints/RP1050.html).)

98−[^6]: "On January 18, 1994, the first large-scale deliberate USENET spam occurred. A message with the subject "Global Alert for All: Jesus is Coming Soon" was cross-posted to every available newsgroup." ([Wikipedia, "History of email spam"](https://en.wikipedia.org/wiki/History_of_email_spam))

99−[^7]: The first instance which seems to have brough this to general public awareness was the submission of Judge Robert Bork's video rental history as evidence in his Supreme Court hearings before the U.S. Senate. The resulting Video Privacy Protection Act was delightfully naïve. Besides relying on "video rental" narrowly construed, users have effectively no leverage against unilaterally-imposed terms of service and end-user license agreements. (See, e.g., [Electronic Privacy Information Center, "Video Privacy Protection Act"](https://archive.epic.org/privacy/vppa/).)

100−[^8]: E.g. Tumblr and OnlyFans and adult content; Twitter and right-wing content; Youtube and Facebook and unsanctioned medical content, etc. Note that this is regardless of the viability of a given view or the necessity of vigorous debate within a field, but focuses on the palatibility of politics to the megacorp entity providing the platform, even if the content drives platform usage.

101−[^9]: Hughes, Eric. (1993) [_A Cypherpunk's Manifesto_](https://nakamotoinstitute.org/cypherpunk-manifesto/).

102−[^10]: The mass shift to remote work from March 2020 onwards due to the COVID-19 pandemic has accelerated the trend of corporate colonization of private spaces. At first, this was occasionally humorous, as when a child ran into the background of a Zoom call, or underwear or private materials were inadvertently left in view of the remote audience. In the end, it demanded that individuals reconfigure their homes to accommodate mass corporate preferences, thus another invasion of private space by the megacorp panopticon. I note as well an invasive doctrine demanding "truth in communication" under names like ["radical transparency"](https://www.bridgewater.com/principles-and-culture) and ["radical candor"](https://third-bit.com/2018/11/24/afraid-of-change/) put forward by partisans of power over against vulnerable employees, clients, and customers, who may be disproportionately affected by a megacorp demand for one-sided transparency.

103−[^11]: Several have pointed to the failure of Craig S. Wright to demonstrate cryptographically that he is Satoshi Nakamoto, the pseudonymous inventor of Bitcoin. (C.f. Khaosan, Venzen. (2016) ["Craig Wright is Not Satoshi Nakamoto---The Technical Proof"](https://www.ccn.com/technical-proof-craig-wright-not-satoshi-nakamoto/).)

104−[^12]: Davidson, Dale, and Rees-Mogg, William. (1999) _The Sovereign Individual: Mastering the Transition to the Information Age_.

105−[^13]: Raymond, Eric. (1999) [_The Cathedral and the Bazaar_](http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html).

106−[^14]: The [Coalition for Content Provenance and Authenticity](https://c2pa.org/) "addresses the prevalence of misleading information online through the development of technical standards for certifying the source and history (or provenance) of media content."

107−[^15]: Cf. Walker, Shawn, et al. (2019) ["The disinformation landscape and the lockdown of social platforms."](https://www.tandfonline.com/doi/full/10.1080/1369118X.2019.1648536) _Information, Communication & Society 22_, pp. 1531--43. Walker et al. lament that "highly ephemeral mis/disinformation campaigns" are not susceptible of study due to closed platform APIs. "Social media platforms \[attempt\] to rekindle trust by appearing to reinforce individual privacy within a newly secured user community, a set of measures that also locked academic and non-profit researchers out from studying social platforms while preserving corporate and business access to social media users' data." They fail to address the tension between community self-determination and academic exploitation.

108−[^16]: "If in fact you can't crack \[the encryption\] at all, government can't get in, then everybody is walking around with a Swiss bank account in their pocket -- right? So there has to be some concession to the need to be able to get into that information somehow." ([Barack Obama in March 2016 at SXSW](https://www.businessinsider.com/obama-comments-on-encryption-at-sxsw-2016-3))

109−[^17]: Heninger, Nadia. (2016) ["The Legacy of Export-Grade Cryptography in the 21^st^ Century"](https://publish.illinois.edu/science-of-security-lablet/files/2016/08/10062016-Heninger-Slides.pdf).

110−[^18]: Chohan, Usman. (2017) ["The Decentralized Autonomous Organization and Governance Issues"](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3082055). Discussion Paper Series: _Notes on the 21^st^ Century_.

111−[^19]: Lessig, Lawrence. (1999) _Code and Other Laws of Cyberspace_.

112−[^20]: Hobart, Byrne `~lableg-tadrex`. (Nov 17, 2021) ["The Promise and Paradox of Decentralization"](https://urbit.org/blog/2021-11-18-the-promise-and-paradox-of-decentralization). _The Diff_.

113−[^21]: See, e.g., the Governor Alpha smart contract protocols. Solari, R. (2021) ["The case for Governor Alpha".](https://medium.com/tally-blog/the-case-for-governor-alpha-15c1362d49eb)

114−[^22]: Robinson, D. (2020) ["Ethereum is a dark forest"](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest). Paradigm blog.

115−[^23]: [Uqbar Network](https://uqbar.network/); ["Introducing Uqbar Network"](https://uqbarnetwork.substack.com/p/introducing-uqbar-network); \~hocwyn-tipwex/uqbar-event-horizon (Urbit group)

116−[^24]: This is not to deny the benefits of system-legibility, in particular legal protections. As common law develops around DAOs, I hope for similar affordances where they must interact with the legacy legal system.

117−[^25]: Originally this list included Discord, as there has been substantial growth in stable goal-oriented communities thereon. However, more recently the company [adopted a user policy](https://discord.com/blog/addressing-harmful-off-platform-behavior) which subjects use of their product to judgment calls about "off-platform behavior"---a clear violation of a cypherpunk ethos which Discord likely never espoused anyway.

118−[^26]: E.g., Auerbach, David. (Mar 3, 2022) ["The metaverse will steal your identity"](https://unherd.com/2022/03/the-metaverse-will-steal-your-identity/). _UnHerd_. Auerbach correctly recognizes and decries the looming "monetisation of identity" which will allow any platform controller to incentivize prosocial or antisocial behaviors at will.

content/blog/infrastructural.md+17−12

@@ -1,15 +1,16 @@

1+++

1+++

2title = "Infrastructural"

2title = "Infrastructural"

3−date = "2020-04-09"

3+date = 2020-04-10

4description = "A reflection–meditation on OS 1’s initial form development, and the attitude we brought to bear in designing it."

4description = "A reflection–meditation on OS 1’s initial form development, and the attitude we brought to bear in designing it."

5−

6[extra]

5[extra]

7author = "É. Urcades"

6author = "É. Urcades"

8ship = "~fabled-faster"

7ship = "~fabled-faster"

9−image = "https://media.urbit.org/site/posts/essays/infrastructural-2.jpg"

8+image ="https://media.urbit.org/site/posts/essays/infrastructural-2.jpg"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/infrastructural-1.jpg">

13

14

14## Seasons

15## Seasons

15

16

@@ -25,9 +26,9 @@ This post serves as a reflection–meditation on OS 1’s initial form developme

25

26

26## Products

27## Products

27

28

28−Urbit’s interfaces, and the process by which we build them, are resolutely not projections of the world’s current conception of digital design—that of mass digital product design. Products are sold, bought, and discarded as they are in their physical sense. Digital products are slotted into the [vending machines](https://urcad.es/writing/personal-computer-vending-machine/) we call our phones and are mass produced as candy is produced. Candy is _essentially_ free, and contemporary digital products are _absolutely_ free of cost. If you’re reading this, you probably already have a good idea of what free corporate digital products mean for your privacy.

29+Urbit’s interfaces, and the process by which we build them, are resolutely not projections of the world’s current conception of digital design—that of mass digital product design. Products are sold, bought, and discarded as they are in their physical sense. Digital products are slotted into the [vending machines](https://urcad.es/writing/personal-computer-vending-machine/) we call our phones and are mass produced as candy is produced. Candy is *essentially* free, and contemporary digital products are *absolutely* free of cost. If you’re reading this, you probably already have a good idea of what free corporate digital products mean for your privacy.

29

30

30−Urbit is distinctly _not_ free (as in freely offered as a service via a corporate entity), and your urbit is distinctly _not_ a product. As we trace over the interfaces we design with our cursors, we’re not building a product, we’re not selling a product, we’re not painting a product, and we’re certainly not decorating a product.

31+Urbit is distinctly *not* free (as in freely offered as a service via a corporate entity), and your urbit is distinctly *not* a product. As we trace over the interfaces we design with our cursors, we’re not building a product, we’re not selling a product, we’re not painting a product, and we’re certainly not decorating a product.

31

32

32Here at Tlon, we’re assembling thoughtful infrastructure you can spend your life using, learning, and extending. We’re attempting to assemble spaces you can one day pass on to friends, close collaborators, or possibly your grandchildren. We are resolute in our practice and stay our hands to the greatest degree possible as a result of this mindset.

33Here at Tlon, we’re assembling thoughtful infrastructure you can spend your life using, learning, and extending. We’re attempting to assemble spaces you can one day pass on to friends, close collaborators, or possibly your grandchildren. We are resolute in our practice and stay our hands to the greatest degree possible as a result of this mindset.

33

34

@@ -39,25 +40,29 @@ OS 1, while incremental in its initial expression from OS 0, serves to outline o

39

40

40**Beautiful infrastructure is a gravitational force**. Even if you can’t feel it or directly experience it, well-designed infrastructure is a cohering force. One is grounded with respect to the infrastructure they live alongside.

41**Beautiful infrastructure is a gravitational force**. Even if you can’t feel it or directly experience it, well-designed infrastructure is a cohering force. One is grounded with respect to the infrastructure they live alongside.

41

42

42−**Beautiful infrastructure is like a [shell](https://en.wikipedia.org/wiki/Shell)**. Well-considered infrastructural projects provide durable, generalized, reusable, and most importantly, _self-designed_ containers around otherwise formless flows of information.

43+**Beautiful infrastructure is like a [shell](https://en.wikipedia.org/wiki/Shell)**. Well-considered infrastructural projects provide durable, generalized, reusable, and most importantly, *self-designed* containers around otherwise formless flows of information.

43The current state of mass software design has gotten many of the “reusable” elements of design down pat, but these structures are optimized to pump ads and information into your brain, algorithmically-sorted-linear-feed style.

44The current state of mass software design has gotten many of the “reusable” elements of design down pat, but these structures are optimized to pump ads and information into your brain, algorithmically-sorted-linear-feed style.

44In Urbit, I can take the conceptual container of "temporal linearity" and use this to shape communication data as I see fit. I should be able to shape once-linear communication and cast it into a nodal communication model: My DM is now a MUD.

45In Urbit, I can take the conceptual container of "temporal linearity" and use this to shape communication data as I see fit. I should be able to shape once-linear communication and cast it into a nodal communication model: My DM is now a MUD.

45

46

46Truly beautiful infrastructure undergirds the daily exchanges people actually care about—I don’t drink plumbing, I drink the water it carries and protects.

47Truly beautiful infrastructure undergirds the daily exchanges people actually care about—I don’t drink plumbing, I drink the water it carries and protects.

47

48

48−Another way of thinking about “Infrastructure” (here defined loosely as “the _truly_ essential structures that allow society at varying scales to operate”) is to think about it in terms of interpersonal support structure.

49+Another way of thinking about “Infrastructure” (here defined loosely as “the *truly* essential structures that allow society at varying scales to operate”) is to think about it in terms of interpersonal support structure.

49

50

50We deeply hope that Urbit can form a support structure for you and your community.

51We deeply hope that Urbit can form a support structure for you and your community.

51

52

52−These self-evident statements underlie the core problems we sought to address in designing a userspace for OS 1: How do we design an _actually_ personal digital infrastructure? What does infrastructure look like when shared with immediate friends? With a cooperative organization? How can we impress upon Urbit's earliest adopters that once they've obtained an Urbit ID, their computer is at that moment _literally_ entirely theirs?

53+These self-evident statements underlie the core problems we sought to address in designing a userspace for OS 1: How do we design an *actually* personal digital infrastructure? What does infrastructure look like when shared with immediate friends? With a cooperative organization? How can we impress upon Urbit's earliest adopters that once they've obtained an Urbit ID, their computer is at that moment *literally* entirely theirs?

54+

55+<br>

56+

57+<br>

53

58

54−

59+<img class="ba" src="https://media.urbit.org/site/posts/essays/infrastructural-2.jpg">

55

60

56## Expressing Infrastructure

61## Expressing Infrastructure

57

62

58OS 1 was optimized from an interface design standpoint to ensure that a new inhabitant viscerally felt like there was a “space to inhabit”, or a “canvas to be painted”, or a set of simple and fundamental digital structures they could arrange to make their computer their own.

63OS 1 was optimized from an interface design standpoint to ensure that a new inhabitant viscerally felt like there was a “space to inhabit”, or a “canvas to be painted”, or a set of simple and fundamental digital structures they could arrange to make their computer their own.

59

64

60−Counterintuitively, designing around this notion of a "rich blank slate” required OS 1 to be designed in a manner that _almost_ results in it feeling incomplete, or on the verge of appearing deeply unremarkable.

65+Counterintuitively, designing around this notion of a "rich blank slate” required OS 1 to be designed in a manner that *almost* results in it feeling incomplete, or on the verge of appearing deeply unremarkable.

61

66

62A few key design decisions emphasized the above gestalt we sought to express:

67A few key design decisions emphasized the above gestalt we sought to express:

63

68

@@ -70,4 +75,4 @@ Many other small constraints have been set into place to build what we truly bel

70

75

71While visually primitive, OS 1 has managed to manifest a rich systematic expressiveness based on how it seems to be currently inhabited. We've been enjoying witnessing the ways people are beginning to interpret and make use of the faculties provided to create communal computing experiences of their own.

76While visually primitive, OS 1 has managed to manifest a rich systematic expressiveness based on how it seems to be currently inhabited. We've been enjoying witnessing the ways people are beginning to interpret and make use of the faculties provided to create communal computing experiences of their own.

72

77

73−What's most wonderful to observe is the fun people are having in striking out on their own in this collective endeavor. More than anything, we hope Urbit’s inhabitants are having a good time and learning to enjoy computers again.

78+What's most wonderful to observe is the fun people are having in striking out on their own in this collective endeavor. More than anything, we hope Urbit’s inhabitants are having a good time and learning to enjoy computers again.

content/blog/interim-constitution.md+28−29

@@ -1,9 +1,8 @@

1+++

1+++

2title = "Interim Constitution"

2title = "Interim Constitution"

3−date = "2016-05-15"

3+date = 2016-05-16

4description = "The governing rules for the early days of the Urbit network."

4description = "The governing rules for the early days of the Urbit network."

5−aliases = [ "/posts/essays/interim-constitution", "/posts/constitution" ]

5+aliases = ["/posts/essays/interim-constitution", "/posts/constitution"]

6−

7[extra]

6[extra]

8author = "Tlon"

7author = "Tlon"

9ship = ""

8ship = ""

@@ -14,22 +13,22 @@ image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/interi

14

13

15## Declaration of purpose

14## Declaration of purpose

16

15

17−Urbit is a new network created by the Tlon Corporation. Tlon's

16+Urbit is a new network created by the Tlon Corporation. Tlon's

18broad intention is to surrender governance of Urbit to its users,

17broad intention is to surrender governance of Urbit to its users,

19as soon as the community is collectively ready to receive it.

18as soon as the community is collectively ready to receive it.

20

19

21This constitution (which is not a legal contract, just our present

20This constitution (which is not a legal contract, just our present

22intent, which may be updated arbitrarily) describes our governance

21intent, which may be updated arbitrarily) describes our governance

23−process during this interim period. Its design borrows from validated

22+process during this interim period. Its design borrows from validated

24historical structures, mainly Roman and Anglo-American.

23historical structures, mainly Roman and Anglo-American.

25

24

26The last and most important task of the interim government is to

25The last and most important task of the interim government is to

27−write the next version of the constitution. This document may or

26+write the next version of the constitution. This document may or

28may not incorporate any or all of the interim structures.

27may not incorporate any or all of the interim structures.

29

28

30## Beliefs and principles

29## Beliefs and principles

31

30

32−See our document of [beliefs and principles](/blog/beliefs-and-principles).

31+See our document of [beliefs and principles](../beliefs-and-principles).

33

32

34## Governance structures

33## Governance structures

35

34

@@ -37,15 +36,15 @@ The interim republic has four branches: an executive consulate, a

37galactic senate, a stellar congress and a planetary assembly.

36galactic senate, a stellar congress and a planetary assembly.

38

37

39For the interim, full authority is held by the (Roman style)

38For the interim, full authority is held by the (Roman style)

40−consulate. The legislature (senate, congress, assembly) is

39+consulate. The legislature (senate, congress, assembly) is

41−advisory. The senate is never consulted and the congress is

40+advisory. The senate is never consulted and the congress is

42almost never consulted.

41almost never consulted.

43

42

44In the future, the assembly of planets specializes in technical

43In the future, the assembly of planets specializes in technical

45−governance. The congress of stars specializes in internal, but

44+governance. The congress of stars specializes in internal, but

46−nontechnical, governance. The senate of galaxies selects the

45+nontechnical, governance. The senate of galaxies selects the

47consuls and holds them accountable, and specializes in compliance

46consuls and holds them accountable, and specializes in compliance

48−with external powers. All votes, elections and other public

47+with external powers. All votes, elections and other public

49actions are logged in the Urbit global namespace.

48actions are logged in the Urbit global namespace.

50

49

51As in most parliamentary systems, each of these structures sets

50As in most parliamentary systems, each of these structures sets

@@ -53,29 +52,29 @@ and enforces its own internal rules of operation.

53

52

54### Consulate

53### Consulate

55

54

56−A consulate is a two-person executive. The consuls must work out

55+A consulate is a two-person executive. The consuls must work out

57−their own organization and division of labor. Disagreements

56+their own organization and division of labor. Disagreements

58between consuls are resolved by the senate.

57between consuls are resolved by the senate.

59

58

60−A consul must be a senator. The senate, voting per galaxy,

59+A consul must be a senator. The senate, voting per galaxy,

61replaces the consulate whenever either a vacancy exists, or a

60replaces the consulate whenever either a vacancy exists, or a

62−vote of no confidence gains a majority. When electing consuls,

61+vote of no confidence gains a majority. When electing consuls,

63first a plurality selects one consul; then the plurality of those

62first a plurality selects one consul; then the plurality of those

64who voted for anyone but the winner selects the second.

63who voted for anyone but the winner selects the second.

65

64

66### Senate

65### Senate

67

66

68The _senate_ is the set of all galaxy holders, voting per galaxy.

67The _senate_ is the set of all galaxy holders, voting per galaxy.

69−It does not convene except to replace the consuls. Its

68+It does not convene except to replace the consuls. Its

70proceedings are in private.

69proceedings are in private.

71

70

72To avoid growing the network too quickly, galaxies are activated

71To avoid growing the network too quickly, galaxies are activated

73−gradually. Initially, only one galaxy is active, the root `~zod`

72+gradually. Initially, only one galaxy is active, the root `~zod`

74(galaxy 0).

73(galaxy 0).

75

74

76Further activation is at the discretion of the consuls, who

75Further activation is at the discretion of the consuls, who

77control `urbit.org` and will only bind activated galaxies to

76control `urbit.org` and will only bind activated galaxies to

78−`galaxy.urbit.org`. Routing at the galaxy layer is by DNS, so

77+`galaxy.urbit.org`. Routing at the galaxy layer is by DNS, so

79unbound galaxies, and any stars or planets they launch, hear no

78unbound galaxies, and any stars or planets they launch, hear no

80packets.

79packets.

81

80

@@ -86,36 +85,36 @@ Non-activated galaxies can still be rekeyed.

86### Congress

85### Congress

87

86

88The _congress_ is the set of all active independent stars.

87The _congress_ is the set of all active independent stars.

89−voting per star. An _independent star_ is any star _not_ owned

88+voting per star. An _independent star_ is any star _not_ owned

90by anyone who is either a senator, or has some connection to one

89by anyone who is either a senator, or has some connection to one

91that would pose a conflict of interest.

90that would pose a conflict of interest.

92

91

93The congress of stars is designed to exercise project and

92The congress of stars is designed to exercise project and

94−community governance. Its proceedings are in private. The

93+community governance. Its proceedings are in private. The

95consuls convene it at their pleasure, and keep it informed.

94consuls convene it at their pleasure, and keep it informed.

96

95

97### Assembly

96### Assembly

98

97

99The _assembly_ is the set of all active primary planets, voting

98The _assembly_ is the set of all active primary planets, voting

100−per planet. A _primary planet_ is the main planet of a unique

99+per planet. A _primary planet_ is the main planet of a unique

101human (no sockpuppets).

100human (no sockpuppets).

102

101

103−The assembly is responsible for technical governance. Its

102+The assembly is responsible for technical governance. Its

104proceedings are in public.

103proceedings are in public.

105

104

106### The next constitution

105### The next constitution

107

106

108The congress proposes, and the senate approves, the next version

107The congress proposes, and the senate approves, the next version

109−of this constitution. Future constitutions should be defined in

108+of this constitution. Future constitutions should be defined in

110a smart contract platform, such as Ethereum.

109a smart contract platform, such as Ethereum.

111

110

112## Galaxy table

111## Galaxy table

113

112

114−95 galaxies are held by the [Tlon Corporation](https://tlon.io/). 50,

113+95 galaxies are held by the [Tlon Corporation](https://tlon.io/). 50,

115−reserved for urbit.org, the future community foundation. 40, by

114+reserved for urbit.org, the future community foundation. 40, by

116Tlon employees and their family members (24 by Curtis, who

115Tlon employees and their family members (24 by Curtis, who

117−started in 2002; 16 by everyone else, who started in 2014). 34,

116+started in 2002; 16 by everyone else, who started in 2014). 34,

118−by outside investors in Tlon. 37, by 33 other individuals, who

117+by outside investors in Tlon. 37, by 33 other individuals, who

119donated to the project, contributed code or services, won a

118donated to the project, contributed code or services, won a

120contest, or were just at the right place at the right time.

119contest, or were just at the right place at the right time.

121

120

@@ -135,7 +134,7 @@ intended as property of the republic, and will be used only in

135the interests of the republic and Urbit as a whole.

134the interests of the republic and Urbit as a whole.

136

135

137Externally, these galaxies are held by Tlon; internally, they are

136Externally, these galaxies are held by Tlon; internally, they are

138−managed and voted by Tlon. Once the republic acquires a legal

137+managed and voted by Tlon. Once the republic acquires a legal

139identity and an independent human organization, Tlon pledges to

138identity and an independent human organization, Tlon pledges to

140donate the `urbit.org` galaxies, the DNS domain, and the GitHub

139donate the `urbit.org` galaxies, the DNS domain, and the GitHub

141`urbit` account to it.

140`urbit` account to it.

content/blog/interplanetary_commerce.md+9−7

@@ -1,17 +1,19 @@

1+++

1+++

2title = "Interplanetary Commerce"

2title = "Interplanetary Commerce"

3−date = "2021-04-08"

3+date = 2021-04-09

4description = "OS-level commercial primitives."

4description = "OS-level commercial primitives."

5−tags = ["bitcoin"]

6−

7[extra]

5[extra]

8author = "Christian Langalis"

6author = "Christian Langalis"

9ship = "~pindet-timmut"

7ship = "~pindet-timmut"

10image = "https://media.urbit.org/site/posts/essays/ocean.jpeg"

8image = "https://media.urbit.org/site/posts/essays/ocean.jpeg"

11+++

9+++

12

10

11+<br>

12+

13

13

14

14

15+<br>

16+

15## Paying

17## Paying

16

18

17A year ago, we started [integrating](https://urbit.org/blog/urbit-and-bitcoin/) Bitcoin into Urbit to be an OS-level primitive for money. Our initial objective: build a payments wallet, equally sovereign and ergonomic. The first public version, releasing this month, will have a broad set of capabilities including ship-to-ship payments, hardware wallet support, and full node integration. We’ll be unveiling this wallet on [April 27th](https://www.meetup.com/urbit-sf/events/276741426/). Do join us.

19A year ago, we started [integrating](https://urbit.org/blog/urbit-and-bitcoin/) Bitcoin into Urbit to be an OS-level primitive for money. Our initial objective: build a payments wallet, equally sovereign and ergonomic. The first public version, releasing this month, will have a broad set of capabilities including ship-to-ship payments, hardware wallet support, and full node integration. We’ll be unveiling this wallet on [April 27th](https://www.meetup.com/urbit-sf/events/276741426/). Do join us.

@@ -20,18 +22,18 @@ Things only accelerate from here. Our next objective, to integrate Lightning Net

20

22

21## Being Paid

23## Being Paid

22

24

23−> And there is all the difference in the world between paying and being paid. The act of paying is perhaps the most uncomfortable infliction that the two orchard thieves entailed upon us. But being paid,—what will compare with it?

25+>And there is all the difference in the world between paying and being paid. The act of paying is perhaps the most uncomfortable infliction that the two orchard thieves entailed upon us. But being paid,—what will compare with it?

24>

26>

25−> **Herman Melville**

27+><cite>Herman Melville</cite>

26

28

27However, a good wallet is only half the equation for a holistic P2P commercial experience. Interfaces for selling goods and services is the other half. While we don’t part with our Bitcoin [easily](https://nakamotoinstitute.org/mempool/everyones-a-scammer/), two initial markets appear logical and attractive: content and Urbit-native services.

29However, a good wallet is only half the equation for a holistic P2P commercial experience. Interfaces for selling goods and services is the other half. While we don’t part with our Bitcoin [easily](https://nakamotoinstitute.org/mempool/everyones-a-scammer/), two initial markets appear logical and attractive: content and Urbit-native services.

28

30

29First, digital cottage industry, the “creator economy”, is blossoming. Streaming, podcasting, and writing on platforms like Youtube, Patreon, and Substack has been big business [lately](https://otherlife.co/barbarians-past-the-gate/). What fintech did to “unbundle the banks", we will now do to media monopolies and their centralized distribution platforms. With the introduction of Urbit payments, you can syndicate, distribute, and monetize your media on Urbit. By selling access to a private group containing content, digital creatives can begin doing this today.

31First, digital cottage industry, the “creator economy”, is blossoming. Streaming, podcasting, and writing on platforms like Youtube, Patreon, and Substack has been big business [lately](https://otherlife.co/barbarians-past-the-gate/). What fintech did to “unbundle the banks", we will now do to media monopolies and their centralized distribution platforms. With the introduction of Urbit payments, you can syndicate, distribute, and monetize your media on Urbit. By selling access to a private group containing content, digital creatives can begin doing this today.

30

32

31−Second, Urbit-native [service providers](https://urbit.org/blog/providers/) are now operating at scale. Companies offering Urbit hosting, onboarding, Urbit IDs, and software now communicate with their customers directly on the network. A basic set of commercial tools will make their processes more efficient. Storefront interfaces, paywalls, CRM, and reputation tools will replace the ad-hoc assemblages they currently use.

33+Second, Urbit-native [service providers](https://urbit.org/blog/providers/) are now operating at scale. Companies offering Urbit hosting, onboarding, Urbit IDs, and software now communicate with their customers directly on the network. A basic set of commercial tools will make their processes more efficient. Storefront interfaces, paywalls, CRM, and reputation tools will replace the ad-hoc assemblages they currently use.

32

34

33The Urbit Foundation is soliciting contributors to this project through Urbit Grants. If you’re interested in working on any of these components [send us a proposal](https://grants.urbit.org/create).

35The Urbit Foundation is soliciting contributors to this project through Urbit Grants. If you’re interested in working on any of these components [send us a proposal](https://grants.urbit.org/create).

34

36

35## An Ocean

37## An Ocean

36

38

37−After honing our commercial tools on these use-cases, we’ll sail into a blue ocean. On the horizon: beautiful products, deployable at scale, built with the robust primitives of Urbit OS. Extensibility is Urbit’s promise to middle-men: every Web2.0 service they use to scalp us will find its P2P analog on Urbit. We invite developers and entrepreneurs of all stripes to join in the feeding frenzy. Ideas are constantly nucleating in [Urbitcoiners](web+urbitgraph://group/~pindet-timmut/urbitcoiners) and [Urbit Community](web+urbitgraph://group/~bitbet-bolbel/urbit-community/graph/~darrux-landes/business-building-on-urbit).

39+After honing our commercial tools on these use-cases, we’ll sail into a blue ocean. On the horizon: beautiful products, deployable at scale, built with the robust primitives of Urbit OS. Extensibility is Urbit’s promise to middle-men: every Web2.0 service they use to scalp us will find its P2P analog on Urbit. We invite developers and entrepreneurs of all stripes to join in the feeding frenzy. Ideas are constantly nucleating in <a href="web+urbitgraph://group/~pindet-timmut/urbitcoin-cash">Urbitcoiners</a> and <a href="web+urbitgraph://group/~bitbet-bolbel/urbit-community/graph/~darrux-landes/business-building-on-urbit">Urbit Community</a>.

content/blog/introducing-os1.md+12−11

@@ -1,14 +1,15 @@

1+++

1+++

2title = "Introducing OS 1"

2title = "Introducing OS 1"

3−date = "2020-04-29"

3+date = 2020-04-30

4description = "OS 1 is somewhere between ‘productivity software’ and a ‘social network’. We think it’s the beginning of an altogether new breed of social computing."

4description = "OS 1 is somewhere between ‘productivity software’ and a ‘social network’. We think it’s the beginning of an altogether new breed of social computing."

5−

6[extra]

5[extra]

7author = "Galen Wolfe-Pauly"

6author = "Galen Wolfe-Pauly"

8ship = "~ravmel-ropdyl"

7ship = "~ravmel-ropdyl"

9−image = "https://media.urbit.org/site/posts/essays/intro-os1-landscape.png"

8+image ="https://media.urbit.org/site/posts/essays/intro-os1-landscape.png"

10+++

9+++

11

10

11+<br>

12+

12<video class="ba w-100" autoplay loop src="https://media.urbit.org/site/posts/essays/intro-os1.mov"></video>

13<video class="ba w-100" autoplay loop src="https://media.urbit.org/site/posts/essays/intro-os1.mov"></video>

13

14

14## Introducing OS 1

15## Introducing OS 1

@@ -37,7 +38,7 @@ Let’s walk through the features of OS 1 one by one to see what it’s like.

37

38

38### Groups

39### Groups

39

40

40−

41+<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-groups.png">

41

42

42The group is the main building block in OS 1. A group is simply a list of people that share a set of chat, links, and publish channels. A group is sort of like a super powerful group chat.

43The group is the main building block in OS 1. A group is simply a list of people that share a set of chat, links, and publish channels. A group is sort of like a super powerful group chat.

43

44

@@ -49,7 +50,7 @@ Let’s walk through each module and talk about what they can do.

49

50

50### Chat

51### Chat

51

52

52−

53+<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-chat.png">

53

54

54Chat is chat: a sequential list of messages meant for synchronous communication. There are already a million ways to chat — but Urbit chat differs in a few important ways.

55Chat is chat: a sequential list of messages meant for synchronous communication. There are already a million ways to chat — but Urbit chat differs in a few important ways.

55

56

@@ -67,7 +68,7 @@ Anyway, not everything can happen in a chat. Let’s keep moving.

67

68

68### Links

69### Links

69

70

70−

71+<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-links.png">

71

72

72Links is a bit like Hacker News or Reddit. It’s just a collection of links with comments. There’s no upvoting or sorting. We decided that with a small group it’s more about collecting references than deciding what’s most exciting — but permutations of Links could be a great area for contributors to experiment with.

73Links is a bit like Hacker News or Reddit. It’s just a collection of links with comments. There’s no upvoting or sorting. We decided that with a small group it’s more about collecting references than deciding what’s most exciting — but permutations of Links could be a great area for contributors to experiment with.

73

74

@@ -77,7 +78,7 @@ We originally imagined links as evolving into more of a general-purpose ‘colle

77

78

78### Publishing

79### Publishing

79

80

80−

81+<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-publish1.png">

81

82

82Publishing is somewhere between a blog and a note-taking system. A Publish notebook is a list of markdown files with optional comments. A private Publish notebook is like a journal, a group notebook can be like a forum (with comments on) or a collaborative blog.

83Publishing is somewhere between a blog and a note-taking system. A Publish notebook is a list of markdown files with optional comments. A private Publish notebook is like a journal, a group notebook can be like a forum (with comments on) or a collaborative blog.

83

84

@@ -87,7 +88,7 @@ Publish, like all our other modules, is an interface to a generalized protocol f

87

88

88### Modules

89### Modules

89

90

90−

91+<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-home.png">

91

92

92You’ll find a few other things on the home screen: a clock, the weather, and a simple command-line that we call the Dojo. These are system-wide utilities that aren’t group-specific.

93You’ll find a few other things on the home screen: a clock, the weather, and a simple command-line that we call the Dojo. These are system-wide utilities that aren’t group-specific.

93

94

@@ -95,7 +96,7 @@ The clock and weather tiles are simple indications of the state of the outside w

95

96

96### Dojo

97### Dojo

97

98

98−

99+<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-dojo.png">

99

100

100The Dojo gives you a quick way to see that, under the hood, Urbit OS is a powerful general-purpose system. The system hasn’t evolved to the point that our libraries, frameworks, and modules are polished to our standards. Since it’s still early, we can’t claim that it’s easy to develop on top of this platform. But we want it to become much easier.

101The Dojo gives you a quick way to see that, under the hood, Urbit OS is a powerful general-purpose system. The system hasn’t evolved to the point that our libraries, frameworks, and modules are polished to our standards. Since it’s still early, we can’t claim that it’s easy to develop on top of this platform. But we want it to become much easier.

101

102

@@ -109,7 +110,7 @@ OS 1 is a first step down the road back to a system that’s simple, durable, an

109

110

110One really critical thing about OS 1 is the pattern of ‘groups sharing modules’. This pattern makes it perfectly clear how a virtual computer can outcompete a bunch of different services. As the collection of modules in OS 1 → N grows, we make it easier for others to contribute modules, and we increase the flexibility of connecting modules our system quickly outruns the messy, disconnected world we’re currently stuck in.

111One really critical thing about OS 1 is the pattern of ‘groups sharing modules’. This pattern makes it perfectly clear how a virtual computer can outcompete a bunch of different services. As the collection of modules in OS 1 → N grows, we make it easier for others to contribute modules, and we increase the flexibility of connecting modules our system quickly outruns the messy, disconnected world we’re currently stuck in.

111

112

112−OS 1 isn’t mature enough to be _easy_ for outside contributors to add modules — but it is [open source](https://github.com/urbit/urbit), and anyone is welcome to tinker and experiment with modifying it. We run a [grants program](https://grants.urbit.org/) to reward contributors for improving any part of Urbit OS. As the system matures we expect this program to expand and accelerate.

113+OS 1 isn’t mature enough to be *easy* for outside contributors to add modules — but it is [open source](https://github.com/urbit/urbit), and anyone is welcome to tinker and experiment with modifying it. We run a [grants program](https://grants.urbit.org/) to reward contributors for improving any part of Urbit OS. As the system matures we expect this program to expand and accelerate.

113

114

114## Looking ahead

115## Looking ahead

115

116

@@ -131,7 +132,7 @@ As we expand the affordances of the system and add modules over the course of OS

131

132

132### Becoming a homesteader

133### Becoming a homesteader

133

134

134−

135+<img class="ba" src="https://media.urbit.org/site/posts/essays/intro-os1-landscape.png">

135

136

136As a distributed team trying to stay connected, we like using OS 1 from day to day. We’d really like to hand-onboard a small group of like-minded groups of people who want to experiment with living on the fringe of the digital world. Toward this end, we started the community grants program.

137As a distributed team trying to stay connected, we like using OS 1 from day to day. We’d really like to hand-onboard a small group of like-minded groups of people who want to experiment with living on the fringe of the digital world. Toward this end, we started the community grants program.

137

138

content/blog/introduction-to-the-combine-dao.mddeleted−46

@@ -1,46 +0,0 @@

1−+++

2−title = "Introduction to the Combine DAO"

3−date = "2022-07-01"

4−description = "Inside the mind of the Combine"

5−

6−[extra]

7−author = "Anthony Arroyo"

8−ship = "~poldec-tonteg"

9−image = "https://media.urbit.org/blog/cortina-ampezzo.jpg"

10−+++

11−

12−

13−

14−_This is cross-posted from [The Combine DAO Blog](https://blog.the-combine.org). If you'd like to comment, join the public [Urbit group](https://urbit.org/groups/~famreb-todmec/the-combine-public)_

15−

16−Until a couple of weeks ago, The Combine was a subdivision of the Urbit Foundation with a budget earmarked to invest in new projects. As of Urbit NYC that all changed. Now we’re an honest-to-goodness DAO built on Urbit—by Urbit maximalists, for Urbit maximalists. We pool assets to invest in teams building new tools, products and services for the Urbit Universe. Our members are investors, engineers, founders and galactic senators.

17−

18−In this post we'll talk about what we're aiming to do and why we’re in the best position to do it. In a future post, we'll dive into technical and strategic insights drawn from building a DAO on Urbit.

19−

20−## Our Objective

21−

22−Our objective is simple: support organizations in building high-value projects on Urbit. Urbit address space has intrinsic, tradeable value, as is the case with many crypto assets. But, unlike most crypto, that’s just the tip of the Urbit iceberg. Where most crypto assets are built to be owned and exchanged, Urbit is built to be owned and used. It has the potential to replace virtually every centralized part of Web2 you use (but don’t own) today.

23−

24−The Combine DAO invests in teams working on projects that generate and capture value beyond Urbit address space. The price of address space reflects confidence in Urbit's user growth, but every increase in utility to an Urbit user — that is, every time a user can do more with their Urbit — creates additional value. The Combine takes advantage of this upside.

25−

26−For example, one of our portfolio companies, [Uqbar](https://uqbar.network), is building a smart contract platform on Urbit. The Uqbar network will use Urbit ships as nodes in their network, as ZK provers and sequencers, creating an ZK Rollup L2 with the full power of general compute and identity. While their use of the Urbit network as part of their infrastructure will drive demand for planets, stars and galaxies, the value of Uqbar is potentially much greater than that demand.

27−

28−So, members of The Combine DAO should believe at least one of two things:

29−

30−- That products built on Urbit can outpace the value of address space alone, and that The Combine is in the best position to capture that value.

31−- That successful projects built on Urbit will enhance the value of Urbit address space.

32−

33−## Our Pipeline

34−

35−The Combine works hand-in-hand with the Urbit Foundation, meaning we have unparalleled visibility into the development of new projects and teams on Urbit. The Foundation has been working hard to shore up Urbit's developer pipeline, with Hoon School constantly bringing in new developers. The last cohort had 61 finishers, seven of whom had no previous programming experience. The Foundation’s [Grants](https://urbit.org/grants) program is active with over 40 active grants. The Combine and The Foundation continue to work together to identify, nurture and launch projects in need of funding.

36−

37−## Our Membership

38−

39−Startups are risky by nature. Add Urbit’s novel technology and you’ve got more than your share of pitfalls. The Combine mitigates these risks through its membership. Combine members are long-time supporters of the project who have run startups, exchanges and have invested in successful technology on Urbit and beyond. The membership can help lead teams past challenges inherent to all new ventures. We're familiar with the technical and product landscape of Urbit and its adjacent technologies. All of us have experience building technology, on Urbit and outside it, which enables us to provide valuable coaching and due diligence.

40−

41−Another of our portfolio companies, [Holium](https://holium.com), is building unified tooling for DAOs. They started with an application that the Combine DAO uses internally: a voting app called “Ballot.” Holium’s founder has been working on a unified environment for DAOs for some time, but it wasn’t until he came to Assembly 2021 that the pieces finally clicked and he realized that Urbit was the correct stack for Holium’s projects. As he built Ballot on Urbit, The Combine provided product feedback, investor intros, and access to experienced contractors and personnel. Now we’re actively dogfooding Ballot as a core element in The Combine stack.

42−

43−In the coming weeks we’ll dive into the details of why we think Urbit is the natural home for DAOs. For now, we’ll just say that Urbit’s unified stack opens up a unique level of ownership and customizability to DAO builders. The Combine, as a DAO built on Urbit, to support Urbit, is test driving this use case. What we learn here will feed back into diligence, outreach and development priorities for the Foundation.

44−

45−In the next post, we’ll share technical insights for DAOs gleaned from our own experiences building The Combine DAO on Urbit.

46−

content/blog/io-in-hoon.md+137−157

@@ -1,16 +1,20 @@

1+++

1+++

2title = "Input and Output in Hoon"

2title = "Input and Output in Hoon"

3description = "Let's talk about IO in Urbit."

3description = "Let's talk about IO in Urbit."

4−date = "2020-12-15"

4+date = 2020-12-16

5−

6[extra]

5[extra]

7author = "Philip Monk"

6author = "Philip Monk"

8ship = "~wicdev-wisryt"

7ship = "~wicdev-wisryt"

9image = "https://media.urbit.org/site/posts/essays/zion-canyon-1.jpg"

8image = "https://media.urbit.org/site/posts/essays/zion-canyon-1.jpg"

10+++

9+++

11

10

11+<br>

12+

12

13

13

14

15+<br>

16+

17+

14Let's talk about IO in Urbit. I won't say much about how events and effects are processed by the runtime; it suffices to note that the runtime is a normal Unix program which (1) listens for various events, (2) passes them to Arvo (Urbit OS), and (3) processes the effects produced by Arvo. Instead, I’ll focus on how IO works from the perspective of Hoon programs, like Arvo or apps running on Arvo. But first, let's review IO paradigms in other languages.

18Let's talk about IO in Urbit. I won't say much about how events and effects are processed by the runtime; it suffices to note that the runtime is a normal Unix program which (1) listens for various events, (2) passes them to Arvo (Urbit OS), and (3) processes the effects produced by Arvo. Instead, I’ll focus on how IO works from the perspective of Hoon programs, like Arvo or apps running on Arvo. But first, let's review IO paradigms in other languages.

15

19

16All examples are in a made-up language, since it's useful to understand this information even before you're comfortable in Hoon. If you're learning Hoon and want a challenge, try translating them!

20All examples are in a made-up language, since it's useful to understand this information even before you're comfortable in Hoon. If you're learning Hoon and want a challenge, try translating them!

@@ -25,21 +29,17 @@ Imperative languages (such as C and Python) perform IO by calling a function in

25

29

26In this example and others to follow, the task will be to read a filename from the command line, read a URL out of that file, and fetch the contents at that URL.

30In this example and others to follow, the task will be to read a filename from the command line, read a URL out of that file, and fetch the contents at that URL.

27

31

28−```

29−output = fetchUrl(stripWhitespace(readFile(cliInput())))

32+ output = fetchUrl(stripWhitespace(readFile(cliInput())))

30−```

31

33

32For readability, intermediate variables would be a good idea, but nothing stops you from nesting IO this way.

34For readability, intermediate variables would be a good idea, but nothing stops you from nesting IO this way.

33

35

34### Monadic IO

36### Monadic IO

35

37

36−Languages that use explicit monads for IO (such as Haskell) perform IO by running IO behind a bind operation, which I'll notate with `<-`. Thus, while you can't put IO _anywhere_, the general structure is a sequence of IO operations.

38+Languages that use explicit monads for IO (such as Haskell) perform IO by running IO behind a bind operation, which I'll notate with `<-`. Thus, while you can't put IO *anywhere*, the general structure is a sequence of IO operations.

37

39

38−```

39−fileName <- cliInput()

40+ fileName <- cliInput()

40−url <- readFile(fileName)

41+ url <- readFile(fileName)

41−output <- fetchUrl(stripWhitespace(url))

42+ output <- fetchUrl(stripWhitespace(url))

42−```

43

43

44[Tackling the Awkward Squad](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf) is the canonical description of monadic IO, and does a great job of explaining how the Haskell community decided to use this as their primary IO style.

44[Tackling the Awkward Squad](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf) is the canonical description of monadic IO, and does a great job of explaining how the Haskell community decided to use this as their primary IO style.

45

45

@@ -47,24 +47,22 @@ output <- fetchUrl(stripWhitespace(url))

47

47

48Languages that use explicit state machines for IO (such as Elm) perform IO by accepting events and producing a list of effects.

48Languages that use explicit state machines for IO (such as Elm) perform IO by accepting events and producing a list of effects.

49

49

50−```

51−event :: Initialize

50+ event :: Initialize

52− | CLIInput text

51+ | CLIInput text

53− | FileInput text

52+ | FileInput text

54− | HTTPResponse body

53+ | HTTPResponse body

55−effect :: CLIInput

54+ effect :: CLIInput

56− | ReadFile fileName

55+ | ReadFile fileName

57− | FetchUrl url

56+ | FetchUrl url

58− | Print text

57+ | Print text

59−main(event) {

58+ main(event) {

60− switch event {

59+ switch event {

61− Initialize -> [CLIInput ~]

60+ Initialize -> [CLIInput ~]

62− CLIinput fileName -> [ReadFile fileName]

61+ CLIinput fileName -> [ReadFile fileName]

63− FileInput url -> [FetchUrl stripWhitespace(url)]

62+ FileInput url -> [FetchUrl stripWhitespace(url)]

64− HTTPResponse body -> [Print body]

63+ HTTPResponse body -> [Print body]

65− }

64+ }

66−}

65+ }

67−```

68

66

69The effects produced are not functions but data.

67The effects produced are not functions but data.

70

68

@@ -76,45 +74,39 @@ Let's look at another type of program: a simple HTTP server that you can give te

76

74

77Imperative:

75Imperative:

78

76

79−```

80−text = "no text entered yet"

77+ text = "no text entered yet"

81−while (true)

78+ while (true)

82− cli = readCli()

79+ cli = readCli()

83− if (cli != Null)

80+ if (cli != Null)

84− text = cli

81+ text = cli

85− request = readHttp()

82+ request = readHttp()

86− if (request != Null)

83+ if (request != Null)

87− respond(request,text)

84+ respond(request,text)

88−```

89

85

90Monadic:

86Monadic:

91

87

92−```

93−loop("no text entered yet")

88+ loop("no text entered yet")

94

89

95−where:

90+ where:

96

91

97−loop :: text -> IO Null

92+ loop :: text -> IO Null

98−loop =

93+ loop =

99− input <- readInput()

94+ input <- readInput()

100− switch input

95+ switch input

101− CLIInput newText -> loop(newText)

96+ CLIInput newText -> loop(newText)

102− HTTPRequest request ->

97+ HTTPRequest request ->

103− _ <- respond(request,text)

98+ _ <- respond(request,text)

104− loop(text)

99+ loop(text)

105−```

106

100

107State machine:

101State machine:

108

102

109−```

110−text = "no text entered yet"

103+ text = "no text entered yet"

111−main(text,event) {

104+ main(text,event) {

112− switch event {

105+ switch event {

113− CLIInput newText -> [newText, Null]

106+ CLIInput newText -> [newText, Null]

114− HTTPRequest request -> [text, HTTPResponse text]

107+ HTTPRequest request -> [text, HTTPResponse text]

115− }

108+ }

116−}

109+ }

117−```

118

110

119Again, note the response in the state machine is data, not a function.

111Again, note the response in the state machine is data, not a function.

120

112

@@ -132,9 +124,9 @@ When inventing a new system, you should consider which of these you intend to su

132

124

133So much for exploring the space of IO solutions. In terms of deployed code on Earth, the split is about 90% imperative, 5% monadic, and 5% state machine. In Urbit, the split is about 90% state machine and 10% monadic. This is what I intend to explain and defend.

125So much for exploring the space of IO solutions. In terms of deployed code on Earth, the split is about 90% imperative, 5% monadic, and 5% state machine. In Urbit, the split is about 90% state machine and 10% monadic. This is what I intend to explain and defend.

134

126

135−Urbit's OS is called Arvo; it has several "kernel modules" called vanes, and it has userspace applications. Colloquially these are called "apps," but when speaking about them abstractly, it's helpful to use their more specific name: ["agents"](https://developers.urbit.org/reference/glossary/agent). Arvo, the vanes, and agents are all structured as explicit state machines.

127+Urbit's OS is called Arvo; it has several "kernel modules" called vanes, and it has userspace applications. Colloquially these are called "apps," but when speaking about them abstractly, it's helpful to use their more specific name: ["agents"](https://urbit.org/docs/tutorials/arvo/gall/#agents). Arvo, the vanes, and agents are all structured as explicit state machines.

136

128

137−In addition, there are ["threads"](https://developers.urbit.org/reference/glossary/thread), which are structured as monadic IO. Note there's only a superficial resemblance to Unix threads: they are not executed in parallel and they don't share memory, or at least not any more than agents do. They're simply a computation that takes an argument and produces a result, possibly after doing some IO, structured monadically.

129+In addition, there are ["threads"](https://urbit.org/docs/tutorials/arvo/gall/#threads), which are structured as monadic IO. Note there's only a superficial resemblance to Unix threads: they are not executed in parallel and they don't share memory, or at least not any more than agents do. They're simply a computation that takes an argument and produces a result, possibly after doing some IO, structured monadically.

138

130

139As you can see, all the lowest levels of Arvo are explicit state machines, and only the highest layer supports monadic IO. To see why this is the case, let's list advantages and disadvantages to each type. Note that, while I'm speaking specifically of agents and threads in the context of Urbit, these are fundamental properties of monadic and state machine IO.

131As you can see, all the lowest levels of Arvo are explicit state machines, and only the highest layer supports monadic IO. To see why this is the case, let's list advantages and disadvantages to each type. Note that, while I'm speaking specifically of agents and threads in the context of Urbit, these are fundamental properties of monadic and state machine IO.

140

132

@@ -166,18 +158,16 @@ However, Arvo is a single-level store — all of its state is permanent. This is

166

158

167Further, Arvo and the vanes rarely perform long sequences of IO. Generally, they do one thing and emit some effects, similar to the HTTP server example above. Sometimes they "pass through" a request. For example, the Eyre vane passes HTTP requests to userspace agents or threads. In this case, there is a sequence of IO, which in monadic code would be:

159Further, Arvo and the vanes rarely perform long sequences of IO. Generally, they do one thing and emit some effects, similar to the HTTP server example above. Sometimes they "pass through" a request. For example, the Eyre vane passes HTTP requests to userspace agents or threads. In this case, there is a sequence of IO, which in monadic code would be:

168

160

169−```

170−loop()

161+ loop()

171

162

172−where:

163+ where:

173

164

174−loop =

165+ loop =

175− request <- receiveRequest()

166+ request <- receiveRequest()

176− agent = lookupAgent(request)

167+ agent = lookupAgent(request)

177− response <- callAgent(agent, request)

168+ response <- callAgent(agent, request)

178− _ <- sendResponse(request, response)

169+ _ <- sendResponse(request, response)

179− loop()

170+ loop()

180−```

181

171

182This is clear code to read, but it leaves open the question of how to respond during the callAgent() function. If another request comes in, can we handle it in parallel? If we need to upgrade ourselves before the agent responds, can we make sure to properly handle the response?

172This is clear code to read, but it leaves open the question of how to respond during the callAgent() function. If another request comes in, can we handle it in parallel? If we need to upgrade ourselves before the agent responds, can we make sure to properly handle the response?

183

173

@@ -185,18 +175,16 @@ The naive solution in monadic code is to say that you can only handle one reques

185

175

186In a state machine, the naive solution is:

176In a state machine, the naive solution is:

187

177

188−```

189−state :: (map request agent)

178+ state :: (map request agent)

190−main(state, event) {

179+ main(state, event) {

191− switch event {

180+ switch event {

192− HTTPRequest request ->

181+ HTTPRequest request ->

193− agent = lookupAgent(request)

182+ agent = lookupAgent(request)

194− [put(state, request, agent), CallAgent agent request]

183+ [put(state, request, agent), CallAgent agent request]

195− AgentResponse request response ->

184+ AgentResponse request response ->

196− [del(state, request), HTTPRespond request response]

185+ [del(state, request), HTTPRespond request response]

197− }

186+ }

198−}

187+ }

199−```

200

188

201Upgrading this is trivial, since the state (map of requests to outstanding calls to agents) is explicit. It also trivially handles concurrent requests.

189Upgrading this is trivial, since the state (map of requests to outstanding calls to agents) is explicit. It also trivially handles concurrent requests.

202

190

@@ -212,63 +200,59 @@ However, userspace sometimes needs to perform long sequences of IO. Let's look a

212

200

213Monadic:

201Monadic:

214

202

215−```

216−topStories <- fetch(topStoriesUrl)

203+ topStories <- fetch(topStoriesUrl)

217−loop(topStories)

204+ loop(topStories)

218

205

219−where:

206+ where:

220

207

221−loop :: topStories -> IO Null

208+ loop :: topStories -> IO Null

222− if topStories is Null

209+ if topStories is Null

223− return Null

210+ return Null

224− comments <- retryLoop(5,head(topStories))

211+ comments <- retryLoop(5,head(topStories))

225− otherComments <- loop(tail(topStories))

212+ otherComments <- loop(tail(topStories))

226− append(comments,otherComments)

213+ append(comments,otherComments)

227

214

228−retryLoop :: [n story] -> IO Comments

215+ retryLoop :: [n story] -> IO Comments

229− comments <- fetchComments(story)

216+ comments <- fetchComments(story)

230− if comments is HTTPError:

217+ if comments is HTTPError:

231− if n == 0:

218+ if n == 0:

232− bail

219+ bail

233− else:

220+ else:

234− retryLoop(n-1, story)

221+ retryLoop(n-1, story)

235−```

236

222

237State machine:

223State machine:

238

224

239−```

240−state :: Initial

225+ state :: Initial

241− | FetchingTop

226+ | FetchingTop

242− | FetchingStory comments stories retries

227+ | FetchingStory comments stories retries

243− | Done comments

228+ | Done comments

244−

229+

245−main(state, event) {

230+ main(state, event) {

246− switch event {

231+ switch event {

247− Initialize ->

232+ Initialize ->

248− assert state == Initial

233+ assert state == Initial

249− [FetchingTop, Fetch topStoriesUrl]

234+ [FetchingTop, Fetch topStoriesUrl]

250− HttpResponse response ->

235+ HttpResponse response ->

251− switch state {

236+ switch state {

252− FetchingTop ->

237+ FetchingTop ->

253− [FetchingStory Null stories 5, FetchComments head(stories)]

238+ [FetchingStory Null stories 5, FetchComments head(stories)]

254− FetchingStory comments stories retries ->

239+ FetchingStory comments stories retries ->

255− if response is HTTPError:

240+ if response is HTTPError:

256− if retries == 0:

241+ if retries == 0:

257− [Initial, Null]

242+ [Initial, Null]

258− else:

243+ else:

259− [FetchingStory comments stories retries-1,

244+ [FetchingStory comments stories retries-1,

260− FetchComments head(stories)]

245+ FetchComments head(stories)]

261− else:

246+ else:

262− comments = append(response,comments)

247+ comments = append(response,comments)

263− if tail(stories) is Null:

248+ if tail(stories) is Null:

264− [Done comments, Null]

249+ [Done comments, Null]

265− else:

250+ else:

266− [FetchingStory append(comments,response) tail(stories) 5,

251+ [FetchingStory append(comments,response) tail(stories) 5,

267− FetchComments head(tail(stories))]

252+ FetchComments head(tail(stories))]

253+ }

268 }

254 }

269− }

270−}

255+ }

271−```

272

256

273With practice, the state machine version of this can be written correctly. However, (1) it's verbose, (2) the control flow jumps all over the place, and (3) in practice it's challenging to get exactly right. This is still a small example, and it gets much worse as the length and complexity of the IO sequence grows.

257With practice, the state machine version of this can be written correctly. However, (1) it's verbose, (2) the control flow jumps all over the place, and (3) in practice it's challenging to get exactly right. This is still a small example, and it gets much worse as the length and complexity of the IO sequence grows.

274

258

@@ -296,34 +280,30 @@ We're in a bit of a bind, though: Jael has to be a state machine. The solution i

296

280

297This thread has a definite purpose: given the most recent block number we already know about, fetch all the PKI transactions since then. The function signature is:

281This thread has a definite purpose: given the most recent block number we already know about, fetch all the PKI transactions since then. The function signature is:

298

282

299−```

300−syncEthereum oldBlockNumber -> IO [newBlockNumber, newTxs]

283+ syncEthereum oldBlockNumber -> IO [newBlockNumber, newTxs]

301−```

302

284

303Jael runs this thread every five minutes and, if it succeeds, then we update our block number and PKI state. If the thread fails, gets stuck, or we need to upgrade it, we just kill the old thread and start a new one. Again, a few extra HTTP requests don’t matter.

285Jael runs this thread every five minutes and, if it succeeds, then we update our block number and PKI state. If the thread fails, gets stuck, or we need to upgrade it, we just kill the old thread and start a new one. Again, a few extra HTTP requests don’t matter.

304

286

305From Jael's perspective, it looks something like:

287From Jael's perspective, it looks something like:

306

288

307−```

308−state :: State block txs outstandingThread

289+ state :: State block txs outstandingThread

309−main(state,event) {

290+ main(state,event) {

310− switch event {

291+ switch event {

311− Initialize -> [State 0 Null Null, StartTimer (now + five minutes)]

292+ Initialize -> [State 0 Null Null, StartTimer (now + five minutes)]

312− TimerFired ->

293+ TimerFired ->

313− effects = If outstandingThread is Null

294+ effects = If outstandingThread is Null

314− then Null

295+ then Null

315− else [Kill outstandingThread]

296+ else [Kill outstandingThread]

316− newId = newThreadId()

297+ newId = newThreadId()

317− [State txs newId,

298+ [State txs newId,

318− append(effects,

299+ append(effects,

319− StartThread newId syncEthereum(block),

300+ StartThread newId syncEthereum(block),

320− StartTimer (now + five minutes))]

301+ StartTimer (now + five minutes))]

321− ThreadFinished Failure -> [State block txs Null, Null]

302+ ThreadFinished Failure -> [State block txs Null, Null]

322− ThreadFinished Success newBlockNumber newTxs ->

303+ ThreadFinished Success newBlockNumber newTxs ->

323− [State newBlockNumber append(txs,newTxs) Null, Null]

304+ [State newBlockNumber append(txs,newTxs) Null, Null]

324− }

305+ }

325−}

306+ }

326−```

327

307

328In other words, from Jael's perspective, it's just a single IO event that encapsulates arbitrarily complex IO in the thread. A single IO event is easy enough, and we can maintain all our permanency and robustness guarantees, because we know the thread will have one of three results: success, failure, or it hangs. If we set a timeout, hang becomes failure, so there's only two possible results: success or failure. If we handle both of those correctly, we've handled all the possible IO errors that could have occurred.

308In other words, from Jael's perspective, it's just a single IO event that encapsulates arbitrarily complex IO in the thread. A single IO event is easy enough, and we can maintain all our permanency and robustness guarantees, because we know the thread will have one of three results: success, failure, or it hangs. If we set a timeout, hang becomes failure, so there's only two possible results: success or failure. If we handle both of those correctly, we've handled all the possible IO errors that could have occurred.

329

309

content/blog/iot.md+8−5

@@ -1,16 +1,19 @@

1+++

1+++

2title = "Lunar Urbit and the Internet of Things"

2title = "Lunar Urbit and the Internet of Things"

3−date = "2021-04-29"

3+date = 2021-04-30

4description = "Potential future use cases of moons for industry and consumers"

4description = "Potential future use cases of moons for industry and consumers"

5−

6[extra]

5[extra]

7author = "Jonathan Paprocki"

6author = "Jonathan Paprocki"

8ship = "~datnut-pollen"

7ship = "~datnut-pollen"

9image = "https://media.urbit.org/site/posts/essays/phobos.jpeg"

8image = "https://media.urbit.org/site/posts/essays/phobos.jpeg"

10+++

9+++

11

10

11+<br>

12+

12

13

13

14

15+<br>

16+

14Each of the ~4B 32-or-fewer-bit or [Azimuth](/docs/glossary/azimuth)

17Each of the ~4B 32-or-fewer-bit or [Azimuth](/docs/glossary/azimuth)

15identities, namely [planets](/docs/glossary/planet),

18identities, namely [planets](/docs/glossary/planet),

16[stars](/docs/glossary/star), and [galaxies](/docs/glossary/galaxy), may

19[stars](/docs/glossary/star), and [galaxies](/docs/glossary/galaxy), may

@@ -298,7 +301,7 @@ So let us focus on the additional meritorious aspects of Urbit (or more

298generally, solid state interpreter networks) that make it not merely a band-aid

301generally, solid state interpreter networks) that make it not merely a band-aid

299to the broken IoT system but a permanent and sound replacement.

302to the broken IoT system but a permanent and sound replacement.

300

303

301−#### Solid state interpreter networks {% #ssi %}

304+#### Solid state interpreter networks {#ssi}

302

305

303

306

304

307

@@ -438,8 +441,8 @@ microtransactions. On Mars, this task will be trivial, and is merely a stone's

438throw away from a vast and undiscovered universe of other possibilities unlocked

441throw away from a vast and undiscovered universe of other possibilities unlocked

439by SSI networks.

442by SSI networks.

440

443

441−[^0]:

444+

442− Of course, all moon names have four words, not three. What the fourth word

445+[^0]: Of course, all moon names have four words, not three. What the fourth word

443 needs to be for only three words to display is a matter of Urbit lore that

446 needs to be for only three words to display is a matter of Urbit lore that

444 is more fun to discover yourself than have it told to you, so we won't spoil

447 is more fun to discover yourself than have it told to you, so we won't spoil

445 it here.

448 it here.

content/blog/landscape-a-portrait.md+6−10

@@ -1,12 +1,8 @@

1+++

1+++

2title = "Landscape: A Portrait"

2title = "Landscape: A Portrait"

3−date = "2019-09-02"

3+date = 2019-09-03

4description = "On the latest Urbit user interface, and the interfaces to come."

4description = "On the latest Urbit user interface, and the interfaces to come."

5−aliases = [

6− "/posts/essays/landscape-a-portrait/",

5+aliases = ["/posts/essays/landscape-a-portrait/", "/posts/landscape-a-portrait"]

7− "/posts/landscape-a-portrait"

8−]

9−

10[extra]

6[extra]

11author = "Matilde Park"

7author = "Matilde Park"

12ship = "~haddef-sigwen"

8ship = "~haddef-sigwen"

@@ -32,7 +28,7 @@ Urbit has been in “research mode” for most of its history, but the system ha

32

28

33Urbit’s kernel is graduating from its rebellious period, however its _userspace_ has remained embryonic for most of its history. The project of building an application model has been restarted and rescoped into _aspects_ that could weather the chaotic growth of the kernel, but it would never quite serve as an interface to the entire operating system. Due to one of our latest vane refactors, it’s becoming possible to start that work in earnest.

29Urbit’s kernel is graduating from its rebellious period, however its _userspace_ has remained embryonic for most of its history. The project of building an application model has been restarted and rescoped into _aspects_ that could weather the chaotic growth of the kernel, but it would never quite serve as an interface to the entire operating system. Due to one of our latest vane refactors, it’s becoming possible to start that work in earnest.

34

30

35−Alongside the latest release of Landscape came the rewrite of the [`%eyre`](https://urbit.org/docs/learn/arvo/eyre/) vane, which serves a ship’s files and applications over HTTP. Among the improvements came the decision to move from serving from one ‘/web’ folder by default to an application-specific endpoint.

31+Alongside the latest release of Landscape came the rewrite of the [`%eyre`](https://urbit.org/docs/learn/arvo/eyre/) vane, which serves a ship’s files and applications over HTTP. Among the improvements came the decision to move from serving from one ‘/web’ folder by default to an application-specific endpoint.

36

32

37That is, a Hoon application, upon being started, now tells Eyre it wants to serve _these files_ at _this endpoint_ over HTTP and Eyre facilitates that.

33That is, a Hoon application, upon being started, now tells Eyre it wants to serve _these files_ at _this endpoint_ over HTTP and Eyre facilitates that.

38

34

@@ -54,9 +50,9 @@ All of this is fantastic news; and while Landscape-oriented userspace developmen

54

50

55Among the inspirations for our team are [the tales of Andy Hertzfeld](https://www.folklore.org/StoryView.py?project=Macintosh&story=Were_Not_Hackers!.txt), working on the Macintosh, and ongoing [discussions](http://doc.cat-v.org/plan_9/4th_edition/papers/812/) and [decisions](https://research.swtch.com/help.pdf) that went into Plan 9 from Bell Labs. (Sometimes, for fun, we also watch videos about [the Xerox Alto](https://www.youtube.com/watch?v=tngrLvyiNEI).)

51Among the inspirations for our team are [the tales of Andy Hertzfeld](https://www.folklore.org/StoryView.py?project=Macintosh&story=Were_Not_Hackers!.txt), working on the Macintosh, and ongoing [discussions](http://doc.cat-v.org/plan_9/4th_edition/papers/812/) and [decisions](https://research.swtch.com/help.pdf) that went into Plan 9 from Bell Labs. (Sometimes, for fun, we also watch videos about [the Xerox Alto](https://www.youtube.com/watch?v=tngrLvyiNEI).)

56

52

57−These inspirations share that their creators were dealing with really primordial stuff – the font of human-computer interface had really just sprung and they were _seeing things no one had seen before_ because they _had to_.

53+These inspirations share that their creators were dealing with really primordial stuff – the font of human-computer interface had really just sprung and they were _seeing things no one had seen before_ because they _had to_.

58

54

59−Doing that now, after a lifetime of reflexive familiarity with the dominant solutions – from Apple’s macOS to Google’s Material Design – we have to do the work of _unseeing_. By engaging with what it was like to see for the first time, we get closer to seeing with fresh eyes. We work to avoid implicitly categorising the new territory as simply, well, comparative to the old one.

55+Doing that now, after a lifetime of reflexive familiarity with the dominant solutions – from Apple’s macOS to Google’s Material Design – we have to do the work of _unseeing_. By engaging with what it was like to see for the first time, we get closer to seeing with fresh eyes. We work to avoid implicitly categorising the new territory as simply, well, comparative to the old one.

60

56

61So, while it’s not the same to simply _read_ these dialogues, it can get us pretty close.

57So, while it’s not the same to simply _read_ these dialogues, it can get us pretty close.

62

58

@@ -70,7 +66,7 @@ So what do we think that new platform needs from its interface?

70

66

71- **Landscape, and all of Urbit’s future interfaces, need a way to easily organise around _cohorts_ of ships, or _groups_,** with shared applications or files and a socially-oriented computing experience in turn — [something always in the vision](https://urbit.org/posts/azimuth-is-on-chain/#aegean), but not quite implemented yet.

67- **Landscape, and all of Urbit’s future interfaces, need a way to easily organise around _cohorts_ of ships, or _groups_,** with shared applications or files and a socially-oriented computing experience in turn — [something always in the vision](https://urbit.org/posts/azimuth-is-on-chain/#aegean), but not quite implemented yet.

72

68

73−- Lastly, **Landscape, and all of Urbit’s future interfaces, need a userspace-specific, software design pattern** to integrate all of this: access to the file system, permissioning shared sets of files, and tying it together, an underlying representation of both data and interface amongst many computers.

69+- Lastly, **Landscape, and all of Urbit’s future interfaces, need a userspace-specific, software design pattern** to integrate all of this: access to the file system, permissioning shared sets of files, and tying it together, an underlying representation of both data and interface amongst many computers.

74

70

75No more siloed input/output in applications on a ‘timeshared computer’ with your redundant data always belonging to someone else.

71No more siloed input/output in applications on a ‘timeshared computer’ with your redundant data always belonging to someone else.

76

72

content/blog/layer-2-faq.mddeleted−155

@@ -1,155 +0,0 @@

1−+++

2−title = "Layer 2 FAQ"

3−date = "2022-03-01"

4−description = "Answers to all your lingering L2 questions."

5−[extra]

6−image = "https://media.urbit.org/site/posts/essays/l2-faq-artwork.jpg"

7−+++

8−

9−The launch of our [Layer 2](https://urbit.org/blog/layer-2-guides) was met with

10−a lot of excitement and a few questions. Don’t fret, we have answers. Below is a

11−selection of the most frequently asked questions and our responses.

12−

13−If you're still stumped, head to `~bitbet-bolbel/urbit-community` or give us a

14−shout online.

15−

16−### Questions:

17−

18−#### Planet Booting, Buying, Custody

19−

20−1. [Do I need ETH to boot my planet?](#1-do-i-need-eth-to-boot-my-planet)

21−2. [Do I have full custody of my L2 planet?](#2-is-there-anything-i-need-to-do-to-ensure-full-custody-of-my-planet)

22−3. [Where can I buy a planet?](#3-are-there-any-platforms-where-i-can-buy-a-planet-for-btc-or-usd)

23−4. [How do I get a hosted planet?](#4-how-do-i-get-a-cloud-hosted-planet)

24−

25−#### Layer 2 Architecture & Migration

26−

27−5. [Why did you decide to build your own Layer 2 rollup?](#5-there-are-plenty-of-organizations-dedicated-to-customizable-rollup-solutions-why-did-you-decide-to-build-your-own)

28−6. [Should I migrate my L1 planet to L2?](#6-if-i-currently-have-an-l1-planet-are-there-any-advantages-to-migrating)

29−7. [Where did the old Bridge go? Can I still use it?](#7-is-it-possible-to-use-the-old-bridge-for-l1-operations)

30−8. [Why is the cost reduction so significant?](#8-why-is-the-cost-reduction-so-significant)

31−9. [What exactly is the mechanism for the “naive” consensus?](#9-what-exactly-is-the-mechanism-for-the-naive-consensus)

32−10. [When I spawn L2 planets via Metamask, I'm prompted to sign every transaction. Do you have plans to remedy this?](#10-when-i-spawn-l2-planets-via-metamask-im-prompted-to-sign-every-transaction-do-you-have-plans-to-remedy-this)

33−

34−#### 1. Do I need ETH to boot my planet?

35−

36−If you were invited to claim a L2 planet, you **do not** need ETH to claim

37−that Urbit ID. Anyone can get on Urbit without ETH or a crypto wallet via L2.

38−Inviting your mom to Urbit just got a lot easier.

39−

40−If you have a L1 planet, you **do** need ETH to claim that Urbit ID.

41−

42−Once you have claimed your Urbit ID and have recorded your master ticket,

43−you **do not** need ETH to boot Urbit. That Urbit ID is now yours, forever.

44−

45−Unsure whether you have been invited to claim a L2 or L1 planet? The quickest

46−way to identify a L2 planet is if you used the below flow to claim.

47−

48−

49−

50−For those with L1 planets, you can avoid future transaction fees by migrating

51−your L1 planet to L2. Read the migration instructions

52−[here](https://urbit.org/getting-started/layer-2-for-planets).

53−

54−#### 2. Is there anything I need to do to ensure full custody of my planet?

55−

56−If you were sent a direct link to claim an L2 planet (see above), it’s

57−in your full custody by design. Bridge generates your master ticket, which you

58−downloaded during the claiming process.

59−

60−#### 3. Are there any platforms where I can buy a planet for BTC or USD?

61−

62−There are a few ways to procure a planet, including some platforms that offer

63−BTC and USD payment options.

64−

65−To purchase a L2 planet, we direct you to:

66−

67−- [Networked Subject](https://subject.network/buy/) for payment in BTC.

68− Brought to you by `~sitful-hatred`.

69−- [planets.lanlyd.net](https://planets.lanlyd.net) and

70− [tomdys.gumroad.com](https://tomdys.gumroad.com) for payment in USD.

71−

72−To purchase a L1 planet with ETH, there are a number of platforms dedicated

73−exclusively to Urbit ID. These include:

74−

75−- [urbit.live](https://urbit.live/buy)

76−- [urbitex.io](https://urbitex.io)

77−- [urbit.me](https://urbit.me)

78−

79−You can also acquire L1 Urbit IDs with ETH on [OpenSea](https://opensea.io/collection/urbit-id).

80−

81−Once you purchase a planet, the easiest way to manage your cryptographic asset

82−is through [Bridge](https://bridge.urbit.org/), which is our Urbit ID management

83−interface, wallet navigator, and governance portal.

84−

85−You can use Bridge to perform any desired

86−[Azimuth](https://urbit.org/docs/glossary/azimuth) interactions or download your

87−planet’s keyfile. As an alternative, [Metamask](https://metamask.io) is an

88−easy-to-use Ethereum wallet with a browser extension that integrates easily with

89−Bridge.

90−

91−#### 4. How do I get a cloud-hosted planet?

92−

93−There are a number of ways to host a planet in the cloud. Your options:

94−

95−- DIY:

96− The most cost-effective method is [setting it up

97− yourself](https://urbit.org/using/running/hosting), though this route requires

98− some system administration, and troubleshooting if any issues arise.

99−

100−- Via a Hosting Provider:

101− The more “headache-free” option is paying for a

102− hosting provider to take care of all these processes for you, plus support. The

103− following service providers offer hosting (some include a free planet):

104− [Tlon](https://urbit.typeform.com/to/zQ9QOV3Z?typeform-source=tlon.io#source=tlon_io),

105− [UrbitHost](https://urbithost.com/landing), [Get Urbit

106− ID](https://www.geturbitid.com), [Escape Pod

107− Store](https://www.escapepod.store), [Nodestead](https://www.nodestead.dev), and

108− [ThirdEarth](https://third.earth/en/).

109−

110−#### 5. There are plenty of organizations dedicated to customizable rollup solutions. Why did you decide to build your own?

111−

112−Simply put, we designed and engineered our own rollup because we can’t depend

113−on the success or longevity of another organization. As they currently exist,

114−outsourced rollups are too immature and compromised in ways that undermine the

115−integrity of our technical principles. We also can’t restrict the aggregators to

116−a waitlist, another issue which might eventually be resolved, but one that we

117−can’t count on to be resolved soon.

118−

119−#### 6. If I currently have an L1 planet, are there any advantages to migrating?

120−

121−One of the most significant advantages to migrating is the reduced cost of

122−Azimuth-event related transactions. On L2, you can change sponsors or reset your

123−network keys for free with our roller. An important note: migration is currently

124−one-way. If you want to hold onto your L1 planet as a novelty, migration isn't

125−recommended.

126−

127−#### 7. Is it possible to use the old Bridge for L1 operations?

128−

129−The old version of Bridge will remain live, but unmaintained and eventually

130−decommissioned. You can access it at

131−[bridge-sunset.urbit.org](https://bridge-sunset.urbit.org). If you run into

132−something you can only do with the older version of Bridge,

133−[let us know on Github](https://github.com/urbit/bridge/issues/new?assignees=&labels=bridge&template=bridge-bug-report.md&title=).

134−

135−#### 8. Why is the cost reduction so significant?

136−

137−On L1, every operation is an Ethereum transaction, with logic and state, etc.

138−On L2, these operations are reduced and simplified into a

139−no-logic-involved Ethereum transaction. This is what makes L2 transactions

140−cost-efficient: multiple transactions happen simultaneously to share the cost of

141−just one L1 transaction.

142−

143−#### 9. What exactly is the mechanism for the “naive” consensus?

144−

145−Our engineering team has written extensively about the technical features of

146−our L2 rollup. To learn about its intricacies, we encourage you to read

147−`~datnut-pollen`’s comprehensive

148−[overview](https://urbit.org/blog/rollups#technical) and `~wicdev-wisryt`’s

149−original

150−[proposal](https://groups.google.com/a/urbit.org/g/dev/c/p6rP_WsxLS0/m/hQBX0modAwAJ?pli=1)

151−on the Urbit developer mailing list.

152−

153−#### 10. When I spawn L2 planets via Metamask, I'm prompted to sign every transaction. Do you have plans to remedy this?

154−

155−We realize this UX headache and are taking active steps to devise a more efficient transaction scheme. The new method will reduce the number of manual signatures needed for each spawned L2 planet. At the time of this FAQ's publication, we haven't publicized the release timing for the improvement. A provisional solution: set the star's spawn proxy to a custodied L2 planet secured via Master ticket and log in to Bridge as that planet to spawn invites.

content/blog/magic.md+86−87

@@ -1,9 +1,8 @@

1+++

1+++

2title = "Magic"

2title = "Magic"

3−date = "2016-05-15"

3+date = 2016-05-16

4description = "A thought-experiment to explain the Urbit user experience."

4description = "A thought-experiment to explain the Urbit user experience."

5−aliases = [ "/posts/essays/magic", "/posts/magic" ]

5+aliases = ["/posts/essays/magic", "/posts/magic"]

6−

7[extra]

6[extra]

8author = "Curtis Yarvin"

7author = "Curtis Yarvin"

9ship = "~sorreg-namtyv"

8ship = "~sorreg-namtyv"

@@ -12,186 +11,186 @@ image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/magic.

12

11

13

12

14

13

15−It's easy to get too obsessed with Urbit's alien technology. We

14+It's easy to get too obsessed with Urbit's alien technology. We

16−didn't build Urbit for its tech. We built it for people to use.

15+didn't build Urbit for its tech. We built it for people to use.

17

16

18It's also hard to understand the power of Urbit, because it's

17It's also hard to understand the power of Urbit, because it's

19−still quite immature. Unless you understand it already, it's

18+still quite immature. Unless you understand it already, it's

20just a weird OS that doesn't work all that well.

19just a weird OS that doesn't work all that well.

21

20

22And this OS is supposedly designed as a new kind of product: a

21And this OS is supposedly designed as a new kind of product: a

23−personal server. What is a personal server? If you had one,

22+personal server. What is a personal server? If you had one,

24−you'd know. Since you don't, you don't. So both your problem

23+you'd know. Since you don't, you don't. So both your problem

25and our solution are totally unclear.

24and our solution are totally unclear.

26

25

27One way to understand Urbit is to forget the technology totally.

26One way to understand Urbit is to forget the technology totally.

28−Instead, let's build the same product out of magic. Technology

27+Instead, let's build the same product out of magic. Technology

29−is hard and imperfect and slow. Magic is easy and perfect and

28+is hard and imperfect and slow. Magic is easy and perfect and

30−fast. Why not use it? At least for a demo?

29+fast. Why not use it? At least for a demo?

31

30

32## Magic step one: total integration.

31## Magic step one: total integration.

33

32

34Make a list of all the cloud apps which have your personal data.

33Make a list of all the cloud apps which have your personal data.

35−OK, just imagine making a list. OK, use magic.

34+OK, just imagine making a list. OK, use magic.

36

35

37−By magic, we make some giant company buy all these apps. It

36+By magic, we make some giant company buy all these apps. It

38−could be any of them, but let's say it's Facebook. Facebook buys

37+could be any of them, but let's say it's Facebook. Facebook buys

39−_all the apps_. As of now, _all your cloud computing happens in

38+_all the apps_. As of now, _all your cloud computing happens in

40your Facebook profile_.

39your Facebook profile_.

41

40

42Your Facebook is now your Dropbox and your Evernote and your

41Your Facebook is now your Dropbox and your Evernote and your

43−Wordpress and your Gmail. And it's not just Web apps; all your

42+Wordpress and your Gmail. And it's not just Web apps; all your

44−servers move to Facebook. Your Nest talks to a Facebook server.

43+servers move to Facebook. Your Nest talks to a Facebook server.

45−Your iPhone talks to Facebook instead of iCloud. Your Fitbit

44+Your iPhone talks to Facebook instead of iCloud. Your Fitbit

46−records your heart rate in a Facebook log. Your Facebook

45+records your heart rate in a Facebook log. Your Facebook

47−manages your finances and pays your bills. Got bitcoin?

46+manages your finances and pays your bills. Got bitcoin?

48−Facebook is your wallet. Shop online? Check out the Facebook

47+Facebook is your wallet. Shop online? Check out the Facebook

49Store -- it sells everything!

48Store -- it sells everything!

50

49

51−In short, you can just lock your browser to `facebook.com`. The

50+In short, you can just lock your browser to `facebook.com`. The

52−Web is dead. Or more precisely, it's an obsolete protocol which

51+Web is dead. Or more precisely, it's an obsolete protocol which

53you use to log in to Facebook.

52you use to log in to Facebook.

54

53

55−Does this sound creepy? Sure. It's incredibly creepy. But look

54+Does this sound creepy? Sure. It's incredibly creepy. But look

56−on the bright side: it's also incredibly convenient. (And

55+on the bright side: it's also incredibly convenient. (And

57incredibly secure, at least with a 2-factor key.)

56incredibly secure, at least with a 2-factor key.)

58

57

59−For the first time ever, _all your data is in one place_. For

58+For the first time ever, _all your data is in one place_. For

60example, the engineers at Facebook, who are awesome, would never

59example, the engineers at Facebook, who are awesome, would never

61leave Dropbox, Instagram and iCloud as three separate things.

60leave Dropbox, Instagram and iCloud as three separate things.

62−You don't need an "integration" between them. Your profile is

61+You don't need an "integration" between them. Your profile is

63−one thing: you. Your entire digital life.

62+one thing: you. Your entire digital life.

64

63

65(In fact, if you're a geek and have Unix boxes, your Facebook is

64(In fact, if you're a geek and have Unix boxes, your Facebook is

66−magically integrated with Unix. You can just open your laptop

65+magically integrated with Unix. You can just open your laptop

67and type `ls /photos/2016/May/` -- as if your digital life was a

66and type `ls /photos/2016/May/` -- as if your digital life was a

68chip in a box in your backpack, not redundant servers in multiple

67chip in a box in your backpack, not redundant servers in multiple

69secure data centers.)

68secure data centers.)

70

69

71Imagine we all lived in hotels, all the time, even in just one

70Imagine we all lived in hotels, all the time, even in just one

72−city. Imagine you don't even have one room with a long-term

71+city. Imagine you don't even have one room with a long-term

73−lease. You sleep in one pod Mondays, another on Tuesdays...

72+lease. You sleep in one pod Mondays, another on Tuesdays...

74−then, someone offers you a home. Your own house. With your own

73+then, someone offers you a home. Your own house. With your own

75furniture, your own books in your own bookcases...

74furniture, your own books in your own bookcases...

76

75

77## Magic step two: free your data.

76## Magic step two: free your data.

78

77

79−The good news is, you get your own house. The bad news is, it's

78+The good news is, you get your own house. The bad news is, it's

80in North Korea.

79in North Korea.

81

80

82−Having your whole life owned by Facebook is still creepy. Or so

81+Having your whole life owned by Facebook is still creepy. Or so

83−most people would think. It's not actually clear that it's more

82+most people would think. It's not actually clear that it's more

84creepy to be owned by one corporation, than nine corporations.

83creepy to be owned by one corporation, than nine corporations.

85But it _feels_ creepier.

84But it _feels_ creepier.

86

85

87−By magic, Facebook cares. So it decides to free you. Actually,

86+By magic, Facebook cares. So it decides to free you. Actually,

88−Facebook's business is owning you. So freedom will destroy its

87+Facebook's business is owning you. So freedom will destroy its

89−business. But magically, Facebook doesn't mind.

88+business. But magically, Facebook doesn't mind.

90

89

91Right now, the software behind your Facebook experience is a

90Right now, the software behind your Facebook experience is a

92−million lines of Facebook goo. It solves your problems and shows

91+million lines of Facebook goo. It solves your problems and shows

93your ads and does whatever the heck it wants with your data.

92your ads and does whatever the heck it wants with your data.

94−(Not that it's "your" data. It's Facebook's data, about you.)

93+(Not that it's "your" data. It's Facebook's data, about you.)

95

94

96Without changing the functionality of your Facebook experience,

95Without changing the functionality of your Facebook experience,

97Facebook replaces every component of this goo with an "agent."

96Facebook replaces every component of this goo with an "agent."

98−(You have about as many agents as you used to have apps.) If you

97+(You have about as many agents as you used to have apps.) If you

99−don't care about being free, you won't notice the change. If you

98+don't care about being free, you won't notice the change. If you

100do care, everything changes.

99do care, everything changes.

101

100

102−One, you don't have to run Facebook's agents. You can replace

101+One, you don't have to run Facebook's agents. You can replace

103−them with anyone else's software, free or paid. Agents upgrade

102+them with anyone else's software, free or paid. Agents upgrade

104themselves automatically, but you are never locked in; you can

103themselves automatically, but you are never locked in; you can

105always switch agents and/or vendors without damaging your data.

104always switch agents and/or vendors without damaging your data.

106

105

107−Don't like your email UI? Change it. Don't like to see ads?

106+Don't like your email UI? Change it. Don't like to see ads?

108You no longer see any ads -- why would someone use an agent that

107You no longer see any ads -- why would someone use an agent that

109−showed them ads? Ick. Unless it's something ridiculously

108+showed them ads? Ick. Unless it's something ridiculously

110specialized, an agent is either free software or costs $3.99.

109specialized, an agent is either free software or costs $3.99.

111

110

112−Two, agents _act as you_. Facebook is no longer the Panopticon.

111+Two, agents _act as you_. Facebook is no longer the Panopticon.

113It is not a giant mainframe where all the code can access all the

112It is not a giant mainframe where all the code can access all the

114−data. An agent can use as much of your own data as you give it;

113+data. An agent can use as much of your own data as you give it;

115−it cannot use anyone else's data. At least not without asking.

114+it cannot use anyone else's data. At least not without asking.

116

115

117−When anyone can write an agent, only code can be law. Privacy is

116+When anyone can write an agent, only code can be law. Privacy is

118no longer enforced by the informal decisions of Facebook product

117no longer enforced by the informal decisions of Facebook product

119−managers. It must be enforced by formal security policies.

118+managers. It must be enforced by formal security policies.

120

119

121This might constrict the services Facebook can offer, but only a

120This might constrict the services Facebook can offer, but only a

122−little. Since privacy is a human universal, apps that don't

121+little. Since privacy is a human universal, apps that don't

123−respect it (for instance, image face tagging) feel weird. A

122+respect it (for instance, image face tagging) feel weird. A

124service like this can't be broken up into personal agents; it

123service like this can't be broken up into personal agents; it

125−still requires a Big Data mainframe somewhere. But it's okay;

124+still requires a Big Data mainframe somewhere. But it's okay;

126the agents can still talk to it.

125the agents can still talk to it.

127

126

128For the most part, Big Data (everyone's) has become little data

127For the most part, Big Data (everyone's) has become little data

129−(yours). You no longer have a Facebook profile -- a fancy UI

128+(yours). You no longer have a Facebook profile -- a fancy UI

130backed by a million lines of Facebook goo on one big mainframe.

129backed by a million lines of Facebook goo on one big mainframe.

131−Now what you have is a Facebook _server_: a real computer. Or at

130+Now what you have is a Facebook _server_: a real computer. Or at

132least, a virtual computer (which is much more reliable than any

131least, a virtual computer (which is much more reliable than any

133one physical computer).

132one physical computer).

134

133

135−Is this computer hard to manage? You have the same basic job as

134+Is this computer hard to manage? You have the same basic job as

136−someone who owns an iPhone: deciding what software to run. If

135+someone who owns an iPhone: deciding what software to run. If

137you skip this job, your iPhone or your Facebook is still pretty

136you skip this job, your iPhone or your Facebook is still pretty

138−useful. You also need to decide what data to keep. An iPhone

137+useful. You also need to decide what data to keep. An iPhone

139has finite, free storage; the cloud has infinite, non-free

138has finite, free storage; the cloud has infinite, non-free

140−storage. You still want a warning when your server gets fat.

139+storage. You still want a warning when your server gets fat.

141But at least it keeps working.

140But at least it keeps working.

142

141

143## Magic step three: free your server.

142## Magic step three: free your server.

144

143

145−This agent-oriented Facebook can't show you ads. But this is not

144+This agent-oriented Facebook can't show you ads. But this is not

146−actually a huge business problem. Since Facebook owns everyone's

145+actually a huge business problem. Since Facebook owns everyone's

147−life, it has the mother of all monopoly lockins. It can just

146+life, it has the mother of all monopoly lockins. It can just

148−bill you $9.99 a month for running your Facebook server. This is

147+bill you $9.99 a month for running your Facebook server. This is

149a great deal, for you and for Facebook.

148a great deal, for you and for Facebook.

150

149

151−But you're still a slave, Neo. A Facebook server still isn't a

150+But you're still a slave, Neo. A Facebook server still isn't a

152−personal server. Monopolies suck.

151+personal server. Monopolies suck.

153

152

154−Magic works, so Facebook feels guilty. It goes all the way

153+Magic works, so Facebook feels guilty. It goes all the way

155toward freeing you, and ruins its own business.

154toward freeing you, and ruins its own business.

156

155

157Now, your server is just a big file whose format is precisely

156Now, your server is just a big file whose format is precisely

158−defined. You can move it to any hosting service, or even run it

157+defined. You can move it to any hosting service, or even run it

159−on a home PC. Since hosting is now a commodity, it costs almost

158+on a home PC. Since hosting is now a commodity, it costs almost

160−nothing and has zero profit margin. It may even come bundled

159+nothing and has zero profit margin. It may even come bundled

161with your Internet service.

160with your Internet service.

162

161

163−Every data center is owned by the local government. If you have

162+Every data center is owned by the local government. If you have

164−data to hide from the authorities, compute at home. Most people

163+data to hide from the authorities, compute at home. Most people

165don't have anything to hide and should run in the cloud, because

164don't have anything to hide and should run in the cloud, because

166−the cloud works better. But using the _same platform_ as those

165+the cloud works better. But using the _same platform_ as those

167−who do have something to hide creates "herd immunity". You don't

166+who do have something to hide creates "herd immunity". You don't

168have to choose between a secure platform with no network effect,

167have to choose between a secure platform with no network effect,

169and a non-secure platform that everyone else uses.

168and a non-secure platform that everyone else uses.

170

169

171## Magic step four: free your name.

170## Magic step four: free your name.

172

171

173−Freeing your server also means freeing your identity. It's no

172+Freeing your server also means freeing your identity. It's no

174−longer true that Facebook decides who you are. Facebook just

173+longer true that Facebook decides who you are. Facebook just

175−wrote the algorithm. Your server contains cryptographic secrets

174+wrote the algorithm. Your server contains cryptographic secrets

176−that control your identity. If your identity was a bitcoin, your

175+that control your identity. If your identity was a bitcoin, your

177server would be a giant bitcoin wallet.

176server would be a giant bitcoin wallet.

178

177

179−The bad news: lose the file, lose the identity. The good news:

178+The bad news: lose the file, lose the identity. The good news:

180−your server is genuinely personal now. It's yours in every way.

179+your server is genuinely personal now. It's yours in every way.

181It's so personal that if you destroy it, it's gone.

180It's so personal that if you destroy it, it's gone.

182

181

183−Facebook doesn't even keep its power to create new servers. The

182+Facebook doesn't even keep its power to create new servers. The

184"real name" policy has done great things to control spam, because

183"real name" policy has done great things to control spam, because

185−spam always depends on disposable accounts. But it implies a

184+spam always depends on disposable accounts. But it implies a

186central authority.

185central authority.

187

186

188Instead, Facebook borrows an idea from bitcoin and just limits

187Instead, Facebook borrows an idea from bitcoin and just limits

189−the number of identities. If you need one, you have to buy one.

188+the number of identities. If you need one, you have to buy one.

190They don't cost that much; just enough to deter spammers.

189They don't cost that much; just enough to deter spammers.

191

190

192−(Is your real name still linked to your identity? Maybe, maybe

191+(Is your real name still linked to your identity? Maybe, maybe

193−not. There's a role for name validation, but not everyone needs

192+not. There's a role for name validation, but not everyone needs

194−to have a real name, and not everyone else needs to know it. A

193+to have a real name, and not everyone else needs to know it. A

195dissident, or anyone who wants to speak out and let the words

194dissident, or anyone who wants to speak out and let the words

196speak for themselves, might want a second anonymous identity.

195speak for themselves, might want a second anonymous identity.

197But sock puppets remain evil -- two names for the same person

196But sock puppets remain evil -- two names for the same person

@@ -201,5 +200,5 @@ should not interact in the same place.)

201

200

202And, with magic, we've succeeded in turning Facebook into Urbit.

201And, with magic, we've succeeded in turning Facebook into Urbit.

203Technically, Urbit is pretty close to magic, but there is no way

202Technically, Urbit is pretty close to magic, but there is no way

204−it's going to happen this way. See the [roadmap](/blog/roadmap) for how it

203+it's going to happen this way. See the [roadmap](../roadmap) for how it

205actually happens.

204actually happens.

content/blog/metaphase.md+11−16

@@ -1,25 +1,20 @@

1+++

1+++

2title = "Metaphase"

2title = "Metaphase"

3−date = "2020-12-08"

3+date = 2020-12-09

4description = "On the upcoming and foregoing Landscape lifecycles, and other forms of mitosis across the Urbit project."

4description = "On the upcoming and foregoing Landscape lifecycles, and other forms of mitosis across the Urbit project."

5−

6[extra]

5[extra]

7author = "Matilde Park"

6author = "Matilde Park"

8ship = "~haddef-sigwen"

7ship = "~haddef-sigwen"

9image = "https://media.urbit.org/site/posts/essays/metaphase.jpg"

8image = "https://media.urbit.org/site/posts/essays/metaphase.jpg"

10+++

9+++

11

10

12−

11+<br>

13

12

14−_Previous versions of this essay specified the stream deploy date as December 11, 2020; then December 18, 2020. This has been amended to the actual date of release, with our sincere apologies. For new readers, you can opt into the dev stream by running:_

13+

15

14

16−```

15+<br>

17−|ota ~hanruc-nalfus-nidsut-tomdun %kids

18−|merge %home ~hanruc-nalfus-nidsut-tomdun %kids, =gem %take-that

19−|merge %kids ~hanruc-nalfus-nidsut-tomdun %kids, =gem %take-that

20−```

21

16

22−_We will surface this option more broadly in a future settings overhaul._

17+*Previous versions of this essay specified the stream deploy date as December 11, 2020; then December 18, 2020. This has been amended to the actual date of release, with our sincere apologies. For new readers, you can opt into the dev stream by running `|ota ~lomlyx-lopsem-nidsut-tomdun %kids` (you may have to resolve a merge conflict using `|merge %home ~lomlyx-lopsem-nidsut-tomdun %kids, =gem %take-that`). We will surface this option more broadly in a future settings overhaul.*

23

18

24A few weeks ago, the Landscape team — those of us building Tlon’s suite of userspace applications on top of Urbit— deployed our first over-the-air update for notifications. This is a big leap forward for us. Of course, getting notifications inside Landscape itself is a big deal, but getting a push notification on your phone, or an email digest based on activity inside Urbit is now just one step away, a weekend project for a hobby developer, not an indeterminate number of steps away.

19A few weeks ago, the Landscape team — those of us building Tlon’s suite of userspace applications on top of Urbit— deployed our first over-the-air update for notifications. This is a big leap forward for us. Of course, getting notifications inside Landscape itself is a big deal, but getting a push notification on your phone, or an email digest based on activity inside Urbit is now just one step away, a weekend project for a hobby developer, not an indeterminate number of steps away.

25

20

@@ -27,7 +22,7 @@ After release, we received some feedback from users on the behaviour and design

27

22

28As I’ll describe, we haven’t just been iterating Landscape, but the way we develop Landscape, and the way we consider Landscape in relation to Arvo. Finally, we’ll discuss our upcoming two-stream release process: a “stable” release stream with updates every six weeks and a development stream, with ongoing changes continuously deployed on an opt-in basis.

23As I’ll describe, we haven’t just been iterating Landscape, but the way we develop Landscape, and the way we consider Landscape in relation to Arvo. Finally, we’ll discuss our upcoming two-stream release process: a “stable” release stream with updates every six weeks and a development stream, with ongoing changes continuously deployed on an opt-in basis.

29

24

30−To someone coming to Landscape for the first time, it is starting to look mature; and it is indeed maturing quickly. After all, these mismatches in expectations are pangs calling out for growth. Landscape truly has _users_, not just explorers, who are developing the same expectations they have with the other tools they use: predictability, reliability, and iterative improvements, not just leaps forward. So to meet those expectations, we’ve been working on the prerequisite work for a mature release schedule, with two different release streams for users and explorers: a lifecycle, with the cells, interlinked, dividing into a coherent higher being.

25+To someone coming to Landscape for the first time, it is starting to look mature; and it is indeed maturing quickly. After all, these mismatches in expectations are pangs calling out for growth. Landscape truly has *users*, not just explorers, who are developing the same expectations they have with the other tools they use: predictability, reliability, and iterative improvements, not just leaps forward. So to meet those expectations, we’ve been working on the prerequisite work for a mature release schedule, with two different release streams for users and explorers: a lifecycle, with the cells, interlinked, dividing into a coherent higher being.

31

26

32## Landscapers and lifecycles

27## Landscapers and lifecycles

33

28

@@ -43,9 +38,9 @@ We traditionally tended toward solving those problems by writing the simplest po

43

38

44For most of its history, Landscape’s userspace suite had to be up-to-date on all ships to function at all, so multiple staging streams added quite a few complications. Since incompatible versions of applications on different ships would produce mutual fail states if they attempted to interact –and since each application had no sense of how to negotiate compatibility with older applications, each user had to keep up-to-date. Landscape was moving too fast, constantly reconfiguring (to give you a sense of this: we still refer to a month ago as “old”).

39For most of its history, Landscape’s userspace suite had to be up-to-date on all ships to function at all, so multiple staging streams added quite a few complications. Since incompatible versions of applications on different ships would produce mutual fail states if they attempted to interact –and since each application had no sense of how to negotiate compatibility with older applications, each user had to keep up-to-date. Landscape was moving too fast, constantly reconfiguring (to give you a sense of this: we still refer to a month ago as “old”).

45

40

46−Historically, Arvo and Landscape were also considered just one object; changes in Landscape would often require refining the layers underneath it as well. We often aimed to use our interface’s requirements to refine Arvo in turn. But as Landscape’s cells continued to split, as it became a proper client _for_ Arvo rather than a subsection _of_ Arvo, it required its own planning and execution cycle that only came to fruition around April of this year.

41+Historically, Arvo and Landscape were also considered just one object; changes in Landscape would often require refining the layers underneath it as well. We often aimed to use our interface’s requirements to refine Arvo in turn. But as Landscape’s cells continued to split, as it became a proper client *for* Arvo rather than a subsection *of* Arvo, it required its own planning and execution cycle that only came to fruition around April of this year.

47

42

48−The first thing we did was start recurring, six-week product backlogs with designers and engineers to occasionally reassess short-term priorities with a larger roadmap. Once we did that, we began working on opening our process to the public, migrating all tasks, priorities, and current decisions to a [product board](https://github.com/urbit/landscape). By doing this, community members could both suggest features _and_ contribute features, with a centralised, transparent process for getting designer input and Tlon engineer priorities. This has also been a successful effort.

43+The first thing we did was start recurring, six-week product backlogs with designers and engineers to occasionally reassess short-term priorities with a larger roadmap. Once we did that, we began working on opening our process to the public, migrating all tasks, priorities, and current decisions to a [product board](https://github.com/urbit/landscape). By doing this, community members could both suggest features *and* contribute features, with a centralised, transparent process for getting designer input and Tlon engineer priorities. This has also been a successful effort.

49

44

50By adjusting ourselves to a six week rhythm for execution, it’s clearly time to slow down our release schedule and dedicate design and QA time to each release.

45By adjusting ourselves to a six week rhythm for execution, it’s clearly time to slow down our release schedule and dedicate design and QA time to each release.

51

46

@@ -56,7 +51,7 @@ That said, our userspace infrastructure is maturing, so we could at least organi

56So now, before we could launch a stable stream, we had some things to do first:

51So now, before we could launch a stable stream, we had some things to do first:

57

52

58- **We wanted to provide assurance that the userspace suite is relatively stable.** All our remaining stores (invite-store, metadata-store, and contact-store) needed to be modernised to use the same libraries and utilities inside Arvo as newer userspace applications.

53- **We wanted to provide assurance that the userspace suite is relatively stable.** All our remaining stores (invite-store, metadata-store, and contact-store) needed to be modernised to use the same libraries and utilities inside Arvo as newer userspace applications.

59−- **We wanted all our applications to be using graph-store.** If we were going to migrate the entire network to a new userspace model, we shouldn’t undermine the new release cycle process and make it more difficult to test and deploy to meet higher user expectations. We needed to migrate everything first.

54+- **We wanted all our applications to be using graph-store.** If we were going to migrate the entire network to a new userspace model, we shouldn’t undermine the new release cycle process and make it more difficult to test and deploy to meet higher user expectations. We needed to migrate everything first.

60- **We wanted to release the notification-store**. After the October 2020 groups release, Landscape simply wouldn’t be complete without it.

55- **We wanted to release the notification-store**. After the October 2020 groups release, Landscape simply wouldn’t be complete without it.

61- Finally, **we wanted all of Landscape to use the [Indigo component library](https://github.com/urbit/indigo-react).** Landscape shipped with each application using its own build with handwritten, bespoke DOM components. Once we moved to a single-page application architecture in June 2020, we wanted the same guaranteed consistency for both back-end and front-end code.

56- Finally, **we wanted all of Landscape to use the [Indigo component library](https://github.com/urbit/indigo-react).** Landscape shipped with each application using its own build with handwritten, bespoke DOM components. Once we moved to a single-page application architecture in June 2020, we wanted the same guaranteed consistency for both back-end and front-end code.

62

57

@@ -68,12 +63,12 @@ And for intrepid users, you can opt-in to a development stream and help us find

68

63

69## Mitosis

64## Mitosis

70

65

71−Describing our progress so candidly can feel strange — after all, it sounds so _early_. But to me, it’s exciting. It’s mitosis.

66+Describing our progress so candidly can feel strange — after all, it sounds so *early*. But to me, it’s exciting. It’s mitosis.

72

67

73Take another example. For all of Urbit’s history — all until now — Tlon was playing the role of both parents to the project when it was really just an embryonic corporate vehicle itself, fated to become twins. But in the past few months the burgeoning Urbit Foundation’s interim Director, Josh Lehman (`~wolref-podlex`), has begun to ramp up responsibility, taking increasing stewardship over urbit.org and giving it a physical voice, an Otherness, apart from Tlon’s own goals.

68Take another example. For all of Urbit’s history — all until now — Tlon was playing the role of both parents to the project when it was really just an embryonic corporate vehicle itself, fated to become twins. But in the past few months the burgeoning Urbit Foundation’s interim Director, Josh Lehman (`~wolref-podlex`), has begun to ramp up responsibility, taking increasing stewardship over urbit.org and giving it a physical voice, an Otherness, apart from Tlon’s own goals.

74

69

75Now, each day, we stray a little closer to these entities splitting apart, a step closer to the Urbit Foundation and the Tlon Corporation being completely different entities with completely different concerns.

70Now, each day, we stray a little closer to these entities splitting apart, a step closer to the Urbit Foundation and the Tlon Corporation being completely different entities with completely different concerns.

76

71

77−The same has occurred with Landscape. Previously Landscape was “_the_ interface to Urbit,” the proof that there was more to the project than a Unix executable. And slowly to those of us at Tlon, it became obvious what it was destined to become: a flagship client for an entire network, a tree branch rooting a world beneath clearnet, the first cell by which other clients might be born. Mitosis can be clumsy to watch; it can be nauseating to experience; it can be difficult to make out what will arrive where.

72+The same has occurred with Landscape. Previously Landscape was “*the* interface to Urbit,” the proof that there was more to the project than a Unix executable. And slowly to those of us at Tlon, it became obvious what it was destined to become: a flagship client for an entire network, a tree branch rooting a world beneath clearnet, the first cell by which other clients might be born. Mitosis can be clumsy to watch; it can be nauseating to experience; it can be difficult to make out what will arrive where.

78

73

79But this is, after all, how a body forms.

74But this is, after all, how a body forms.

content/blog/on-christopher-alexander.mddeleted−70

@@ -1,70 +0,0 @@

1−+++

2−title = "On Christopher Alexander"

3−date = "2021-07-19"

4−description = "An overview of his writing and relevance"

5−

6−[extra]

7−author = "Matt"

8−ship = "~tirwyd-sarmes"

9−image = "https://media.urbit.org/site/posts/essays/timelesswaybridge.png"

10−+++

11−

12−

13−

14−_A well-designed house not only fits its context well but also illuminates the problem of just what the context is, and thereby clarifies the life which it accommodates — Notes on the Synthesis of Form_

15−

16−There is an unofficial design canon at Urbit. If you were a fly on the wall, you would hear the name &quot;Christopher Alexander&quot; regularly mentioned around the office. Christopher Alexander is an architect, albeit one who isn&#39;t taught at most architecture schools. However, his work encompasses far more than what is usually understood as &quot;architecture&quot;. Alexander&#39;s work is concerned with the production of functional beauty. What&#39;s remarkable about his books is that they are not empty philosophical manifestos—Alexander gives specific, actionable guidance on creative problems. His best books are manuals for how to construct forms that are &quot;alive&quot;. Alexander threads the needle between highly specific instruction and generalized abstract concepts—his success at this task can be seen in his influence on fields outside of architecture, from computer science to network theory. In his most recent work, Alexander touches upon subjects ranging from religion to math and connects it all into a theory about how the universe functions. But people read him for less lofty reasons: to build a house that is beautiful, design a comprehensive programming language, or figure out how to approach a complex problem. In this post, I&#39;ll give an overview of Alexander&#39;s work and hear from some Urbit staff about his relevance to software development.

17−

18−Alexander&#39;s first book, _Notes on the Synthesis of Form,_ detailed a new way to approach the design process. Released in 1962, it incorporated networks, set theory, language, and math into a new method for accurately modeling and solving design problems. Although Alexander was an architect, the book was concerned with fundamental issues: how do you solve complex problems with hundreds of interconnected variables? The answer lies in decomposing the problem into subsystems and then &quot;diagramming&quot; those subsystems back into a singular integrated form. The process of decomposing a set into [highly-interconnected subsets](https://en.wikipedia.org/wiki/Community_structure) involves a significant amount of computation—Alexander wrote a computer program for the IBM 7090 mainframe which was described in his 1962 paper _HIDECS 2: A Computer Program for the Hierarchical Decomposition of a Set with an Associated Graph._ But this was only half of his design process; after the creation of subsets which are the fundamental units of the design problem, the subsets must be diagrammed. This second half of the process involves integrating and synthesizing all of the variables within a single subset into a conceptual diagram. These fundamental diagrams are then integrated and combined _themselves_ into a single diagram which is the final result of the process. The diagram below is Alexander&#39;s solution to the problem of designing a village in India with a huge number of variables and constraints.

19−

20−

21−

22−_Notes on the Synthesis of Form_ can be seen as embodying many of the tensions in 1960s America. Computers were seen as a suspicious technology which embodied the institutionalized science that created the nuclear bomb and cold war era tensions. These suspicions were understandable: computers were massive esoteric machines housed in entire rooms of university and government buildings. They were physically and mentally inaccessible to the average American citizen, while the elites who did use them were held in contempt by the populace. Student protests against being just another cog in &quot;the machine&quot; or &quot;IBM card&quot; were partly right—at this point in the early 60s, many intellectuals were interested in [cybernetics](https://en.wikipedia.org/wiki/Cybernetics:_Or_Control_and_Communication_in_the_Animal_and_the_Machine) and the [mathematical modeling of &quot;human&quot; problems](https://en.wikipedia.org/wiki/Theory_of_Games_and_Economic_Behavior) and Alexander drew from these fields frequently in his book. However, when _Notes on the Synthesis of Form_ came out in 1964 computer culture was shifting towards an alliance with the counterculture—a cultural and technological process that would culminate with these massive pieces of institutional technology becoming &quot;personal computers&quot;. He criticized those who wished to keep math and computers away from human creativity: he saw the possibility of computers yoked to creative human beings. He believed this symbiotic approach to technology was necessary—without a new approach to design, the world would continueto produce the ugliness endemic since the industrial revolution. According to Alexander, a designer could only successfully solve this problem by combining his creativity with the analytic and computational power of machines. Through his books and [presentations](https://www.youtube.com/watch?v=98LdFA-_zfA), Alexander would have a lasting impact on object-oriented programming and [pattern based thinking in software design](https://en.wikipedia.org/wiki/Design_Patterns).

23−

24−In _Notes on_ _the Synthesis of Form_ Alexander applauds the buildings and towns of many primitive societies but he notes that there is no hope of a return to this &quot;unselfconscious&quot; state. Therefore, modern people must develop a new design process to reach the same end. But what is this end that Alexander is trying to achieve? Alexander states his aim negatively in _Notes on the Synthesis of Form_ as &quot;the absence of misfits between a form and its context&quot;. An [apophatic](https://en.wikipedia.org/wiki/Apophasis) statement might be good enough for mystics but, for someone like Alexander who was concerned with precision, a positive statement was necessary. His positive statement wouldn&#39;t come until 1979 with the publication of _A Timeless Way of Building_.

25−

26−In 1975, Alexander would begin publishing his most famous book series which included _The Timeless Way of Building_ and _A Pattern Language_. In these works Alexander took a more holistic approach to creative production and placed less emphasis on design models. This new approach cemented the importance of culture as the substrate that supports a people&#39;s inherited &quot;pattern language&quot;. Just like a spoken language, a pattern language is developed incrementally over time by people who adapt to the same local environment. Alexander wrote that &quot;a pattern language gives each person who uses it, the power to create an infinite variety of new and unique buildings, just as his ordinary language gives him the power to create an infinite variety of sentences&quot;. _A Pattern Language_ is an attempt to create a new language from observing the dialects of buildings around the world. Alexander recognized that there were large-scale patterns between people and the buildings they found beautiful—a productive tension between specificity and more general patterns common to all human beings. Alexander&#39;s pattern language is therefore more general than historically generated languages. The &quot;pattern language&quot; approach is now native to many software developers: seeing solutions as complexes of layered and interconnected systems.

27−

28−_A Pattern Language_ is the book that is closest to an instruction manual. It is meant to take the prospective builder all the way through the process of designing and constructing a building, neighborhood, or city. Alexander writes about the macro-patterns of cities and the micro-patterns of buildings, from road design to doorknobs. Alexander wanted to enumerate patterns that interlock and produce beauty at different scales while still being as precise and actionable as possible. In _Notes on the Synthesis of Form_, Alexander was concerned with how to best model reality in order to solve a problem, while _A Pattern Language_ focused on the production of a vernacular that would allow people to produce beautiful buildings.

29−

30−

31−

32−Underlying these different pattern languages is a deep, precise, and objective appreciation of an important quality of human existence—what Alexander calls &quot;the quality without a name&quot;. This &quot;quality&quot; is the ultimate goal of Alexander&#39;s work. Greater efficiency and instrumentality cannot be ends in themselves. For Alexander, it is a moral imperative to save the world from ugliness and to make human culture match the natural world in beauty, complexity, and aliveness. It is described in _The Timeless Way of Building_ as &quot;the root criterion of life and spirit in a man, a town, a building, or a wilderness. This quality is objective and precise, but it cannot be named&quot;. The &quot;quality&quot; cannot be named not because it is a vague or airy concept, but because &quot;the quality is too particular, and words too broad&quot;. Nevertheless, Alexander makes an attempt to circumscribe the concept with the words alive, whole, comfortable, free, exact, egoless, eternal.

33−

34−Alexander would say that a Japanese temple and a German church are both approaching the &quot;quality&quot; from different histories and cultures. They are examples of two vernacular languages developing in parallel. The similarity between two modern cities is an example of how we&#39;ve been severed from our pattern languages and therefore the &quot;quality&quot;; we are forced to design from barren earth. Global homogeneity is a symptom of disconnect from both temporal and spatial order—it is the death of our inherited languages.

35−

36−

37−

38−_The Nature of Order_ is Alexander&#39;s most recent book series and explores the metaphysical implications of Alexander&#39;s thought. According to Alexander, the failure of the modern built world is because we have learned to view the world as fundamentally dead. Alexander makes an argument that is close to [hylozoism](https://en.wikipedia.org/wiki/Hylozoism) or [IIT](https://en.wikipedia.org/wiki/Integrated_information_theory): all structures have varying amounts of aliveness (an aspect of the &quot;quality&quot;). Because of the modern worldview that sees all structure as dead we have become blind to this deeper aspect. The basic component which makes structures alive are strong and varied centers. Furthermore there are fifteen fundamental attributes of centers which allow them to network and become alive. These fifteen abstract units are what patterns are composed of—patterns that are then woven into languages (this process of formalizing implementations as higher-level abstractions should be familiar to any computer scientist). _The Nature of Order_ is the most philosophical and [spiritual](https://www.firstthings.com/article/2016/02/making-the-garden) of Alexander&#39;s work and ties together his overarching preoccupations: how to solve complex human problems and why the task of making the world beautiful is important.

39−

40−You might be wondering how Christopher Alexander is relevant to Urbit?

41−

42−That depends on who you ask.

43−

44−**Galen (~ravmel-ropdyl)**

45−

46−> I suppose the main thing is that most designers tend to become fixated on the mechanics of what they&#39;re building. Most design theory is about how things are made, not what it&#39;s like to live inside of them or actually rely on them on a daily basis. Alexander is much more concerned with the first-person experience of inhabiting a place or a building. I guess his approach is just much more empathetic which means it&#39;s also more practical. He&#39;s concerned with _how people actually live_ and how their environment evolves alongside them.

47−>

48−> We live, work, and develop on Urbit. We&#39;re often the first people to notice bugs because we are the end users ourselves. Alexander makes the point that old buildings were responsive to feedback because the architect was also the inhabitant. This tight feedback means that the system as a whole is dynamic and alive. We want Urbit to be a house that you live in and make yours, because unlike all the other software you use, your Urbit is actually _yours_.

49−

50−**Josh (~wolref-podlex)**

51−

52−> _The Nature of Order_ has had a big influence on my thinking. At first, the idea of all physical structures being alive sounded like something out of a new age bookstore. But not only do I think that Alexander justifies this claim; it started to make intuitive sense when I looked closely at my experience.

53−>

54−> When I first read _The Nature of Order_ I was living in an industrial neighborhood of San Francisco—the scale of the buildings and streets felt inhuman and everything was made of metal, glass, and concrete. I chose to leave. I moved into a 100+ year-old flat and the difference was immediate and visceral. The space felt like it was designed from experience rather than _ex nihilo_. The apartment was meant to be lived in, surrounded by public spaces where strangers could safely spend time outdoors together.

55−>

56−> If physical objects can have the quality of &quot;aliveness&quot; so too can information objects. Alexander&#39;s book is alive. Many of the software projects I&#39;ve worked on have been cold fish. Keeping this quality in mind is an important part of my decision making. I want Urbit to be a living structure.

57−

58−**Édouard (~fabled-faster)**

59−

60−> I enjoy telling people unfamiliar with Urbit and interface design with respect to Urbit, that the object of our work is essentially that of designing an environment &quot;like a piece of paper&quot;.

61−>

62−> Consider how paper as a constrained environment is one that yet can bear nearly any visual expression imaginable—apart from containing drawings or human-made marks, paper can be used to display photographs, paper can be multiplexed to form lenticular holograms, paper can be folded into a crane, etc.

63−>

64−> The &quot;sheet of paper and its resulting forms&quot; I manifest as a design ideal here is what Alexander might refer to as a &quot;semilattice&quot;. A mathematical term he co-opted to describe an ideal structural relationship between elements in a system, as opposed to a &quot;tree&quot;, which is a top-down structural system that forces elements into rigid categorical constraints. [In his own words](https://www.patternlanguage.com/archive/cityisnotatree.html):

65−>

66−> > _For the human mind, the tree is the easiest vehicle for complex thoughts. But the city is not, cannot and must not be a tree. The city is a receptacle for life. If the receptacle severs the overlap of the strands of life within it, because it is a tree, it will be like a bowl full of razor blades on edge, ready to cut up whatever is entrusted to it. In such a receptacle life will be cut to pieces. If we make cities which are trees, they will cut our life within to pieces._

67−>

68−> A city is a good ideal to maintain for the construction of a new internet and notion of personal computing, but I&#39;ve tended towards my own interpretation of a piece of paper as a semilattice-embodying object due to its accessibility and ability to be imagined by anyone, designer or not. Our object of design is that of a receptacle of life, of deep expression, of multiplexed possibilities. When I imagine an Urbit in the not-so-distant future, I imagine it as a _method_ (to contrast against those who pin software&#39;s expression down to &quot;tools&quot; or &quot;functions&quot;) by which I can become &quot;whole&quot; again in a digital context, in all my complexity.

69−

70−Christopher Alexander wanted to collapse the distinction between those who live in buildings and those who design them. Urbit wants to do the same thing with software—in order to not produce ugliness, we should live in what we build. Although we have personal computers now, all of our data is housed in enormous warehouses that make the industrial computers of the 1950s look tiny. What we think of as “our information” actually belongs to someone else and, more often than not, is weaponized against us. Alexander’s moral imperative can be taken and applied to our digital structures. We need to become close with our software again.

content/blog/pin-the-face-that-launches-a-thousand-ships.mddeleted−146

@@ -1,146 +0,0 @@

1−+++

2−title = "Pin the Face that Launches a Thousand Ships"

3−date = "2023-04-07"

4−description = "A guest post by ~nospex-larsut"

5−[extra]

6−image = "https://storage.googleapis.com/media.urbit.org/blog/6a0120a85dcdae970b016766c94c14970b-800wi.jpg"

7−author = ""

8−ship = "~nospex-larsut"

9−+++

10−_The original article can be found [here](https://nospex-larsut.arvo.network/blog/whyhoon) using [%blog](https://urbit.org/applications/~hanrut-sillet-dachus-tiprel/blog)._

11−

12−

13−

14−## Pin the Face that Launches a Thousand Ships[^1] ##

15−_A short piece addressing some of the standard hesitations to learning Hoon, considered in light of all of the recent exciting network activity._

16−

17−### Setting The Table ###

18−One can draw many distinctions between the Urbit apps that were available this time last year and those released thus far in 2023, but the most important of these may be that the former were apps noticed and used almost exclusively by users already on Urbit, where the latter - notably Pongo, Realm, Tirell Studio, Groups 2, Portal, etc - are apps that are _creating Urbit users_.

19−

20−Prior to the start of 2023, the superficial, yet incomplete, take was something to the effect that much of Urbit’s appeal was largely an affinity with the ideas and principles surrounding the project.

21−

22−People who found their way to Urbit latched on to philosophical entry points, among them values such as calm computing, decentralized/privacy/data-ownership maximalism, or aspirations of replacing a generations-deep legacy computing system that entrenched an ethos of doing things fundamentally inefficiently & incorrectly, in ways that not only hobbled the potential of the internet, but resulted in outright harm to its users through establishing platform models and incentives that consciously sought to manipulate the behavior of those users in countless subtle and not-so-subtle ways.

23−

24−Urbit was a nexus, collecting people from disparate backgrounds & disciplines to something like a spiritual oasis, yes, though one seemingly situated a million miles from anywhere familiar to the outside world; its appeal was more a function of the shared ethos of the community and a shared sense of its potential rather than the existence of new & immediately useful alternatives for day-to-day compute tasks.

25−

26−The energy of Assembly '22 was palpaple; it almost seemed that widespread adoption was around the corner. Inevitably, some of the post-Assembly ‘22 buzz seemed to fizzle as the ensuing months went by; many ships launched during that time went dormant, wondering if the potential hinted at would materialize; the shallow criticisn/meme for getting on to Urbit became, “I’m here… um, now what.”

27−

28−This whole time though, the project was simultaneously also an incredibly busy construction site.

29−

30−Remarkably short-lived, “I’m here… um, now what?’ is unraveling with the realization that this universe has always been accelerating, and this new wave of apps establishes a very visible & powerful reference point for truly appreciating that acceleration and the distance traveled; after what seemed like a brief post-Assembly fizzle, the network is again kinetic and crackling with energy, but in reality it was never slowing down.

31−

32−The latest generation of apps marks an important shift in the trajectory of Urbit adoption. Much of this is possible thanks to the proliferation of hosting options - whether [Native Planet’s](https://nativeplanet.io/) self-hosted solutions or through turnkey models - which collectively have vastly streamlined the Urbit onboarding process such that getting on the network is no longer the equivalent of scaling a forbidding & remote mountain peak, arriving at the threshold of a silent monastery, heaving its heavy door ajar to find it seemingly abandoned only a thin sliver of light to illuminate your path, nobody there to acknowledge your arrival much less offer a tour. The thrill of having finally gotten there dampened by the increasing sense that all of its life is subterranean and the real journey is just beginning.[^2]

33−

34−Single-click onboarding and preloaded apps & groups may not seem like a lot for newcomers, but these things have increased tremendously the ability to get on Urbit compared to just six months ago.

35−

36−And just as a selection of competing hosting providers expanded the number of possible onramps, this new crop of Urbit apps likewise provides a complimentary function as entry points - hidden doors to Urbit embedded in the Apple/Android app stores - in ways that Urbit apps never enjoyed previously, all helping to further reduce the friction of onboarding by orders of magnitude. A user searching for a Telegram alternative stumbles across Pongo; new eyes find Urbit without ever intentionally seeking it out.

37−

38−The animating ideas behind the project, I think, remain as alive as ever - Urbit does not need to jockey to become the ‘current thing’ if it can much more efficiently become the undercurrent thing; without having to waste a single breath converting users at the margin on the necessity or virtue of recreating the web in a decentralized & privacy-oriented manner, new users are able to become advocates for apps that provide practical utility for day-to-day compute, creative, and communication needs - but that also happen to be built on such infrastructure. The yew tree doesn’t propagate itself by trying to convince the bird that it is desirable that there be more yew trees in the world, it just wraps its seed in a tasty & nutritious berry and lets the bird carry it off.

39−

40−Compelling apps, built on continually-improving and innovative infrastructure & development tooling is one piece of the adoption curve. These things bring users, who bring perspectives, feedback, ideas, wants, and needs. It brings their attention to earn it. If they are spending time on Urbit apps, they will also be exposed to whatever else is being shared on Urbit through those apps – what will catch their attention that maybe they are not seeing elsewhere? Suffice to say this is all basically network effects 101, so on to the question of learning Hoon.

41−

42−### Some Grains of Salt ###

43−Perhaps that was a lot of table-setting to get to the original inspiration of this piece, in which I wish to present some arguments to the standard objections or concerns that seem to arise for people thinking of learning Hoon. My aim is not to twist any arms or legs, but only to offer some considerations for those on the fence. Hopefully the preceding bit of history at least reveals some shred of the potential opportunities for Hooners (and other creatives - we absolutely need those as well).

44−

45−But first the grain of salt with which you should take the following:

46−I currently Hoon at something approximating a tenth-grade level. I am by no means a natural born developer, nor am I moving towards a dynamic career switch to full-time Urbit dev. Not by any stretch of the imagination. While I am interested in continuing to learn Hoon for a variety of reasons, none are likely to reverberate very far beyond my own ship.

47−

48−My Hoon education began in the summer/fall ’22 cohort of Hoon School Live. In my early 40’s, I walked into it slightly intimidated by its reputation, and with a personal technical background not much deeper than writing Excel formulas, a little Python, and building simple websites (like, 20 years ago). At the moment, I am much better at reading it than writing it, but thanks to HSL & ASL (and everyone involved with those efforts), it does make sense to me.

49−

50−So despite not exactly practicing what all I am about to preach, the foregoing, combined with having talked to enough people on the fence about learning Hoon, I feel somewhat qualified to at least offer some perspective for those considering the question.

51−

52−### The Standard Hesitations ###

53−The following hesitancies seem to be the recurring ones, and we’ll take them one at a time, although they share a significant degree of overlap.

54−<ol>

55−<li> But I already know languages x, y, z, etc and can build things with them now.</li>

56−<li> I hear Hoon is very difficult / weird / etc.</li>

57−<li> Urbit’s future is uncertain; investing in learning Hoon seems risky.</li>

58−<li> I don’t see many immediate jobs for Hoon devs.</li>

59−</ol>

60−

61−__Hesitancy 1: But I _already know_ languages x, y, z, etc and can build things with them _now_.__

62−

63−A valid contention in that one has invested in skills they are eager to put to use or continue to use. But can you build what you want to build - and where you want to build it? And what is the cost in terms of personal satisfaction to working on something which doesn’t truly excite you?

64−

65−There is something of the sunk-cost fallacy is at work here. It is not always a bad impulse, and opportunity costs are very real. But if there is something compelling about Urbit - and the fact that one is at least seriously considering learning Hoon suggests this is the case - and one is willing to view their existing proficiency in some other language as a demonstration of their capability to learn any programming language, then existing knowledge should not act as a barrier to pursuing new knowledge, particularly if there is a suspicion that working on Urbit may afford more intellectually stimulating and enjoyable opportunities.

66−

67−Consider also that a person working on things that truly animate them, despite maybe being relatively less experienced in the language, nonetheless has much more room to grow in a smaller pool where they may create closer connections, have more access to the perspectives of experienced devs, and get noticed for their contributions faster than those that may exist for a person working on things they are decidedly less passionate about amidst a pool of thousands.

68−

69−Yet another upside of working in Urbit is the sheer amount of projects yet to be built (not all require Hoon, btw); projects that may be intriguing to a developer but which already exist in some other language/product have yet to be built on here, and there is a need for them. The amount of still low-hanging fruit and infrastructure work remaining to be done, let alone potential app and utilities, is substantial, and this is a community that generally speaking, respects anybody who can come in and start contributing with minimal direction or permission.

70−

71−And is time spent learning Hoon really time spent not building things? Are you not building skills, reputation, friendships, problem-solving skills, camaraderie - building a better self - throughout the learning process? One can easily present the argument that the cost in this regard is much less than it may seem at first glance.

72−

73−Since one can only try to subjectively weigh the opportunities open to them with their current skills against the nebulous costs of _not_ pursuing something that has piqued their interest, the dilemma often cannot but remain unanswered until one takes the steps to find out; until then, it remains a persistent, nagging 'what if'?. It may take several months to feel really comfortable writing Hoon, but there is a relatively low cost to spending a few weeks to dive in and see if one has an aptitude or affinity for it.

74−

75−__Hesitancy 2: Hoon is difficult and/or weird.__

76−

77−Recognizing that there are a lot of runes, and that Hoon is odd compared to other languages,

78−

79−- learning just a handful[^3] of them along with the basic families (create cores with | runes, call functions with % runes, conditionals statements are built with ? runes, etc) will get one well on their way. </li>

80−- if Hoon is not your first language, you have already demonstrated a capacity for becoming comfortable working within a framework of structure and syntax that was, relative to your previous inexperience, alien and weird. And while there are additional wrinkles in dealing with a functional language, the majority of CS concepts remain relevant and are transferable.

81−

82−And if Hoon is your first language, it is all uncharted territory anyway and not having anything to compare it to means one is essentially in the same situation as in learning any new language, and in that respect it mirrors almost any endeavor to grasp new modes of problem-solving under a unique set of conditions and constraints. Even if you do not stick with Hoon, the new perspectives in problem-solving experience are valuable, and most of the fundamental concepts will be transferable to other languages.

83−

84−You might also consider how to use Hoon’s reputation for difficulty to your advantage from the standpoint that, if you are firmly convinced that it is or will be unduly difficult, then that should yield a much deeper satisfaction after proving you are in fact capable of learning it.

85−

86−And from a more opportunistic standpoint, realize that others who allow this reputation to dissuade them create outsized opportunities for those who are willing to learn it. One can very usefully calibrate expectations here to use the reputation to provide some cover - if it really is that hard, iit is ok to not get it at first, and you can succeed where others gave up or failed to even try.

87−

88−Speaking from my own experience, the sheer amount of terminology was somewhat overwhelming at first, and this was true of both HSL & ASL (more so the latter, IMO). Many of the names seem arbitrary, but like anything, making it familiar is largely a function of effort.

89−

90−Recognize that Hoon's unique syntax and functional paradigm are integral to its design and purpose. Instead of trying to force parallels between Hoon and other languages or concepts you already know, just immerse yourself in it with an open mind and willingness to grasp its distinct features and the reasoning behind them.

91−

92−<div class="polaroid">

93− <img src="https://storage.googleapis.com/media.urbit.org/docs/userspace/hoon-school/binary-tree-bottom-row-full.png" alt="Tree">

94− <div class="container">

95−

96− <p>See - it's easy!</p>

97− </div>

98−</div>

99−

100−__Hesitancy 3: Urbit’s future is uncertain; investing in learning Hoon seems risky.__

101−

102−Much of the table-setting for this piece was an attempt to frame the potential opportunity for devs of any level. Keeping things in perspective, Urbit is just about to hit [3,000 active ships](https://twitter.com/urbitfoundation/status/1637931937351491584). There are several reasons why recent activity may be much more indicative of even greater future growth than one might assume from looking at the chart:

103−<ul>

104−<li>a. Maybe very obviously, the growth of the last three months is not simply a 1:1 reflection of the work of the last three months, but of the many preceding years of core development that made a significant increase in percentage terms within a very short interval possible. The stage is set for much faster growth.</li>

105−<li>b. Previously mentioned, but all these threads are interconnected in that, the more eyes on Urbit, the more ideas, talent and additional users will be introduced to, and recognize the depth, of the opportunity here. A steadily stabilizing building environment (thanks to a)) that attracts and can support more users should continue to build momentum. </li>

106−</ul>

107−

108−Remaining sober about reality, 3,000 users is not exactly a ton in web 2 terms; for Urbit, it is simultaneously very many and very little. But with better apps providing more reasons to be on Urbit, working in unison with better UX and onboarding, those users have more reason to stay engaged with Urbit once they are on, which means anything an aspiring Hooner or creator can think of to give them compelling reasons to make them even more engaged is an opportunity.

109−

110−Deliberately twisting the fomo screws a little, it is as true for learning Hoon as it is of anything else that the more widely adopted a platform or language becomes, the safer a bet it will be in terms of stability and longevity. With the accretion of that stability however, the window for realizing the benefits of gaining early experience and exposure in a less-crowded space diminishes accordingly as the sense of perceived riskiness in staking ground there decreases. Like any investment, uncertaintly about the future carries the gift of a difficult to quantity but very real species of camaraderie, credibility, and respect that is only available to those willing to get involved at early stages, and which is lost as the project starts to look increasingly like a 'sure thing.' Hard to value, but weigh that aspect when considering if one should begin learning now or wait until things look ‘slightly more certain’ - what is the bar for this certainty? What is ‘certain enough’?

111−

112−Urbit, by (beautiful) design, is a very low-time preference project in some respects, but it is growing quickly. And the longer you’ve been watching Urbit grow, the more perspective you have of how much can happen in a very short time.

113−

114−When there are 10,000, 100,000 active ships it will be a trip in itself to remember that you started learning Hoon back when there were "only" 3,000, and contributed in maybe some non-trivial way to attract some quantity of new ones by building something you were excited about building.

115−

116−__Hesitancy 4: I don’t see many immediate jobs for Hoon devs.__

117−

118−_Not yet you don’t_. Much of the response to Objection 3 is also relevant here.

119−

120−The pool of Urbit companies is not fixed. It is not an insurmountable obstacle to start up a small-scale dev shop with a handful of talented devs.

121−Money flowing into Urbit is being reported with increasing frequency, and this is only the incoming money that you _hear about_. As Urbit grows, money will chase money, bringing more jobs and more opportunities. For better, or worse, of course, money changes things - more money will necessarily mean more discipline, more focus on shipping product, etc. But not having money changes things too. Money comes here in no small part because it sees the energy and intensity with which this community has been building out Urbit - regardless of whether money was flowing in or out of it - it attracted devs because the project itself was an ambitious worthwhile good in itself.

122−

123−There is much opportunity here for bright, motivated developers willing to make the effort to learn. One only has to bump the total current dev headcounts up against the growing momentum of the project to see the opportunity, whether it be in core projects, apps, or novel pairings with creators to determine ways to distribute and produce content on Urbit. The speed of deployment on Urbit compared to other projects and relative exposure to other platforms affords a significant advantage to motivated, talented people in terms of visibility - when an app gets published on Urbit, everyone sees it.

124−

125−### Wrapping Up ###

126−Hopefully the above provides some perspetive on reframing some of the standard hesitancies. None of them are irrational. However, if none of the above sways you, ask what projects or features might materialize on Urbit that would make you wish you started learning Hoon a year ago (which, in the grand scheme, would make you a reasonably well-experienced Hooner) and then consider that you could wait for that thing to materialize, or play an active part in making it a reality that will attract many other users to the network, along with making others feel like they should have started learning Hoon a year ago.

127−

128−And if the Hoon question is indeed a recurrent & nagging one, attempt to replace it with the question, “two months from now (approximately the duration of an HSL cohort), would I rather have tried learning Hoon and discovered that I don’t like it and be done with the question, or still be sitting here wondering if I should learn Hoon?”

129−

130−The resources for learning Hoon are growing:<br>

131−● [Hoon School Live](https://developers.urbit.org/courses/hsl)<br>

132−● [App School Live](https://developers.urbit.org/courses/asl) <br>

133−● [App Workshop Live](https://developers.urbit.org/courses/awl) <br>

134−● An upcoming [Core Dev course](https://developers.urbit.org/courses/csl)<br>

135−● The growing corpus of [documentation](https://developers.urbit.org/reference/hoon/overview)<br>

136−● And of course the most valuable resource of all is all the people on the network who are willing to answer questions and help one learn. Find them in the Hacker House.

137−<p>

138−

139−If something about Urbit is drawing you toward it, if the project resonates with you in a way that other things in tech do not - if you are truly intrigued by it and want to be here - it is reasonable to assert that the process of learning Hoon is not simply a tax with questionable upside, but a productive process in and of itself; that the very process of learning it will embed you deeper into a space you want to be in.

140−

141−So learn Hoon. Not only is it fun, but as an Urbiter, it is something of a cultural heritage, and the conduit between reality and whatever your endless imagination conceives Urbit’s potential to be - space here is wide open, and any of today’s aspiring Hooners has the potential to pin the face that launches a thousand ships.

142−

143−----------------

144−[^1]: To 'pin a face' is to declare a variable in Hoon.

145−[^2]: Maybe some slight dramatization; this aspect also made it fun for those not in need of immediate gratification.

146−[^3]: [See 'Rune Utilization in Hoon'](https://developers.urbit.org/blog/rune-frequency-202212)

content/blog/pki-maze.md+16−12

@@ -1,8 +1,7 @@

1+++

1+++

2title = "Designing a Permanent Personal Identity"

2title = "Designing a Permanent Personal Identity"

3−date = "2019-11-26"

3+date = 2019-11-27

4description = "A public key infrastructure (PKI) is a system for binding a set of keys to a name. Sometimes a small amount of metadata is included."

4description = "A public key infrastructure (PKI) is a system for binding a set of keys to a name. Sometimes a small amount of metadata is included."

5−

6[extra]

5[extra]

7author = "Philip Monk"

6author = "Philip Monk"

8ship = "~wicdev-wisryt"

7ship = "~wicdev-wisryt"

@@ -27,7 +26,7 @@ This is our first stop in the idea maze. We call this sort of name a "comet". A

27

26

28However, Urbit is yours and it's forever. You shouldn't have to change your name every time you change your keys. So, we go back and take the other choice: you must be able to change your keys.

27However, Urbit is yours and it's forever. You shouldn't have to change your name every time you change your keys. So, we go back and take the other choice: you must be able to change your keys.

29

28

30−To change keys, you must sign a message with the old keys revoking them and supplying the new ones[^1]. The question is what happens if the old keys also sign a second set of new keys. This could happen if an attacker obtained your old keys after the fact. This is important because one of the reasons to be able to change your keys is to invalidate the old ones so that they have no power.

29+To change keys, you must sign a message with the old keys revoking them and supplying the new ones[^0]. The question is what happens if the old keys also sign a second set of new keys. This could happen if an attacker obtained your old keys after the fact. This is important because one of the reasons to be able to change your keys is to invalidate the old ones so that they have no power.

31

30

32We have two options again: the PKI may be globally consistent or not. To be globally consistent means that if you believe a name is bound to a set of keys, then nobody on the network will disagree.

31We have two options again: the PKI may be globally consistent or not. To be globally consistent means that if you believe a name is bound to a set of keys, then nobody on the network will disagree.

33

32

@@ -37,13 +36,13 @@ For a globally consistent PKI that allows you to revoke keys, you need to be abl

37

36

38However, the problem of proving one message was sent before any later ones inverts the problem. You can solve this with newspapers by placing the message in the text of the newspaper. However, while reading a newspaper requires no central party, writing one does. For a long time, this sort of message was always handled by a central party. SSL revocations are managed by a few central parties. When you buy property, it's not sufficient to have the previous owner sign the title — this must be entered into a central land registry. Otherwise, the owner may sell their property to multiple people and there would be no way to determine who is the new owner. With the land registry, all you need to do is ask the registry which sale happened first, and that's the one that counts.

37However, the problem of proving one message was sent before any later ones inverts the problem. You can solve this with newspapers by placing the message in the text of the newspaper. However, while reading a newspaper requires no central party, writing one does. For a long time, this sort of message was always handled by a central party. SSL revocations are managed by a few central parties. When you buy property, it's not sufficient to have the previous owner sign the title — this must be entered into a central land registry. Otherwise, the owner may sell their property to multiple people and there would be no way to determine who is the new owner. With the land registry, all you need to do is ask the registry which sale happened first, and that's the one that counts.

39

38

40−However, Urbit is yours and it's forever. Trusting central registries jeopardizes both. The keen reader will notice that the problem of determining which key rotation happened first is exactly the double-spend problem that Satoshi solved with his proof of work algorithm for Bitcoin. His first block famously includes a newspaper headline to prove he didn't mine the block before that date. In a beautiful duality, his own algorithm proves that he didn't mine it after that date.[^2]

39+However, Urbit is yours and it's forever. Trusting central registries jeopardizes both. The keen reader will notice that the problem of determining which key rotation happened first is exactly the double-spend problem that Satoshi solved with his proof of work algorithm for Bitcoin. His first block famously includes a newspaper headline to prove he didn't mine the block before that date. In a beautiful duality, his own algorithm proves that he didn't mine it after that date.[^1]

41

40

42Some argue that blockchain is only good for money. This is myopic and is generally based on the experience that its most valuable application so far has been money. However, blockchain is a cryptographic primitive to do what was previously impossible: prove that one message was signed before another without a central party. Blockchain was discovered by someone trying to create digital money, and he needed that primitive, but that doesn't mean that's all it's good for.

41Some argue that blockchain is only good for money. This is myopic and is generally based on the experience that its most valuable application so far has been money. However, blockchain is a cryptographic primitive to do what was previously impossible: prove that one message was signed before another without a central party. Blockchain was discovered by someone trying to create digital money, and he needed that primitive, but that doesn't mean that's all it's good for.

43

42

44−Thus, we store our PKI data on a blockchain for our second kind of name: planets. A planet is a 32-bit address which has key information stored on the blockchain.[^3] The owner of a planet may broadcast new PKI data by adding it to the blockchain. Any later messages by the old keys will be rejected, and everyone on the network will listen to the blockchain for key data. Thus, we have global consistency, permanence, and self sovereignty. We know of no other solution that can provide these properties.

43+Thus, we store our PKI data on a blockchain for our second kind of name: planets. A planet is a 32-bit address which has key information stored on the blockchain.[^2] The owner of a planet may broadcast new PKI data by adding it to the blockchain. Any later messages by the old keys will be rejected, and everyone on the network will listen to the blockchain for key data. Thus, we have global consistency, permanence, and self sovereignty. We know of no other solution that can provide these properties.

45

44

46−However, while small individually, the aggregate PKI data for all nodes on the network may become very large. This is not an issue for comets because nobody needs to store comet keys except for those which they're talking with, and even those can be garbage-collected and re-requested and verified. For planets, there is a canonical set of keys, and somebody must store that. There are about 2^32^, or 4 billion planets. If the PKI data is about 100 bytes for each planet, this is about 400 GB of data. This may be more than most users wish to store, but it's small enough that it would be very cheap for someone to host this data for many users[^4].

45+However, while small individually, the aggregate PKI data for all nodes on the network may become very large. This is not an issue for comets because nobody needs to store comet keys except for those which they're talking with, and even those can be garbage-collected and re-requested and verified. For planets, there is a canonical set of keys, and somebody must store that. There are about 2³², or 4 billion planets. If the PKI data is about 100 bytes for each planet, this is about 400 GB of data. This may be more than most users wish to store, but it's small enough that it would be very cheap for someone to host this data for many users[^3].

47

46

48This information is currently stored directly on the Ethereum 1.0 blockchain, but as is well understood in blockchain circles this approach will not scale beyond a certain point. Many chains are pursing designs that allow the users of the smart contracts to store locally the data associated with the contracts they care about and only commit hashes to the chain. We expect there to be several viable options for this by the time our scaling needs exceed what's provided by Ethereum 1.0. This will free us from the cost of hosting the PKI data on all Ethereum nodes, but the data must still be stored somewhere. Any service that could handle such a large amount of data would inherently centralize the network.

47This information is currently stored directly on the Ethereum 1.0 blockchain, but as is well understood in blockchain circles this approach will not scale beyond a certain point. Many chains are pursing designs that allow the users of the smart contracts to store locally the data associated with the contracts they care about and only commit hashes to the chain. We expect there to be several viable options for this by the time our scaling needs exceed what's provided by Ethereum 1.0. This will free us from the cost of hosting the PKI data on all Ethereum nodes, but the data must still be stored somewhere. Any service that could handle such a large amount of data would inherently centralize the network.

49

48

@@ -61,10 +60,15 @@ To create a sane network, we require global consistency for all our names. There

61

60

62- Moons are permanent, not self sovereign, and plentiful.

61- Moons are permanent, not self sovereign, and plentiful.

63

62

64−Fancifully, comets are wayward celestial bodies that are great for testing and miscellaneous low-value things that won't last for long. Planets are where you can build a home and shape it into anything you want it to be. People can always find your planet; it's not going anywhere. Moons are useful for special purposes, like storage, heavy industry, and anything else you might want to do off-planet.[^5]

63+Fancifully, comets are wayward celestial bodies that are great for testing and miscellaneous low-value things that won't last for long. Planets are where you can build a home and shape it into anything you want it to be. People can always find your planet; it's not going anywhere. Moons are useful for special purposes, like storage, heavy industry, and anything else you might want to do off-planet.[^4]

64+

65+

66+[^0]: Or the equivalent with a hierarchical key structure. In practice, you want to have a master key which signs a junior key for everyday use. You use the master key to rotate the junior key.

67+

68+[^1]: More strictly: it proves that he didn't mine it after the other blocks currently on the Bitcoin blockchain. It only gives an ordering within the chain, not a literal timestamp.

69+

70+[^2]: In addition to planets, there are stars and galaxies. From a PKI perspective they're treated exactly like planets, but on the network they provide infrastructure services like routing.

71+

72+[^3]: In practice, this will likely be an included service by your sponsoring star. It could be a separate service, but it will be very cheap because it's a commodity and the "cost of production" is very cheap. At any rate, it should never rise above the capital cost of a 400GB hard drive.

65

73

66−[^1]: Or the equivalent with a hierarchical key structure. In practice, you want to have a master key which signs a junior key for everyday use. You use the master key to rotate the junior key.

67−[^2]: More strictly: it proves that he didn't mine it after the other blocks currently on the Bitcoin blockchain. It only gives an ordering within the chain, not a literal timestamp.

68−[^3]: In addition to planets, there are stars and galaxies. From a PKI perspective they're treated exactly like planets, but on the network they provide infrastructure services like routing.

69−[^4]: In practice, this will likely be an included service by your sponsoring star. It could be a separate service, but it will be very cheap because it's a commodity and the "cost of production" is very cheap. At any rate, it should never rise above the capital cost of a 400GB hard drive.

70−[^5]: To extend the metaphor, stars are a neighborhood to live in -- they're easier for other planets to see, so when they want to send you a message they look for your star first. If they don't even know where your star is, they can certainly find your star's galaxy, and that will be enough to locate the star. Of course, if your star is not providing satisfactory service, you can take your planet and move to another star.

74+[^4]: To extend the metaphor, stars are a neighborhood to live in -- they're easier for other planets to see, so when they want to send you a message they look for your star first. If they don't even know where your star is, they can certainly find your star's galaxy, and that will be enough to locate the star. Of course, if your star is not providing satisfactory service, you can take your planet and move to another star.

content/blog/platform-decay.md+6−5

@@ -1,15 +1,16 @@

1+++

1+++

2title = "Platform Decay, Decentralized Marketplaces, and Urbit"

2title = "Platform Decay, Decentralized Marketplaces, and Urbit"

3−date = "2020-05-07"

3+date = 2020-05-08

4description = "Urbit is calm computing. Calm commerce follows naturally. "

4description = "Urbit is calm computing. Calm commerce follows naturally. "

5−

6[extra]

5[extra]

7author = "Nicholas Simmons"

6author = "Nicholas Simmons"

8ship = "~simfur-ritwed"

7ship = "~simfur-ritwed"

9−image = "https://media.urbit.org/site/posts/essays/platform-decay-preview.png"

8+image ="https://media.urbit.org/site/posts/essays/platform-decay-preview.png"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/platform-decay.png">

13

14

14## Platform decay, decentralized marketplaces, and Urbit

15## Platform decay, decentralized marketplaces, and Urbit

15

16

@@ -35,7 +36,7 @@ Even more subtle and worrying effects come when e-commerce platforms realize tha

35

36

36The manufacturing of consumer desire in this way feels creepy. It’s frustrating to have your tastes dictated to you by whoever has the biggest ad spend. It also spells the end of small business on the Internet—you can spend years mastering knowledge of a profitable niche, but if Amazon profiles your customers and decides they’re more likely to spend their money on the latest Pixar DVD, your listings will be shoved below the fold. Pixar paid for placement and you didn’t; the Pixar ad placement deal made a splash in the quarterly report, your fees didn’t. In cultural terms, this threatens to create a winner-take-all situation that will prevent new and niche artists and thinkers from gaining attention at the expense of explicitly placed, ‘premium’ content.

37The manufacturing of consumer desire in this way feels creepy. It’s frustrating to have your tastes dictated to you by whoever has the biggest ad spend. It also spells the end of small business on the Internet—you can spend years mastering knowledge of a profitable niche, but if Amazon profiles your customers and decides they’re more likely to spend their money on the latest Pixar DVD, your listings will be shoved below the fold. Pixar paid for placement and you didn’t; the Pixar ad placement deal made a splash in the quarterly report, your fees didn’t. In cultural terms, this threatens to create a winner-take-all situation that will prevent new and niche artists and thinkers from gaining attention at the expense of explicitly placed, ‘premium’ content.

37

38

38−Again, this is all accelerated by the way that ad sales function; platforms like broadly popular content and products because the larger number of customers searching for and purchasing them creates more granular data and increased opportunities for micro-targeting ads. This incentive leads to the increasing invisibility of long-tail, niche content or products whose appeal has less to do with lowest-common-denominator addictive virality, whether it’s the repair manual for your ‘85 Toyota or a copy of Plato’s _Republic_. It also accelerates the stampede toward a ‘sharing’ and ‘renting’ economy; when ad impressions are a sizable part of company revenue, forcing customers to return to ad-infested platforms to continue renting objects or content, rather than making one-time purchases, is a no-brainer.

39+Again, this is all accelerated by the way that ad sales function; platforms like broadly popular content and products because the larger number of customers searching for and purchasing them creates more granular data and increased opportunities for micro-targeting ads. This incentive leads to the increasing invisibility of long-tail, niche content or products whose appeal has less to do with lowest-common-denominator addictive virality, whether it’s the repair manual for your ‘85 Toyota or a copy of Plato’s *Republic*. It also accelerates the stampede toward a ‘sharing’ and ‘renting’ economy; when ad impressions are a sizable part of company revenue, forcing customers to return to ad-infested platforms to continue renting objects or content, rather than making one-time purchases, is a no-brainer.

39

40

40There’s a nightmare scenario here, a kind of hybrid, zombie brainchild of Jean Baudrillard’s concerns about the simulation of common meaning and Peter Thiel’s arguments about the stealthy hollowing-out of industrial capacity. In this nightmare future, financial and legal regulation strangle the viability of anything like a real industry, and we’re left with a handful of incumbent platforms which have concluded that the smartest move is to just sell vaporware ‘content,’ collectible bobbleheads, and sugar water. The supposed niche of any platform business is academic at this level; Amazon, Spotify, and Patreon are simply machines for converting user attention into the highest-margin purchases possible. The ‘high-velocity trash economy’ (h/t Pierre Rochard) increasingly shows itself as a network of funnels by which insider prognostications about government and central bank policy are turned into profits, with the illusion of productive activity serving only as window dressing. This deforming process extends all the way down to the vagaries of the consumer economy. If there is no financial reason for available consumer offerings to be anything we actually need, they can and will be deprecated and displaced; useful goods and services will be sidelined by literal trash that has the ‘financial’ logic of maintaining an unbroken, upward metric by virtue of direct parasitism upon the human brainstem.

41There’s a nightmare scenario here, a kind of hybrid, zombie brainchild of Jean Baudrillard’s concerns about the simulation of common meaning and Peter Thiel’s arguments about the stealthy hollowing-out of industrial capacity. In this nightmare future, financial and legal regulation strangle the viability of anything like a real industry, and we’re left with a handful of incumbent platforms which have concluded that the smartest move is to just sell vaporware ‘content,’ collectible bobbleheads, and sugar water. The supposed niche of any platform business is academic at this level; Amazon, Spotify, and Patreon are simply machines for converting user attention into the highest-margin purchases possible. The ‘high-velocity trash economy’ (h/t Pierre Rochard) increasingly shows itself as a network of funnels by which insider prognostications about government and central bank policy are turned into profits, with the illusion of productive activity serving only as window dressing. This deforming process extends all the way down to the vagaries of the consumer economy. If there is no financial reason for available consumer offerings to be anything we actually need, they can and will be deprecated and displaced; useful goods and services will be sidelined by literal trash that has the ‘financial’ logic of maintaining an unbroken, upward metric by virtue of direct parasitism upon the human brainstem.

41

42

content/blog/precepts-discussion.md+67−55

@@ -1,15 +1,16 @@

1+++

1+++

2title = "Precepts: Discussion"

2title = "Precepts: Discussion"

3−date = "2020-03-17"

3+date = 2020-03-18

4description = "The precepts aren’t arguments. We discuss and justify them here."

4description = "The precepts aren’t arguments. We discuss and justify them here."

5−

6[extra]

5[extra]

7author = "Philip Monk"

6author = "Philip Monk"

8ship = "~wicdev-wisryt"

7ship = "~wicdev-wisryt"

9−image = "https://media.urbit.org/site/posts/essays/discuss-01.jpg"

8+image ="https://media.urbit.org/site/posts/essays/discuss-01.jpg"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/discuss-01.jpg">

13

14

14The precepts aren’t arguments. We will discuss and justify them here. We don't expect to convince you this is exactly the right set of precepts, but we hope to convince you that this is a coherent set of precepts that might lead to something very interesting.

15The precepts aren’t arguments. We will discuss and justify them here. We don't expect to convince you this is exactly the right set of precepts, but we hope to convince you that this is a coherent set of precepts that might lead to something very interesting.

15

16

@@ -34,7 +35,9 @@ We will address these in the same categories presented above:

34- F: Real Software. Not all software matters. Any software which

35- F: Real Software. Not all software matters. Any software which

35 wouldn't exist on Mars isn't real.

36 wouldn't exist on Mars isn't real.

36

37

38+<br>

39+

37−

40+<img class="ba" src="https://media.urbit.org/site/posts/essays/discuss-02.jpg">

38

41

39### A: General Design

42### A: General Design

40

43

@@ -83,7 +86,7 @@ Some examples of things that are objectively quite simple but subjectively hard

83 more obvious in retrospect than it does on first glance.

86 more obvious in retrospect than it does on first glance.

84

87

85- Any language that induces a moment where you exclaim to yourself,

88- Any language that induces a moment where you exclaim to yourself,

86− "This is true programming! Everyone should program this way, it's so

89+ "This is true programming! Everyone should program this way, it's so

87 obviously better!". People say that often about Lisp, Haskell,

90 obviously better!". People say that often about Lisp, Haskell,

88 Prolog, and Smalltalk. Nobody ever said that about C, Java,

91 Prolog, and Smalltalk. Nobody ever said that about C, Java,

89 Javascript, or Python. And yet, which ones are easier to learn?

92 Javascript, or Python. And yet, which ones are easier to learn?

@@ -237,7 +240,7 @@ strong guarantees on top of something with weak guarantees — for

237example, delivery guarantees on top of an unreliable transport protocol.

240example, delivery guarantees on top of an unreliable transport protocol.

238In that case, you are sure of the underlying system, it's just that what

241In that case, you are sure of the underlying system, it's just that what

239you're sure of is that you can't rely on it delivering packets in order

242you're sure of is that you can't rely on it delivering packets in order

240−or at all. So, you formalize what you _are_ sure of, which is that it

243+or at all. So, you formalize what you *are* sure of, which is that it

241will eventually get your packets through if you keep sending them

244will eventually get your packets through if you keep sending them

242forever. And that's something you can build on.

245forever. And that's something you can build on.

243

246

@@ -351,7 +354,9 @@ An example of the second is "security through obscurity is ineffective". Securit

351

354

352However, it's important for whoever's coming up with the cliches to understand the specifics of how they're untruthful. Some of these very precepts may fall under the category of "literally untrue but more useful than the truth".

355However, it's important for whoever's coming up with the cliches to understand the specifics of how they're untruthful. Some of these very precepts may fall under the category of "literally untrue but more useful than the truth".

353

356

357+<br>

358+

354−

359+<img class="ba" src="https://media.urbit.org/site/posts/essays/discuss-03.jpg">

355

360

356## B: Specific Design

361## B: Specific Design

357

362

@@ -359,7 +364,7 @@ There are some principles that aren't obviously better than the alternatives, bu

359

364

360> B1: Always ack a dupe; never ack an ack.

365> B1: Always ack a dupe; never ack an ack.

361>

366>

362−> It's okay to ack a nack as long as you never nack a nack.

367+> It's okay to ack a nack as long as you never nack a nack.

363

368

364This is a simple rule, and if you follow it you get various guarantees for free. For example, sending a message will always cause up to a constant number of additional messages to be sent by direct or indirect causality (other than application-level code), so you never have to worry about accidentally causing a loop.

369This is a simple rule, and if you follow it you get various guarantees for free. For example, sending a message will always cause up to a constant number of additional messages to be sent by direct or indirect causality (other than application-level code), so you never have to worry about accidentally causing a loop.

365

370

@@ -409,28 +414,30 @@ Memory access restrictions are blunt tools. Blunt tools are nice in simple syste

409

414

410Better to define rules in a more powerful language. This allows you to follow A6 and A8. It also lets you use all the correctness tools, like type systems, that you've developed for the rest of your code.

415Better to define rules in a more powerful language. This allows you to follow A6 and A8. It also lets you use all the correctness tools, like type systems, that you've developed for the rest of your code.

411

416

417+<br>

418+

412−

419+<img class="ba" src="https://media.urbit.org/site/posts/essays/discuss-04.jpg">

413

420

414### C: Attitude

421### C: Attitude

415

422

416Good code is the result of people approaching the act of engineering with the right attitude.

423Good code is the result of people approaching the act of engineering with the right attitude.

417

424

418> C1: Code courageously.

425> C1: Code courageously.

419−

426+

420−If you avoid changing a section of code for fear of awakening the

427+ If you avoid changing a section of code for fear of awakening the

421−demons therein, you are living in fear. If you stay in the

428+ demons therein, you are living in fear. If you stay in the

422−comfortable confines of the small section of the code you wrote or

429+ comfortable confines of the small section of the code you wrote or

423−know well, you will never write legendary code. All code was

430+ know well, you will never write legendary code. All code was

424−written by humans and can be mastered by humans.

431+ written by humans and can be mastered by humans.

425−

432+

426−It's natural to feel fear of code; however, you must act as though

433+ It's natural to feel fear of code; however, you must act as though

427−you are able to master and change any part of it. To code

434+ you are able to master and change any part of it. To code

428−courageously is to walk into any abyss, bring light, and make it

435+ courageously is to walk into any abyss, bring light, and make it

429−right.

436+ right.

430

437

431The unix/internet stack is a giant ball of mud. It's so big that when you're standing on it, it looks like a bog, and it's not clear that there is a bottom to it. You know there must be, but it doesn't matter because you learned long ago that the best solution is to not dig too deep. Build a strong structure by spreading out your weight and using strong construction materials. If there's something useful deep in the mud, it's probably not worth diving in to pull it out. That's dangerous and prone to failure, and you know many people who have gotten stuck down there.

438The unix/internet stack is a giant ball of mud. It's so big that when you're standing on it, it looks like a bog, and it's not clear that there is a bottom to it. You know there must be, but it doesn't matter because you learned long ago that the best solution is to not dig too deep. Build a strong structure by spreading out your weight and using strong construction materials. If there's something useful deep in the mud, it's probably not worth diving in to pull it out. That's dangerous and prone to failure, and you know many people who have gotten stuck down there.

432

439

433−This is an appropriate reaction to the unix/internet stack. It's also self-perpetuating. The bog is filled — even _composed_ of — countless predecessors who did that same thing. If you ever find yourself on solid ground, protect that with your life. Learn how it works and how to use it well. Then build a strong structure on top of that. Don't let it decompose into a layer of mud.

440+This is an appropriate reaction to the unix/internet stack. It's also self-perpetuating. The bog is filled — even *composed* of — countless predecessors who did that same thing. If you ever find yourself on solid ground, protect that with your life. Learn how it works and how to use it well. Then build a strong structure on top of that. Don't let it decompose into a layer of mud.

434

441

435Urbit is small enough that, while there's definitely some construction-related dirt and muck covering it, the solid metallic core is not very deep — not more than waist deep in most places. The feeling of always being in contact with the bottom is very different than flailing about in a bog.

442Urbit is small enough that, while there's definitely some construction-related dirt and muck covering it, the solid metallic core is not very deep — not more than waist deep in most places. The feeling of always being in contact with the bottom is very different than flailing about in a bog.

436

443

@@ -444,11 +451,11 @@ follow conventions, and fire anyone who won't. Anything that can

444be solved by discipline is not a real problem.

451be solved by discipline is not a real problem.

445

452

446> "To him who knows to do good and does not do it, to him it is

453> "To him who knows to do good and does not do it, to him it is

447−> sin."

454+sin."

448

455

449Preserving the property of solid ground requires perpetual discipline. Once lost, it's often impossible to reacquire. Don't compromise your standards.

456Preserving the property of solid ground requires perpetual discipline. Once lost, it's often impossible to reacquire. Don't compromise your standards.

450

457

451−Call people out when they're being lazy. And when someone calls you out, recognize it and fix it. Sometimes it's just a question on a code review — "why did you do it this way?" Upon reflection, you determine that you did it that way because you couldn't be bothered to do it right. Maybe that was a reasonable choice at the time you were coding so you wouldn't be distracted, but if it's been called out in a code review, now's the time to fix it, not make excuses.

458+Call people out when they're being lazy. And when someone calls you out, recognize it and fix it. Sometimes it's just a question on a code review — "why did you do it this way?" Upon reflection, you determine that you did it that way because you couldn't be bothered to do it right. Maybe that was a reasonable choice at the time you were coding so you wouldn't be distracted, but if it's been called out in a code review, now's the time to fix it, not make excuses.

452

459

453> C3: When a smart person makes an obviously stupid suggestion, before

460> C3: When a smart person makes an obviously stupid suggestion, before

454> responding take a full 60 seconds to envision how you would implement

461> responding take a full 60 seconds to envision how you would implement

@@ -457,10 +464,12 @@ Call people out when they're being lazy. And when someone calls you out, recogni

457Once you've determined that someone understands a situation well, if they earnestly make a suggestion that you haven't thought of, or that you immediately dismissed as impractical, stop and consciously consider it. This is one of the best ways of countering the natural echo chamber

464Once you've determined that someone understands a situation well, if they earnestly make a suggestion that you haven't thought of, or that you immediately dismissed as impractical, stop and consciously consider it. This is one of the best ways of countering the natural echo chamber

458of your own mind.

465of your own mind.

459

466

460−This is also one of the best ways to build stuff correctly. Very often, you will be tempted to cut a corner, and someone will point out that it should be done correctly. You should consider why you immediately rejected it. Was it because you were afraid of the relevant piece of code? If so, you should learn more about that code to determine if it's actually a good idea. Did you reject it because you felt it would distract you from working on what you thought was more important?

467+This is also one of the best ways to build stuff correctly. Very often, you will be tempted to cut a corner, and someone will point out that it should be done correctly. You should consider why you immediately rejected it. Was it because you were afraid of the relevant piece of code? If so, you should learn more about that code to determine if it's actually a good idea. Did you reject it because you felt it would distract you from working on what you thought was more important?

461Consider carefully whether this particular piece of technical debt is worth taking on. It's worth 60 seconds of thinking about how you could solve it correctly right now — often it would be quite easy to do correctly and you'd be paying interest on the incorrectness for a long time.

468Consider carefully whether this particular piece of technical debt is worth taking on. It's worth 60 seconds of thinking about how you could solve it correctly right now — often it would be quite easy to do correctly and you'd be paying interest on the incorrectness for a long time.

462

469

470+<br>

471+

463−

472+<img class="ba" src="https://media.urbit.org/site/posts/essays/discuss-05.jpg">

464

473

465### D: Theory

474### D: Theory

466

475

@@ -501,7 +510,9 @@ objective properties and your subjective judgment of the quality of the system.

501

510

502However, that explanatory power is indeed powerful, and the exploratory suggestions are often able to break you out of a rut (attractor basin). Respect the tension.

511However, that explanatory power is indeed powerful, and the exploratory suggestions are often able to break you out of a rut (attractor basin). Respect the tension.

503

512

504−

513+<img class="ba" src="https://media.urbit.org/site/posts/essays/discuss-06.jpg">

514+

515+<br>

505

516

506### E: Text Style

517### E: Text Style

507

518

@@ -530,7 +541,7 @@ Some of these are strongly affected by workflows. We can't force a developer to

530

541

531One of the primary inputs to code navigability is how much of it you can have on your screen. Code that is too wide limits the number of columns of code. Some people keep only one column on their screen, so they don't see a problem with long lines of code. The most efficient navigation is to already be there (i.e. to only have to move your eyes). If you only have one column of code open, you can only be in one place, which eliminates the best form of navigation.

542One of the primary inputs to code navigability is how much of it you can have on your screen. Code that is too wide limits the number of columns of code. Some people keep only one column on their screen, so they don't see a problem with long lines of code. The most efficient navigation is to already be there (i.e. to only have to move your eyes). If you only have one column of code open, you can only be in one place, which eliminates the best form of navigation.

532

543

533−Dually, code that is too narrow limits the number of lines you can have on a screen (this isn't a separate precept simply because we've never had to tell someone to write _wider_ code). This suggests there is some happy medium. This is dependent on the language, but in Hoon we've

544+Dually, code that is too narrow limits the number of lines you can have on a screen (this isn't a separate precept simply because we've never had to tell someone to write *wider* code). This suggests there is some happy medium. This is dependent on the language, but in Hoon we've

534found that up to 55 columns is a pretty good number for most code. However, there are plenty of legitimate reasons to go a bit longer than that. 70 columns is rare, but not surprising. There is essentially never a reason to extend beyond 80 columns.

545found that up to 55 columns is a pretty good number for most code. However, there are plenty of legitimate reasons to go a bit longer than that. 70 columns is rare, but not surprising. There is essentially never a reason to extend beyond 80 columns.

535

546

536> E2: Tabs aren't real.

547> E2: Tabs aren't real.

@@ -542,7 +553,6 @@ There can be good reason for inconsistency in some areas, but not in

542code formatting, which is such an intensely communicative action.

553code formatting, which is such an intensely communicative action.

543

554

544> E3: A text file is a series of lines, each ending with a newline

555> E3: A text file is a series of lines, each ending with a newline

545−

546 character.

556 character.

547

557

548There are several competing definitions of text files, but most commonly-used software uses this one. It's simple and consistent.

558There are several competing definitions of text files, but most commonly-used software uses this one. It's simple and consistent.

@@ -571,9 +581,9 @@ However, cache invalidation and naming things are genuinely hard because they mu

571context.

581context.

572

582

573You shouldn't solve hard problems if you don't need to, so don't name anything you don't have to. Giving unique names to things is tiring, and it reduces readability. A consistent pattern for naming things makes it easy to keep track of what is what and reduces the number of

583You shouldn't solve hard problems if you don't need to, so don't name anything you don't have to. Giving unique names to things is tiring, and it reduces readability. A consistent pattern for naming things makes it easy to keep track of what is what and reduces the number of

574−decisions you must make.

584+decisions you must make.

575

585

576−Examples:

586+Examples:

577

587

578- If the only difference between three things is that they're not the

588- If the only difference between three things is that they're not the

579 same, consider naming them `thing-1`, `thing-2`, and `thing-3`.

589 same, consider naming them `thing-1`, `thing-2`, and `thing-3`.

@@ -603,7 +613,9 @@ We're really good at memorizing sets of things, like runes. We're also good at i

603

613

604So don't be afraid to use new names for new concepts. If concepts are siblings, they needn't necessarily have a direct connection in their name, but if they're hierarchical, then something should suggest that. This can be syntactic or semantic.

614So don't be afraid to use new names for new concepts. If concepts are siblings, they needn't necessarily have a direct connection in their name, but if they're hierarchical, then something should suggest that. This can be syntactic or semantic.

605

615

616+<br>

617+

606−

618+<img class="ba" src="https://media.urbit.org/site/posts/essays/discuss-07.jpg">

607

619

608### F: Real Software

620### F: Real Software

609

621

@@ -620,43 +632,43 @@ This is the most important passage in all that has ever been written

620about Urbit:

632about Urbit:

621

633

622> What is Martian code actually like? There are two possibilities.

634> What is Martian code actually like? There are two possibilities.

623−>

635+>

624> One: since Earth code is fifty years old, and Martian code is fifty

636> One: since Earth code is fifty years old, and Martian code is fifty

625> million years old, Martian code has been evolving into a big ball of mud

637> million years old, Martian code has been evolving into a big ball of mud

626> for a million times longer than Earth software. (And two million times

638> for a million times longer than Earth software. (And two million times

627> longer than Windows.)

639> longer than Windows.)

628−>

640+>

629−> This hypothesis strikes me as possible, but implausible. Since the _big

641+> This hypothesis strikes me as possible, but implausible. Since the *big

630−> ball of mud_ expands indefinitely, Martian code would therefore be so

642+> ball of mud* expands indefinitely, Martian code would therefore be so

631> large and horrible that, despite its underground installed base, the

643> large and horrible that, despite its underground installed base, the

632> server room bulged into space like a termite mound, intercepting

644> server room bulged into space like a termite mound, intercepting

633> low-flying asteroids and stinking up the solar system all the way to

645> low-flying asteroids and stinking up the solar system all the way to

634> Pluto. Our latest space telescopes would surely have detected this

646> Pluto. Our latest space telescopes would surely have detected this

635> abominable structure - if not, in fact, collided with it.

647> abominable structure - if not, in fact, collided with it.

636−>

648+>

637> Two: therefore, at some point in Martian history, some abject fsck of a

649> Two: therefore, at some point in Martian history, some abject fsck of a

638−> Martian code-monkey must have said: _fsck_ this entire fscking ball of

650+> Martian code-monkey must have said: *fsck* this entire fscking ball of

639−> mud. For _lo_, its defects cannot be summarized; for they exceed the

651+> mud. For *lo*, its defects cannot be summarized; for they exceed the

640> global supply of bullet points; for numerous as the fishes in the sea,

652> global supply of bullet points; for numerous as the fishes in the sea,

641> like the fishes in the sea they fsck, making more little fscking fishes.

653> like the fishes in the sea they fsck, making more little fscking fishes.

642−> For lo, it is _fscked_, and a big ball of mud. And there is only one thing

654+> For lo, it is *fscked*, and a big ball of mud. And there is only one thing

643−> to do with it: _obliterate_ the trunk, _fire_ the developers, and hire a

655+> to do with it: *obliterate* the trunk, *fire* the developers, and hire a

644−> whole new fscking _army_ of Martian code-monkeys to rewrite the _entire

656+> whole new fscking *army* of Martian code-monkeys to rewrite the *entire

645−> fscking thing_.

657+> fscking thing*.

646−>

658+>

647−> This is such an obvious and essential response to the _big ball of mud_

659+> This is such an obvious and essential response to the *big ball of mud*

648> pattern that, despite the fact that we know nothing about Mars, we can

660> pattern that, despite the fact that we know nothing about Mars, we can

649> deduce that it must have happened on Mars. Probably several times.

661> deduce that it must have happened on Mars. Probably several times.

650> Probably several hundred. For each of these attempts but the last, of

662> Probably several hundred. For each of these attempts but the last, of

651−> course, the result was either (a) abject failure, (b) another _big ball

663+> course, the result was either (a) abject failure, (b) another *big ball

652−> of mud_, or (c) both.

664+> of mud*, or (c) both.

653−>

665+>

654> But the last, by definition, succeeded. This is the crucial inference we

666> But the last, by definition, succeeded. This is the crucial inference we

655> can draw about Mars: since the Martians had 50 million years to try, in

667> can draw about Mars: since the Martians had 50 million years to try, in

656> the end they must have succeeded. The result: Martian code, as we know

668> the end they must have succeeded. The result: Martian code, as we know

657−> it today. Not enormous and horrible — _tiny and diamond-perfect_.

669+> it today. Not enormous and horrible — *tiny and diamond-perfect*.

658> Moreover, because it is tiny and diamond-perfect, it is perfectly stable

670> Moreover, because it is tiny and diamond-perfect, it is perfectly stable

659−> and never changes or decays. It neither is a _big ball of mud_, nor tends

671+> and never changes or decays. It neither is a *big ball of mud*, nor tends

660> to become one. It has achieved its final, permanent and excellent state.

672> to become one. It has achieved its final, permanent and excellent state.

661

673

662We don't know that Urbit will achieve this final form, but Urbit is an attempt to make progress in that direction. Any software that isn't a candidate for "tiny and diamond-perfect" is either a prototype or scaffolding.

674We don't know that Urbit will achieve this final form, but Urbit is an attempt to make progress in that direction. Any software that isn't a candidate for "tiny and diamond-perfect" is either a prototype or scaffolding.

@@ -680,17 +692,17 @@ acceptable. If you depend on a piece of source code to be kept forever, copied a

680Another way to look at this is to say that anything that wouldn't work on a spaceship is architecturally flawed. Maybe it requires many sequential round-trips to a central server because it doesn't have all the relevant information. See discussion of A7.

692Another way to look at this is to say that anything that wouldn't work on a spaceship is architecturally flawed. Maybe it requires many sequential round-trips to a central server because it doesn't have all the relevant information. See discussion of A7.

681

693

682> F3: If it's owned by someone else, it isn't yours.

694> F3: If it's owned by someone else, it isn't yours.

683−>

695+>

684> F4: If it's managed by someone else and you can't change who that is, it

696> F4: If it's managed by someone else and you can't change who that is, it

685> isn't yours.

697> isn't yours.

686−>

698+>

687> F5: If it's not yours, it isn't permanent.

699> F5: If it's not yours, it isn't permanent.

688−>

700+>

689> F6: If it's not permanent, it isn't real.

701> F6: If it's not permanent, it isn't real.

690

702

691Nobody is as aligned with your values as you are. If you don't control the software, then you can't guarantee you'll always have access to it. Whoever does control the software may destroy it, move away, or simply revoke your access to it.

703Nobody is as aligned with your values as you are. If you don't control the software, then you can't guarantee you'll always have access to it. Whoever does control the software may destroy it, move away, or simply revoke your access to it.

692

704

693−Control has some nuance. If it's physically controlled by a company and you can't get your data and the software that makes it useful, you definitely don't have control. If you have physical control of it, you do have control. But if you're hosting the data and software on a commodity cloud server, you still mostly have control of it. Your privacy has been reduced, sure. However, as long as you keep regular backups of the data and software, if the hosting provider disappears you just need to find another host, or host it yourself. Any particular host is likely to disappear, but the situation where _every_ host disappears and you can't even host it yourself is much less likely. Brands are mortal, commodities are not.

705+Control has some nuance. If it's physically controlled by a company and you can't get your data and the software that makes it useful, you definitely don't have control. If you have physical control of it, you do have control. But if you're hosting the data and software on a commodity cloud server, you still mostly have control of it. Your privacy has been reduced, sure. However, as long as you keep regular backups of the data and software, if the hosting provider disappears you just need to find another host, or host it yourself. Any particular host is likely to disappear, but the situation where *every* host disappears and you can't even host it yourself is much less likely. Brands are mortal, commodities are not.

694

706

695Some branded hosts allow you to download a zip file of your data. This gives you a little more control over your data, but it's much closer to "no control" than "total control". This is because your online world is data plus code, and without the code that makes it useful, data is only good for scrapbooking. The scrapbook will remind you of the good old days, but you won't be able to live them again.

707Some branded hosts allow you to download a zip file of your data. This gives you a little more control over your data, but it's much closer to "no control" than "total control". This is because your online world is data plus code, and without the code that makes it useful, data is only good for scrapbooking. The scrapbook will remind you of the good old days, but you won't be able to live them again.

696

708

@@ -753,4 +765,4 @@ other communities and may spread if they provide some benefit.

753Many technologies today combine us into a single community, or at least a single set of norms. If many communities are hosted by a single entity, there will be pressure from some of those communities toward the entity to pressure other communities to follow certain of their norms.

765Many technologies today combine us into a single community, or at least a single set of norms. If many communities are hosted by a single entity, there will be pressure from some of those communities toward the entity to pressure other communities to follow certain of their norms.

754This crosstalk isn't all bad, but there must be an equilibrium. All too often the lines between the communities are so permeable as to be inconsequential. In this case, the communities will converge in a single large community, at the cost of the memetic diversity of the original communities.

766This crosstalk isn't all bad, but there must be an equilibrium. All too often the lines between the communities are so permeable as to be inconsequential. In this case, the communities will converge in a single large community, at the cost of the memetic diversity of the original communities.

755

767

756−Technology should mirror human interaction, and humans interact in communities.

768+Technology should mirror human interaction, and humans interact in communities.

content/blog/precepts.md+208−194

@@ -1,341 +1,355 @@

1+++

1+++

2title = "Precepts"

2title = "Precepts"

3−date = "2020-03-17"

3+date = 2020-03-18

4description = "Technical maxims that define Urbit's approach to engineering."

4description = "Technical maxims that define Urbit's approach to engineering."

5−

6[extra]

5[extra]

7author = "Philip Monk"

6author = "Philip Monk"

8ship = "~wicdev-wisryt"

7ship = "~wicdev-wisryt"

9−image = "https://media.urbit.org/site/posts/essays/pre-01.jpg"

8+image ="https://media.urbit.org/site/posts/essays/pre-01.jpg"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-01.jpg">

13

14

14−Urbit is a principled approach to system design and programming, but it's often not obvious what those principles are. We have many specific terms for the different parts of the project: Arvo is the OS, Hoon is the language, Tlon is the company, Azimuth is the identity system, Ames is the network. But the word most associated with the project is "Urbit", and it's not clear what technically it refers to. It's only a small stretch to say that "Urbit" _is_ this set of principles, and that if anybody follows these principles strictly they will create a system that is isomorphic to the Urbit.

15+Urbit is a principled approach to system design and programming, but it's often not obvious what those principles are. We have many specific terms for the different parts of the project: Arvo is the OS, Hoon is the language, Tlon is the company, Azimuth is the identity system, Ames is the network. But the word most associated with the project is "Urbit", and it's not clear what technically it refers to. It's only a small stretch to say that "Urbit" *is* this set of principles, and that if anybody follows these principles strictly they will create a system that is isomorphic to the Urbit.

15

16

16Some of these are commonly held among many software projects, and some are not. Some are only debatably better than the alternatives, but Urbit exclusively chooses them.

17Some of these are commonly held among many software projects, and some are not. Some are only debatably better than the alternatives, but Urbit exclusively chooses them.

17

18

18We’ll start with a brief description of many principles, then we’ll go into a long-form justification.

19We’ll start with a brief description of many principles, then we’ll go into a long-form justification.

19

20

21+<br>

22+

20−

23+<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-02.jpg">

24+

21

25

22### A: General Design

26### A: General Design

23

27

24−1. Data is better than code.

28+1) Data is better than code.

25

29

26− Store data in your state, send data over the wire, dispatch based

30+ Store data in your state, send data over the wire, dispatch based

27− on data.

31+ on data.

28

32

29−2. Everything should be CQRS.

33+2) Everything should be CQRS.

30

34

31−3. (Almost) Everything should be pubsub.

35+3) (Almost) Everything should be pubsub.

32

36

33−4. A subscriber shouldn't affect a publisher.

37+4) A subscriber shouldn't affect a publisher.

34

38

35−5. Communication between nodes should be communication between

39+5) Communication between nodes should be communication between

36 independent actors.

40 independent actors.

37

41

38− Each message should do one complete thing, and there shouldn't

42+ Each message should do one complete thing, and there shouldn't

39− need to be a sequence of coupled messages.

43+ need to be a sequence of coupled messages.

40

44

41−6. Represent your data as closely as possible to the essential structure

45+6) Represent your data as closely as possible to the essential structure

42 of the problem.

46 of the problem.

43

47

44−7. A client's representation of data should be as close as possible to

48+7) A client's representation of data should be as close as possible to

45 that of the server.

49 that of the server.

46

50

47− This blurs the distinction between client and server. It allows

51+ This blurs the distinction between client and server. It allows

48− offline-mode, reduces communication to syncing, and decentralizes.

52+ offline-mode, reduces communication to syncing, and decentralizes.

49

53

50−8. When mating different paradigms, build one cleanly on top of the

54+8) When mating different paradigms, build one cleanly on top of the

51 other.

55 other.

52

56

53− Never try to make them work on some of the same primitives. Never

57+ Never try to make them work on some of the same primitives. Never

54− abuse one to make the other work. For example, ducts in

58+ abuse one to make the other work. For example, ducts in

55− themselves are very general - if you want to do pubsub, that can

59+ themselves are very general - if you want to do pubsub, that can

56− easily be built on top of ducts, but don't pretend that pubsub is

60+ easily be built on top of ducts, but don't pretend that pubsub is

57− a _part_ of the duct system.

61+ a *part* of the duct system.

58

62

59−9. Never misuse an abstraction.

63+9) Never misuse an abstraction.

60

64

61− An abstraction provides a certain set of tools; use them and only

65+ An abstraction provides a certain set of tools; use them and only

62− them.

66+ them.

63

67

64−10. Correctness is more important than performance.

68+10) Correctness is more important than performance.

65

69

66−11. Be simple and uncompromising in defining what's correct; go crazy

70+11) Be simple and uncompromising in defining what's correct; go crazy

67 with optimizations.

71 with optimizations.

68

72

69− Nock is a great example of this. It contains the character of the

73+ Nock is a great example of this. It contains the character of the

70− virtual machine, but its asymptotics are bad. Add jets to fix the

74+ virtual machine, but its asymptotics are bad. Add jets to fix the

71− asymptotics.

75+ asymptotics.

72−

76+

73− Another example is the ACID nature of Arvo. Arvo is a pure

77+ Another example is the ACID nature of Arvo. Arvo is a pure

74− function f(logs) of its event log, so formally Arvo is just a

78+ function f(logs) of its event log, so formally Arvo is just a

75− function run against an event log. A naive implementation has

79+ function run against an event log. A naive implementation has

76− very bad asymptotics; processing each new event is O(n) in the

80+ very bad asymptotics; processing each new event is O(n) in the

77− number of historical events. Choose the function g(state,log)

81+ number of historical events. Choose the function g(state,log)

78− such that f(logs ++ log) = g(f(logs),log). Then, as long as you

82+ such that f(logs ++ log) = g(f(logs),log). Then, as long as you

79− keep the state in memory, processing each new event is constant in

83+ keep the state in memory, processing each new event is constant in

80− the number of previous events. This still requires O(n) restart

84+ the number of previous events. This still requires O(n) restart

81− from disk, but you can also periodically (and non-blockingly)

85+ from disk, but you can also periodically (and non-blockingly)

82− write a checkpoint of the state to disk, so that restart from disk

86+ write a checkpoint of the state to disk, so that restart from disk

83− is only linear in the number of events since the last checkpoint.

87+ is only linear in the number of events since the last checkpoint.

84−

88+

85−12. Correctness is more important than optimality.

89+12) Correctness is more important than optimality.

86−

90+

87−13. If you don't completely understand your code and the semantics of

91+13) If you don't completely understand your code and the semantics of

88 all the code it depends on, your code is wrong.

92 all the code it depends on, your code is wrong.

89

93

90−14. Deterministic beats heuristic.

94+14) Deterministic beats heuristic.

91

95

92− Heuristics are evil and should only be used where determinism is

96+ Heuristics are evil and should only be used where determinism is

93− infeasible, such as in cache reclamation.

97+ infeasible, such as in cache reclamation.

94

98

95−15. Stateless is better than stateful.

99+15) Stateless is better than stateful.

96

100

97−16. Explicit state is better than implicit state.

101+16) Explicit state is better than implicit state.

98

102

99−17. Referential transparency is honesty and stability.

103+17) Referential transparency is honesty and stability.

100

104

101− Lack of referential transparency and other forms of

105+ Lack of referential transparency and other forms of

102− disingenuousness are some of the world's big problems. Only

106+ disingenuousness are some of the world's big problems. Only

103− deviate from referential transparency if absolutely necessary.

107+ deviate from referential transparency if absolutely necessary.

104

108

105−18. Responsibilities should be clearly separated.

109+18) Responsibilities should be clearly separated.

106

110

107− This applies from kernel modules through network citizens.

111+ This applies from kernel modules through network citizens.

108

112

109−19. Dualities must be faced head-on and analyzed differently at

113+19) Dualities must be faced head-on and analyzed differently at

110 different layers.

114 different layers.

111

115

112− Statically typed vs. dynamically typed, imperative vs. functional,

116+ Statically typed vs. dynamically typed, imperative vs. functional,

113− code vs. data, and effectful vs. pure can all be a matter of

117+ code vs. data, and effectful vs. pure can all be a matter of

114− perspective, and all relevant perspectives must have coherent

118+ perspective, and all relevant perspectives must have coherent

115− answers.

119+ answers.

116

120

117−20. One hundred lines of simplicity is better than twenty lines of

121+20) One hundred lines of simplicity is better than twenty lines of

118 complexity.

122 complexity.

119

123

120− It's not enough for an abstraction to reduce code duplication; it

124+ It's not enough for an abstraction to reduce code duplication; it

121− must actually make the code simpler.

125+ must actually make the code simpler.

122

126

123−21. Prefer mechanical simplicity to mathematical simplicity.

127+21) Prefer mechanical simplicity to mathematical simplicity.

124

128

125− Often mechanical simplicity and mathematical simplicity go

129+ Often mechanical simplicity and mathematical simplicity go

126− together.

130+ together.

127

131

128−22. The Law of Leaky Abstractions is a lie; abstract airtightly.

132+22) The Law of Leaky Abstractions is a lie; abstract airtightly.

129

133

130− If your abstractions are leaking, it's not due to some law of the

134+ If your abstractions are leaking, it's not due to some law of the

131− universe; you just suck at abstracting. Usually, you didn't

135+ universe; you just suck at abstracting. Usually, you didn't

132− specify the abstraction narrowly enough.

136+ specify the abstraction narrowly enough.

133

137

134−23. Some cliches are repeated because they are true; others must be

138+23) Some cliches are repeated because they are true; others must be

135 repeated because they are not.

139 repeated because they are not.

136

140

137−

141+<br>

138

142

139−### B: Specific Design

143+<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-03.jpg">

140

144

141−1. Always ack a dupe; never ack an ack.

145+### B: Specific Design

142

146

143− It's okay to ack a nack as long as you never nack a nack.

147+1) Always ack a dupe; never ack an ack.

144

148

145−2. Never construct or deconstruct a duct.

149+ It's okay to ack a nack as long as you never nack a nack.

146

150

147−3. Route on wire before sign, never sign before wire.

151+2) Never construct or deconstruct a duct.

148

152

149−4. Only go from statically typed to dynamically typed if you must.

153+3) Route on wire before sign, never sign before wire.

150

154

151− Once you go into a dynamically typed world, it's hard to go back.

155+4) Only go from statically typed to dynamically typed if you must.

152− Statically typed is better than dynamically typed, so if something

153− can be made static, it should be.

154

156

157+ Once you go into a dynamically typed world, it's hard to go back.

158+ Statically typed is better than dynamically typed, so if something

159+ can be made static, it should be.

160+

155− Each timeless data structure is a brick in the foundation of

161+ Each timeless data structure is a brick in the foundation of

156− digital civilization.

162+ digital civilization.

157

163

158−5. Anything with business logic speaks one paradigm; anything that

164+5) Anything with business logic speaks one paradigm; anything that

159 translates paradigms has no business logic.

165 translates paradigms has no business logic.

160

166

161−6. Functionally enforced semantic rules are better security primitives

167+6) Functionally enforced semantic rules are better security primitives

162 than memory access restrictions.

168 than memory access restrictions.

163

169

164− A compiler can use type safety as an effective tool to enforce

170+ A compiler can use type safety as an effective tool to enforce

165− some classes of security guarantees.

171+ some classes of security guarantees.

172+

173+<br>

166

174

167−

175+<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-04.jpg">

168

176

169### C: Attitude

177### C: Attitude

170

178

171−1. Code courageously.

179+1) Code courageously.

172

180

173− If you avoid changing a section of code for fear of awakening the

181+ If you avoid changing a section of code for fear of awakening the

174− demons therein, you are living in fear. If you stay in the

182+ demons therein, you are living in fear. If you stay in the

175− comfortable confines of the small section of the code you wrote or

183+ comfortable confines of the small section of the code you wrote or

176− know well, you will never write legendary code. All code was

184+ know well, you will never write legendary code. All code was

177− written by humans and can be mastered by humans.

185+ written by humans and can be mastered by humans.

178

186

179− It's natural to feel fear of code; however, you must act as though

187+ It's natural to feel fear of code; however, you must act as though

180− you are able to master and change any part of it. To code

188+ you are able to master and change any part of it. To code

181− courageously is to walk into any abyss, bring light, and make it

189+ courageously is to walk into any abyss, bring light, and make it

182− right.

190+ right.

183

191

184−2. No time for lazy people.

192+2) No time for lazy people.

185

193

186− If there's clearly a right way to do something and a wrong way, do

194+ If there's clearly a right way to do something and a wrong way, do

187− it the right way. Coding requires incredible discipline. Always

195+ it the right way. Coding requires incredible discipline. Always

188− follow conventions, and fire anyone who won't. Anything that can

196+ follow conventions, and fire anyone who won't. Anything that can

189− be solved by discipline is not a real problem.

197+ be solved by discipline is not a real problem.

190

198

191− > "To him who knows to do good and does not do it, to him it is

199+ > "To him who knows to do good and does not do it, to him it is

192− > sin."

200+ sin."

193

201

194−3. When a smart person makes an obviously stupid suggestion, before

202+3) When a smart person makes an obviously stupid suggestion, before

195 responding take a full 60 seconds to envision how you would implement

203 responding take a full 60 seconds to envision how you would implement

196 it and what the effects would be.

204 it and what the effects would be.

197

205

206+<br>

207+

198−

208+<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-05.jpg">

199

209

200### D: Theory

210### D: Theory

201

211

202−1. Academia is a succubus.

212+1) Academia is a succubus.

203

213

204− Academia has a really high ratio of smart people to useful

214+ Academia has a really high ratio of smart people to useful

205− products. Academia has many genuinely smart and interesting

215+ products. Academia has many genuinely smart and interesting

206− ideas, but always remember that pursuing them whole-heartedly will

216+ ideas, but always remember that pursuing them whole-heartedly will

207− never result in a useful product.

217+ never result in a useful product.

208

218

209−2. Never fear math.

219+2) Never fear math.

210

220

211− Academia is inefficient, but it's also correct. Those people

221+ Academia is inefficient, but it's also correct. Those people

212− wasted a lot of time finding the right answer, but now that

222+ wasted a lot of time finding the right answer, but now that

213− they've done it, you must exploit it. If you don't know the

223+ they've done it, you must exploit it. If you don't know the

214− theory, learn it. No excuse for being "bad at math". Most who

224+ theory, learn it. No excuse for being "bad at math". Most who

215− are "bad at math" are simply lazy or fearful. Be strong and of

225+ are "bad at math" are simply lazy or fearful. Be strong and of

216− good courage. If you're truly so bad at math that you cannot

226+ good courage. If you're truly so bad at math that you cannot

217− learn it, you should not design systems.

227+ learn it, you should not design systems.

218

228

219−3. Not being qualified to solve a problem is no reason not to solve it.

229+3) Not being qualified to solve a problem is no reason not to solve it.

220

230

221− If you don't know how to do it, do it anyway. "We are too young

231+ If you don't know how to do it, do it anyway. "We are too young

222− to realize that certain things are impossible. So, we will do

232+ to realize that certain things are impossible. So, we will do

223− them anyway."

233+ them anyway."

224

234

225−4. The best way to get the right answer is to try it the wrong way.

235+4) The best way to get the right answer is to try it the wrong way.

226

236

227− You cannot design a good system without spending most of your time

237+ You cannot design a good system without spending most of your time

228− in contact with the problem. The bad parts about systems are

238+ in contact with the problem. The bad parts about systems are

229− rarely obvious in theory, but often in practice.

239+ rarely obvious in theory, but often in practice.

230

240

231−5. Practice tells you that things are good or bad; theory tells you why.

241+5) Practice tells you that things are good or bad; theory tells you why.

232

242

233− Never use theory to design a good system from scratch; only

243+ Never use theory to design a good system from scratch; only

234− practice can tell whether the system is good.

244+ practice can tell whether the system is good.

235

245

236−6. Everyone must regularly alternate between theory and practice.

246+6) Everyone must regularly alternate between theory and practice.

237

247

238− There is an eternal wheel of system design. Given a system, use

248+ There is an eternal wheel of system design. Given a system, use

239− practice to discover what is bad, missing, or unnecessary. Then,

249+ practice to discover what is bad, missing, or unnecessary. Then,

240− use theory to fix the bad, add the missing, and remove the

250+ use theory to fix the bad, add the missing, and remove the

241− unnecessary. Repeat.

251+ unnecessary. Repeat.

242

252

253+<br>

254+

243−

255+<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-06.jpg">

244

256

245### E: Text Style

257### E: Text Style

246

258

247−1. No code should extend beyond 80 characters, most within 55.

259+1) No code should extend beyond 80 characters, most within 55.

248

260

249−2. Tabs aren't real.

261+2) Tabs aren't real.

250

262

251−3. A text file is a series of lines, each ending with a newline

263+3) A text file is a series of lines, each ending with a newline

252 character.

264 character.

253

265

254− Corollary: all non-empty text files end with a newline (often

266+ Corollary: all non-empty text files end with a newline (often

255− hidden by editors). An empty text file does not end with a

267+ hidden by editors). An empty text file does not end with a

256− newline.

268+ newline.

269+

270+4) One block comment is better than interleaved comments on every line.

257

271

258−4. One block comment is better than interleaved comments on every line.

272+5) Don't name anything you don't have to.

259

273

260−5. Don't name anything you don't have to.

274+ This includes conventional names for variables of particular

275+ types. For example, the conventional name for a variable of type

276+ `path` is `pax`. You should have a good reason for using any

277+ other name for a `path`.

261

278

262− This includes conventional names for variables of particular

279+ A more recent convention that follows the same principle is to

263− types. For example, the conventional name for a variable of type

280+ give the variable the same name as its type.

264− `path` is `pax`. You should have a good reason for using any

265− other name for a `path`.

266

281

267− A more recent convention that follows the same principle is to

268− give the variable the same name as its type.

282+6) If it's the same thing, give it the same name.

269

283

270−6. If it's the same thing, give it the same name.

284+7) Humans are good at memorizing.

271

285

272−7. Humans are good at memorizing.

286+8) Abbreviations aren't worth it.

273

287

274−8. Abbreviations aren't worth it.

288+<br>

275

289

276−

290+<img class="ba" src="https://media.urbit.org/site/posts/essays/pre-07.jpg">

277

291

278### F: Real Software

292### F: Real Software

279

293

280−1. If it's not deterministic, it isn't real.

294+1) If it's not deterministic, it isn't real.

281

295

282−2. If it's centralized, it isn't real.

296+2) If it's centralized, it isn't real.

283

297

284−3. If it's owned by someone else, it isn't yours.

298+3) If it's owned by someone else, it isn't yours.

285

299

286−4. If it's managed by someone else and you can't change who that is, it

300+4) If it's managed by someone else and you can't change who that is, it

287 isn't yours.

301 isn't yours.

288

302

289−5. If it's not yours, it isn't permanent.

303+5) If it's not yours, it isn't permanent.

290

304

291−6. If it's not permanent, it isn't real.

305+6) If it's not permanent, it isn't real.

292

306

293−7. The way it is isn't always the way it ought to be.

307+7) The way it is isn't always the way it ought to be.

294

308

295− If you can make it the way it ought to be, do so.

309+ If you can make it the way it ought to be, do so.

296

310

297−8. The way it ought to be isn't always the way it is.

311+8) The way it ought to be isn't always the way it is.

298

312

299− Some things can't be made more elegant.

313+ Some things can't be made more elegant.

300

314

301− For every ailment under the sun

315+ For every ailment under the sun

302− There is a remedy, or there is none;

316+ There is a remedy, or there is none;

303− If there be one, try to find it;

317+ If there be one, try to find it;

304− If there be none, never mind it.

318+ If there be none, never mind it.

305

319

306−9. Timeless software is good software.

320+9) Timeless software is good software.

307

321

308−10. System modules should be designed to be frozen permanently;

322+10) System modules should be designed to be frozen permanently;

309 conversely, Urbit consists of that system software which admits of a

323 conversely, Urbit consists of that system software which admits of a

310 Kelvin version.

324 Kelvin version.

311

325

312−11. The two procedures for achieving timelessness are distillation and

326+11) The two procedures for achieving timelessness are distillation and

313 generalization.

327 generalization.

314

328

315− Every temporary or contingent feature in a system module should

329+ Every temporary or contingent feature in a system module should

316− eventually either be removed (distillation) or relaxed into

330+ eventually either be removed (distillation) or relaxed into

317− timelessness (generalization). For an example of the result of

331+ timelessness (generalization). For an example of the result of

318− both procedures, consider the abstraction of the core in Nock and

332+ both procedures, consider the abstraction of the core in Nock and

319− Hoon.

333+ Hoon.

320

334

321−12. Standardization is better than perfection.

335+12) Standardization is better than perfection.

322

336

323− Kelvin versioning stops when we run out of versions, not when

337+ Kelvin versioning stops when we run out of versions, not when

324− every defect has been rectified.

338+ every defect has been rectified.

325

339

326−13. That which cannot be Kelvin-versioned should update fluidly and

340+13) That which cannot be Kelvin-versioned should update fluidly and

327 automatically.

341 automatically.

328

342

329− All incompatible upgrades should provide permanent and automatic

343+ All incompatible upgrades should provide permanent and automatic

330− upgrade paths. This is principled permanent backward

344+ upgrade paths. This is principled permanent backward

331− compatibility.

345+ compatibility.

332

346

333−14. Humans are interactive and temporal; technology is permanent and

347+14) Humans are interactive and temporal; technology is permanent and

334 exhaustive.

348 exhaustive.

335

349

336−15. Communities are autonomous.

350+15) Communities are autonomous.

337

351

338−16. Sovereignty necessitates understanding.

352+16) Sovereignty necessitates understanding.

339

353

340− If you don't understand a system you're using, you don't control

354+ If you don't understand a system you're using, you don't control

341− it. If nobody understands the system, the system is in control.

355+ it. If nobody understands the system, the system is in control.

content/blog/providers.md+32−25

@@ -1,82 +1,89 @@

1+++

1+++

2title = "Providers"

2title = "Providers"

3−date = "2020-08-17"

3+date = 2020-08-18

4description = "We’ve always assumed that providers would have to come into existence sooner or later. By the look of it, that time is now. Tlon and a few others have provider-like services in the works."

4description = "We’ve always assumed that providers would have to come into existence sooner or later. By the look of it, that time is now. Tlon and a few others have provider-like services in the works."

5−

6[extra]

5[extra]

7author = "Galen Wolfe-Pauly"

6author = "Galen Wolfe-Pauly"

8ship = "~ravmel-ropdyl"

7ship = "~ravmel-ropdyl"

9−image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/providers.png"

8+image ="https://storage.googleapis.com/media.urbit.org/site/posts/essays/providers.png"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://storage.googleapis.com/media.urbit.org/site/posts/essays/providers.png">

14+

15+<br>

16+

17+We look forward to a future where your Urbit is an always-on, always-available service. You should be able to pick up any device and conjure up your whole digital life immediately.

13

18

14−We look forward to a future where your Urbit is an always-on, always-available service. You should be able to pick up any device and conjure up your whole digital life immediately.

19+Sounds good—but how does this actually come to pass? Urbit has to be technically robust and have a nice interface. Assuming we can deliver both of those things, your Urbit node also has to be safe, secure, and running somewhere with a network connection.

15

20

16−Sounds good—but how does this actually come to pass? Urbit has to be technically robust and have a nice interface. Assuming we can deliver both of those things, your Urbit node also has to be safe, secure, and running somewhere with a network connection.

21+Urbit has been getting nicer to use and more stable every day. We use it constantly, both as a company (Tlon) and for the broader Urbit community. From what we can tell, people are using Urbit to start communities of their own here and there. The problem is: to use our platform, you’ve got to run it yourself. This limits our audience *a lot*. Setting up a VPS and running an Urbit OS node is pretty easy if you’re comfortable in the command line, which makes it completely impossible for most people.

17

22

18−Urbit has been getting nicer to use and more stable every day. We use it constantly, both as a company (Tlon) and for the broader Urbit community. From what we can tell, people are using Urbit to start communities of their own here and there. The problem is: to use our platform, you’ve got to run it yourself. This limits our audience _a lot_. Setting up a VPS and running an Urbit OS node is pretty easy if you’re comfortable in the command line, which makes it completely impossible for most people.

23+We hear from people regularly who want to be able to sign up for Urbit like it was any cloud service. What they want is what we’ve been calling a *provider*: a service to provide easy onboarding and hosting. Given a good provider, we’d be pretty close to our long-term vision: Urbit would feel like a ubiquitous, easily accessible service.

19

24

20−We hear from people regularly who want to be able to sign up for Urbit like it was any cloud service. What they want is what we’ve been calling a _provider_: a service to provide easy onboarding and hosting. Given a good provider, we’d be pretty close to our long-term vision: Urbit would feel like a ubiquitous, easily accessible service.

25+We’ve always assumed that providers would have to come into existence sooner or later. By the look of it, that time is now. Tlon and a few others have provider-like services in the works. We’ll talk about the specifics of what Tlon is planning to do in a future post. In this one, we’ll talk about what a provider is, why anyone would start one, and give a few examples of what they might look like.

21

26

22−We’ve always assumed that providers would have to come into existence sooner or later. By the look of it, that time is now. Tlon and a few others have provider-like services in the works. We’ll talk about the specifics of what Tlon is planning to do in a future post. In this one, we’ll talk about what a provider is, why anyone would start one, and give a few examples of what they might look like.

23

27

24## What is a provider?

28## What is a provider?

25

29

26−A provider is anyone (company, DAO, a group of friends) that provides easy onboarding and hosting.

30+A provider is anyone (company, DAO, a group of friends) that provides easy onboarding and hosting.

27

31

28−From a user perspective, signing up with a provider should be as simple as picking a planet and hosting plan, paying, and getting connected to a running Urbit OS node. This should be able to be done entirely in a browser or a standalone app and feel more or less like signing up for a conventional service.

32+From a user perspective, signing up with a provider should be as simple as picking a planet and hosting plan, paying, and getting connected to a running Urbit OS node. This should be able to be done entirely in a browser or a standalone app and feel more or less like signing up for a conventional service.

29

33

30From a technical perspective, this means a provider needs to create an Ethereum wallet for the user (client-side, of course), deliver an Urbit ID to it, and boot an Urbit OS node for them. And, at some point in the process, collect payment.

34From a technical perspective, this means a provider needs to create an Ethereum wallet for the user (client-side, of course), deliver an Urbit ID to it, and boot an Urbit OS node for them. And, at some point in the process, collect payment.

31

35

32−As a user, your provider is somewhere between your ISP and your WordPress host. Your provider both runs the star that sponsors your planet (and provides peer discovery) as well as potentially providing both access to communities and even provider-specific software. We don’t really expect providers to be terribly generic—quite the opposite. Providers are likely to differentiate themselves on price, available software, and available communities. We’ll get into some examples later.

36+As a user, your provider is somewhere between your ISP and your WordPress host. Your provider both runs the star that sponsors your planet (and provides peer discovery) as well as potentially providing both access to communities and even provider-specific software. We don’t really expect providers to be terribly generic—quite the opposite. Providers are likely to differentiate themselves on price, available software, and available communities. We’ll get into some examples later.

33

37

34−The utility that a provider offers involves quite a lot of trust on behalf of the user. While the provider never actually holds the keys to your Urbit ID, they do run your node and, in turn, can access its contents. Unlike giant cloud services, your data isn’t in an easily searchable database. Inspecting your data should be something explicitly protected by a good provider ToS.

38+The utility that a provider offers involves quite a lot of trust on behalf of the user. While the provider never actually holds the keys to your Urbit ID, they do run your node and, in turn, can access its contents. Unlike giant cloud services, your data isn’t in an easily searchable database. Inspecting your data should be something explicitly protected by a good provider ToS.

35

39

36−If a strongly worded ToS isn’t enough for you, you can always host yourself. And, given the way Urbit works, downloading your Urbit from a provider and running it elsewhere should be both really simple and something a provider will _always_ let you do. It’s perfectly fine to run Urbit in your closet—which means that providers are really competing on ease of use and price.

40+If a strongly worded ToS isn’t enough for you, you can always host yourself. And, given the way Urbit works, downloading your Urbit from a provider and running it elsewhere should be both really simple and something a provider will *always* let you do. It’s perfectly fine to run Urbit in your closet—which means that providers are really competing on ease of use and price.

37

41

38Let’s move on and talk a bit about why starting a provider makes sense to begin with.

42Let’s move on and talk a bit about why starting a provider makes sense to begin with.

39

43

44+

40## Why would anyone start a provider?

45## Why would anyone start a provider?

41

46

42Our aim is to make Urbit OS so obviously nice to use that it’s well worth paying for. Today, a planet goes for about $10–$20 and, once you buy one, you’ve got to figure out how to really put it to use. Which takes some work.

47Our aim is to make Urbit OS so obviously nice to use that it’s well worth paying for. Today, a planet goes for about $10–$20 and, once you buy one, you’ve got to figure out how to really put it to use. Which takes some work.

43

48

44Any large holder of address space should immediately see the opportunity here: the more useful Urbit is, the more value can be captured by starting a provider. Providers make it possible to actually capture the value in address space, both by selling it and by operating nodes.

49Any large holder of address space should immediately see the opportunity here: the more useful Urbit is, the more value can be captured by starting a provider. Providers make it possible to actually capture the value in address space, both by selling it and by operating nodes.

45

50

46−Let’s say the base cost of running an Urbit OS node, in a hosted environment, is $10 / node / month. If you can sell hosting for $200 / year, you’re making back the ‘cost’ of the planet when someone signs up. Given that it’s more desirable to buy a planet when you know the star is online and you can put it to good use, this seems like a pretty good proposition: both for the provider and the customer.

51+Let’s say the base cost of running an Urbit OS node, in a hosted environment, is $10 / node / month. If you can sell hosting for $200 / year, you’re making back the ‘cost’ of the planet when someone signs up. Given that it’s more desirable to buy a planet when you know the star is online and you can put it to good use, this seems like a pretty good proposition: both for the provider and the customer.

47

52

48−Starting a provider doesn’t _have_ to be done by address-space holders. You could start a provider with no address space of your own by custodying the address space of others. Then, you could take a cut of the address space sales and all of the hosting revenue. With a market of people looking to use Urbit, the crux of success with this approach is simply whether you can compete on user experience.

53+Starting a provider doesn’t *have* to be done by address-space holders. You could start a provider with no address space of your own by custodying the address space of others. Then, you could take a cut of the address space sales and all of the hosting revenue. With a market of people looking to use Urbit, the crux of success with this approach is simply whether you can compete on user experience.

49

54

50Providers are, in a way, like the miners of Urbit. They’re incentivized to run fleets of very specific VMs for profit. The profit motive, in Urbit’s case, is just a bit more conventional than a bitcoin miner. An Urbit provider is just offering a service in exchange for money.

55Providers are, in a way, like the miners of Urbit. They’re incentivized to run fleets of very specific VMs for profit. The profit motive, in Urbit’s case, is just a bit more conventional than a bitcoin miner. An Urbit provider is just offering a service in exchange for money.

51

56

57+

52## What are some examples of providers?

58## What are some examples of providers?

53

59

54−If you think of a provider simply as a business, its most basic incentive is to attract as many customers as possible. You can do that by competing on price or performance, or by competing on aesthetics and community—there are lots of ways that providers can compete.

60+If you think of a provider simply as a business, its most basic incentive is to attract as many customers as possible. You can do that by competing on price or performance, or by competing on aesthetics and community—there are lots of ways that providers can compete.

55

61

56−As a roughly similar ecosystem, the world of webhosting is a great comparison. There are lots of small webhosts that all have very specific services: Dreamhost, MediaTemple, prgmr.com, and Linode all come to mind. Then there are the more generic, large-scale, performance-oriented options: AWS, GCP, Azure. It’s not quite time for an AWS-scale Urbit provider, but perhaps the AWS of Urbit will start as something much smaller.

62+As a roughly similar ecosystem, the world of webhosting is a great comparison. There are lots of small webhosts that all have very specific services: Dreamhost, MediaTemple, prgmr.com, and Linode all come to mind. Then there are the more generic, large-scale, performance-oriented options: AWS, GCP, Azure. It’s not quite time for an AWS-scale Urbit provider, but perhaps the AWS of Urbit will start as something much smaller.

57

63

58Let’s walk through a few examples to get a feel for what’s possible:

64Let’s walk through a few examples to get a feel for what’s possible:

59

65

60Communities -

66Communities -

61

67

62−A provider could easily curate community content like news, events, and discussion that it only delivers to its customers. Think of it as a bit like the days of sharing a server among friends—only in this case it could be hundreds or thousands of people who form a collective to run infrastructure and share information.

68+A provider could easily curate community content like news, events, and discussion that it only delivers to its customers. Think of it as a bit like the days of sharing a server among friends—only in this case it could be hundreds or thousands of people who form a collective to run infrastructure and share information.

63

69

64−Custom software -

70+Custom software -

65

71

66−There are so many ways that providers can offer custom software. Urbit isn’t ready for third party software distribution. When it is, subscribers to a specific provider could get unique modules and applications synced directly to their Urbit nodes along with their membership.

72+There are so many ways that providers can offer custom software. Urbit isn’t ready for third party software distribution. When it is, subscribers to a specific provider could get unique modules and applications synced directly to their Urbit nodes along with their membership.

67

73

68Aside from Urbit-specific software, providers could provide custom software services to their subscribers. A straightforward example of this could come in the form of Bitcoin or Ethereum nodes for processing transactions. Sign up with a provider and get the ability to send transactions to the chain quickly and reliably.

74Aside from Urbit-specific software, providers could provide custom software services to their subscribers. A straightforward example of this could come in the form of Bitcoin or Ethereum nodes for processing transactions. Sign up with a provider and get the ability to send transactions to the chain quickly and reliably.

69

75

70−Security -

76+Security -

71

77

72Let’s say our base cost of $10 / month / planet from above is correct (it’s probably high, but it’s a simple number). Would someone pay $100 / month for a planet hosted in a bunker or in the pylon of an abandoned oil rig? Maybe.

78Let’s say our base cost of $10 / month / planet from above is correct (it’s probably high, but it’s a simple number). Would someone pay $100 / month for a planet hosted in a bunker or in the pylon of an abandoned oil rig? Maybe.

73

79

80+

74## What about Tlon?

81## What about Tlon?

75

82

76−Before there can be an ecosystem of providers, there has to be _one_ provider. While we’ve heard of a few other people working on things, we expect Tlon to be the first to try to really get into the provider business in earnest.

83+Before there can be an ecosystem of providers, there has to be *one* provider. While we’ve heard of a few other people working on things, we expect Tlon to be the first to try to really get into the provider business in earnest.

77

84

78I’ll save the details of what we’re going to do for a future post. Launching Tlon as a separate business will be the beginning of the separation of Tlon and Urbit. I’m really quite excited about it. Tlon is only able to consider becoming a business of its own because Urbit is mature enough that we can actually do it.

85I’ll save the details of what we’re going to do for a future post. Launching Tlon as a separate business will be the beginning of the separation of Tlon and Urbit. I’m really quite excited about it. Tlon is only able to consider becoming a business of its own because Urbit is mature enough that we can actually do it.

79

86

80−For now, I’ll just say that Tlon will pick the low-hanging fruit first. Our goal is to make onboarding a group into Urbit incredibly simple. We want people to be able to go from email invite to running Urbit in a few minutes without ever knowing anything about Ethereum, Unix, or what a private key is.

87+For now, I’ll just say that Tlon will pick the low-hanging fruit first. Our goal is to make onboarding a group into Urbit incredibly simple. We want people to be able to go from email invite to running Urbit in a few minutes without ever knowing anything about Ethereum, Unix, or what a private key is.

81

88

82−Once we’ve laid the groundwork with something that _just works_, we plan to open-source some of our components. Scaling up Urbit isn’t going to be easy. We hope that others will help us, and will help explore what’s possible in supporting Urbit users in the future.

89+Once we’ve laid the groundwork with something that *just works*, we plan to open-source some of our components. Scaling up Urbit isn’t going to be easy. We hope that others will help us, and will help explore what’s possible in supporting Urbit users in the future.

content/blog/pseudonymous-reputation.mddeleted−64

@@ -1,64 +0,0 @@

1−+++

2−title = "Building Your DAO with Pseudonymous Reputation on Urbit"

3−date = "2022-07-19"

4−description = "Using Urbit ID’s pseudonymous reputation model, DAO participants know Urbit ID holders’ past behavior before relying on them, and without sacrificing anonymity."

5−

6−[extra]

7−author = "Anthony Arroyo"

8−ship = "~poldec-tonteg"

9−image = "https://storage.googleapis.com/media.urbit.org/blog/2022.7.14..19.19.05-image.jpg"

10−+++

11−

12−

13−

14−_This is cross-posted from [The Combine DAO Blog](https://blog.the-combine.org). If you'd like to comment, join the public [Urbit group](https://urbit.org/groups/~famreb-todmec/the-combine-public)._

15−

16−[The Combine DAO](https://blog.the-combine.org/introduction-to-the-combine-dao) is a DAO built on Urbit to invest in promising projects on the network. While building the DAO, we did a survey of the existing identity solutions and found our solution close to home: Urbit ID provided the best balance of trust and anonymity due to the Urbit networks’ pseudonymous reputation. In this post, we’ll discuss the challenges facing DAOs and discuss why Urbit ID presents advantages over current approaches like token gated DAOs.

17−

18−## Trust, Anonymity and Pseudonymous Reputation

19−

20−Anonymity is a core feature of most DAOs. It’s great in theory. No one wants to trust that the humans operating Robinhood will execute trades how and when they say they will (much less know their names.) We’d all prefer if a smart contract handled it for them.

21−

22−The problem is that trust and anonymity don’t mix, and trust is essential to the practical operation of any organization. This is why existing DAOs take shortcuts to establish trust hierarchies—things like delegating multi-sigs to small groups of trusted leaders, or trusted leaders establishing authority via exclusive Discord channels.

23−

24−Put simply, if there’s no human to trust, there’s no human to hold accountable. Lack of accountability is a major hurdle for any organization.

25−

26−We were aware of this fundamental flaw when building Combine DAO on Urbit, and we’ve found a solution in Urbit ID. Urbit ID is the decentralized identity system at the core of the Urbit project. Urbit IDs are the “decentralized IDs” that [DAO builders yearn](https://thmueller.medium.com/decentralized-identity-3-ways-to-build-trust-in-your-dao-4871491903c8) for. They’re endowed with what we call pseudonymous reputations that unlock the ability to run DAOs in ways that more closely resemble successful IRL organizations, while maintaining the automation that makes them so attractive.

27−

28−## What is Urbit ID?

29−

30−Why is your Urbit ID so different from every other online identity you’ve ever had? The substantive answer is simple: it’s a lot more like your IRL identity. It’s permanent and owned by you. And because it’s the same throughout the Urbit network, it can accrue a reputation.

31−

32−You’ve probably seen Urbit IDs like `~ravmel-ropdyl` or `~mogmet-tadnem` in Twitter profiles. Each is a unique NFT that can be transferred and sold like any other cryptographic asset. Your Urbit ID is your username, network address and crypto wallet all in one.

33−

34−Like wallet addresses, Urbit IDs are anonymous. Like Discord, Twitter, or Notion accounts, they are also pseudonymous. Pseudonymity is the kind of anonymity you find in most online communities: a common username that people recognize even if it’s not your “real” name.

35−

36−Your Urbit ID is to your urbit ship what your deed is to your house or your keys to your car. It encrypts all of your ship’s communications and provides access to your online communities, which in this instance are DAOs.

37−

38−Using Urbit ID’s pseudonymous reputation model, DAO participants know Urbit ID holders’ past behavior before relying on them, and without sacrificing anonymity. Why do reputations stick to Urbit IDs? Because, like your physical person, every action you take with your Urbit ID affects your reputation. Urbit maximalists often ask “How high of a ransom would you pay if your Urbit ID were ‘kidnapped?’” That’s because the reputation of your Urbit ID is the result of years of labor. Imagine every social account you’ve ever had in one immutable chain tied to one immutable pseudonym.

39−

40−Thus, unlike an anonymous wallet address, Twitter handles or Discord accounts, there are high incentives for keeping your Urbit ID’s reputation squeaky clean.

41−

42−## Urbit ID for DAOs

43−

44−Many DAOs gate their membership on the ownership of a cryptographic asset like an ERC-721 or an ERC-20 token. Token gating is used to create a flat, anonymous membership. This was initially seen as a good thing. “One member, one voice.” All decisions made anonymously via multi-sigs and voting apps secured via smart contract.

45−

46−Token gating also adds utility to NFTs; it unlocks access to perks like special releases or events apart from the core asset. To get into the Milady Rave you need to buy a Milady NFT. It doesn’t matter who you are, what you’ve done, or how capable you are of participating in the community’s goals, if you buy a Milady, you’re in. You have the same rights and privileges as everyone else.

47−

48−In reality, many DAOs move inexorably back towards a more conventional model of “human trust” simply because organization requires it. That’s why DAO builders have long sought “decentralized IDs” for members. “One member, one voice” doesn’t work for complex, efficient decision making; it risks chaos and endless discussion. It creates the need for offchain governance executed by smaller groups, which is cumbersome, requires a patchwork of Web2 apps (i.e. Google and Notion), and undermines the “trustless” nature of the DAO.

49−

50−To return to a prior example, imagine Robinhood was a DAO of its members. If it was run like DAOs today—e.g. those not built on Urbit—a group of Robinhood “elites” make and execute trade decisions via private Discord channels. DAO members vote to approve, but participation is low. Some DAOs even cold-call members to garner participation. Not only is participation low, it’s also low quality: banter about the issues of the day.

51−

52−Urbit ID mitigates membership participation issues by adding permanent, pseudonymous reputations to the mix. As in: Who are you letting into your DAO? And whose DAO are you joining?

53−

54−As a leader of an organization, you want high quality members. You want to avoid Dumb Money: people passively investing in your DAO because it’s cool, but without the ability to add value. You also want to avoid oversubscription/underparticipation: a dropoff in engagement from most members as they become interested in newer, shinier things.

55−

56−When it came time to recruit members for Combine DAO, we didn’t have to leave Urbit. We only considered those with strong pseudonymous reputations on the network, many of whom were anonymous outside of Urbit. Some of the Urbit IDs in Combine DAO like `~bitmep-faswyn` have been on the network for years. Some like `~timluc-miptev` have created valuable groups and built companies on Urbit. Selection blindness was both unneeded and unnecessary—members were selected not in spite of “who” they were on Urbit, but because of it.

57−

58−Pseudonymous reputations also allow prospective DAO members to better evaluate leaders. Urbit ID reputations subsume the need for patchworks of authority. You know exactly “who” `~mogmet-tadnem` is. You don’t need to google his Twitter handle and figure out, oh maybe he’s also the guy behind this or that DAO or NFT release. Leaders benefit from the past and are held accountable for future actions.

59−

60−Now, the organizing forces behind Combine DAO are `~poldec-tonteg` and `~wolref-podlex`. In this case, their real world identities are known to many, but they needn’t be: their actions on the network speak for themselves. `~poldec-tonteg` is the former CPO of Tlon and `~wolref-podlex` is the Executive Director of the Urbit Foundation. Prospective members of Combine DAO know who they are aligning themselves with.

61−

62−To sum it up, Urbit ID is a solution for the reputational problems faced by DAOs in their current form. While good in theory, the trustless nature of DAOs leads to practical issues around organization, leadership, membership, voting, and participation. This is why DAO builders need ways to give their membership durable reputations that can travel with the members as they participate.

63−

64−Urbit offers just such cryptographic identities with portable reputations in the form of Urbit IDs. We put pseudonymous reputations to the test in building Combine DAO, and discovered they enhanced leadership formation and membership curation, eliminating some of the organizational problems that DAOs struggle with today.

content/blog/rollups.md+14−16

@@ -1,8 +1,7 @@

1+++

1+++

2title = "The Gang Solves the Gas Crisis"

2title = "The Gang Solves the Gas Crisis"

3−date = "2021-05-13"

3+date = 2021-05-14

4description = "How we're making Urbit ID affordable again"

4description = "How we're making Urbit ID affordable again"

5−

6[extra]

5[extra]

7author = "Jonathan Paprocki"

6author = "Jonathan Paprocki"

8ship = "~datnut-pollen"

7ship = "~datnut-pollen"

@@ -121,7 +120,7 @@ And that's it! If you'd like to know how things will be changing for

121[stars](#stars), what goes into [setting up a roller](#rollers), and additional

120[stars](#stars), what goes into [setting up a roller](#rollers), and additional

122[technical details](#technical), read on.

121[technical details](#technical), read on.

123

122

124−### Changes to stars {% #stars %}

123+### Changes to stars {#stars}

125

124

126Both planets and stars will be able to move to layer 2.

125Both planets and stars will be able to move to layer 2.

127[Galaxies](/docs/glossary/galaxy) must remain on layer 1 for technical

126[Galaxies](/docs/glossary/galaxy) must remain on layer 1 for technical

@@ -148,7 +147,7 @@ moving ownership to layer 2, this will be a one-way journey for now. Planets

148spawned before moving the spawn proxy to layer 2 will remain on layer 1, but

147spawned before moving the spawn proxy to layer 2 will remain on layer 1, but

149from then on, all planets spawned by that star will live on layer 2. Finally, stars in this second mode may transition to the first mode, but not vice versa.

148from then on, all planets spawned by that star will live on layer 2. Finally, stars in this second mode may transition to the first mode, but not vice versa.

150

149

151−### Creating a roller {% #rollers %}

150+### Creating a roller {#rollers}

152

151

153

152

154

153

@@ -176,24 +175,22 @@ these factors to be included in the roller documentation.

176governing Urbit ID. They will require a few changes to accommodate the new

175governing Urbit ID. They will require a few changes to accommodate the new

177system. Some of this has been implicit above, but to be clear, we will only be

176system. Some of this has been implicit above, but to be clear, we will only be

178making a couple minor alterations:

177making a couple minor alterations:

178+ - Once a star's spawn proxy is set to the layer 2 address, it can't be switched

179+ back, and they can no longer spawn layer 1 planets.

180+ - Galaxies and their proxies cannot be deposited to layer 2.

181+Some other minor details are yet to be worked out, but again, nothing will change for those who wish to remain on layer 1.

179

182

180−- Once a star's spawn proxy is set to the layer 2 address, it can't be switched

181− back, and they can no longer spawn layer 1 planets.

182−- Galaxies and their proxies cannot be deposited to layer 2.

183− Some other minor details are yet to be worked out, but again, nothing will change for those who wish to remain on layer 1.

184−

185−### Technical details {% #technical %}

183+### Technical details {#technical}

186

184

187What's really going on behind the scenes here? Briefly, only the data of the Urbit ID transactions will be posted on-chain, while computation and state storage will now happen on your ship.

185What's really going on behind the scenes here? Briefly, only the data of the Urbit ID transactions will be posted on-chain, while computation and state storage will now happen on your ship.

188

186

189In layer 1, the [Ethereum Virtual Machine (EVM)](https://ethereum.org/en/developers/docs/evm/) guarantees the validity of state transitions, while for layer 2 transactions, each Urbit node guarantees the validity of the state transitions.

187In layer 1, the [Ethereum Virtual Machine (EVM)](https://ethereum.org/en/developers/docs/evm/) guarantees the validity of state transitions, while for layer 2 transactions, each Urbit node guarantees the validity of the state transitions.

190

188

191Changes to the state of Urbit ID on layer 1 works as follows:

189Changes to the state of Urbit ID on layer 1 works as follows:

192−

193−1. A transaction is posted to the Ethereum blockchain.

190+ 1. A transaction is posted to the Ethereum blockchain.

194−2. The EVM calculates the resulting state transition and checks its validity, then updates the state.

191+ 2. The EVM calculates the resulting state transition and checks its validity, then updates the state.

195−3. Your urbit downloads the new state from an Ethereum node.

192+ 3. Your urbit downloads the new state from an Ethereum node.

196−4. Your urbit makes the final decision on whether the new state is valid.

193+ 4. Your urbit makes the final decision on whether the new state is valid.

197

194

198In practice, the fourth step is never used in layer 1. The primary change to our

195In practice, the fourth step is never used in layer 1. The primary change to our

199security model is that we are cutting out step 2 and beefing up step 4. Your

196security model is that we are cutting out step 2 and beefing up step 4. Your

@@ -203,7 +200,7 @@ blockchain, rather than the EVM.

203Since [Urbit OS](/docs/glossary/arvo) is deterministic, and Hoon has some nice formal

200Since [Urbit OS](/docs/glossary/arvo) is deterministic, and Hoon has some nice formal

204properties, it turns out to be a great language for writing smart contracts. Thus we are effectively swapping the Ethereum smart contract with a “Hoon smart contract” run locally on your ship.

201properties, it turns out to be a great language for writing smart contracts. Thus we are effectively swapping the Ethereum smart contract with a “Hoon smart contract” run locally on your ship.

205

202

206−#### Further Resources {% #resources %}

203+#### Further Resources {#resources}

207

204

208We want to keep this post brief and non-technical, so that's all we'll say about

205We want to keep this post brief and non-technical, so that's all we'll say about

209it for now. To find out more, you have a few directions to go on. We held a

206it for now. To find out more, you have a few directions to go on. We held a

@@ -220,3 +217,4 @@ post on the `urbit-dev` mailing list. Lastly, the primary working branch on

220Github for the Urbit side of naive rollups is

217Github for the Urbit side of naive rollups is

221[here](https://github.com/urbit/urbit/tree/philip/naive), though it is not the

218[here](https://github.com/urbit/urbit/tree/philip/naive), though it is not the

222only place code is accumulating.

219only place code is accumulating.

220+

content/blog/security-and-continuity.md+5−3

@@ -1,8 +1,7 @@

1+++

1+++

2title = "Security and Continuity"

2title = "Security and Continuity"

3description = "An update on our primary infrastructure milestones for 2020."

3description = "An update on our primary infrastructure milestones for 2020."

4−date = "2020-11-30"

4+date = 2020-12-01

5−

6[extra]

5[extra]

7author = "Galen Wolfe-Pauly"

6author = "Galen Wolfe-Pauly"

8ship = "~ravmel-ropdyl"

7ship = "~ravmel-ropdyl"

@@ -21,6 +20,7 @@ For this year, we committed to completing two things: passing a third-party secu

21

20

22We’ve been steadily making progress on these two fronts, and I’m happy to report both are nearly complete. We’ll walk through some of the details here and then follow up in another post soon to report on how the final work turned out.

21We’ve been steadily making progress on these two fronts, and I’m happy to report both are nearly complete. We’ll walk through some of the details here and then follow up in another post soon to report on how the final work turned out.

23

22

23+

24## Ames Audit

24## Ames Audit

25

25

26Urbit OS is an ‘overlay OS’: it runs on top of (pretty much) any flavor of Unix. Each Urbit OS node communicates with other nodes over UDP using Ames, the Urbit-specific networking protocol.

26Urbit OS is an ‘overlay OS’: it runs on top of (pretty much) any flavor of Unix. Each Urbit OS node communicates with other nodes over UDP using Ames, the Urbit-specific networking protocol.

@@ -41,16 +41,18 @@ The good thing about an audit scoped in this way is that we can trust the protoc

41

41

42As of the end of November 2020, the audit is very nearly complete, and we’ve handled all the important issues that were brought up. We’ll post the results and talk about our mitigation strategies in a future writeup.

42As of the end of November 2020, the audit is very nearly complete, and we’ve handled all the important issues that were brought up. We’ll post the results and talk about our mitigation strategies in a future writeup.

43

43

44+

44## Continuity

45## Continuity

45

46

46Urbit is designed to last a long time. What’s the use of a personal computer if it’s gonna disappear along with all the data you put in it? Ideally, you can put your Urbit on a USB stick, forget about it for ten years and have it work again when you plug it in. It’ll need to update for a while, but once our work on continuity is complete, your urbit should be able to upgrade itself through ten years of updates, all over the air.

47Urbit is designed to last a long time. What’s the use of a personal computer if it’s gonna disappear along with all the data you put in it? Ideally, you can put your Urbit on a USB stick, forget about it for ten years and have it work again when you plug it in. It’ll need to update for a while, but once our work on continuity is complete, your urbit should be able to upgrade itself through ten years of updates, all over the air.

47

48

48−While Urbit is designed to upgrade seamlessly over the network we have occasionally run into issues that have caused us to reboot the entire network. Most of the time this is when some incompatibility between the interpreter and the kernel means we have to force everyone to do a hard reset to ensure compatibility between the two. Our current work on continuity addresses this. Soon, your urbit will tell you when your interpreter needs to be upgraded. At first this won’t be that different from an application notifying you to download an update. Eventually, we think we can make this a lot smoother.

49+While Urbit is designed to upgrade seamlessly over the network we have occasionally run into issues that have caused us to reboot the entire network. Most of the time this is when some incompatibility between the interpreter and the kernel means we have to force everyone to do a hard reset to ensure compatibility between the two. Our current work on continuity addresses this. Soon, your urbit will tell you when your interpreter needs to be upgraded. At first this won’t be that different from an application notifying you to download an update. Eventually, we think we can make this a lot smoother.

49

50

50A network reboot isn’t the only way that we can break continuity. Urbit is a general-purpose computer — which means you’re free to attempt to destroy it. If, for any reason, you do manage to screw the system up we want you to be able to get your data out and effectively reset continuity on a single node. We built the affordance for that a while ago, but before the end of the year we’ll also distribute tooling to migrate userspace data between hard resets.

51A network reboot isn’t the only way that we can break continuity. Urbit is a general-purpose computer — which means you’re free to attempt to destroy it. If, for any reason, you do manage to screw the system up we want you to be able to get your data out and effectively reset continuity on a single node. We built the affordance for that a while ago, but before the end of the year we’ll also distribute tooling to migrate userspace data between hard resets.

51

52

52The combination of version negotiation and data migration should afford us the ability to run the network indefinitely into the future. Unfortunately, to get this change in, we’ll need to reset the network. We’re optimistic that this will be the last time we ever do it. And, given our data migration tooling, this breach won’t involve losing data.

53The combination of version negotiation and data migration should afford us the ability to run the network indefinitely into the future. Unfortunately, to get this change in, we’ll need to reset the network. We’re optimistic that this will be the last time we ever do it. And, given our data migration tooling, this breach won’t involve losing data.

53

54

55+

54## Status + conclusion

56## Status + conclusion

55

57

56We have been working with auditors since this summer and should have a report ready to publish in the next few weeks. Both version negotiation and data migration are in testing and are ready to be deployed.

58We have been working with auditors since this summer and should have a report ready to publish in the next few weeks. Both version negotiation and data migration are in testing and are ready to be deployed.

content/blog/security-audit.md+50−46

@@ -1,153 +1,157 @@

1+++

1+++

2title = "Ames Security Audit and the Future of the Protocol"

2title = "Ames Security Audit and the Future of the Protocol"

3description = "Ames’ design has unparalleled potential to deter, mitigate, and recover from attacks, since every packet is authenticated and encrypted and backed by a stable, decentralized PKI."

3description = "Ames’ design has unparalleled potential to deter, mitigate, and recover from attacks, since every packet is authenticated and encrypted and backed by a stable, decentralized PKI."

4−date = "2020-12-17"

4+date = 2020-12-18

5−

6[extra]

5[extra]

7author = "Ted Blackman + Anthony Arroyo"

6author = "Ted Blackman + Anthony Arroyo"

8ship = "~rovnys-ricfer + ~poldec-tonteg"

7ship = "~rovnys-ricfer + ~poldec-tonteg"

9image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/20201218-audit.png"

8image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/20201218-audit.png"

10+++

9+++

11

10

11+<br>

12+

12

13

13

14

15+<br>

16+

14The security firm Leviathan has now finished their initial audit of the security of Urbit's Ames network protocol. In addition to their review of Ames, we also asked them to identify any other issues in order to help guide further development.

17The security firm Leviathan has now finished their initial audit of the security of Urbit's Ames network protocol. In addition to their review of Ames, we also asked them to identify any other issues in order to help guide further development.

15

18

16I'm pleased to report they confirmed the cryptographic soundness of the protocol, namely that "a ship must have possession of their own valid Urbit key in order to authenticate as that ship and to send valid Ames messages. Additionally, no other ship except the two communicating may be able to decrypt or modify messages during transport."

19I'm pleased to report they confirmed the cryptographic soundness of the protocol, namely that "a ship must have possession of their own valid Urbit key in order to authenticate as that ship and to send valid Ames messages. Additionally, no other ship except the two communicating may be able to decrypt or modify messages during transport."

17

20

18−This means Ames uses cryptography in a mathematically sound manner that protects your privacy, keeps your secrets secret, and ensures nobody else will be able to impersonate you on the network. Since this was an architectural audit, it’s possible there are still vulnerabilities in the runtime implementation. Until the runtime has been hardened, Tlon continues to recommend against storing valuables in your ship.

21+This means Ames uses cryptography in a mathematically sound manner that protects your privacy, keeps your secrets secret, and ensures nobody else will be able to impersonate you on the network. Since this was an architectural audit, it’s possible there are still vulnerabilities in the runtime implementation. Until the runtime has been hardened, Tlon continues to recommend against storing valuables in your ship.

19

22

20Aside from a couple of minor issues that have already been resolved, there are three general classes of problem highlighted in their report that future work will need to address:

23Aside from a couple of minor issues that have already been resolved, there are three general classes of problem highlighted in their report that future work will need to address:

21

24

22−- Forward secrecy

25++ Forward secrecy

23−- Protection against denial of service attacks

26++ Protection against denial of service attacks

24−- Enforcement of social boundaries

27++ Enforcement of social boundaries

25

28

26Ames’ design allows for versioning of the protocol, which means that the proposed changes below can be deployed as over-the-air updates as they become more pressing concerns. This feature gives us confidence that we can address future security issues as they arise.

29Ames’ design allows for versioning of the protocol, which means that the proposed changes below can be deployed as over-the-air updates as they become more pressing concerns. This feature gives us confidence that we can address future security issues as they arise.

27

30

28−We will need to improve all of these over the next couple of years, as independent lines of work. As the network grows: better forward secrecy will decrease the damage from a key getting compromised; resistance against denial of service attacks will make the Urbit network resilient to increasingly determined saboteurs; and stricter enforcement of social boundaries will let Urbit’s social networks remain safe and friendly despite potentially increasingly large numbers of bad actors and increasingly complex app ecosystems.

31+We will need to improve all of these over the next couple of years, as independent lines of work. As the network grows: better forward secrecy will decrease the damage from a key getting compromised; resistance against denial of service attacks will make the Urbit network resilient to increasingly determined saboteurs; and stricter enforcement of social boundaries will let Urbit’s social networks remain safe and friendly despite potentially increasingly large numbers of bad actors and increasingly complex app ecosystems.

29

32

30## Forward Secrecy

33## Forward Secrecy

31

34

32−A protocol is said to have forward secrecy if compromising a key used in a recent message doesn’t also compromise all previous messages. Similarly, a protocol is said to have backward secrecy -- also called future secrecy -- if compromising a key used in a previous message fails to compromise all future messages. Ames has some degree of both, but more would be better, to decrease the damage an attacker could inflict by compromising a key.

35+A protocol is said to have forward secrecy if compromising a key used in a recent message doesn’t also compromise all previous messages. Similarly, a protocol is said to have backward secrecy -- also called future secrecy -- if compromising a key used in a previous message fails to compromise all future messages. Ames has some degree of both, but more would be better, to decrease the damage an attacker could inflict by compromising a key.

33

36

34−As it stands, an Urbit user can change their Ames keys whenever they want, by conducting an Ethereum transaction to update the Ames public key listed in the Azimuth contract, which implements Urbit’s PKI on Ethereum. Compromise of one Ames private key does not compromise earlier or later keys, so this has both forward and backward secrecy. The main drawback is that Ethereum transactions can be expensive, so key rotation is likely to be infrequent, and an attacker might be able to gain access to a long stretch of time by compromising a single key.

37+As it stands, an Urbit user can change their Ames keys whenever they want, by conducting an Ethereum transaction to update the Ames public key listed in the Azimuth contract, which implements Urbit’s PKI on Ethereum. Compromise of one Ames private key does not compromise earlier or later keys, so this has both forward and backward secrecy. The main drawback is that Ethereum transactions can be expensive, so key rotation is likely to be infrequent, and an attacker might be able to gain access to a long stretch of time by compromising a single key.

35

38

36Various key rotation “ratchet” schemes could be added to Ames to establish varying degrees of forward and backward secrecy, and other kinds of cryptographic protections beyond basic soundness, such as break-in recovery.

39Various key rotation “ratchet” schemes could be added to Ames to establish varying degrees of forward and backward secrecy, and other kinds of cryptographic protections beyond basic soundness, such as break-in recovery.

37

40

38−Right now, changing a key through Azimuth is a manual process. It could be automated, possibly as one of a suite of services that an Urbit Provider will offer. Unfortunately, each key rotation costs the user money, so automating rotation could get prohibitively expensive.

41+Right now, changing a key through Azimuth is a manual process. It could be automated, possibly as one of a suite of services that an Urbit Provider will offer. Unfortunately, each key rotation costs the user money, so automating rotation could get prohibitively expensive.

39−Existing protocols, such as the Signal app's encrypted messaging protocol, the Noise protocol framework, and the Wireguard VPN protocol, use ephemeral Diffie-Hellman key exchange and KDF chaining to achieve forward and backward secrecy and self-healing.

42+Existing protocols, such as the Signal app's encrypted messaging protocol, the Noise protocol framework, and the Wireguard VPN protocol, use ephemeral Diffie-Hellman key exchange and KDF chaining to achieve forward and backward secrecy and self-healing.

40

43

41−Ames could be upgraded to use one of these existing ratchet algorithms, or we might create an Urbit-specific variant optimized for the Urbit network. This is work that should be done, but fortunately it will not require any novel research or drastic changes to Ames’s architecture.

44+Ames could be upgraded to use one of these existing ratchet algorithms, or we might create an Urbit-specific variant optimized for the Urbit network. This is work that should be done, but fortunately it will not require any novel research or drastic changes to Ames’s architecture.

42

45

43While Urbit’s cryptographic protections don’t yet match those of Signal or a few other privacy-focused apps, Ames is cryptographically sound, and since Urbit updates itself over-the-air and is backed by a stable, decentralized PKI, I’m confident that the level of sophistication of Urbit’s cryptography has the potential to be world-class with just a bit more work.

46While Urbit’s cryptographic protections don’t yet match those of Signal or a few other privacy-focused apps, Ames is cryptographically sound, and since Urbit updates itself over-the-air and is backed by a stable, decentralized PKI, I’m confident that the level of sophistication of Urbit’s cryptography has the potential to be world-class with just a bit more work.

44

47

45## Denial of Service

48## Denial of Service

46

49

47−A denial of service (DoS) attack against an Urbit ship is an attempt to overwhelm it remotely by sending it network data in such a way as to interfere with the ship’s ability to communicate with other ships or process other events -- usually by hogging its resources (computational power, memory, or bandwidth) until normal operation slows down or ceases entirely. Since the promise of Urbit is that everyone can run their own server, that server needs to be able to defend itself against DoS attacks. This is in fact one of the main impediments to running your own server in the modern world.

50+A denial of service (DoS) attack against an Urbit ship is an attempt to overwhelm it remotely by sending it network data in such a way as to interfere with the ship’s ability to communicate with other ships or process other events -- usually by hogging its resources (computational power, memory, or bandwidth) until normal operation slows down or ceases entirely. Since the promise of Urbit is that everyone can run their own server, that server needs to be able to defend itself against DoS attacks. This is in fact one of the main impediments to running your own server in the modern world.

48

51

49−Right now, Urbit has no protection. Soon, it will need to at least be able to resist a simple attack carried out by an individual. Eventually, it should be able to resist a determined Distributed Denial of Service (“DDoS”) attack, which is more difficult.

52+Right now, Urbit has no protection. Soon, it will need to at least be able to resist a simple attack carried out by an individual. Eventually, it should be able to resist a determined Distributed Denial of Service (“DDoS”) attack, which is more difficult.

50

53

51−There are two categories of DoS attacks in Urbit: authenticated and unauthenticated. An authenticated attack requires access to a ship's private key to construct valid Ames packets intended to overwhelm a target. All authenticated attacks will be handled primarily through enforcement of social boundaries, as discussed in the next section.

54+There are two categories of DoS attacks in Urbit: authenticated and unauthenticated. An authenticated attack requires access to a ship's private key to construct valid Ames packets intended to overwhelm a target. All authenticated attacks will be handled primarily through enforcement of social boundaries, as discussed in the next section.

52

55

53An unauthenticated DoS attack constructs packets that eventually fail to authenticate and decrypt but still overwhelm the target by causing it to waste resources (CPU, memory, disk, bandwidth) in such a way that it can't keep up with legitimate communications.

56An unauthenticated DoS attack constructs packets that eventually fail to authenticate and decrypt but still overwhelm the target by causing it to waste resources (CPU, memory, disk, bandwidth) in such a way that it can't keep up with legitimate communications.

54

57

55−An unauthenticated DoS attack relies on the lack of Sybil resistance of IP networks: it's possible to generate new IP addresses rapidly, and a determined attacker might also be able to spoof its sender IP address. This is best considered an IP-layer attack that must be handled mostly at the IP layer itself, by maintaining state about which IP addresses can be trusted and which can't, determined empirically and heuristically by the Urbit runtime. The best any higher-level protocol, such as Ames or TCP, can do is make it as cheap as possible for a DoS target to reject a bad packet.

58+An unauthenticated DoS attack relies on the lack of Sybil resistance of IP networks: it's possible to generate new IP addresses rapidly, and a determined attacker might also be able to spoof its sender IP address. This is best considered an IP-layer attack that must be handled mostly at the IP layer itself, by maintaining state about which IP addresses can be trusted and which can't, determined empirically and heuristically by the Urbit runtime. The best any higher-level protocol, such as Ames or TCP, can do is make it as cheap as possible for a DoS target to reject a bad packet.

56

59

57The overall strategy that Ames can take, as a protocol layering over the IP protocol, is to add an authentication procedure to each packet that can quickly identify bad packets, which an implementation will then use to mark that IP address as suspect and to refrain from adding the sender IP to a list of known-good IPs.

60The overall strategy that Ames can take, as a protocol layering over the IP protocol, is to add an authentication procedure to each packet that can quickly identify bad packets, which an implementation will then use to mark that IP address as suspect and to refrain from adding the sender IP to a list of known-good IPs.

58

61

59−Currently, Ames handles this by attempting to decrypt a message and rejecting the message on failure. This may be a more costly solution than other methods, such as attaching a signature or a MAC to each message. The way to mitigate unauthenticated attacks is to make bad packets fail faster by augmenting each packet with a signature or MAC to each packet, since those are faster to validate than encryption.

62+Currently, Ames handles this by attempting to decrypt a message and rejecting the message on failure. This may be a more costly solution than other methods, such as attaching a signature or a MAC to each message. The way to mitigate unauthenticated attacks is to make bad packets fail faster by augmenting each packet with a signature or MAC to each packet, since those are faster to validate than encryption.

60

63

61−So far, we have identified three approaches that could be taken here. Of these three, Leviathan recommended the end-to-end HMAC solution, since that would not impose additional CPU requirements on packet-relay nodes, such as stars.

64+So far, we have identified three approaches that could be taken here. Of these three, Leviathan recommended the end-to-end HMAC solution, since that would not impose additional CPU requirements on packet-relay nodes, such as stars.

62

65

63−- Sign each packet, and any relay or final recipient could validate the signature

66++ Sign each packet, and any relay or final recipient could validate the signature

64−- Wrap each packet in an HMAC, validated by the final receiver

67++ Wrap each packet in an HMAC, validated by the final receiver

65−- Wrap each packet in a HMAC for each hop in a relay chain; each relay would validate and strip the previous HMAC and add a new one for the next hop

68++ Wrap each packet in a HMAC for each hop in a relay chain; each relay would validate and strip the previous HMAC and add a new one for the next hop

66

69

67−Any of these solutions would be attempts to increase the rate at which the network could discard invalid packets, with different tradeoffs. I'll back up a bit to provide some context, and then I'll compare the approaches.

70+Any of these solutions would be attempts to increase the rate at which the network could discard invalid packets, with different tradeoffs. I'll back up a bit to provide some context, and then I'll compare the approaches.

68

71

69−In any DoS solution, a planet will want to block or throttle IPs that have been sending it packets that fail to authenticate and decrypt. Ideally, a star will help protect planets for whom it’s relaying, too. Many different arrangements among galaxy, star, and planet are imaginable here, from an open policy to a policy wherein each packet has to come from a known-good IP. This sort of paranoid, closed-off arrangement might still not be enough to withstand a determined DDoS, but it's difficult for me to imagine doing better than that without launching Urbit-specific ISPs. Ames packets are cryptographically authenticated, so an Urbit ISP would actually be feasible.

72+In any DoS solution, a planet will want to block or throttle IPs that have been sending it packets that fail to authenticate and decrypt. Ideally, a star will help protect planets for whom it’s relaying, too. Many different arrangements among galaxy, star, and planet are imaginable here, from an open policy to a policy wherein each packet has to come from a known-good IP. This sort of paranoid, closed-off arrangement might still not be enough to withstand a determined DDoS, but it's difficult for me to imagine doing better than that without launching Urbit-specific ISPs. Ames packets are cryptographically authenticated, so an Urbit ISP would actually be feasible.

70

73

71−This brings us back to the three possible ways of mitigating DoS from within the Ames protocol. They all involve adding a piece of authenticating information to each packet that can be verified more quickly than waiting for the cyphertext to fail to decrypt — Ames's symmetric encryption is authenticated, so it's not a cryptographic soundness issue, but the performance impact of trying to decrypt could be significant enough to make it hard to prevent a DoS.

74+This brings us back to the three possible ways of mitigating DoS from within the Ames protocol. They all involve adding a piece of authenticating information to each packet that can be verified more quickly than waiting for the cyphertext to fail to decrypt — Ames's symmetric encryption is authenticated, so it's not a cryptographic soundness issue, but the performance impact of trying to decrypt could be significant enough to make it hard to prevent a DoS.

72

75

73As-is, an Ames packet is basically `[protocol-version checksum sndr rcvr (nullable origin) cyphertext]` (visit [this PR](https://github.com/urbit/urbit/pull/4051#issue-530369627) for a full specification). Let’s walk through the construction of the packet and how it can be upgraded to offer different DOS mitigations.

76As-is, an Ames packet is basically `[protocol-version checksum sndr rcvr (nullable origin) cyphertext]` (visit [this PR](https://github.com/urbit/urbit/pull/4051#issue-530369627) for a full specification). Let’s walk through the construction of the packet and how it can be upgraded to offer different DOS mitigations.

74

77

75### DoS Mitigation Approach 1: Signature

78### DoS Mitigation Approach 1: Signature

76

79

77−The first approach to DoS protection would be to add a signature to the packet. The signature would cover everything except the checksum and the origin, since those need to be swapped out by relays. The signature would probably obviate the need for the (20-bit) checksum, although we could also leave it in there if we can't figure out what else to do with those header bits.

80+The first approach to DoS protection would be to add a signature to the packet. The signature would cover everything except the checksum and the origin, since those need to be swapped out by relays. The signature would probably obviate the need for the (20-bit) checksum, although we could also leave it in there if we can't figure out what else to do with those header bits.

78

81

79#### Advantages of a signature over other approaches

82#### Advantages of a signature over other approaches

80

83

81−- It can be validated by anyone on the network. Relays would not need to modify it. This might also give it symmetry with the upcoming remote scry protocol, which might also sign every packet. I'm not quite sure this is an important property, actually, but it might theoretically make launching an Urbit ISP or internet backbone easier one day.

84+- It can be validated by anyone on the network. Relays would not need to modify it. This might also give it symmetry with the upcoming remote scry protocol, which might also sign every packet. I'm not quite sure this is an important property, actually, but it might theoretically make launching an Urbit ISP or internet backbone easier one day.

82- It would be signed directly by the key listed on Ethereum, not something that might get ratcheted at some point for better forward secrecy — this could eventually lower the rate at which intermediate validators need their key caches invalidated, although this is a bit of a theoretical concern.

85- It would be signed directly by the key listed on Ethereum, not something that might get ratcheted at some point for better forward secrecy — this could eventually lower the rate at which intermediate validators need their key caches invalidated, although this is a bit of a theoretical concern.

83

86

84#### Disadvantages of a signature over other approaches

87#### Disadvantages of a signature over other approaches

85

88

86- Generating and validating a signature is significantly slower than generating and validating an HMAC.

89- Generating and validating a signature is significantly slower than generating and validating an HMAC.

87−- An ECDSA signature is 64 bytes, which is ~6% of a packet payload. As far as I can tell, it can't be compressed.

90+- An ECDSA signature is 64 bytes, which is ~6% of a packet payload. As far as I can tell, it can't be compressed.

88- Since the signature could be validated by anyone, it doesn't attest to a specific communication channel, so it might not help as much with IP filtering.

91- Since the signature could be validated by anyone, it doesn't attest to a specific communication channel, so it might not help as much with IP filtering.

89

92

90### DoS Mitigation Approach 2: End-to-End HMAC

93### DoS Mitigation Approach 2: End-to-End HMAC

91

94

92−The second approach would be to use an HMAC instead of a signature, validated by the eventual receiver. This HMAC would also cover everything except the mug and origin. I'm calling this the "end-to-end HMAC" design. An HMAC requires a shared secret, for which we could use the same symmetric key that Ames uses.

95+The second approach would be to use an HMAC instead of a signature, validated by the eventual receiver. This HMAC would also cover everything except the mug and origin. I'm calling this the "end-to-end HMAC" design. An HMAC requires a shared secret, for which we could use the same symmetric key that Ames uses.

93

96

94#### Advantages of end-to-end HMAC

97#### Advantages of end-to-end HMAC

95

98

96- It's simple in some sense; relays don't need to do anything cryptographic.

99- It's simple in some sense; relays don't need to do anything cryptographic.

97- HMACs are much faster to create and validate than signatures.

100- HMACs are much faster to create and validate than signatures.

98−- HMACs, since they're hashes, can be truncated arbitrarily and still maintain some security — to find hash collisions, you'd still have to guess what packet||shared-secret would hash to; it would just be a smaller search space. Since Ames's encryption already guarantees authentication and we'd just be using this as a performance optimization, I suspect we could get away with using one that's significantly smaller than a signature — I'm not sure how small, but if 4 bytes would be enough in practice, that would take up less than 0.5% of the space in a packet.

101+- HMACs, since they're hashes, can be truncated arbitrarily and still maintain some security — to find hash collisions, you'd still have to guess what packet||shared-secret would hash to; it would just be a smaller search space. Since Ames's encryption already guarantees authentication and we'd just be using this as a performance optimization, I suspect we could get away with using one that's significantly smaller than a signature — I'm not sure how small, but if 4 bytes would be enough in practice, that would take up less than 0.5% of the space in a packet.

99

102

100#### Disadvantages of end-to-end HMAC

103#### Disadvantages of end-to-end HMAC

101

104

102−- Only the recipient can validate. This means the authentication couldn't be used by relays to discard invalid packets. The recipient could provide back-pressure out-of-band to a relay to ask the relay to discard packets from an IP with an invalid HMAC, but this is indirect and might need to filter backward through multiple relays to work properly.

105+- Only the recipient can validate. This means the authentication couldn't be used by relays to discard invalid packets. The recipient could provide back-pressure out-of-band to a relay to ask the relay to discard packets from an IP with an invalid HMAC, but this is indirect and might need to filter backward through multiple relays to work properly.

103

106

104### DoS Mitigation Approach 3: Point-to-Point HMAC

107### DoS Mitigation Approach 3: Point-to-Point HMAC

105

108

106−The third approach, which is what I would build unless convinced otherwise, is what I'm calling "point-to-point HMAC". This design would include a different HMAC for each hop in a relay chain, instead of (or maybe in addition to) including one end-to-end HMAC.

109+The third approach, which is what I would build unless convinced otherwise, is what I'm calling "point-to-point HMAC". This design would include a different HMAC for each hop in a relay chain, instead of (or maybe in addition to) including one end-to-end HMAC.

107

110

108−We have a couple different options for how to construct the shared secret for each hop. I would intuitively construct it using a Diffie-Hellman of my private signing key and your public signing key — the "networking keys" on Ethereum include a currently unused signing key in addition to the encryption key that Ames uses. This way even if we add more forward secrecy to Ames, changing the symmetric key used for encryption, relays wouldn't have to have their caches invalidated as often; the state required to perform relaying wouldn't be as tied to the state required to receive a message.

111+We have a couple different options for how to construct the shared secret for each hop. I would intuitively construct it using a Diffie-Hellman of my private signing key and your public signing key — the "networking keys" on Ethereum include a currently unused signing key in addition to the encryption key that Ames uses. This way even if we add more forward secrecy to Ames, changing the symmetric key used for encryption, relays wouldn't have to have their caches invalidated as often; the state required to perform relaying wouldn't be as tied to the state required to receive a message.

109

112

110#### Advantages of point-to-point HMAC

113#### Advantages of point-to-point HMAC

111

114

112−- A star could perform some validation on every packet it's asked to relay. This makes it more difficult for an attacker to route a ton of packets to a planet through a star, or even through many relays. Signatures also have this property, but they're slower to verify. This approach and the signature approach, but not the end-to-end HMACs, force an attacker to use an (at least partially) authenticated attack in order to use a relay as a way to get to a planet.

115+- A star could perform some validation on every packet it's asked to relay. This makes it more difficult for an attacker to route a ton of packets to a planet through a star, or even through many relays. Signatures also have this property, but they're slower to verify. This approach and the signature approach, but not the end-to-end HMACs, force an attacker to use an (at least partially) authenticated attack in order to use a relay as a way to get to a planet.

113- A planet could quickly validate that a relayed packet actually came from its star, not an attacker who's managed to spoof the star's IP address.

116- A planet could quickly validate that a relayed packet actually came from its star, not an attacker who's managed to spoof the star's IP address.

114

117

115#### Disadvantages of point-to-point HMAC

118#### Disadvantages of point-to-point HMAC

116

119

117- Not everyone on the network can validate a packet, unlike a signature.

120- Not everyone on the network can validate a packet, unlike a signature.

118−- Each relay needs to validate and strip off the previous HMAC and create a new one before sending it. This should be quite fast, since an HMAC is just a hash, but it's still some CPU, and potentially creates an imbalance where an attacker could induce the relay to spend more CPU in validation than the attacker spent in constructing the packets.

121+- Each relay needs to validate and strip off the previous HMAC and create a new one before sending it. This should be quite fast, since an HMAC is just a hash, but it's still some CPU, and potentially creates an imbalance where an attacker could induce the relay to spend more CPU in validation than the attacker spent in constructing the packets.

119−- By itself, it doesn't validate the cyphertext in an end-to-end way. I suspect we might want to include both a per-route HMAC and an end-to-end one, especially if we use truncated HMACs — although per-route might be enough on its own, since if the receiver fails to validate a bunch of packets whose HMACs were validated by the relay, the receiver can ask the relay to block that whole Urbit address regardless of IP, so it shouldn't be possible to sustain that kind of attack for long.

122+- By itself, it doesn't validate the cyphertext in an end-to-end way. I suspect we might want to include both a per-route HMAC and an end-to-end one, especially if we use truncated HMACs — although per-route might be enough on its own, since if the receiver fails to validate a bunch of packets whose HMACs were validated by the relay, the receiver can ask the relay to block that whole Urbit address regardless of IP, so it shouldn't be possible to sustain that kind of attack for long.

120

123

121#### An Aside About Cryptographic Performance

124#### An Aside About Cryptographic Performance

122

125

123−I'm not sure exactly how much faster HMAC is. According to DJB (https://ed25519.cr.yp.to/ed25519-20110705.pdf), an ECDSA signature can be created in around 30 microseconds and verified in around 100 microseconds. This source (https://www.jacksondunstan.com/articles/3206) suggests about 21 microseconds for HMAC-SHA256, so about a 1.5x improvement in generation speed and 5x in validation speed. We should verify these numbers for ourselves before making a decision.

126+I'm not sure exactly how much faster HMAC is. According to DJB (https://ed25519.cr.yp.to/ed25519-20110705.pdf), an ECDSA signature can be created in around 30 microseconds and verified in around 100 microseconds. This source (https://www.jacksondunstan.com/articles/3206) suggests about 21 microseconds for HMAC-SHA256, so about a 1.5x improvement in generation speed and 5x in validation speed. We should verify these numbers for ourselves before making a decision.

124

127

125### DoS Protection Strategy and Timeline

128### DoS Protection Strategy and Timeline

126

129

127−Tlon is not currently pursuing adding any of the extra cryptographic authentication on Ames packets described above. Since this is ultimately a performance issue, there are other more pressing performance issues that we could improve upon before decryption will become the limiting factor in how many packets can be processed by a ship. We will revisit this authentication performance question once some of the low-hanging fruit has been done, perhaps roughly a year from now.

130+Tlon is not currently pursuing adding any of the extra cryptographic authentication on Ames packets described above. Since this is ultimately a performance issue, there are other more pressing performance issues that we could improve upon before decryption will become the limiting factor in how many packets can be processed by a ship. We will revisit this authentication performance question once some of the low-hanging fruit has been done, perhaps roughly a year from now.

128

131

129Since the audit, we’ve already improved the Ames packet format to allow faster parsing, faster validation of basic fields, and faster relaying; in the future, increases in performance of Nock execution and inter-process communication between Urbit's I/O process and Nock worker would allow Urbit to absorb somewhat more punishment before service can be effectively denied.

132Since the audit, we’ve already improved the Ames packet format to allow faster parsing, faster validation of basic fields, and faster relaying; in the future, increases in performance of Nock execution and inter-process communication between Urbit's I/O process and Nock worker would allow Urbit to absorb somewhat more punishment before service can be effectively denied.

130

133

131## Enforcement of Social Boundaries

134## Enforcement of Social Boundaries

132

135

133−While Urbit needs to rely largely on its runtime to mitigate unauthenticated attacks, any attack conducted from an Urbit ship needs to be handled inside Arvo itself, not just by IP filtering in the runtime. Just like in any DoS, an attacker ship might try to induce you to use too much memory, CPU, or disk space in order to sabotage normal operation. An authenticated attack is harder to define than an unauthenticated attack, because it depends on what social relationship the attacker and target have, and it involves valid, authenticated Ames packets; once discovered, though, it’s easier to mitigate, because it can use Urbit’s permanent identity system to enforce social consequences, i.e. stop listening to that Urbit address and possibly encourage others to do so as well.

136+While Urbit needs to rely largely on its runtime to mitigate unauthenticated attacks, any attack conducted from an Urbit ship needs to be handled inside Arvo itself, not just by IP filtering in the runtime. Just like in any DoS, an attacker ship might try to induce you to use too much memory, CPU, or disk space in order to sabotage normal operation. An authenticated attack is harder to define than an unauthenticated attack, because it depends on what social relationship the attacker and target have, and it involves valid, authenticated Ames packets; once discovered, though, it’s easier to mitigate, because it can use Urbit’s permanent identity system to enforce social consequences, i.e. stop listening to that Urbit address and possibly encourage others to do so as well.

134

137

135There are a couple of different kinds of authenticated attack: attempts to exploit vulnerabilities in the Nock worker (the interpreter, allocator, and jets) by causing particular Nock code to run, and attempts to induce the target to exhaust various computational resources.

138There are a couple of different kinds of authenticated attack: attempts to exploit vulnerabilities in the Nock worker (the interpreter, allocator, and jets) by causing particular Nock code to run, and attempts to induce the target to exhaust various computational resources.

136

139

137−Protecting against attempts to break out of the sandbox and hijack or otherwise interfere with the Unix process running Nock will require a process of hardening, fuzzing, and likely further security audits specifically evaluating the security of that boundary. This is largely out of scope of the Ames protocol itself, which was the subject of this audit.

140+Protecting against attempts to break out of the sandbox and hijack or otherwise interfere with the Unix process running Nock will require a process of hardening, fuzzing, and likely further security audits specifically evaluating the security of that boundary. This is largely out of scope of the Ames protocol itself, which was the subject of this audit.

141+

142+This leaves us with the latter case: resource exhaustion attacks. A peer could try to get my ship to use too much RAM, disk, CPU, or bandwidth by sending it valid Ames packets. This represents a social problem: a person on the network is trying to interfere with me. It's what's known in blockchain circles as an "attributable fault": once the attack is detected, it's trivial to determine the identity of the culprit.

138

143

139−This leaves us with the latter case: resource exhaustion attacks. A peer could try to get my ship to use too much RAM, disk, CPU, or bandwidth by sending it valid Ames packets. This represents a social problem: a person on the network is trying to interfere with me. It's what's known in blockchain circles as an "attributable fault": once the attack is detected, it's trivial to determine the identity of the culprit.

144+Once the attacker’s Urbit address is known, Urbit will fall back on the Sybil resistance of its identity system: there are a finite number of identities, each of which costs some money. Because Urbit identities are relatively permanent, they can be blocked permanently. As long as the expected value of an authenticated attack is less than the cost of the identity, the attacks won't happen very much — they'll cost money to sustain, instead of being self-perpetuating.

140

145

141−Once the attacker’s Urbit address is known, Urbit will fall back on the Sybil resistance of its identity system: there are a finite number of identities, each of which costs some money. Because Urbit identities are relatively permanent, they can be blocked permanently. As long as the expected value of an authenticated attack is less than the cost of the identity, the attacks won't happen very much — they'll cost money to sustain, instead of being self-perpetuating.

146+Attacks like this are best thought of as attempts to violate social boundaries. I don't want you using up too many of my resources; that's a social boundary, and an attempt to force my ship to spend its resources on your behalf constitutes a violation of this boundary. The strategy for mitigating these attacks is to impose social and, indirectly, economic consequences on the perpetrators. The main social consequence is other ships refusing to communicate with you anymore.

142

147

143−Attacks like this are best thought of as attempts to violate social boundaries. I don't want you using up too many of my resources; that's a social boundary, and an attempt to force my ship to spend its resources on your behalf constitutes a violation of this boundary. The strategy for mitigating these attacks is to impose social and, indirectly, economic consequences on the perpetrators. The main social consequence is other ships refusing to communicate with you anymore.

148+Some of this mitigation will take place in the Arvo kernel, and some will need to be application-specific. To protect the system from attackers, the kernel needs to be able to free space (Urbit is a single-level store, so there's no distinction between disk and RAM from Arvo's perspective) taken up by unfinished messages sent by peers. This can be done by allowing an application to ask Ames to delete partially received messages from a peer, generally replacing the received packets with an intent to nack (negative acknowledgment) to indicate that the transaction the peer wanted me to perform has been rejected.

144

149

145−Some of this mitigation will take place in the Arvo kernel, and some will need to be application-specific. To protect the system from attackers, the kernel needs to be able to free space (Urbit is a single-level store, so there's no distinction between disk and RAM from Arvo's perspective) taken up by unfinished messages sent by peers. This can be done by allowing an application to ask Ames to delete partially received messages from a peer, generally replacing the received packets with an intent to nack (negative acknowledgment) to indicate that the transaction the peer wanted me to perform has been rejected.

150+Applications should also be able to set resource usage policies that the Arvo kernel will enforce. For example, a chat application should configure Ames to reject any chat messages larger than, say, two hundred kilobytes. A file-sharing application would need a much larger per-message limit (ideally no per-message limit), but it might need to place a cap on its bandwidth usage to make sure lower-latency communications aren't swamped by a large file transfer. This kernel/application interface starts to resemble a permissioning or capabilities system, and it could be built as part of the crucial larger project of providing for configurable application permissions.

146

151

147−Applications should also be able to set resource usage policies that the Arvo kernel will enforce. For example, a chat application should configure Ames to reject any chat messages larger than, say, two hundred kilobytes. A file-sharing application would need a much larger per-message limit (ideally no per-message limit), but it might need to place a cap on its bandwidth usage to make sure lower-latency communications aren't swamped by a large file transfer. This kernel/application interface starts to resemble a permissioning or capabilities system, and it could be built as part of the crucial larger project of providing for configurable application permissions.

152+To close the loop on enforcing social boundaries, reputation information should be shared across ships. This will likely be done by building one or more applications that share statistics and block operations. Some forms of reputation are likely to be globally shared, whereas others are likely to be multipolar, i.e. some people like you and some don’t. Generally, the lower the layer of the attack, the more global the reputation effect will be; the higher the layer, the more multipolar. An attempt to spam the network with millions of malicious packets will cause most people not to want to talk to you; sending me a movie I found mediocre is probably not even information worth sharing with anyone else.

148

153

149−To close the loop on enforcing social boundaries, reputation information should be shared across ships. This will likely be done by building one or more applications that share statistics and block operations. Some forms of reputation are likely to be globally shared, whereas others are likely to be multipolar, i.e. some people like you and some don’t. Generally, the lower the layer of the attack, the more global the reputation effect will be; the higher the layer, the more multipolar. An attempt to spam the network with millions of malicious packets will cause most people not to want to talk to you; sending me a movie I found mediocre is probably not even information worth sharing with anyone else.

150

154

151## Conclusion

155## Conclusion

152

156

153−Ames’ design has unparalleled potential to deter, mitigate, and recover from attacks, since every packet is authenticated and encrypted and backed by a stable, decentralized PKI. It feels good to have our design for encryption and authentication be confirmed by a third party as cryptographically sound, and we know more or less what we need to build to reach the full security potential of the platform, including the steps outlined here.

157+Ames’ design has unparalleled potential to deter, mitigate, and recover from attacks, since every packet is authenticated and encrypted and backed by a stable, decentralized PKI. It feels good to have our design for encryption and authentication be confirmed by a third party as cryptographically sound, and we know more or less what we need to build to reach the full security potential of the platform, including the steps outlined here.

content/blog/simple-durable-yours.md+7−5

@@ -1,21 +1,23 @@

1+++

1+++

2title = "Simple, Durable, Yours"

2title = "Simple, Durable, Yours"

3−date = "2019-10-16"

3+date = 2019-10-17

4description = "We built Urbit from scratch to be a system that’s simple, durable, and yours. Everything that computing today is not — but should be."

4description = "We built Urbit from scratch to be a system that’s simple, durable, and yours. Everything that computing today is not — but should be."

5−extra = { }

5+[extra]

6+++

6+++

7

7

8We live in a world dense with digital services. We see the world through them, we depend on them completely, and they’re not going away. They’re only becoming more ubiquitous.

8We live in a world dense with digital services. We see the world through them, we depend on them completely, and they’re not going away. They’re only becoming more ubiquitous.

9

9

10But computers are a mess.

10But computers are a mess.

11

11

12+

12−

13+<img class="ba mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/simple-durable-yours/simple-durable-yours-notifications.svg">

14+

13

15

14We spend all our time switching between services, juggling logins and different interfaces. And once we’re logged in, the services we use harvest our data, spy on us, and often shut down with little warning.

16We spend all our time switching between services, juggling logins and different interfaces. And once we’re logged in, the services we use harvest our data, spy on us, and often shut down with little warning.

15

17

16If computers are going to be a part of our lives for generations to come, we need a sound foundation for them. We need a _system_, not a grab bag of apps and services. Urbit is that system.

18If computers are going to be a part of our lives for generations to come, we need a sound foundation for them. We need a _system_, not a grab bag of apps and services. Urbit is that system.

17

19

18−

20+<img class="ba mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/simple-durable-yours/simple-durable-yours-rock%402x.png">

19

21

20We built Urbit from scratch to be a system that’s simple, durable, and yours. Everything that computing today is not — but should be.

22We built Urbit from scratch to be a system that’s simple, durable, and yours. Everything that computing today is not — but should be.

21

23

@@ -39,7 +41,7 @@ Your Urbit is designed to be durable: both to store your data across generations

39

41

40Finally, your Urbit belongs to you in every possible way. You own it with a private key, control it completely, and can inspect its source code. We want your Urbit to be your digital home. A home you don’t own is just a hotel room.

42Finally, your Urbit belongs to you in every possible way. You own it with a private key, control it completely, and can inspect its source code. We want your Urbit to be your digital home. A home you don’t own is just a hotel room.

41

43

42−

44+<img class="ba mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/simple-durable-yours/simple-durable-yours-evolution.svg">

43

45

44Urbit began as a sketch, driven from a basic intuition that a better platform could be built. Today, Urbit is two components: Urbit ID, an identity system that’s already live on Ethereum; and Urbit OS, a decentralized network and OS stack that’s young but working well.

46Urbit began as a sketch, driven from a basic intuition that a better platform could be built. Today, Urbit is two components: Urbit ID, an identity system that’s already live on Ethereum; and Urbit OS, a decentralized network and OS stack that’s young but working well.

45

47

content/blog/smart-home-of-the-future.mddeleted−60

@@ -1,60 +0,0 @@

1−+++

2−title = "The Smart Home of the Future"

3−date = "2022-08-04"

4−description = "Homes are getting smarter. A smart home is no longer just a collection of smart devices but a superorganism of data-collecting objects. These people and devices who use and inhabit these homes form a complex socio-technical system. What is the future of the smart home and how will Urbit fit into it?"

5−[extra]

6−author = ""

7−ship = "~pilwyc-fastec"

8−image = "https://storage.googleapis.com/media.urbit.org/blog/484f30d6e2d5aa86840a662a8b57bdd5.jpg"

9−+++

10−

11−

12−

13−During the last couple months I’ve worked on learning what makes smart homes tick for Urbit users through a [grant by the Urbit Foundation](https://urbit.org/grants/communal-computing). What I’ve found (and [published in the final whitepaper](https://pilwyc-fastec-public.s3.us-west-2.amazonaws.com/Communal-Computing-for-Urbit-whitepaper.pdf)) is that people have a complicated relationship with the technologies in their homes while the number of devices are continuously increasing.

14−

15−It is further complexified by the fact that for every additional person in the household there is an expanding total number of interactions because of connections individuals form as groups. For example, I may generate one type of data sitting in a room by myself listening to music and a very different set of data sitting with my whole household watching a video together (while also browsing our own personal devices).

16−

17−The relationships you have with everyone that lives and visits your home (even the people that are not supposed to be there) are how we start to define our identity inside those spaces.

18−

19−During the study, I also learned about some important distinctions of Urbit's identity and (current lack of) digital reputation compared to other computing platforms.

20−

21−[Lunar Urbit and the Internet of Things](https://urbit.org/blog/iot) brings up key questions about the perfect paradigm for computing in the Urbit smart home. In that post [~datnut-pollen](https://urbit.org/ids/~datnut-pollen) articulates a problem with smart home devices:

22−

23−

24−> The Internet of Things is much maligned by technologists as a privacy, security, and maintenance nightmare. These products usually depend on phoning home to perform their service, which is inevitably a funnel by which personal data is harvested, an attack surface for hackers to gain access to your home network, and a single point of failure which may render the device useless, all in one!

25−

26−There are a range of needs and preferences regarding a person’s identity, the data they create in the home, and how data would be used. About half of the people thought of themselves as a singular online identity and had fewer concerns with sharing their data with 3rd parties. The other half of people that saw themselves segmented into different identities (e.g. home vs. work vs. online) were concerned with all of the data being sent to 3rd parties from their smart home.

27−

28−This is likely because people’s identities are split based on the relationships they have in their lives. This is related to how they consider what is a violation of privacy based on how their information is used. A framework in the practice of privacy is [Contextual Integrity](https://en.wikipedia.org/wiki/Contextual_integrity) first proposed by Helen Nissenbaum in [Privacy In Context: Technology, Policy, and the Integrity of Social Life](https://www.amazon.com/Privacy-Context-Technology-Policy-Integrity/dp/0804752370). It outlines a model that is based on norms and expectations by people of how they control the flow of their data rather than a false dichotomy of private vs. public. Mismatches between where a person expects their data to go and where it actually goes causes privacy violations. For more ways this is linked to the Urbit privacy models see the [white paper](https://pilwyc-fastec-public.s3.us-west-2.amazonaws.com/Communal-Computing-for-Urbit-whitepaper.pdf).

29−

30−Through these interviews I also found that Urbit’s identity doesn’t, by default, include strong reputational considerations for people. It started in an early conversation I had with [~wolref-podlex](https://urbit.org/ids/~wolref-podlex) about how communal computing would make sense in the Urbit world of strong identity and was confirmed through the discussions we had. The only information that shows up in Urbit communities today are your ID and sigil. Your reputation is then built in every human’s head based on the interactions they have with you through the community. This is a departure from what many technology platforms do today by encoding reputation in stars, likes, and other reputational markers.

31−

32−Lack of reputation legibility is valuable because “snapping to” a set of reputations doesn’t account for all of the different identities that form through the relationships you have. This is especially true for households where there are multiple people or multiple generations. It isn’t so much that they need to be illegible but that having anything other than a human decide what is appropriate will lead to incorrect assessments.

33−

34−In a recent post [Soulbinding Like a State](https://subconscious.substack.com/p/soulbinding-like-a-state), Gordon Brander makes some important points on how the requirement to be legible with identity systems is hazardous for people, especially at the scale of the internet. Client-server models that have proliferated with smart home technologies require that identities need to be legible to the 3rd party services. This is because we are mistaking the need for access with evaluations of those people. Confusing those creates circumstances that will overconstrain the possibilities of a people with the needs of the system.

35−

36−An Urbit smart home could deliver a more realistic identity model, communal experiences, and match the expectations of privacy by letting people relate as humans rather than identities or accounts. It doesn’t stop with only people physically in the household. Households can be joined across space and time. Think about those households intermediated by technology like a shared photo stream that shows up in two different household’s picture frames.

37−

38−For Urbit to be a better part of the home it needs to continue to focus on access through its peer-to-peer network rather than creating complex schemes for the person’s reputation. The reputation within a household is through the interpretations of those that are there in the household. There are many different relational identities like being a parent, a spouse, part of a parent-teacher association, table-top gaming group, and a backyard BBQ crew which is all part of your identity. The norms of how people deal with each other in the home will evolve over time including what should be shared within that context. Who is allowed in a room or not is something set by the expectations of norms that are negotiated between people. This includes photos that should be shown (or not) on the shared picture frame.

39−

40−[Stewart Brand](https://en.wikipedia.org/wiki/Stewart_Brand)’s book [How Buildings Learn](https://en.wikipedia.org/wiki/How_Buildings_Learn) points to how building are in a constant state of flux:

41−

42−> A building is not something you finish. A building is something you start.

43−

44−We should assume that when we add technologies to the household with connected devices this isn’t any different. How we build these devices to respect the privacy, identity, and relationships of people will be key.

45−

46−The next step is to take this work forward and show how the Urbit platform could be used for smart home control. Due to the way the most smart home devices are built today we won’t be able to completely stop the sharing of data in the home with 3rd parties but we can somewhat obfuscate a person’s identity behind their Urbit identity that the device maker won’t understand. In my next [grant proposal](https://pilwyc-fastec-public.s3.us-west-2.amazonaws.com/Communal-Computing-for-Urbit-whitepaper.pdf#page=11&zoom=100,96,96) we will be looking to build a prototype of Gall app to control the most commonly used smart home device: the smart light bulb.

47−

48−The future of Urbit in the smart home will depend on its ability to integrate with many different device manufacturers. As these devices are installed, upgraded, and generally maintained they need to persist the identities of people in the home and configuration over time whereas most today require a relogin. The people in the home should maintain control over the systems automatically and perpetually rather than having to keep reasserting it through password resets. When they decide to leave the home they should be able to easily transfer that ownership to the next occupant like they would a set of keys.

49−

50−Another quote by Stewart Brand on buildings:

51−

52−> All buildings are predictions. All predictions are wrong.

53−

54−Our guesses as to what the people in a smart home of the future needs will be incorrect. What we can do is start to build around the doctrine of Urbit focused on personal data ownership, simplified identity, and leaving reputation to humans.

55−

56−The future of computing in the home will be one that is ubiquitous, contextual, and communal. Urbit needs to embrace the strong identity it already has without forcing legible reputational systems that are meant to be all-encompassing. The ownership over data and what happens to an Urbit ship will be a huge benefit when considering the growing distrust in 3rd party, client-server architectures. Urbit has a real opportunity to provide the home of the future with a platform for computing that let’s people be themselves and feel their home’s data, like their home, is really theirs.

57−

58−–

59−

60−*[~pilwyc-fastec](https://urbit.org/ids/~pilwyc-fastec) is a smart home pragmatist and Urbit enthusiast. While he enjoys the chaos of children using smart home devices he wishes it didn’t wreck his music recommendations so much. He can be found in the [Communal Computing for Urbit community](https://pilwyc-fastec.tlon.network/apps/landscape/~landscape/ship/~pilwyc-fastec/communal-computing-for-urbit/resource/chat/ship/~pilwyc-fastec/discussion-7484) if you want to get in touch.*

content/blog/stable-arvo.md+13−11

@@ -1,8 +1,7 @@

1+++

1+++

2title = "Stable Arvo"

2title = "Stable Arvo"

3−date = "2019-11-19"

3+date = 2019-11-20

4description = "This year we set out to get Arvo to a point that we can credibly call ‘stable.' "

4description = "This year we set out to get Arvo to a point that we can credibly call ‘stable.' "

5−

6[extra]

5[extra]

7author = "Anthony Arroyo"

6author = "Anthony Arroyo"

8ship = "~poldec-tonteg"

7ship = "~poldec-tonteg"

@@ -15,20 +14,21 @@ image = "https://media.urbit.org/site/posts/essays/stable-arvo.png"

15

14

16We want your Urbit to last forever. We want an ordinary Urbit user to never worry about their Urbit breaking, going away or failing unexpectedly. We don’t just want this — we think this is one of the most incredible things Urbit can actually deliver.

15We want your Urbit to last forever. We want an ordinary Urbit user to never worry about their Urbit breaking, going away or failing unexpectedly. We don’t just want this — we think this is one of the most incredible things Urbit can actually deliver.

17

16

18−In order to get closer to an Urbit that can last forever, we set for ourselves the goal of getting Arvo (the kernel of what we’ve been calling ‘Urbit OS’) to a point that we can credibly call ‘stable’ by the end of 2019.

17+In order to get closer to an Urbit that can last forever, we set for ourselves the goal of getting Arvo (the kernel of what we’ve been calling ‘Urbit OS’) to a point that we can credibly call ‘stable’ by the end of 2019.

19

18

20−But what do we mean exactly by ‘stable’? For something meant to last far into the future, stability really means _resilience_. Arvo has to both run and upgrade itself without ever breaking or falling into an unrecoverable state.

19+But what do we mean exactly by ‘stable’? For something meant to last far into the future, stability really means *resilience*. Arvo has to both run and upgrade itself without ever breaking or falling into an unrecoverable state.

21

20

22Getting Arvo to this point doesn’t quite achieve the user-level goal we’re hoping to achieve. But if you’re comfortable doing a bit of system administration, Arvo itself should need almost no maintenance.

21Getting Arvo to this point doesn’t quite achieve the user-level goal we’re hoping to achieve. But if you’re comfortable doing a bit of system administration, Arvo itself should need almost no maintenance.

23

22

24To achieve stability in practice Arvo needs three things:

23To achieve stability in practice Arvo needs three things:

25

24

26−- The Arvo network (Ames) has to be stable

25+- The Arvo network (Ames) has to be stable

27- Arvo can’t easily fall into an unrecoverable state

26- Arvo can’t easily fall into an unrecoverable state

28- Arvo has to have a clear and formalized upgrade mechanic

27- Arvo has to have a clear and formalized upgrade mechanic

29

28

30All of these are actively being worked on, and are mostly near completion. Let’s walk through them one by one.

29All of these are actively being worked on, and are mostly near completion. Let’s walk through them one by one.

31

30

31+

32### A new Ames

32### A new Ames

33

33

34To ensure that Arvo can upgrade itself forever, it needs a network to deliver the updates. Toward this end we’ve put a lot of work into making Ames, the Urbit networking protocol, as reliable as possible.

34To ensure that Arvo can upgrade itself forever, it needs a network to deliver the updates. Toward this end we’ve put a lot of work into making Ames, the Urbit networking protocol, as reliable as possible.

@@ -41,6 +41,7 @@ We’ve been working on that rewrite, codenamed Alef, for a few months now. Alef

41

41

42We expect to switch to Alef in a continuity breach (network reset) during this quarter. This will be a huge step toward resilience. A networking protocol we can trust to deliver updates is essential for a computer that will last a long time.

42We expect to switch to Alef in a continuity breach (network reset) during this quarter. This will be a huge step toward resilience. A networking protocol we can trust to deliver updates is essential for a computer that will last a long time.

43

43

44+

44### Recoverability

45### Recoverability

45

46

46Another barrier to stability with existing Urbit is that a ship can, under specific conditions, fall into a terminal state. If part of your ship’s state relies on event in the future and this event crashes, then that part of the state can become unrecoverable. Consider, for example, an event that is set to be triggered by a timer. If this timer crashes, that event will never happen. This is a huge problem.

47Another barrier to stability with existing Urbit is that a ship can, under specific conditions, fall into a terminal state. If part of your ship’s state relies on event in the future and this event crashes, then that part of the state can become unrecoverable. Consider, for example, an event that is set to be triggered by a timer. If this timer crashes, that event will never happen. This is a huge problem.

@@ -51,24 +52,25 @@ This architecture means that errors have to be considered not simply as an excep

51

52

52Deterministic errors are currently handled within the virtual interpreter, Mock, and result in a “bail: exit.” They can be handled “within” Arvo and are never written to the event log. The real difficulty lies with non-deterministic errors, specifically ones can potentially cause other events.

53Deterministic errors are currently handled within the virtual interpreter, Mock, and result in a “bail: exit.” They can be handled “within” Arvo and are never written to the event log. The real difficulty lies with non-deterministic errors, specifically ones can potentially cause other events.

53

54

54−An obvious case of causally-connected events is a timer; any code that sets a timer eventually suspends itself, waiting to be awoken. And yet, if the subsequent timer event were to crash, the state machine awaiting it would remain suspended, expecting a transition that can and will not

55+An obvious case of causally-connected events is a timer; any code that sets a timer eventually suspends itself, waiting to be awoken. And yet, if the subsequent timer event were to crash, the state machine awaiting it would remain suspended, expecting a transition that can and will not

55occur.

56occur.

56

57

57−We believe that we have a general scheme that accounts for both classes of error. We’ve formalized this and will use it going forward to avoid falling into inconsistent states.

58+We believe that we have a general scheme that accounts for both classes of error. We’ve formalized this and will use it going forward to avoid falling into inconsistent states.

58

59

59Our solution to this problem is simple: if Arvo or one of its vanes crashes while processing an event, the fact of the failed event itself becomes a new event. The runtime injects an error notification in the event log, named, as is befitting of a failed event: %crud.

60Our solution to this problem is simple: if Arvo or one of its vanes crashes while processing an event, the fact of the failed event itself becomes a new event. The runtime injects an error notification in the event log, named, as is befitting of a failed event: %crud.

60

61

61In the case of a failed timer event, the error notification is routed back to the code that set the timer and communicates the following: you were expecting to be woken up, but, when you were, you crashed. The code in question could then consider the logical operation of which the timer was a part to have failed, or perhaps it could try again. In any case, it must not crash when handling the error notification, and it must not continue to expect to be woken up.

62In the case of a failed timer event, the error notification is routed back to the code that set the timer and communicates the following: you were expecting to be woken up, but, when you were, you crashed. The code in question could then consider the logical operation of which the timer was a part to have failed, or perhaps it could try again. In any case, it must not crash when handling the error notification, and it must not continue to expect to be woken up.

62

63

63−This quarter, building on previous work, we’ve built on the %crud pattern and mapped the protocols between the vanes and between arvo and vere. This allows us to make sure that %cruds are all handled (so as to avoid the crash discussed above) and, in future iterations of the vanes, know what conditions need to be accommodated to avoid introducing regressions.

64+This quarter, building on previous work, we’ve built on the %crud pattern and mapped the protocols between the vanes and between arvo and vere. This allows us to make sure that %cruds are all handled (so as to avoid the crash discussed above) and, in future iterations of the vanes, know what conditions need to be accommodated to avoid introducing regressions.

64

65

65By adopting this pattern and virtualizing userspace, we can make completely sure that code running in the kernel or an app can’t cause your ship to get into an inconsistent state.

66By adopting this pattern and virtualizing userspace, we can make completely sure that code running in the kernel or an app can’t cause your ship to get into an inconsistent state.

66

67

68+

67### Telescoping Kelvins

69### Telescoping Kelvins

68

70

69−Finally, in order for a ship to reliably receive and apply upgrades, we need to formalize and enforce a versioning scheme inside the system.

71+Finally, in order for a ship to reliably receive and apply upgrades, we need to formalize and enforce a versioning scheme inside the system.

70

72

71−Most software simply increases its version number on each release. Nock (our VM spec) and Hoon, on the other hand, uses kelvin versioning. Kelvin versioning doesn’t infinitely increase version numbers. Instead, we decrease the version number on each significant change in the hope that our software will eventually not need to change at all. Infrastructure, if it’s going to be truly reliable, should eventually reach absolute zero.

73+Most software simply increases its version number on each release. Nock (our VM spec) and Hoon, on the other hand, uses kelvin versioning. Kelvin versioning doesn’t infinitely increase version numbers. Instead, we decrease the version number on each significant change in the hope that our software will eventually not need to change at all. Infrastructure, if it’s going to be truly reliable, should eventually reach absolute zero.

72

74

73Nock is already nearly frozen at 4K. A change to Nock is a major event.

75Nock is already nearly frozen at 4K. A change to Nock is a major event.

74

76

@@ -82,7 +84,7 @@ The mechanism for the kernel is pretty simple. In short, we’ll enforce that ev

82

84

83The versioning scheme between the runtime and Arvo is similarly straightforward. We’ll build in an affordance for notifying the user if we need them to manually upgrade the interpreter. This ensures that API changes between interpreter and kernel can always be non-breaking. Someday interpreter changes can be done over the air (like your browser downloading its own upgrades), but we’re not there yet.

85The versioning scheme between the runtime and Arvo is similarly straightforward. We’ll build in an affordance for notifying the user if we need them to manually upgrade the interpreter. This ensures that API changes between interpreter and kernel can always be non-breaking. Someday interpreter changes can be done over the air (like your browser downloading its own upgrades), but we’re not there yet.

84

86

85−What’s important about these two things is that they let us take continuity seriously. "Continuity" or "permanence" is arguably Urbit's killer feature: you start your ship, it just works, forever. Back it up on a USB drive, throw it in a drawer for forty years, and upon reconnecting to the network in 2059 (and pulling down all the updates you've missed) you're back in the game.

87+What’s important about these two things is that they let us take continuity seriously. "Continuity" or "permanence" is arguably Urbit's killer feature: you start your ship, it just works, forever. Back it up on a USB drive, throw it in a drawer for forty years, and upon reconnecting to the network in 2059 (and pulling down all the updates you've missed) you're back in the game.

86

88

87With the recent 0.9.0 release we’ve gotten to the point where we can make almost all our upgrades over the air. Even the language is now upgradeable over the wire.

89With the recent 0.9.0 release we’ve gotten to the point where we can make almost all our upgrades over the air. Even the language is now upgradeable over the wire.

88

90

content/blog/state-of-urbit.mddeleted−95

@@ -1,95 +0,0 @@

1−+++

2−title = "State of Urbit"

3−date = "2021-08-24"

4−description = "A year in review"

5−[extra]

6−author = "Galen Wolfe-Pauly"

7−ship = "~ravmel-ropdyl"

8−image = "https://media.urbit.org/site/posts/essays/cities-6.jpg"

9−+++

10−

11−

12−

13−In the past year, as Urbit has become more reliable and easier to use, we find that we&#39;re spending almost all of our time on the network. We&#39;ve disappeared into the system we&#39;ve been building, and it&#39;s a pleasure to be on Urbit. There&#39;s nowhere else we&#39;d rather be.

14−

15−If you&#39;re on the network with us you can see the system being built and getting better in real time. Bug fixes and new features appear on your ship constantly. The community is actively planning the future of the system _using the system itself_. At Tlon, we have the unparalleled pleasure of working on the system, _on the system_. This feels great, but for those of you who aren&#39;t on the network, it can look as if we&#39;ve disappeared.

16−

17−Right now, Urbit is not for my non-technical friends. But everyone can tell that mainstream apps are getting worse and most feel a desire for change. We want Urbit to be as easy to use as a conventional service. Or, at least as easy to use as Signal. And we&#39;re getting pretty close to that.

18−

19−In this post I&#39;ll cover the progress we&#39;ve made since releasing OS 1 so those who aren&#39;t on the network can get a sense of what we&#39;ve been up to and where we&#39;re going. We&#39;ve built a great communication tool called Landscape, we are improving Urbit&#39;s ease of onboarding, and we&#39;re launching an entire software distribution system. We have a lot of work on our plate.

20−

21−Okay, let&#39;s talk about where we currently stand and where we&#39;re heading.

22−

23−**Arc**

24−

25−Let&#39;s start at the top: we&#39;re working to build a new network and operating system for everyday cloud computing. We think everyone deserves to control and shape the tools they use to communicate and collaborate.

26−

27−Or, to put it another way: the apps and services we have today are confusing, annoying, and overly complicated. The only way out is to start at the foundation by building a new software stack. Once we have a cloud computing stack that an individual can own and completely control, the old hope that computers can be tools of freedom will return. We haven&#39;t forgotten the original vision of software as a fun, free, flexible everyday tool.

28−

29−This is a hilariously ambitious thing to try to do, we know. This is what makes it fun. So far, we just try to move step-by-step without overhyping what we&#39;re doing. Building a new platform for networked computing is both a technical and social problem. The technology has to work exceptionally well and the community has to care for it and move it forward.

30−

31−Our first step was simply to build a prototype, then to refine it into something that could plausibly work. Then, most recently, take that plausible prototype and build a user experience we liked enough to depend on it from day-to-day.

32−

33−In the last eighteen months we&#39;ve done exactly that. We depend on Urbit day-to-day and have shipped a tool that has become a home for numerous cultures and communities who are invested in moving the system forward. We first called that tool OS 1 but now it&#39;s known as Landscape.

34−

35−First, let&#39;s talk about the general arc of OS 1 → Landscape, both the successes and challenges. Then we&#39;ll talk about our next step, which is to create an independent and community supported software ecosystem.

36−

37−**OS 1 → Landscape**

38−

39−The tools we use shape the way we think. So how could we build better tools with old broken ones? We needed to cut our reliance on old tools that couldn&#39;t care less about how people actually work and live. The only thing they maximized was distraction and dependence. We needed something that was fundamentally private, durable, and flexible. Above all, we needed something that actually belonged to us.

40−

41−Building Urbit involves a lot of communication and collaboration. In order to move Urbit forward we knew that we needed a place to converse and connect, and we knew that place had to be on Urbit itself. We didn&#39;t need a Slack or a Discord or a Google Drive or a Reddit. We needed all of those things, in one place, that actually belonged to us.

42−

43−We experimented, built things, threw them away, and then eventually built and [launched OS 1](https://www.youtube.com/watch?v=71ViyftPkGk).

44−

45−OS 1, now Landscape, is a simple tool for bringing groups together to communicate and stay connected. When a real physical community goes online they immediately become fragmented between various apps. Perhaps a Slack channel coupled with some Notion notebooks and a Telegram channel works for some people. It&#39;s easy to imagine other permutations, and you probably are already in at least two or three. These duct-taped stacks are not only ugly and confusing, but your day to day computing is spread thin and remains in the control of companies—not you.

46−

47−Urbit is a decentralized network but Landscape is for re-centralizing your communication. Users can form groups which share a set of channels; each channel can be either a chat, a notebook or a collection of links. This means groups can communicate flexibly, exactly how they want. And since Landscape is built on Urbit, each group is private and peer to peer; data is only shared between people in the group; each community on Landscape is completely independent. Communities own their data and last as long as they need to.

48−

49−This combination of a flexible unified interface on a decentralized platform you can trust feels really good.

50−

51−When OS 1 was first released, it was slow, buggy, and frustrating—but we loved it and wanted it to be better. We spent the next nine months making sweeping changes to take it from releasable prototype to pretty-nice first version. We rewrote the frontend completely, massively improved the performance of Urbit OS itself, and overhauled the interface. It was an enormous collective effort.

52−

53−By the end of 2020 we had renamed OS 1 to Landscape and the user experience was far better. We [announced our hosting service](https://www.youtube.com/watch?v=w3qKe_WZr50) and onboarded close friends to help us test the system. I [wrote a little](<[https://tlon.io/news/landscape-now/](https://tlon.io/news/landscape-now/)>) about using Landscape from day-to-day around that time.

54−

55−Landscape wasn&#39;t just a useful tool for us, but it was something that other communities were starting to use in earnest. It seemed like Landscape could be a great place for people to grow new private communities, so long as we could onboard new users effectively. Hosting is a huge piece of the puzzle, since we need non-technical people to be able to use this wonderful platform as easily as its mainstream competitors.

56−

57−At this point (early this year), we encountered some pretty serious hurdles.

58−

59−To use Urbit, you need an Urbit ID. Each one of these is an NFT (something that no one cared about when we first launched Urbit ID). The basic idea is that an ID should cost something so that they aren&#39;t used abusively. But, in late 2020 the combination of a crypto bull market and congestion on the Ethereum network caused the transaction fee for buying an Urbit ID to increase from ~$1-2 to ~$100. An Urbit ID should cost _something_, but \&gt;$100 is too much of a barrier for entry. We knew that this could happen and started researching solutions late last year, ultimately deciding to [implement a solution ourselves](https://urbit.org/blog/rollups/).

60−

61−The tough part about having an identity verified on the blockchain is that you become vulnerable to unpredictable volatility. We saw a period of painfully high prices, followed by a dip, followed by another stretch of extremely high prices. We opted to continue releasing Landscape updates and moving the system forward despite the fact that it became prohibitively expensive to onboard people. Luckily, our solution to this problem should go live this summer, and will reduce the cost of onboarding about 60x. The best part is that it is a permanent solution so we&#39;ll never have to face this problem again.

62−

63−The other challenge to scaling the onboarding process is hosting.

64−

65−We have a functional hosting structure but we want it to be fully automated and featured. We&#39;ve been able to onboard friends and enthusiasts which has taught us a lot about how the system should work. But hosting has to be easy for anyone to join and get online quickly. Without an automated invite flow and it&#39;s not ready for prime time.

66−

67−We&#39;ve made great progress on this front. We are currently testing improvements internally and aim to have a final version ready simultaneously with lower planet fees. Then, at long last, we can comfortably invite friends to get on the network without ever leaving the browser.

68−

69−It&#39;s worth mentioning that hosting is very much a Tlon Corporation project. Urbit is a platform owned, maintained, and developed by the people that use it (along with the nascent Urbit Foundation). Tlon, while also contributing to the Urbit project, ultimately wants to produce applications and services on Urbit. Hosting is one of those projects. Hosting makes Urbit easy, approachable, and usable without the compromises involved in using a conventional service. Since we&#39;ll be one of many Urbit-related providers, Tlon won&#39;t be the only host. There are already a few others (like [UrbitHost](https://urbithost.com/)) getting off the ground, which is fantastic.

70−

71−**Landscape → Grid**

72−

73−As the world has become more physically distributed we rely on our digital tools to keep our communities connected. The rise of DAOs, collectives, squads, and alternative community governance structures underscores the importance of tools like Landscape that communities can actually own and control.

74−

75−Our first goal was to find out if we could build something really good on top of Urbit. We did that. And we&#39;re continuing to lower the barrier to entry. We&#39;ve also got an Urbit &#39;messenger&#39; iOS app in the works that&#39;s really nice.

76−

77−Landscape is great, but in the long run Urbit is meant to be a platform for anyone to build on top of. Urbit is a computer, not just a single communications app like Landscape. The whole point of Urbit is to make it easy for an individual to run their own general-purpose computer in the cloud. Your Urbit isn&#39;t just meant to run Landscape it&#39;s meant to run any sort of application. And that&#39;s where we&#39;re going next.

78−

79−Grid is a holistic interface for interacting with your Urbit node. Landscape, as it&#39;s known today, will become one of many apps that can be launched. Perhaps most importantly, Grid will have peer-to-peer software distribution over the network. This means you can, as a developer, build something, let a friend sync it over the network, and never have to run a dedicated distribution server. Or, as an everyday user, you can run software on your private Urbit node without the developer ever being involved.

80−

81−Urbit isn&#39;t an OS in the traditional sense—it&#39;s an &#39;overlay&#39; OS. It has to run on top of something else. But Urbit _is_ an OS in the sense that it&#39;s general-purpose. And our goal in building interfaces for Urbit is to deliver that feeling of openness and flexibility to the user. Grid is a major step toward that goal.

82−

83−Not only should a community own their communication tools, they should be able to run and host their own cloud software. They shouldn&#39;t need to rely on providers to store their data, run the application, and determine how their digital life will function.

84−

85−Grid will surely go through the same process that Landscape did. It&#39;ll start as a working first version that will inspire us to refine and make it better. But, unlike Landscape, Grid opens up an entirely new frontier for what can be done on Urbit.

86−

87−We&#39;re putting together our first conference on Oct 15-17th to inaugurate Urbit as an integrated platform and distribution system for new applications. [Tickets for Assembly 2021 are already available](https://checkout.eventcreate.com/assembly2021/select-buy). Tlon is going to Austin!

88−

89−**Closing**

90−

91−Urbit is a deeply optimistic project. Although the digital world seems more broken than ever, we&#39;re confident that something else is possible. We have already created software that people use everyday. We want everyone to have the experience that we do, and we want that experience to continue to get better. Beautiful, reliable infrastructure that communities can build on will have a significant impact on the world. The end game of connected computers doesn&#39;t have to be dystopian.

92−

93−For those of you who aren&#39;t directly involved with the project, I hope this gives you a snapshot of where we are. If we were on an Antarctic expedition the postcard would read something like &#39;Team is well-fed, healthy and motivated. Making great progress.&#39;

94−

95−With that, I&#39;ll get back to work.

content/blog/the-100-year-computer.md+9−13

@@ -1,12 +1,8 @@

1+++

1+++

2title = "The 100-Year Computer"

2title = "The 100-Year Computer"

3−date = "2019-05-13"

3+date = 2019-05-14

4−description = 'One way to think about Urbit: as a "100-year computer."'

4+description = "One way to think about Urbit: as a \"100-year computer.\""

5−aliases = [

6− "/posts/essays/the-100-year-computer/",

5+aliases = ["/posts/essays/the-100-year-computer/", "/posts/the-100-year-computer"]

7− "/posts/the-100-year-computer"

8−]

9−

10[extra]

6[extra]

11author = "Galen Wolfe-Pauly"

7author = "Galen Wolfe-Pauly"

12ship = "~ravmel-ropdyl"

8ship = "~ravmel-ropdyl"

@@ -15,16 +11,16 @@ image = "https://media.urbit.org/site/posts/essays/100-year-computer-1.png"

15

11

16

12

17

13

18−Around the Tlon office, we’re always looking for more concise ways to describe what we do. We kicked around ‘personal server’ for a long time. It’s pretty close. ‘Personal cloud computer’ did okay for a while, but it’s a little confusing.

14+Around the Tlon office, we’re always looking for more concise ways to describe what we do. We kicked around ‘personal server’ for a long time. It’s pretty close. ‘Personal cloud computer’ did okay for a while, but it’s a little confusing.

19

15

20−One way to think about Urbit is as a 100-year computer.

16+One way to think about Urbit is as a 100-year computer.

21

17

22−A 100-year computer has to be durable, reliable and permanent. It has to never lose data or fail in unpredictable ways. It has to be continuous, meaning it should never need to be updated by the user. If I put it in a closet for 10 years and take it out, it should work again without any intervention.

18+A 100-year computer has to be durable, reliable and permanent. It has to never lose data or fail in unpredictable ways. It has to be continuous, meaning it should never need to be updated by the user. If I put it in a closet for 10 years and take it out, it should work again without any intervention.

23

19

24−And, perhaps most importantly, it should be easy and enjoyable to use. Both for a casual user and for a technical person. If it’s not enjoyable to use, and doesn’t actually _get used_, it’s never going to survive for 100 years.

20+And, perhaps most importantly, it should be easy and enjoyable to use. Both for a casual user and for a technical person. If it’s not enjoyable to use, and doesn’t actually *get used*, it’s never going to survive for 100 years.

25

21

26In theory we could all be using Apple I’s today, but they’re a bit cumbersome. In large part that’s because they don’t update themselves. Those magnetic tapes don’t strike me as particularly durable either.

22In theory we could all be using Apple I’s today, but they’re a bit cumbersome. In large part that’s because they don’t update themselves. Those magnetic tapes don’t strike me as particularly durable either.

27

23

28−Imagine that a computer was something you kept forever. It would comfortably store your entire life: your writing, photos, blood tests, even your genome. Your computer would never show you ads, interrupt you against your wishes, or send your data to someone else without your permission.

24+Imagine that a computer was something you kept forever. It would comfortably store your entire life: your writing, photos, blood tests, even your genome. Your computer would never show you ads, interrupt you against your wishes, or send your data to someone else without your permission.

29

25

30−Imagine a computer that was extremely valuable to you, that you’d pay thousands of dollars to recover, but you used _less_ than the one you do today.

26+Imagine a computer that was extremely valuable to you, that you’d pay thousands of dollars to recover, but you used *less* than the one you do today.

content/blog/the-dao-as-a-lesson-in-decentralized-governance.md+94−100

@@ -1,24 +1,18 @@

1+++

1+++

2title = "The DAO as a Lesson in Decentralized Governance"

2title = "The DAO as a Lesson in Decentralized Governance"

3−date = "2016-06-23"

3+date = 2016-06-24

4description = "What's the right lesson for the decentralization community to learn from the collapse of the DAO?"

4description = "What's the right lesson for the decentralization community to learn from the collapse of the DAO?"

5−aliases = [

6− "/posts/essays/the-dao-as-a-lesson-in-decentralized-governance",

5+aliases = ["/posts/essays/the-dao-as-a-lesson-in-decentralized-governance", "/posts/the-dao-as-a-lesson-in-decentralized-governance", "/blog/dao"]

7− "/posts/the-dao-as-a-lesson-in-decentralized-governance",

8− "/blog/dao"

9−]

10−

11[extra]

6[extra]

12author = "Curtis Yarvin"

7author = "Curtis Yarvin"

13ship = "~sorreg-namtyv"

8ship = "~sorreg-namtyv"

14+++

9+++

15−

16What's the right lesson for the decentralization community to

10What's the right lesson for the decentralization community to

17learn from the collapse of the DAO?

11learn from the collapse of the DAO?

18

12

19Perhaps the simplest lesson is that even decentralized networks

13Perhaps the simplest lesson is that even decentralized networks

20−need governments, and have governments. Every network is a

14+need governments, and have governments. Every network is a

21−state. Every state has a government.

15+state. Every state has a government.

22

16

23## Decentralization theater considered harmful

17## Decentralization theater considered harmful

24

18

@@ -36,79 +30,79 @@ A network without decentralization theater is one that admits:

36- any new state is born at war with full emergency powers.

30- any new state is born at war with full emergency powers.

37- limiting and/or eliminating governance is a slow, hard task.

31- limiting and/or eliminating governance is a slow, hard task.

38

32

39−TLDR: true decentralization isn't just a technical problem. It's

33+TLDR: true decentralization isn't just a technical problem. It's

40−also a political problem, and not an easy one. Believing you've

34+also a political problem, and not an easy one. Believing you've

41solved it, before actually solving it, is not a way to solve it.

35solved it, before actually solving it, is not a way to solve it.

42

36

43## Decentralization and legitimacy

37## Decentralization and legitimacy

44

38

45Steve Randy Waldman is not alone in pointing out that [a

39Steve Randy Waldman is not alone in pointing out that [a

46blockchain is a

40blockchain is a

47−parliament](http://www.interfluidity.com/v2/6581.html). It's

41+parliament](http://www.interfluidity.com/v2/6581.html). It's

48just the technical reality that a majority of miners in a

42just the technical reality that a majority of miners in a

49proof-of-work blockchain, or stakeholders under proof of stake,

43proof-of-work blockchain, or stakeholders under proof of stake,

50have the mathematical power to govern the network absolutely.

44have the mathematical power to govern the network absolutely.

51

45

52But this power does not give them the legitimate authority to do

46But this power does not give them the legitimate authority to do

53−whatever they want. Mathematically, the Ethereum miners can

47+whatever they want. Mathematically, the Ethereum miners can

54−easily roll back the DAO. Do they have the _right_ to roll back

48+easily roll back the DAO. Do they have the _right_ to roll back

55−the DAO? As we write, this question is one much debated.

49+the DAO? As we write, this question is one much debated.

56

50

57−We have an easy answer: no. The most basic principle of law is

51+We have an easy answer: no. The most basic principle of law is

58−that _pacta sunt servanda_, agreements must be respected. A good

52+that _pacta sunt servanda_, agreements must be respected. A good

59clue is that before the DAO hack, everyone swore great oaths to

53clue is that before the DAO hack, everyone swore great oaths to

60−"the steadfast iron will of immutable code." Methinks the lady

54+"the steadfast iron will of immutable code." Methinks the lady

61−did protest too much. But these oaths make rolling back the DAO

55+did protest too much. But these oaths make rolling back the DAO

62blatantly illegitimate.

56blatantly illegitimate.

63

57

64From a governance perspective, the line of lawlessness isn't the

58From a governance perspective, the line of lawlessness isn't the

65−line between soft and hard forks. It's any fork which makes an

59+line between soft and hard forks. It's any fork which makes an

66−exception for a specific address. Ethereum has already done this

60+exception for a specific address. Ethereum has already done this

67−by freezing the DAO contract. At this point, it might as well be

61+by freezing the DAO contract. At this point, it might as well be

68hanged for an ox, and go through with the full rollback.

62hanged for an ox, and go through with the full rollback.

69

63

70## Illegitimacy and belligerency

64## Illegitimacy and belligerency

71

65

72Within the ethos of Ethereum (we are obviously not qualified to

66Within the ethos of Ethereum (we are obviously not qualified to

73−comment on "real" law), a rollback is a _lawless act_. This does

67+comment on "real" law), a rollback is a _lawless act_. This does

74−not make it a wrongful act. It simply cannot be judged as an act

68+not make it a wrongful act. It simply cannot be judged as an act

75−of law. Rather, it is an act of war.

69+of law. Rather, it is an act of war.

76

70

77And judged as an act of war, a DAO rollback is _exactly right_.

71And judged as an act of war, a DAO rollback is _exactly right_.

78−Ethereum is not dealing with a "participant." It is dealing with

72+Ethereum is not dealing with a "participant." It is dealing with

79a pirate, a thief, _hostis humani generis_.

73a pirate, a thief, _hostis humani generis_.

80

74

81As a state at war with an external enemy, the Ethereum network

75As a state at war with an external enemy, the Ethereum network

82−shouldn't just zero the DAO hacker's booty. It must do all it

76+shouldn't just zero the DAO hacker's booty. It must do all it

83−can to destroy her. If possible, it must dox and report her.

77+can to destroy her. If possible, it must dox and report her.

84The right place for this fool is the supermax, not the Riviera.

78The right place for this fool is the supermax, not the Riviera.

85

79

86−But does Ethereum really want to be at war? And if Ethereum is

80+But does Ethereum really want to be at war? And if Ethereum is

87at war -- and this certainly isn't the only pirate in the sea --

81at war -- and this certainly isn't the only pirate in the sea --

88−how does it become decentralized? If Ethereum is at war, where

82+how does it become decentralized? If Ethereum is at war, where

89there is no law, how can it achieve its goal of creating a world

83there is no law, how can it achieve its goal of creating a world

90where code is law?

84where code is law?

91

85

92−But we really shouldn't panic. It is actually possible to go

86+But we really shouldn't panic. It is actually possible to go

93from wartime government to peacetime government, from absolute

87from wartime government to peacetime government, from absolute

94−martial law to absolute rule of law. It is just nontrivial.

88+martial law to absolute rule of law. It is just nontrivial.

95It's a political engineering problem that can't be ignored.

89It's a political engineering problem that can't be ignored.

96If it has to be solved, it should be solved properly.

90If it has to be solved, it should be solved properly.

97

91

98What really doesn't work is to declare martial law, execute all

92What really doesn't work is to declare martial law, execute all

99traitors, terrorists and enemies of the state, then declare that

93traitors, terrorists and enemies of the state, then declare that

100−elections will proceed as scheduled next week. If the goal is

94+elections will proceed as scheduled next week. If the goal is

101the decentralized rule of code as law, a rollback takes an

95the decentralized rule of code as law, a rollback takes an

102−enormous step backward. Reversing this setback isn't trivial.

96+enormous step backward. Reversing this setback isn't trivial.

103

97

104−Should Ethereum actually go to war? Or should it just let the

98+Should Ethereum actually go to war? Or should it just let the

105−hacker win? Clearly, from a pure blockchain perspective, the

99+hacker win? Clearly, from a pure blockchain perspective, the

106only correct thing to do is let the DAO burn -- as a painful

100only correct thing to do is let the DAO burn -- as a painful

107warning to all future contract authors and participants.

101warning to all future contract authors and participants.

108

102

109At present, it seems that Ethereum's leadership has chosen war.

103At present, it seems that Ethereum's leadership has chosen war.

110−Certainly, neither choice is obviously imprudent. Ethereum is a

104+Certainly, neither choice is obviously imprudent. Ethereum is a

111−winner and probably has a bright future either way. But who

105+winner and probably has a bright future either way. But who

112chooses war needs a plan to win that war, and return to peace.

106chooses war needs a plan to win that war, and return to peace.

113

107

114## Sovereignty is conserved

108## Sovereignty is conserved

@@ -117,32 +111,32 @@ For a government to even have the power to consider wartime

117measures, a government has to exist in the first place.

111measures, a government has to exist in the first place.

118

112

119Again, we can't remind ourselves too often that a blockchain just

113Again, we can't remind ourselves too often that a blockchain just

120−puts absolute authority in the hands of the miners. We just

114+puts absolute authority in the hands of the miners. We just

121think of this power in terms of the law it's supposed to enforce.

115think of this power in terms of the law it's supposed to enforce.

122But the two are different -- at least in wartime.

116But the two are different -- at least in wartime.

123

117

124−Why is it so hard to eliminate unaccountable power? Who watches

118+Why is it so hard to eliminate unaccountable power? Who watches

125−the watchmen? The German legal scholar [Carl

119+the watchmen? The German legal scholar [Carl

126Schmitt](https://en.wikipedia.org/wiki/Carl_Schmitt) defined the

120Schmitt](https://en.wikipedia.org/wiki/Carl_Schmitt) defined the

127problem well when he wrote: "the sovereign is who decides the

121problem well when he wrote: "the sovereign is who decides the

128exception."

122exception."

129

123

130In the American regime, the Supreme Court is sovereign by

124In the American regime, the Supreme Court is sovereign by

131−Schmitt's definition. We have a complex system of laws, which

125+Schmitt's definition. We have a complex system of laws, which

132are not formal code but in some ways aspire to be; above it, we

126are not formal code but in some ways aspire to be; above it, we

133have a judiciary system that can decide arbitrary exceptions to

127have a judiciary system that can decide arbitrary exceptions to

134−those laws. Pure rule of law, Schmitt tells us, is always and

128+those laws. Pure rule of law, Schmitt tells us, is always and

135−everywhere an illusion. We can and should strive to approach

129+everywhere an illusion. We can and should strive to approach

136this limit, but it's an infinity that we can't actually reach.

130this limit, but it's an infinity that we can't actually reach.

137

131

138Schmitt's exception principle can be rephrased as "sovereignty is

132Schmitt's exception principle can be rephrased as "sovereignty is

139−conserved." There is always someone who answers to nobody. We

133+conserved." There is always someone who answers to nobody. We

140cannot eliminate government; the best we can do is tame it.

134cannot eliminate government; the best we can do is tame it.

141

135

142One way to think of the problem of reducing exceptional force to

136One way to think of the problem of reducing exceptional force to

143zero is to compare it to a simple unstable equilibrium, like a

137zero is to compare it to a simple unstable equilibrium, like a

144−pencil standing on its point. The pencil on its point needs

138+pencil standing on its point. The pencil on its point needs

145−almost no force to stay upright. But the farther it deviates

139+almost no force to stay upright. But the farther it deviates

146from this orderly, self-sustaining equilibrium, the more energy

140from this orderly, self-sustaining equilibrium, the more energy

147must be applied to return it to vertical.

141must be applied to return it to vertical.

148

142

@@ -152,26 +146,26 @@ things like 'fairness', but it's hard to define what fairness

152even means."

146even means."

153

147

154If we could define fairness, we would have a rule to which there

148If we could define fairness, we would have a rule to which there

155−were no exceptions. We would need no judges, or governments, or

149+were no exceptions. We would need no judges, or governments, or

156−even soldiers. We would need no sovereignty. But since we can't

150+even soldiers. We would need no sovereignty. But since we can't

157define fairness -- yet need to enforce some clear vision of

151define fairness -- yet need to enforce some clear vision of

158fairness -- sovereignty remains conserved.

152fairness -- sovereignty remains conserved.

159

153

160## Bitcoin, a blockchain at peace

154## Bitcoin, a blockchain at peace

161

155

162Bitcoin has done an excellent job of freezing the war power of

156Bitcoin has done an excellent job of freezing the war power of

163−its own "parliament." Ironically, mining power in Bitcoin is

157+its own "parliament." Ironically, mining power in Bitcoin is

164quite centralized -- a small number of Chinese mining-pool

158quite centralized -- a small number of Chinese mining-pool

165managers, who have every opportunity to collude, could roll back

159managers, who have every opportunity to collude, could roll back

166−anything. But they never have and they probably never will.

160+anything. But they never have and they probably never will.

167

161

168Even if a single pool controlled 51% of Bitcoin mining power,

162Even if a single pool controlled 51% of Bitcoin mining power,

169they'd have no incentive to break the rules -- quite the

163they'd have no incentive to break the rules -- quite the

170−converse. We equate physical decentralization with limited

164+converse. We equate physical decentralization with limited

171governance, perhaps because we think of the physical difficulty

165governance, perhaps because we think of the physical difficulty

172of coordination as the main protection against arbitrary power.

166of coordination as the main protection against arbitrary power.

173

167

174−Bitcoin shows that this isn't true. As far as we can tell,

168+Bitcoin shows that this isn't true. As far as we can tell,

175Bitcoin would keep working fine if there was only one miner.

169Bitcoin would keep working fine if there was only one miner.

176This uni-miner would have still have no incentive to corrupt the

170This uni-miner would have still have no incentive to corrupt the

177network -- though another party, such as a real government, might

171network -- though another party, such as a real government, might

@@ -179,41 +173,41 @@ have an incentive to coerce the miner.

179

173

180The important success of Bitcoin is the collective acceptance --

174The important success of Bitcoin is the collective acceptance --

181mathematically false, but politically true -- that rollbacks in

175mathematically false, but politically true -- that rollbacks in

182−Bitcoin are inconceivable. Bitcoin has governance problems, but

176+Bitcoin are inconceivable. Bitcoin has governance problems, but

183they're confined to relatively unimportant questions, like the

177they're confined to relatively unimportant questions, like the

184−blocksize debate. "Decentralization" may not be quite the word,

178+blocksize debate. "Decentralization" may not be quite the word,

185−but somehow Bitcoin has achieved limited government. The pencil

179+but somehow Bitcoin has achieved limited government. The pencil

186−is standing on its point. For now.

180+is standing on its point. For now.

187

181

188## Ethereum's dilemma

182## Ethereum's dilemma

189

183

190−A rollback creates a scary precedent. It's a sort of military

184+A rollback creates a scary precedent. It's a sort of military

191−coup. Just as the miners have the power to rule any blockchain,

185+coup. Just as the miners have the power to rule any blockchain,

192−the military has the power to rule any country. Do they want it?

186+the military has the power to rule any country. Do they want it?

193−The first coup makes the next coup much easier. Same with the

187+The first coup makes the next coup much easier. Same with the

194first rollback.

188first rollback.

195

189

196In retrospect, the great mistake here was that Ethereum didn't

190In retrospect, the great mistake here was that Ethereum didn't

197know it needed a government, and did its best to pretend it

191know it needed a government, and did its best to pretend it

198−didn't have one. After a rollback, Ethereum doesn't just have a

192+didn't have one. After a rollback, Ethereum doesn't just have a

199−government. It has a military dictatorship.

193+government. It has a military dictatorship.

200

194

201−Ethereum and Bitcoin are qualitatively different. Bitcoin has a

195+Ethereum and Bitcoin are qualitatively different. Bitcoin has a

202−simple UI metaphor: cash. Everyone knows how cash works. A

196+simple UI metaphor: cash. Everyone knows how cash works. A

203−smart contract has its own UI metaphor: law. But as we see,

197+smart contract has its own UI metaphor: law. But as we see,

204mechanically administered law, law without judges, is a very

198mechanically administered law, law without judges, is a very

205different thing from ordinary human law.

199different thing from ordinary human law.

206

200

207What the DAO shows is that Ethereum just wasn't ready to be

201What the DAO shows is that Ethereum just wasn't ready to be

208−decentralized. It was not ready to allow a $150 million contract

202+decentralized. It was not ready to allow a $150 million contract

209−with no supervision or appeals process. The problem was not

203+with no supervision or appeals process. The problem was not

210Ethereum's code per se -- although Solidity doesn't seem terribly

204Ethereum's code per se -- although Solidity doesn't seem terribly

211well designed for preventing these pitfalls -- but the human

205well designed for preventing these pitfalls -- but the human

212understanding of its capabilities and limits.

206understanding of its capabilities and limits.

213

207

214−A rollback acknowledges this. It acknowledges that Ethereum

208+A rollback acknowledges this. It acknowledges that Ethereum

215wasn't ready for complete self-government, and _someone_ needed

209wasn't ready for complete self-government, and _someone_ needed

216−to have stopped the DAO from trading. It's not quite clear what

210+to have stopped the DAO from trading. It's not quite clear what

217the principle behind the rollback was.

211the principle behind the rollback was.

218

212

219Perhaps the best kind of DAO rollback would be a rollback which

213Perhaps the best kind of DAO rollback would be a rollback which

@@ -221,13 +215,13 @@ understood this error fully, and acknowledged that -- for the

221moment -- Ethereum needs a sovereign government, with the power

215moment -- Ethereum needs a sovereign government, with the power

222to restrict and/or steward contracts.

216to restrict and/or steward contracts.

223

217

224−Contracts are not payments. They are infinitely more complex.

218+Contracts are not payments. They are infinitely more complex.

225−They will keep blowing up. Ethereum is full of buggy contracts,

219+They will keep blowing up. Ethereum is full of buggy contracts,

226−scammy contracts, ponzis and casinos, etc. A governed Ethereum,

220+scammy contracts, ponzis and casinos, etc. A governed Ethereum,

227in the present state of the technology, might well choose to vet

221in the present state of the technology, might well choose to vet

228all contracts centrally _before_ they started trading.

222all contracts centrally _before_ they started trading.

229

223

230−Would this be a permanent feature? Certainly not -- it would be

224+Would this be a permanent feature? Certainly not -- it would be

231a way for the community to collectively define a good contract.

225a way for the community to collectively define a good contract.

232Once we know what a responsible, well-tested, non-scammy Ethereum

226Once we know what a responsible, well-tested, non-scammy Ethereum

233contract looks like, it's much easier to return to the principle

227contract looks like, it's much easier to return to the principle

@@ -239,49 +233,49 @@ are able to make this decision rationally, and get it right.

239This work simply hasn't been done.

233This work simply hasn't been done.

240

234

241Perhaps the worst-case scenario is one in which Ethereum approves

235Perhaps the worst-case scenario is one in which Ethereum approves

242−the hard fork, on the "just this once" principle. To save the

236+the hard fork, on the "just this once" principle. To save the

243−country, we need a military coup. But don't panic! "After

237+country, we need a military coup. But don't panic! "After

244executing all traitors and enemies of the people, the generals

238executing all traitors and enemies of the people, the generals

245will immediately restore democracy and the rule of law."

239will immediately restore democracy and the rule of law."

246

240

247The "just this once" fork takes us back to decentralization

241The "just this once" fork takes us back to decentralization

248−theater, where Ethereum pretends not to have a government. But

242+theater, where Ethereum pretends not to have a government. But

249−now, this pretense is even more threadbare. The next hack, which

243+now, this pretense is even more threadbare. The next hack, which

250will certainly happen, will produce yet another coup -- or at

244will certainly happen, will produce yet another coup -- or at

251−least a food fight over whether to have a coup. This is the path

245+least a food fight over whether to have a coup. This is the path

252to a "digital banana republic," where the tattered illusion of

246to a "digital banana republic," where the tattered illusion of

253law barely conceals the real law of nature.

247law barely conceals the real law of nature.

254

248

255The bottom line is that if a rollback happens once, we can expect

249The bottom line is that if a rollback happens once, we can expect

256−it to happen again. This time, the rollback can be treated as an

250+it to happen again. This time, the rollback can be treated as an

257−act of war, and no process is necessary. Next time, there needs

251+act of war, and no process is necessary. Next time, there needs

258to be a process -- or the dream of code as law will drift further

252to be a process -- or the dream of code as law will drift further

259away.

253away.

260

254

261Having a central government isn't inconsistent with the ultimate

255Having a central government isn't inconsistent with the ultimate

262−objective of eliminating central government. Certainly, before

256+objective of eliminating central government. Certainly, before

263−Ethereum was released, its developers were its government. Every

257+Ethereum was released, its developers were its government. Every

264government is born in a state of chaos and war.

258government is born in a state of chaos and war.

265

259

266The mistake is just in thinking something as complex as Ethereum

260The mistake is just in thinking something as complex as Ethereum

267−can jump directly to decentralization in a single step. The

261+can jump directly to decentralization in a single step. The

268−pencil is not standing on its point, or anywhere close. Before

262+pencil is not standing on its point, or anywhere close. Before

269anyone can think about letting go, someone needs to actually lift

263anyone can think about letting go, someone needs to actually lift

270−it. To reach law, first enforce peace.

264+it. To reach law, first enforce peace.

271

265

272## Constitutional structure

266## Constitutional structure

273

267

274One of the governance problems of blockchains, related to the

268One of the governance problems of blockchains, related to the

275fundamental error of decentralization theater, is the failure to

269fundamental error of decentralization theater, is the failure to

276build deliberative institutions on top of the "parliament of

270build deliberative institutions on top of the "parliament of

277−miners." Voting by proof of work is great, especially if the

271+miners." Voting by proof of work is great, especially if the

278majority is well above 51%, and can demonstrate its strength

272majority is well above 51%, and can demonstrate its strength

279−without an actual hashing race. It's a good way to finalize

273+without an actual hashing race. It's a good way to finalize

280−decisions. But not a good way to make them.

274+decisions. But not a good way to make them.

281

275

282But blockchain governance would be considerably improved if the

276But blockchain governance would be considerably improved if the

283miners actually had a formal way to delegate their power to a

277miners actually had a formal way to delegate their power to a

284−structured institution that represented them. Both Bitcoin and

278+structured institution that represented them. Both Bitcoin and

285Ethereum have foundations and/or core teams, but authority in

279Ethereum have foundations and/or core teams, but authority in

286these institutions isn't tied in any way to actual mining power.

280these institutions isn't tied in any way to actual mining power.

287Informal politics fills this void with personality cults and

281Informal politics fills this void with personality cults and

@@ -293,22 +287,22 @@ Misalignment between a fundamental power, like the miners, and a

293group purporting to represent them, like the foundations, is

287group purporting to represent them, like the foundations, is

294inherently dangerous.

288inherently dangerous.

295

289

296−What's the alternative? An actual constitution. Perhaps the

290+What's the alternative? An actual constitution. Perhaps the

297first smart contract that Ethereum needs is not the DAO, not even

291first smart contract that Ethereum needs is not the DAO, not even

298well-engineered, high-quality smart contracts like Augur and

292well-engineered, high-quality smart contracts like Augur and

299−Maker, but just its own equivalent of 1789. If Ethereum needs a

293+Maker, but just its own equivalent of 1789. If Ethereum needs a

300−government, it must govern itself. It certainly has all the

294+government, it must govern itself. It certainly has all the

301technical tools it needs!

295technical tools it needs!

302

296

303−Or, of course, it could just let the hackers win. This is the

297+Or, of course, it could just let the hackers win. This is the

304−easiest path. And in the end, it may still be the best. War,

298+easiest path. And in the end, it may still be the best. War,

305who needs it?

299who needs it?

306

300

307## A quick Urbit plug

301## A quick Urbit plug

308

302

309Technically, Urbit needs governance much more than Ethereum.

303Technically, Urbit needs governance much more than Ethereum.

310Decentralization remains our goal -- but it's a long-term goal.

304Decentralization remains our goal -- but it's a long-term goal.

311−Decentralization theater has never even been a temptation. It's

305+Decentralization theater has never even been a temptation. It's

312just technically impossible.

306just technically impossible.

313

307

314For example, until the Urbit OS and language (Arvo and Hoon) are

308For example, until the Urbit OS and language (Arvo and Hoon) are

@@ -317,10 +311,10 @@ Urbit is still "evergreen" -- it still needs automatic hotpatches

317from the network.

311from the network.

318

312

319Whatever institution signs these updates is, by any standard, an

313Whatever institution signs these updates is, by any standard, an

320−absolute government. It's as if the Ethereum Foundation could

314+absolute government. It's as if the Ethereum Foundation could

321push a hardfork of all clients by signing the new code on the

315push a hardfork of all clients by signing the new code on the

322−blockchain. Getting out of this situation is a long-term goal --

316+blockchain. Getting out of this situation is a long-term goal --

323−where "long term" means years. Decentralization is hard.

317+where "long term" means years. Decentralization is hard.

324

318

325Read our [interim

319Read our [interim

326constitution](http://urbit.org/essays/interim-constitution) and our

320constitution](http://urbit.org/essays/interim-constitution) and our

content/blog/the-missing-middle.md+24−21

@@ -1,50 +1,53 @@

1+++

1+++

2title = "The Missing Middle"

2title = "The Missing Middle"

3−date = "2020-05-25"

3+date = 2020-05-26

4description = "Urbit stars can facilitate a flexible continuum of community norms."

4description = "Urbit stars can facilitate a flexible continuum of community norms."

5−

6[extra]

5[extra]

7author = "Nicholas Simmons"

6author = "Nicholas Simmons"

8ship = "~simfur-ritwed"

7ship = "~simfur-ritwed"

9−image = "https://media.urbit.org/site/posts/essays/missing-middle.png"

8+image ="https://media.urbit.org/site/posts/essays/missing-middle.png"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/missing-middle.png">

14+

15+<br>

13

16

14−The promise of social technology is that we can discover more friends; _specifically, people more similar to us_ than we previously had access to. The means by which we do so, the methods of collaboration, the quality of connected experiences; these factors matter, but they are marginal considerations compared to the basic offering of an expanded choice of connections.

17+The promise of social technology is that we can discover more friends; *specifically, people more similar to us* than we previously had access to. The means by which we do so, the methods of collaboration, the quality of connected experiences; these factors matter, but they are marginal considerations compared to the basic offering of an expanded choice of connections.

15

18

16−The wilder-eyed, utopian end of early computing drew greatly from this promise; such unprecedented connection could bring about world peace, intellectual serendipity, higher consciousness. We didn’t get world peace, but we did get a genuine revolution in collaborative information-sharing and rapid communication. That ability to refactor our social preferences gave birth to an uncountable universe of online communities and subcultures that would be unimaginable to anyone who didn’t see it happen.

19+The wilder-eyed, utopian end of early computing drew greatly from this promise; such unprecedented connection could bring about world peace, intellectual serendipity, higher consciousness. We didn’t get world peace, but we did get a genuine revolution in collaborative information-sharing and rapid communication. That ability to refactor our social preferences gave birth to an uncountable universe of online communities and subcultures that would be unimaginable to anyone who didn’t see it happen.

17

20

18−We didn’t get a million friends either. Dunbar’s number, which posits an upper bound of ~150 trusted relationships per person, put the lie to dreams of a ‘global community.’ Better social tools give us more choice in who to fill those slots with, but not the ability to expand the personal spheres where we actually spend most of our time and forge most of our familiarity and trust with others.

21+We didn’t get a million friends either. Dunbar’s number, which posits an upper bound of ~150 trusted relationships per person, put the lie to dreams of a ‘global community.’ Better social tools give us more choice in who to fill those slots with, but not the ability to expand the personal spheres where we actually spend most of our time and forge most of our familiarity and trust with others.

19

22

20−We know this, and the social networks know it. To combat a slump in user activity, Facebook jettisoned promises of boundless discovery and started promoting Groups. The success of Discord and Slack happened precisely because they promised tools for gated communities, not open commons.

23+We know this, and the social networks know it. To combat a slump in user activity, Facebook jettisoned promises of boundless discovery and started promoting Groups. The success of Discord and Slack happened precisely because they promised tools for gated communities, not open commons.

21

24

22−One of those early promises came true in spades, though: while we still live in Dunbar communities, we’ve sped up the sorting process. We can find people like us at astonishing speed, and the diversity of options for what ‘people like us’ means has expanded exponentially. The ‘Big Sort’ of modern society is rapid, unprecedented, and utterly reliant on social technology. The problem is that for all of our freedom to find each other and make mutual agreements, the underlying technologies used for all of this sorting and trusting don’t actually reflect the diversity of expectations, norms, or approaches we might want to try. One major reason for this status quo is the underlying structure of the client-server Internet. Unlike in the physical world, where cities, religious groups, and professional associations both own real assets and collectively determine rules and norms, there is no median level of civic compromise on the Internet; just massive technical providers and platform companies, and dispossessed Dunbar communities and individuals unable to determine such rules and norms for themselves.

25+One of those early promises came true in spades, though: while we still live in Dunbar communities, we’ve sped up the sorting process. We can find people like us at astonishing speed, and the diversity of options for what ‘people like us’ means has expanded exponentially. The ‘Big Sort’ of modern society is rapid, unprecedented, and utterly reliant on social technology. The problem is that for all of our freedom to find each other and make mutual agreements, the underlying technologies used for all of this sorting and trusting don’t actually reflect the diversity of expectations, norms, or approaches we might want to try. One major reason for this status quo is the underlying structure of the client-server Internet. Unlike in the physical world, where cities, religious groups, and professional associations both own real assets and collectively determine rules and norms, there is no median level of civic compromise on the Internet; just massive technical providers and platform companies, and dispossessed Dunbar communities and individuals unable to determine such rules and norms for themselves.

23

26

24−Both internal norms (‘how do we act’) and external perceptions (‘who are we?’) get yanked around by the dictates of platform owners, routing infrastructure providers, and the societal consensus that governs both, at levels far above our Dunbar phyles. Privacy is contradicted by the need to surveil internal activity in order to target ads. The current model of social connection technology sets the bar for self-determination so high as to prevent it from adapting to external circumstances. The technical realities of the situation are due to client-server technology and its institutional history. The social aspect is a holdover from the 20th-century media paradigm of mass consensus cultures.

27+Both internal norms (‘how do we act’) and external perceptions (‘who are we?’) get yanked around by the dictates of platform owners, routing infrastructure providers, and the societal consensus that governs both, at levels far above our Dunbar phyles. Privacy is contradicted by the need to surveil internal activity in order to target ads. The current model of social connection technology sets the bar for self-determination so high as to prevent it from adapting to external circumstances. The technical realities of the situation are due to client-server technology and its institutional history. The social aspect is a holdover from the 20th-century media paradigm of mass consensus cultures.

25

28

26−The ‘long 20th century’ of mass institutions and broad consensus realities is over. Contrary to impressions, it was not the inevitable or final result of moral and civil progress. Rather, it arose from pragmatic external incentives of mass advertising and great-power ideological rivalries.

29+The ‘long 20th century’ of mass institutions and broad consensus realities is over. Contrary to impressions, it was not the inevitable or final result of moral and civil progress. Rather, it arose from pragmatic external incentives of mass advertising and great-power ideological rivalries.

27

30

28−The assumption that we must inevitably play by the same rules of discourse, given the autonomy granted by wealth, technology, and knowledge, is rapidly degrading. This status quo is a leftover from a time when mass education prepared workers for mass jobs, where mass communication hammered the same messages over the factory loudspeaker and advertised the same small number of products over the few television channels available. Yet we still assume that the shape and function of the tools and spaces for dialogue we inherited from that era are immutable and inevitable; this outdated belief cuts us off from new methods of choice and collaboration.

31+The assumption that we must inevitably play by the same rules of discourse, given the autonomy granted by wealth, technology, and knowledge, is rapidly degrading. This status quo is a leftover from a time when mass education prepared workers for mass jobs, where mass communication hammered the same messages over the factory loudspeaker and advertised the same small number of products over the few television channels available. Yet we still assume that the shape and function of the tools and spaces for dialogue we inherited from that era are immutable and inevitable; this outdated belief cuts us off from new methods of choice and collaboration.

29

32

30Without the external political and economic pressures which created our mass culture, inclusion in or acceptance by it becomes just another sinecure for sale, the outcome of a zero-sum auction to benefit from and utilize for further gain, the power accumulated by the legacy institutions safeguarding it. The ‘objective’ model has become a straightjacket on human ingenuity and community self-determination. The fact that it is ‘supposed to exist’ means that it is the ultimate prize. Inclusion in the mainstream Discourse grants scalable exploitation of any idea and prestige to its proponents. But it is a booby prize. No serious and nuanced idea, no dedicated community can withstand its flattening effects or the ways that it commercializes and cargo-cults its subject into an artificial shape. The resulting conversations are lackluster in form as well as subject.

33Without the external political and economic pressures which created our mass culture, inclusion in or acceptance by it becomes just another sinecure for sale, the outcome of a zero-sum auction to benefit from and utilize for further gain, the power accumulated by the legacy institutions safeguarding it. The ‘objective’ model has become a straightjacket on human ingenuity and community self-determination. The fact that it is ‘supposed to exist’ means that it is the ultimate prize. Inclusion in the mainstream Discourse grants scalable exploitation of any idea and prestige to its proponents. But it is a booby prize. No serious and nuanced idea, no dedicated community can withstand its flattening effects or the ways that it commercializes and cargo-cults its subject into an artificial shape. The resulting conversations are lackluster in form as well as subject.

31

34

32−The stiffer the Discourse is; the less input it deems useful, the more fragile it becomes. The inside becomes a stultifying garden party of outdated, anodyne official narratives; the outside a stew of paranoid, enraged rump factions shut out of any path to respectability or good-faith engagement with their perspective.

35+The stiffer the Discourse is; the less input it deems useful, the more fragile it becomes. The inside becomes a stultifying garden party of outdated, anodyne official narratives; the outside a stew of paranoid, enraged rump factions shut out of any path to respectability or good-faith engagement with their perspective.

33

36

34−The same dynamic wreaks havoc inside Dunbar groups as well; when there are fewer gradations of acceptable difference, internal schisms take on a stark tinge of zero-sum loyalty versus betrayal, rather than consensual drift. Savvy users, knowing the stakes, migrate quickly, leaving behind wastelands of the obstinate and clueless, who are in turn preyed upon by grifters and demagogues. Only when external events force a ‘tectonic shift’ in official understanding do these standards change. The problem is that the usual result of a ‘tectonic shift’ is a sudden, destructive earthquake. If networked culture is going to survive dramatic events out in the real world, we’re going to need a middle structural layer that allows norms and agreements to shift and negotiate based on observed reality and the wishes of ordinary participants.

37+The same dynamic wreaks havoc inside Dunbar groups as well; when there are fewer gradations of acceptable difference, internal schisms take on a stark tinge of zero-sum loyalty versus betrayal, rather than consensual drift. Savvy users, knowing the stakes, migrate quickly, leaving behind wastelands of the obstinate and clueless, who are in turn preyed upon by grifters and demagogues. Only when external events force a ‘tectonic shift’ in official understanding do these standards change. The problem is that the usual result of a ‘tectonic shift’ is a sudden, destructive earthquake. If networked culture is going to survive dramatic events out in the real world, we’re going to need a middle structural layer that allows norms and agreements to shift and negotiate based on observed reality and the wishes of ordinary participants.

35

38

36−This omission of a ‘middle layer’ of technical governance directly informs our vision for the Urbit network. In an Urbit-based world, we envision stars will be consensus hubs. There are 256 Urbit galaxies, each able to spawn 255 stars for a total of 65,280 potential stars. Each star, in turn, can spawn 65,535 planets—far above the Dunbar number of an intimate community, but also far below the ratios of authoritarian control under which current platform regimes operate. Stars and galaxies perform the essential routing and peer discovery functions of the Urbit network; planets represent distinct individual identities.

39+This omission of a ‘middle layer’ of technical governance directly informs our vision for the Urbit network. In an Urbit-based world, we envision stars will be consensus hubs. There are 256 Urbit galaxies, each able to spawn 255 stars for a total of 65,280 potential stars. Each star, in turn, can spawn 65,535 planets—far above the Dunbar number of an intimate community, but also far below the ratios of authoritarian control under which current platform regimes operate. Stars and galaxies perform the essential routing and peer discovery functions of the Urbit network; planets represent distinct individual identities.

37

40

38−Although every star is spawned by a particular galaxy, it can move to any other galaxy which agrees to host it. Similarly, planets may migrate between stars. Many imagine the extreme ramifications of such a system, projecting a Darwinian competition of starkly diverse political models encoded in governance. When we think about the future of Urbit, though, we don’t see a chaotic universe of iconoclastic outposts. We don’t doubt there will be diversity among stars (driven by the wishes of their owners and resident planet users/customers), but the real value is in the antifragility allowed by far more subtle gradations of difference in rules and structures decided upon by stars. Each star will have much, but not all, in common with its immediate neighbors, across a constellation which contains a great overall diversity of norms. Changes in policy or alignment will resemble ripples across a pond more than a buildup of tectonic force against a brittle fault.

41+Although every star is spawned by a particular galaxy, it can move to any other galaxy which agrees to host it. Similarly, planets may migrate between stars. Many imagine the extreme ramifications of such a system, projecting a Darwinian competition of starkly diverse political models encoded in governance. When we think about the future of Urbit, though, we don’t see a chaotic universe of iconoclastic outposts. We don’t doubt there will be diversity among stars (driven by the wishes of their owners and resident planet users/customers), but the real value is in the antifragility allowed by far more subtle gradations of difference in rules and structures decided upon by stars. Each star will have much, but not all, in common with its immediate neighbors, across a constellation which contains a great overall diversity of norms. Changes in policy or alignment will resemble ripples across a pond more than a buildup of tectonic force against a brittle fault.

39

42

40−Stars are Schelling points for such gradations precisely because they are discrete cogs in the overall technical infrastructure of Urbit. Technical responsibility and any bounds of ownership will always mark such points. Their designation in the case of Urbit or any other system is necessarily somewhat arbitrary. Our vision is orders of magnitude less centralized than the status quo, but not devolved so far towards the individual that community formation demands massive amounts of _individual_ technical knowledge and maintenance tasks. There will always be a need for routing infrastructure, ergo power (the power to set community norms and external relations) will always accrue to the points of control over that infrastructure.

43+Stars are Schelling points for such gradations precisely because they are discrete cogs in the overall technical infrastructure of Urbit. Technical responsibility and any bounds of ownership will always mark such points. Their designation in the case of Urbit or any other system is necessarily somewhat arbitrary. Our vision is orders of magnitude less centralized than the status quo, but not devolved so far towards the individual that community formation demands massive amounts of *individual* technical knowledge and maintenance tasks. There will always be a need for routing infrastructure, ergo power (the power to set community norms and external relations) will always accrue to the points of control over that infrastructure.

41

44

42−Urbit simplifies much of this infrastructure but, just as importantly, it makes those technical locations, and the conditions of ownership and control, explicit. It allows for them to be owned and controlled by anyone who purchases them, rather than controlled by network-level overlords and unelected government regulators. Stars are somewhere between ISPs and consumer hosting platforms (like Geocities an eon ago, or Wordpress today); independent enough to set their own policies, but generally subject to the realities of running a profitable business. The decisions made by service providers inevitably have a great influence on the norms of any network, and Urbit is no different. The advantage of the Urbit model is that there are far more stars than ISPs, they are easier to run, they are fungible properties with clear ownership, and they are not burdened with technical and regulatory debt which ties them to the status quo. These qualities allow them to be purchased and maintained by a far wider range of people than might be able to control an ISP today; the massive decentralization of routing infrastructure also seems a likely antidote to the current state of regulatory overreach and centralized snooping which ISPs are subject to.

45+Urbit simplifies much of this infrastructure but, just as importantly, it makes those technical locations, and the conditions of ownership and control, explicit. It allows for them to be owned and controlled by anyone who purchases them, rather than controlled by network-level overlords and unelected government regulators. Stars are somewhere between ISPs and consumer hosting platforms (like Geocities an eon ago, or Wordpress today); independent enough to set their own policies, but generally subject to the realities of running a profitable business. The decisions made by service providers inevitably have a great influence on the norms of any network, and Urbit is no different. The advantage of the Urbit model is that there are far more stars than ISPs, they are easier to run, they are fungible properties with clear ownership, and they are not burdened with technical and regulatory debt which ties them to the status quo. These qualities allow them to be purchased and maintained by a far wider range of people than might be able to control an ISP today; the massive decentralization of routing infrastructure also seems a likely antidote to the current state of regulatory overreach and centralized snooping which ISPs are subject to.

43

46

44−The Internet gave us an unprecedented flowering of diverse cultures; it gave communities the option to pursue a vast number of paths and goals. And we _should_ have the ability, granted by wealth, free time, and communications technology, to arrange the rules of our collaboration as we wish. The structural design of the Urbit network is an effort to provide that power, encoded in a digital asset with private keys that can be held both by individuals and (via multisig arrangements) by groups. The lower price and complexity of stars compared to current ISPs also makes a lot more room for innovation in business models; star owners can make their own judgments about how to prioritize commercial revenue versus cooperative ownership, anonymity versus identity, short-term versus long-term contracts.

47+The Internet gave us an unprecedented flowering of diverse cultures; it gave communities the option to pursue a vast number of paths and goals. And we *should* have the ability, granted by wealth, free time, and communications technology, to arrange the rules of our collaboration as we wish. The structural design of the Urbit network is an effort to provide that power, encoded in a digital asset with private keys that can be held both by individuals and (via multisig arrangements) by groups. The lower price and complexity of stars compared to current ISPs also makes a lot more room for innovation in business models; star owners can make their own judgments about how to prioritize commercial revenue versus cooperative ownership, anonymity versus identity, short-term versus long-term contracts.

45

48

46We see stars as an opportunity to incubate community hubs, to plant a flag in the wilderness, declare values and alignments, and see who shows up. This process can be varied; some stars might advertise widely, others might quietly and slowly invite other communities on board. That’s the point. There’s a nice juxtaposition between first mover-effect and overall availability here; early adopters will have an opportunity to shape discourse, but the supply is not so constrained that they’ll capture all of it. Early adopters will likely have an immense and permanent value of voice, infrastructural ownership, and ongoing revenue over their shorter-term speculative one.

49We see stars as an opportunity to incubate community hubs, to plant a flag in the wilderness, declare values and alignments, and see who shows up. This process can be varied; some stars might advertise widely, others might quietly and slowly invite other communities on board. That’s the point. There’s a nice juxtaposition between first mover-effect and overall availability here; early adopters will have an opportunity to shape discourse, but the supply is not so constrained that they’ll capture all of it. Early adopters will likely have an immense and permanent value of voice, infrastructural ownership, and ongoing revenue over their shorter-term speculative one.

47

50

48−The diversity and non-discoverability of Urbit are already showing themselves: we hear whisperings of insular communities that we not only _don’t_ know about but by our express intentions _can’t_ know about unless they make themselves known.

51+The diversity and non-discoverability of Urbit are already showing themselves: we hear whisperings of insular communities that we not only *don’t* know about but by our express intentions *can’t* know about unless they make themselves known.

49

52

50−Regardless of whether we or anyone else know about them, star owners already possess legible chunks of the ‘missing middle’’—large enough to affect the map of the Urbit universe, small enough to allow a wide array of voices—in a way that the ownership models of the current Internet can’t come anywhere close to providing. Not every neighborhood poker club needs an Urbit star. But the institution-founders, tastemakers, and social connectors of today and tomorrow, those who want to build opera houses on the digital prairie, should consider the advantages of building on a star.

53+Regardless of whether we or anyone else know about them, star owners already possess legible chunks of the ‘missing middle’’—large enough to affect the map of the Urbit universe, small enough to allow a wide array of voices—in a way that the ownership models of the current Internet can’t come anywhere close to providing. Not every neighborhood poker club needs an Urbit star. But the institution-founders, tastemakers, and social connectors of today and tomorrow, those who want to build opera houses on the digital prairie, should consider the advantages of building on a star.

content/blog/the-shape-of-dao-governance-to-come.mddeleted−103

@@ -1,103 +0,0 @@

1−+++

2−title = "The Shape of DAO Governance to Come"

3−date = "2022-08-17"

4−description = "When building the Combine DAO, we conducted a survey of DAO governance and tooling and came to the conclusion that the many theoretical approaches to the problem of governance were tied to the implementation details of the DAO stack. Since we were building everything on Urbit—as opposed to through the typical combination of Solidity contracts, Web2 tools and Snapshot—we realized that we’d have to do some rethinking. A new approach for a new stack."

5−

6−[extra]

7−author = "Anthony Arroyo"

8−ship = "~poldec-tonteg"

9−image = "https://storage.googleapis.com/media.urbit.org/blog/2022.7.29..17.14.22-image.jpg"

10−+++

11−

12−

13−

14−On Urbit, the risk of a governance attack is reduced because the Combine DAO’s founding team was selected based on their on-Urbit track records. All participants had skin in the game. This allowed us to focus on workaday consensus building, which forms the bulk of any organization’s activities. We use Holium’s Ballot app, which integrates with all aspects of Urbit OS and gives complete flexibility for automating the execution of a winning proposal via [Custom Actions](https://docs.holium.com/ballot/custom-actions/intro).

15−

16−Let’s walk through the thought process that led us to adopt an Urbit-centric approach to DAO governance.

17−

18−## Reputation’s Effect on DAO Governance

19−

20−In our last blog, we discussed how Urbit’s pseudonymous reputation model frees DAOs from the constraints of “trustless” systems. Urbit IDs also mitigate the inflexibility that plagues DAO governance. Here’s what we mean.

21−

22−One of the primary objectives of DAO governance systems is to prevent governance attacks. A governance attack occurs when one or more actors changes the internal processes to benefit themselves, for example transfering the entire treasury to himself.

23−

24−The risk of governance attacks means DAO governance is either 1) very rigid or 2) vulnerable. The vast majority of DAOs, Moloch for example, opt for the former. Thus the rules around upgrading smart contracts are constrained. Once systems are in place, they can’t be changed. On-chain activity is limited. Voting procedures are either distilled or taken off-chain (and usually onto Web2.) This leaves DAOs inflexible.

25−

26−Here’s an example of said inflexibility gone wrong. In March of this year, the DAO that runs the Ethereum Name Service [held a vote](https://www.coindesk.com/layer2/2022/03/07/ens-and-the-limitations-of-dao-governance/) to oust its director Brantly Millegan. Brantly had recently been canceled for 2016 tweets dug up by an anonymous DAO member, fired from his role as director of operations at ENS’ non-DAO corporate parent True Names Limited. ENS iself, however, was governed by a typical 1 share: 1 vote system (plus delegates). Unsurprisingly, Millegan owned or controlled a large block of votes, and was able to overcome the ouster vote 1.6 million tokens to 1.4 million, with holders of roughly one third of the tokens abstaining or not participating.

27−

28−Now, this is indeed a DAO working as it should, a democratic decision unswayed by the influence of insiders or elites. At the same time, the natural functioning of the DAO was derailed by mass distraction. Instead of focusing on ENS, for nearly a year the DAO’s function was to address a controversy raised by an anonymous member who, if we’re being honest, most likely intended to disrupt its active functioning from the start.

29−

30−We arrive back again at the inflexibility inherent to anonymity—if just anyone can buy a token, bad actors will buy them. Yet currently most DAOs intentionally eschew reputation. The incentives for good behaviors are thus only economic.

31−

32−[Pseudonymous reputation](https://urbit.org/blog/pseudonymous-reputation) changes this calculus, adding incentives beyond money for both security and participation. This means when built on Urbit, DAOs are less susceptible to governance attacks, and more flexible. Having a baseline of trust allows DAOs to experiment with different governance tools and structures.

33−

34−In order to understand how DAOs are more free to experiment on Urbit and what they can experiment with, it’s first important to understand the history of DAO governance, why it developed the way they did, and where it’s at currently.

35−

36−

37−## A Little DAO Governance History Lesson

38−

39−The first DAO, The DAO, was also the most disastrous. A recursive calls flaw in the governance code led to the only hack-related hard fork in Ethereum History.

40−

41−Recursive call weaknesses in DAO code are somewhat like endlessly automated micro-pyramid schemes. An attacker can call a transaction, mark its benefit, then initiate another transaction before the original transaction is completed, over and over until the block limit is reached. Bernie Madoff paid off old investments with new investments while marking fake gains, took out fees, then reinvested before the prior investments could be properly marked. Both schemes work when automated governance fails.

42−

43−While The DAO’s shoddy governance was its downfall, it was Ethereum’s good governance that saved ETH. Ethereum leadership proposed a hard fork and 97% of holders voted in favor. The transaction was undone. Money returned. Ethereum Classic was born.

44−

45−While The DAO failed, its happy ending paved the way for the DAO boom of today. DAO creators learned the security lesson: there hasn’t been a major DAO hack since 2016. They built better governance—a combination of visionary leadership, trustless voting, and vigorous participation—that steered the ETH ship to calmer waters.

46−

47−

48−## Birth of the Ragequit

49−

50−Moloch DAO was born in the shadow of The DAO fiasco; its governance was expressly designed in response to it. Unlike The DAO, Moloch is a charity; it exists only to give money away to Ethereum infrastructure projects. Its on-chain governance is extremely_ _simple. Members can do only one of two things.

51−

52−The first thing is submitting and voting on proposals for new members. Votes are majority rule with one vote per Moloch share. Only an existing member can propose a new member, so prospective members must convince an existing one to nominate them.

53−

54−New member proposals double as funding proposals, a clever wrinkle which demonstrates just how much can be done on-chain with a single function. Every proposal must include a fundable ETH infrastructure project and a fundee to execute it. If approved, Moloch accepts the fundee as a new member and grants them a number of Moloch shares exchangeable 1:1 for ETH.

55−

56−

57−

58−How the fundee exchanges the shares for ETH brings us to the second thing Moloch members can do: ragequitting.

59−

60−Ragequitting is a smart contract function that allows members to rescind their shares—and thus their membership—during a seven day waiting period between approval of new members and disbursement of their funds. Its primary purpose is to allow members to opt out of the DAO if they don’t like a new member or proposal. If they ragequit, they automatically receive ETH equal to their shares.

61−

62−Ragequitting thus provides a major safeguard against the kinds of attack that took down The DAO. Members can simply ragequit en masse to invalidate any harmful action, thereby looting their own DAO and stopping bad actors in their tracks. Ragequitting is Moloch’s “ultimate safety net for malicious attacks.”

63−

64−Like member voting, ragequitting also has a dual purpose. In order to receive their funding, new fundees must ragequit, discharging their shares, receiving ETH, and thereby immediately becoming non-members. Thus, the only time someone becomes a permanent member is if they are granted more shares than they ragequit, which usually happens for non-fundee members, i.e. philanthropic members, not fundees.

65−

66−This is all to say that Moloch, a very successful DAO, has reduced its governance to the simplest imaginable framework. Members can take one of two actions—that’s it. While it makes for a functional secure on-chain charity, the ragequit process isn’t exactly dynamic governance. It’s too low-res for the vast majority of organizations.

67−

68−## Ouroboros

69−

70−In a way, ragequitting uses pyramid scheme logic to its advantage. The only thing members can do is add other members or quit; and it’s through these cyclical actions that the DAO gains members, disburses funds, and maintains security. But it also opens up new problems. For example, what happens if a disgruntled member intentionally votes yes on a harmful proposal, only to ragequit their shares just after the proposal passes? You might call it a murder suicide problem.

71−

72−DAOs supposedly solve the Principal Agent Dilemma; an ancient problem faced by all resource-distributing organizations where an agent’s self-interest inevitably runs counter to principles’ assets. The most common example is a non-shareholding manager of a company (agent) versus its shareholders (principal). The manager is in charge of spending shareholders’ money, but doesn’t suffer the financial consequences from her decisions. Theoretically, DAO principles and DAO agents are indistinguishable—everyone is both investor and employee—which solves the dilemma.

73−

74−But anonymous shareholders often act badly, or they don’t act at all. Even the [DAOs with the highest participation](https://www.businessofbusiness.com/articles/ranking-daos-we-computed-their-net-community-score-to-see-how-they-stack-up/) top out around 75%, and that’s rare. A DAO with low voter participation can become either paralyzed, if a quorum is required, or oligarchical if one isn’t. On-chain voting requires high gas fees and time spend, prohibitively high when it comes to the many technical decisions that need to be made. This is why every successful DAO has naturally developed sets of working groups who make decisions off-chain with the blessing of the body politic. The vast majority of these “governance forums” use a patchwork of Web2 apps.

75−

76−For the bigger decisions, avoiding high gas fees and low participation can mean voting with literal Discord emojis, then having small groups of trusted “delegates” enter on-chain decisions via multi-sigs. This is both sloppy and defeats the purpose of the DAO.

77−

78−More serious solutions make up the primary class L2 products. “Dynamic governance” adds granularity to voting systems, allowing for more complex on-chain voting with different rights for different member classes. “Holographic consensus” gamifies participation by appending a prediction market to every vote. Some are even trying “[Meta Governance](https://indexcoop.com/blog/early-2022-survey-of-metagovernance)”—DAOs governing DAOs. L2 decisions are even further analyzed by deep risk analyzers like Gauntlet that stress test decisions via simulated protocols before they’re executed on-chain.

79−

80−The simple solution is conducting votes using decentralized apps that verify shareholder status. Snapshot is an IPFS voting app that holds votes off-chain, weighing and verifying member votes by reading members’ wallets. It’s a quick and secure way to stage off-chain votes, but it’s still pretty limited. Snapshot is called that because all it really does is take a picture of the result of a vote. All the activity resulting from said vote must still be manually undertaken by DAO operators.

81−

82−Traditional DAOs suffer from what we like to call the Self-Enforcement Problem. Smart contracts enforce themselves, a stark difference from traditional corporations where bylaws and operating rules are met by employees using the best tools for the job. With DAOs, the bylaws and the tools that enforce them are one and the same. This adds up to yet another layer on inflexibility: traditional orgs can adopt new tools for old problems, DAOs cannot.

83−

84−

85−## The Right Tool for the Job

86−

87−This all brings us finally back to Urbit. In the Urbit OS using Urbit IDs, DAOs can integrate every governance solution discussed above without touching Web2. Tailor DAO governance to your own precise needs. Download someone else’s voting app, or spin up your own. Using Urbit blurs the boundaries between on-chain and off-chain actions, eliminating the need for ad hoc fixes then fixes to fix those fixes. It all occurs in one landscape, and can pivot with new information

88−

89−One Urbit app is called Ballot. Ballot most closely resembles Snapshot. It’s like a decentralized version of Snapshot that works without the need for Discord—everything is on the Urbit OS—that can also be modified to execute custom off-chain actions after a vote is held.

90−

91−

92−

93−Ballot allows for this sort of dynamic governance enhancement, or what we call Custom Actions. In a way, Custom Actions make the dream of smart contracts a reality: instead of being constrained to ragequitting or not ragequitting, you can create automated granular responses to Ballot votes. In other words, smart contracts that are actually smart. One action could be “tweet something” or “ping someone” once a vote is recorded in Ballot. You can write any if-then you want on the outcomes of a vote. For example, instead of relegating membership to simplistic on-chain democracy, a la ragequitting, Ballot has a function for inviting or kicking members via Urbit native logic. Imagine if Snapshot could both conduct a Moloch-style membership vote, and then automatically add or kick the member depending on the result. That’s Ballot.

94−

95−What about the small technical decisions, like the ones that took down The DAO, like booting someone from a chat or paying a contractor through treasury? All of those actions are programmatic, irreversible, and immutable on Urbit, eliminating concerns about gas fees and participation.

96−

97−If Ballot doesn’t suit your DAO’s needs, it’s easy to use Urbit’s primitives to write a custom voting application. Since Urbit has ring signature support built in, you can build a simple, anonymous voting app in just 15 minutes, following [this tutorial](https://developers.urbit.org/guides/quickstart/voting-guide). The combination of cryptographic identity and an append-only event log means that you are free to experiment with different tools to support whatever governance process your DAO adheres to.

98−

99−The Combine DAO uses Ballot for voting on proposals as it integrates cleanly with Urbit ID and provides flexibility for setting different quora for votes and Custom Actions to automate outcomes. There is thus no need to distinguish between the tool used for a “real vote” such as deploying Stars in exchange for tokens and the tool used for a “fun vote” like choosing a date for a meetup.This flexibility and interoperability is a hallmark to the burgeoning supply of [applications](https://urbit.org/ecosystem?type=applications) being built for Urbit.

100−

101−—

102−

103−*Anthony Arroyo is the Director of [The Combine DAO](https://blog.the-combine.org/introduction-to-the-combine-dao)*

content/blog/the-state-of-landscape.md+13−16

@@ -1,12 +1,8 @@

1+++

1+++

2title = "The State of Landscape"

2title = "The State of Landscape"

3−date = "2019-05-15"

3+date = 2019-05-16

4description = "An update on the state of Landscape and the Urbit network."

4description = "An update on the state of Landscape and the Urbit network."

5−aliases = [

6− "/posts/essays/the-state-of-landscape",

5+aliases = ["/posts/essays/the-state-of-landscape", "/posts/the-state-of-landscape"]

7− "/posts/the-state-of-landscape"

8−]

9−

10[extra]

6[extra]

11author = "Galen Wolfe-Pauly"

7author = "Galen Wolfe-Pauly"

12ship = "~ravmel-ropdyl"

8ship = "~ravmel-ropdyl"

@@ -15,27 +11,27 @@ image = "https://media.urbit.org/site/posts/essays/the-state-of-landscape-1.png"

15

11

16

12

17

13

18−The TL;DR is: if you’re really excited about living on Mars, Landscape is fun to try out. Come join `~dopzod/urbit-help`, experiment with creating your own chats and collections (did anyone find that easter egg, yet?), and see what you can do with the thing.

14+The TL;DR is: if you’re really excited about living on Mars, Landscape is fun to try out. Come join `~dopzod/urbit-help`, experiment with creating your own chats and collections (did anyone find that easter egg, yet?), and see what you can do with the thing.

19

15

20Landscape today is for the intrepid adventurer. So is much of the system. If you want to read about what we’re doing to make it more welcoming, [check out the 2019 roadmap](/posts/essays/2019-5-roadmap/).

16Landscape today is for the intrepid adventurer. So is much of the system. If you want to read about what we’re doing to make it more welcoming, [check out the 2019 roadmap](/posts/essays/2019-5-roadmap/).

21

17

22## The Broad View

18## The Broad View

23

19

24−We thought a lot last year about how to avoid the pitfalls of modern social networks. The services we all use today each feel like _one place_. It’s as if everyone on MEGANET is living together in the same city.

20+We thought a lot last year about how to avoid the pitfalls of modern social networks. The services we all use today each feel like *one place*. It’s as if everyone on MEGANET is living together in the same city.

25

21

26In the real world, cities have their own cultures. So we thought: there must be some way to build more granular communities online. Living in a single world-city is kind of a bummer, honestly.

22In the real world, cities have their own cultures. So we thought: there must be some way to build more granular communities online. Living in a single world-city is kind of a bummer, honestly.

27

23

28−Landscape was our first experiment in this direction. It’s a ruthlessly simple interface for chat and discussion that runs on top of Arvo. You can connect to Landscape in a browser or in an app on your iOS device. All communication is pseudonymous and authenticated (as with everything in Arvo) with your Azimuth point.

24+Landscape was our first experiment in this direction. It’s a ruthlessly simple interface for chat and discussion that runs on top of Arvo. You can connect to Landscape in a browser or in an app on your iOS device. All communication is pseudonymous and authenticated (as with everything in Arvo) with your Azimuth point.

29

25

30Over the past few months, we’ve been running small experiments, experimenting with ways to support our own work and finding the limits of what we can do on the network. Originally, we built Landscape out of our desire to get away from using MEGACORP communication tools in our daily work. We thought: if we’re trying to build a whole new network and society, we had better go live there first.

26Over the past few months, we’ve been running small experiments, experimenting with ways to support our own work and finding the limits of what we can do on the network. Originally, we built Landscape out of our desire to get away from using MEGACORP communication tools in our daily work. We thought: if we’re trying to build a whole new network and society, we had better go live there first.

31

27

32−Landscape is an experiment — it’s supposed to be fun, above all, and a good way to help focus our efforts on maturing the platform.

28+Landscape is an experiment — it’s supposed to be fun, above all, and a good way to help focus our efforts on maturing the platform.

33

29

34Anyway, let’s show off some of the specifics, and give an update on this experiment so far.

30Anyway, let’s show off some of the specifics, and give an update on this experiment so far.

35

31

36## A Quick Tour

32## A Quick Tour

37

33

38−Landscape is pretty simple. It lets you subscribe to chats, in the spirit of IRC, and ‘collections’, which are effectively forums or blogs with comments. You can also direct message with other running ‘ships’ or Arvo nodes.

34+Landscape is pretty simple. It lets you subscribe to chats, in the spirit of IRC, and ‘collections’, which are effectively forums or blogs with comments. You can also direct message with other running ‘ships’ or Arvo nodes.

39

35

40For the most part, this happens through a web interface that you can access at `https://ship.arvo.network` or via `localhost:80`.

36For the most part, this happens through a web interface that you can access at `https://ship.arvo.network` or via `localhost:80`.

41

37

@@ -49,7 +45,7 @@ What’s keeping us from asking others to use this thing more aggressively? Let

49

45

50They have gotten a lot better, but there are still a few things that can crash your Arvo ship. This, of course, has nothing to do with your Azimuth point, which is completely separate and, as far as we know, secure.

46They have gotten a lot better, but there are still a few things that can crash your Arvo ship. This, of course, has nothing to do with your Azimuth point, which is completely separate and, as far as we know, secure.

51

47

52−The first (and most severe) is a bug in our event persistence that occurs very rarely. Basically, there are conditions under which you can cause events not to be properly written to disk and corrupt your event log. It’s pretty unlikely, but it’s unacceptable for a real product since it basically causes you to have to wait out the current network era.

48+The first (and most severe) is a bug in our event persistence that occurs very rarely. Basically, there are conditions under which you can cause events not to be properly written to disk and corrupt your event log. It’s pretty unlikely, but it’s unacceptable for a real product since it basically causes you to have to wait out the current network era.

53

49

54The second is that Ames (our network protocol) has occasional connectivity problems. Originally, we thought we had found this issue as being related to [a timer bug](https://github.com/urbit/arvo/pull/1072). It may be, but the networking is in the process of a major overhaul — so we’ve implemented a few bandaids to make the situation workable. `|bonk` sometimes needs to be used to reset connections between peers, and `:ethmanage` sometimes need to be used to re-synchronize with the blockchain. It’s an ugly fix, but it usually works.

50The second is that Ames (our network protocol) has occasional connectivity problems. Originally, we thought we had found this issue as being related to [a timer bug](https://github.com/urbit/arvo/pull/1072). It may be, but the networking is in the process of a major overhaul — so we’ve implemented a few bandaids to make the situation workable. `|bonk` sometimes needs to be used to reset connections between peers, and `:ethmanage` sometimes need to be used to re-synchronize with the blockchain. It’s an ugly fix, but it usually works.

55

51

@@ -59,20 +55,21 @@ Relatedly, we have occasionally been seeing errors caused by the Arvo network be

59

55

60One great thing about the Arvo network is that it’s more like a giant single computer than a network. When you talk to another ship, use remote files or sync data it’s almost the same as working with local data.

56One great thing about the Arvo network is that it’s more like a giant single computer than a network. When you talk to another ship, use remote files or sync data it’s almost the same as working with local data.

61

57

62−The main thing underlying this is _sequence numbers_. Your Arvo ship keeps track of every message it has exchanged with every other ship, and it never breaks that sequence. If our ships are talking, and we’re on packet `83910` but you reset and try to start again at `0` my ship just thinks you’ve lost your mind and won’t talk to you anymore.

58+The main thing underlying this is *sequence numbers*. Your Arvo ship keeps track of every message it has exchanged with every other ship, and it never breaks that sequence. If our ships are talking, and we’re on packet `83910` but you reset and try to start again at `0` my ship just thinks you’ve lost your mind and won’t talk to you anymore.

63

59

64−We’d like individual resets to work, and we’re [working on it](https://github.com/urbit/arvo/pull/1169). But, for the time being, if you have any fatal error on your ship, it means you’ve got to sit this era out.

60+We’d like individual resets to work, and we’re [working on it](https://github.com/urbit/arvo/pull/1169). But, for the time being, if you have any fatal error on your ship, it means you’ve got to sit this era out.

65

61

66This is another unacceptable bug for anything we truly rely on.

62This is another unacceptable bug for anything we truly rely on.

67

63

68### 3 - There are no push notifications, yet

64### 3 - There are no push notifications, yet

69

65

70−What’s one thing that a chat application needs to do? Notify you of new messages. What does Landscape notify you about? Well, at the moment, basically nothing.

66+What’s one thing that a chat application needs to do? Notify you of new messages. What does Landscape notify you about? Well, at the moment, basically nothing.

71

67

72We implemented and tested a push notifications server for iOS, which is slated for release in the next few months (it depends on things in our `cc-release` branch). We’d also love to work on having your ship connect to your email provider and send you alerts over email. We’re thinking about how to do that.

68We implemented and tested a push notifications server for iOS, which is slated for release in the next few months (it depends on things in our `cc-release` branch). We’d also love to work on having your ship connect to your email provider and send you alerts over email. We’re thinking about how to do that.

73

69

74## What We’ve Learned and What We’re Doing

70## What We’ve Learned and What We’re Doing

75

71

76−Many of us spend all day on Landscape, use it from our phones, and find it really fun. The bugs above bite less than you might think and, in many cases, the experience is quite nice. It’s a passive, distraction-free way to interact with others around the office.

72+Many of us spend all day on Landscape, use it from our phones, and find it really fun. The bugs above bite less than you might think and, in many cases, the experience is quite nice. It’s a passive, distraction-free way to interact with others around the office.

77

73

78We operate one public channel, `~dopzod/urbit-help` for answering any of your questions about the system. And, from time to time, we have been creating topic-centric channels and announcing them publicly. This has been a lot of fun. Come join us if you’re feeling brave.

74We operate one public channel, `~dopzod/urbit-help` for answering any of your questions about the system. And, from time to time, we have been creating topic-centric channels and announcing them publicly. This has been a lot of fun. Come join us if you’re feeling brave.

75+

content/blog/the-understanding-urbit-podcast.md+5−4

@@ -1,15 +1,16 @@

1+++

1+++

2title = "The Understanding Urbit Podcast"

2title = "The Understanding Urbit Podcast"

3−date = "2020-04-02"

3+date = 2020-04-03

4description = "An interview-based podcast series about the Urbit project, as told by those working on it."

4description = "An interview-based podcast series about the Urbit project, as told by those working on it."

5−

6[extra]

5[extra]

7author = "Arthur Falls"

6author = "Arthur Falls"

8ship = "~satsyt-sogleb"

7ship = "~satsyt-sogleb"

9−image = "https://media.urbit.org/site/posts/essays/uu-podcast.png"

8+image ="https://media.urbit.org/site/posts/essays/uu-podcast.png"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/uu-podcast.png">

13

14

14At the end of January, the team at Tlon invited me to spend some time at their San Francisco office and to create a podcast series about Urbit. The idea was to produce an interview-based series about the project told in the words of those working on it. In this modest goal, I think we were very successful. Beyond a transactional description, however, we captured a range of perspectives of the flaws in our current computing landscape and visions for how Urbit will alter it.

15At the end of January, the team at Tlon invited me to spend some time at their San Francisco office and to create a podcast series about Urbit. The idea was to produce an interview-based series about the project told in the words of those working on it. In this modest goal, I think we were very successful. Beyond a transactional description, however, we captured a range of perspectives of the flaws in our current computing landscape and visions for how Urbit will alter it.

15

16

content/blog/the-urbit-address-space.md+88−93

@@ -1,39 +1,34 @@

1+++

1+++

2title = "The Urbit Address Space"

2title = "The Urbit Address Space"

3−date = "2016-05-15"

3+date = 2016-05-16

4description = "An overview of Urbit's cryptographic address space."

4description = "An overview of Urbit's cryptographic address space."

5−aliases = [

6− "/posts/essays/the-urbit-address-space",

5+aliases = ["/posts/essays/the-urbit-address-space", "/posts/the-urbit-address-space"]

7− "/posts/the-urbit-address-space"

8−]

9−

10[extra]

6[extra]

11author = "Galen Wolfe-Pauly + Curtis Yarvin"

7author = "Galen Wolfe-Pauly + Curtis Yarvin"

12ship = "~ravmel-ropdyl + ~sorreg-namtyv"

8ship = "~ravmel-ropdyl + ~sorreg-namtyv"

13image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/the-urbit-address-space.jpg"

9image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/the-urbit-address-space.jpg"

14+++

10+++

15−

16

11

17

12

18## Basics

13## Basics

19

14

20−Urbit contains a lot of new technology. As an ordinary user, all you

15+Urbit contains a lot of new technology. As an ordinary user, all you

21−need to understand is Urbit's identity model. If you're in a hurry,

16+need to understand is Urbit's identity model. If you're in a hurry,

22just read these simplified basics.

17just read these simplified basics.

23

18

24−An Urbit identity, or "ship," is a string like `~firbyr-napbes`. It

19+An Urbit identity, or "ship," is a string like `~firbyr-napbes`. It

25means nothing, but it's easy to remember and say out loud.

20means nothing, but it's easy to remember and say out loud.

26`~firbyr-napbes` is actually just a 32-bit number, like an IP address,

21`~firbyr-napbes` is actually just a 32-bit number, like an IP address,

27that we turn into a human-memorable string.

22that we turn into a human-memorable string.

28

23

29Technically, a ship is a secure digital identity that you own and

24Technically, a ship is a secure digital identity that you own and

30−control with a cryptographic key, like a Bitcoin wallet. As in

25+control with a cryptographic key, like a Bitcoin wallet. As in

31−Bitcoin, the supply of ships is mathematically limited. This keeps

26+Bitcoin, the supply of ships is mathematically limited. This keeps

32the network friendly, by making spam and abuse expensive.

27the network friendly, by making spam and abuse expensive.

33

28

34A ship name is just a number; smaller numbers make shorter names.

29A ship name is just a number; smaller numbers make shorter names.

35−Shorter names are easier to remember, so they're more valuable. So

30+Shorter names are easier to remember, so they're more valuable. So

36−ships are classified by the number of bits in their name. (A ship

31+ships are classified by the number of bits in their name. (A ship

37name is just a scrambled base-256 representation of the number.)

32name is just a scrambled base-256 representation of the number.)

38

33

39A 32-bit ship (like `~firbyr-napbes`) is called a "planet." A 16-bit

34A 32-bit ship (like `~firbyr-napbes`) is called a "planet." A 16-bit

@@ -42,48 +37,48 @@ ship (like `~pollev)` is a "star." An 8-bit ship (like `~mun`) is a

42Stars and galaxies are network infrastructure.

37Stars and galaxies are network infrastructure.

43

38

44Each planet or star is launched by its "parent," the star or galaxy

39Each planet or star is launched by its "parent," the star or galaxy

45−whose number is its bottom half. So the planet `~firbyr-napbes`,

40+whose number is its bottom half. So the planet `~firbyr-napbes`,

46`0xdead.beef` or `3.735.928.559`, is the child of `~pollev`, `0xbeef`

41`0xdead.beef` or `3.735.928.559`, is the child of `~pollev`, `0xbeef`

47−or `48.879`, whose parent is `~mun`, `0xef`, `239`. The parent of

42+or `48.879`, whose parent is `~mun`, `0xef`, `239`. The parent of

48`~mun` and all galaxies is `~zod`, `0`.

43`~mun` and all galaxies is `~zod`, `0`.

49

44

50−If Bitcoin is money, Urbit is land. Much as all real-estate titles in

45+If Bitcoin is money, Urbit is land. Much as all real-estate titles in

51England trace back to William the Conqueror, all certificates in Urbit

46England trace back to William the Conqueror, all certificates in Urbit

52trace back to `~zod`.

47trace back to `~zod`.

53

48

54−But this universe is worthless unless dispersed. It's already quite

49+But this universe is worthless unless dispersed. It's already quite

55−well fragmented. And as it grows distributed, it grows decentralized.

50+well fragmented. And as it grows distributed, it grows decentralized.

56The endpoint is a virtual city of 4 billion (`2^32`) citizens, all

51The endpoint is a virtual city of 4 billion (`2^32`) citizens, all

57−owners of their own independent digital identities. The stars and

52+owners of their own independent digital identities. The stars and

58galaxies continue as a federated governance and service network.

53galaxies continue as a federated governance and service network.

59

54

60This city is a social network, a peer-to-peer packet network, and a

55This city is a social network, a peer-to-peer packet network, and a

61−public-key infrastructure (PKI). In the social layer, your ship is

56+public-key infrastructure (PKI). In the social layer, your ship is

62−your name. In the packet layer, your ship is your network address.

57+your name. In the packet layer, your ship is your network address.

63−In the PKI, your ship is your cryptographic identity. Perhaps more

58+In the PKI, your ship is your cryptographic identity. Perhaps more

64intuitively, a ship is a sort of pronounceable phone number.

59intuitively, a ship is a sort of pronounceable phone number.

65

60

66−And once Urbit is built, no one owns the city. No one can control it.

61+And once Urbit is built, no one owns the city. No one can control it.

67It does need governance; but it governs itself as a digital republic.

62It does need governance; but it governs itself as a digital republic.

68

63

69## Details

64## Details

70

65

71−As an Urbit user, these basics are all you need to know. As a

66+As an Urbit user, these basics are all you need to know. As a

72−developer, a few more details might interest you. (An even more

67+developer, a few more details might interest you. (An even more

73comprehensive treatment is in the [whitepaper](https://media.urbit.org/whitepaper.pdf)).

68comprehensive treatment is in the [whitepaper](https://media.urbit.org/whitepaper.pdf)).

74

69

75### Design goals

70### Design goals

76

71

77An identity system has three goals: a name wants to be secure,

72An identity system has three goals: a name wants to be secure,

78−human-meaningful, and decentralized. A principle called "Zooko's

73+human-meaningful, and decentralized. A principle called "Zooko's

79triangle" says that a practical identity system can achieve any two of

74triangle" says that a practical identity system can achieve any two of

80these goals.

75these goals.

81

76

82The art of OS design is the art of using strategic tradeoffs to almost

77The art of OS design is the art of using strategic tradeoffs to almost

83−solve unsolvable problems. Urbit's goals are to be secure,

78+solve unsolvable problems. Urbit's goals are to be secure,

84−human-_memorable_, and _eventually_ decentralized. We sacrifice

79+human-_memorable_, and _eventually_ decentralized. We sacrifice

85meaning (Urbit is not competing with the DNS), and postpone

80meaning (Urbit is not competing with the DNS), and postpone

86−decentralization. These tradeoffs buy us a simple system that can

81+decentralization. These tradeoffs buy us a simple system that can

87actually be built.

82actually be built.

88

83

89### Comparison to existing identity layers

84### Comparison to existing identity layers

@@ -97,43 +92,43 @@ addresses (like `126.78.92.112`), domain names (like

97`@galenwp`).

92`@galenwp`).

98

93

99Urbit (or more precisely, its Ames protocol) squeezes all three layers

94Urbit (or more precisely, its Ames protocol) squeezes all three layers

100−into one. At the network level, Urbit is a P2P overlay network; your

95+into one. At the network level, Urbit is a P2P overlay network; your

101−ship is your network address. It's also the name of your server.

96+ship is your network address. It's also the name of your server.

102−Finally, it's your secure digital pseudonym. And we map your ship

97+Finally, it's your secure digital pseudonym. And we map your ship

103name into the DNS, at `ship.urbit.org`.

98name into the DNS, at `ship.urbit.org`.

104

99

105(One way to use Urbit is as an identity for the Internet, which

100(One way to use Urbit is as an identity for the Internet, which

106−doesn't have a standard system of secure authentication. Urbit has a

101+doesn't have a standard system of secure authentication. Urbit has a

107single-signon API which lets any Web server accept Urbit logins, like

102single-signon API which lets any Web server accept Urbit logins, like

108a normal social login -- but not captive to any central mainframe.)

103a normal social login -- but not captive to any central mainframe.)

109

104

110### Cryptographic ownership

105### Cryptographic ownership

111

106

112−You own an Urbit ship cryptographically, like a Bitcoin wallet. But

107+You own an Urbit ship cryptographically, like a Bitcoin wallet. But

113Urbit doesn't use a blockchain or mining.

108Urbit doesn't use a blockchain or mining.

114

109

115You transfer a ship by signing a new public key with the old private

110You transfer a ship by signing a new public key with the old private

116−key, then broadcasting the signature. Any urbit that receives this

111+key, then broadcasting the signature. Any urbit that receives this

117new certificate will no longer trust the old key.

112new certificate will no longer trust the old key.

118

113

119−Urbit is digital land, not digital money. A currency needs to support

114+Urbit is digital land, not digital money. A currency needs to support

120−high-frequency, zero-friction transfers. Real estate transfers are

115+high-frequency, zero-friction transfers. Real estate transfers are

121low frequency and high friction, so the "double spend" problem (which

116low frequency and high friction, so the "double spend" problem (which

122mining solves) is much less pressing.

117mining solves) is much less pressing.

123

118

124−Don't expect urbits to be tradeable on cryptocurrency exchanges. A

119+Don't expect urbits to be tradeable on cryptocurrency exchanges. A

125trade adds at least one signature to the ship's certificate, or two if

120trade adds at least one signature to the ship's certificate, or two if

126−the parties don't trust each other and an intermediary is needed. A

121+the parties don't trust each other and an intermediary is needed. A

127bulky certificate isn't free, since it slows down new connections.

122bulky certificate isn't free, since it slows down new connections.

128

123

129−This isn't a serious problem if urbits are treated like land. But it

124+This isn't a serious problem if urbits are treated like land. But it

130−prevents Urbit from being a competent currency. This is a feature,

125+prevents Urbit from being a competent currency. This is a feature,

131−not a bug. Urbit has no need to compete with Bitcoin or Ethereum,

126+not a bug. Urbit has no need to compete with Bitcoin or Ethereum,

132and every reason not to.

127and every reason not to.

133

128

134## Moons and comets

129## Moons and comets

135

130

136−In the general case, a ship is actually a 128-bit number. A full

131+In the general case, a ship is actually a 128-bit number. A full

137table of ship classes:

132table of ship classes:

138

133

139```

134```

@@ -145,154 +140,154 @@ table of ship classes:

145```

140```

146

141

147Moons are for clients and connected devices: a laptop, a phone, a

142Moons are for clients and connected devices: a laptop, a phone, a

148−digital thermostat. A moon is not independent; its parent planet has

143+digital thermostat. A moon is not independent; its parent planet has

149−to sign its key updates. (We don't want rogue clients floating

144+to sign its key updates. (We don't want rogue clients floating

150randomly around the universe.)

145randomly around the universe.)

151

146

152−A comet's address is the hash of its initial public key. Anyone can

147+A comet's address is the hash of its initial public key. Anyone can

153−launch a comet. Nothing stops you from using a comet as your

148+launch a comet. Nothing stops you from using a comet as your

154identity, except that the name is a mouthful and everyone will assume

149identity, except that the name is a mouthful and everyone will assume

155you're a bot.

150you're a bot.

156

151

157### Scarcity, reputation, friendliness and trust

152### Scarcity, reputation, friendliness and trust

158

153

159A crucial difference between Urbit and other networks is that planets

154A crucial difference between Urbit and other networks is that planets

160−are scarce. Even when the network is fully populated, there are only

155+are scarce. Even when the network is fully populated, there are only

161−4 billion. Early in Urbit's life, most stars and galaxies are not yet

156+4 billion. Early in Urbit's life, most stars and galaxies are not yet

162−operating, so far fewer are available. No one will ever be able to

157+operating, so far fewer are available. No one will ever be able to

163get planets trivially and for free.

158get planets trivially and for free.

164

159

165Urbit is a _friendly network_: a network on which you can assume that

160Urbit is a _friendly network_: a network on which you can assume that

166−a stranger is nice until proven nasty. Friendliness is a direct

161+a stranger is nice until proven nasty. Friendliness is a direct

167−consequence of scarce, individually owned identities. We're not

162+consequence of scarce, individually owned identities. We're not

168changing human nature, just creating the right economic incentives.

163changing human nature, just creating the right economic incentives.

169

164

170Most forms of network abuse are "Sybil attacks": they rely on an

165Most forms of network abuse are "Sybil attacks": they rely on an

171−infinite supply of fresh identities. Scarcity makes reputation work.

166+infinite supply of fresh identities. Scarcity makes reputation work.

172Spam is a business; if the cost of a new planet exceeds the amount of

167Spam is a business; if the cost of a new planet exceeds the amount of

173money you can make by spamming from that planet until its reputation

168money you can make by spamming from that planet until its reputation

174is trashed, there will be no spam.

169is trashed, there will be no spam.

175

170

176Shady stars and galaxies that sell blocks of planets to spammers will

171Shady stars and galaxies that sell blocks of planets to spammers will

177also develop reputations as "bad neighborhoods," damaging the value of

172also develop reputations as "bad neighborhoods," damaging the value of

178−the whole block. Abuse at any level is designed to be

173+the whole block. Abuse at any level is designed to be

179counterproductive and economically self-terminating.

174counterproductive and economically self-terminating.

180

175

181Urbit has no reputation system at all at the moment, simply because

176Urbit has no reputation system at all at the moment, simply because

182−we're so small that friendliness is automatic. The clear and rigorous

177+we're so small that friendliness is automatic. The clear and rigorous

183structure of the address space is not a reputation system; it is a

178structure of the address space is not a reputation system; it is a

184platform on which any number of such systems can and should be built.

179platform on which any number of such systems can and should be built.

185But we can't build one until we need one.

180But we can't build one until we need one.

186

181

187### Initial allocation and rationale

182### Initial allocation and rationale

188

183

189−In cryptocurrency terms, Urbit is "100% premined." Why? Three

184+In cryptocurrency terms, Urbit is "100% premined." Why? Three

190reasons.

185reasons.

191

186

192−One, Urbit doesn't need mining. Two, Urbit is a much more ambitious

187+One, Urbit doesn't need mining. Two, Urbit is a much more ambitious

193−software project than Bitcoin or even Ethereum. To fund its own

188+software project than Bitcoin or even Ethereum. To fund its own

194development, the project needs to capture the potential value of its

189development, the project needs to capture the potential value of its

195own real estate.

190own real estate.

196

191

197Three, most theories of property agree that anyone whoever creates or

192Three, most theories of property agree that anyone whoever creates or

198−discovers new property starts out by owning it. Because galaxies are

193+discovers new property starts out by owning it. Because galaxies are

199−premined, Urbit starts as a centralized system. But it has two strong

194+premined, Urbit starts as a centralized system. But it has two strong

200motivations to decentralize.

195motivations to decentralize.

201

196

202−One, the more decentralized Urbit is, the more Urbit is worth. Two,

197+One, the more decentralized Urbit is, the more Urbit is worth. Two,

203the only way for Urbit to fund its own development is to homestead its

198the only way for Urbit to fund its own development is to homestead its

204own real estate.

199own real estate.

205

200

206Urbit was created by Curtis Yarvin, who has distributed the 256

201Urbit was created by Curtis Yarvin, who has distributed the 256

207galaxies as follows (allocation as of June 1, 2016):

202galaxies as follows (allocation as of June 1, 2016):

208

203

209−95, to the [Tlon Corporation](/blog/company). 50, to urbit.org, the future

204+95, to the [Tlon Corporation](../company). 50, to urbit.org, the future

210−community foundation. 40, to Tlon employees and their family members

205+community foundation. 40, to Tlon employees and their family members

211(24 to Curtis, who started in 2002; 16 to everyone else, who started

206(24 to Curtis, who started in 2002; 16 to everyone else, who started

212−in 2014). 34, to outside investors in Tlon. 37, to 33 other

207+in 2014). 34, to outside investors in Tlon. 37, to 33 other

213individuals, who donated to the project, contributed code or services,

208individuals, who donated to the project, contributed code or services,

214won a contest, or were just in the right place at the right time.

209won a contest, or were just in the right place at the right time.

215

210

216What's critical is that the whole system is unlikely to collapse back

211What's critical is that the whole system is unlikely to collapse back

217−into a single landlord. This is why we've intentionally scattered

212+into a single landlord. This is why we've intentionally scattered

218Urbit's ownership across a diverse set of entities.

213Urbit's ownership across a diverse set of entities.

219

214

220Furthermore, we've defined informal conventions designed to motivate a

215Furthermore, we've defined informal conventions designed to motivate a

221healthy ownership structure by punishing violators with reputation

216healthy ownership structure by punishing violators with reputation

222−cost. Address blocks should only split, never merge; galaxies and

217+cost. Address blocks should only split, never merge; galaxies and

223stars should be owned by different parties; galaxies should be owned

218stars should be owned by different parties; galaxies should be owned

224−by true individuals, not corporations. Urbit does not live up to

219+by true individuals, not corporations. Urbit does not live up to

225these ideals at present, but must always progress toward them.

220these ideals at present, but must always progress toward them.

226

221

227### Federated services, adoption and escape

222### Federated services, adoption and escape

228

223

229−Urbit is a peer-to-peer network. Urbits that live behind a firewall

224+Urbit is a peer-to-peer network. Urbits that live behind a firewall

230or on a home network need "supernodes" to help them route packets.

225or on a home network need "supernodes" to help them route packets.

231−The supernode is the parent. So a parent's work isn't done once it's

226+The supernode is the parent. So a parent's work isn't done once it's

232launched all its children.

227launched all its children.

233

228

234−There's no way to enforce this responsibility. So a star or planet

229+There's no way to enforce this responsibility. So a star or planet

235can be _adopted_ by a new parent of the same class, letting it escape

230can be _adopted_ by a new parent of the same class, letting it escape

236−from a bad default parent. If your parent stops serving you, and no

231+from a bad default parent. If your parent stops serving you, and no

237other parent is willing to adopt you, you're probably a bad actor.

232other parent is willing to adopt you, you're probably a bad actor.

238

233

239−Supernode routing is just one example of why you need a parent. A

234+Supernode routing is just one example of why you need a parent. A

240mature Urbit will naturally develop all kinds of other _federated

235mature Urbit will naturally develop all kinds of other _federated

241services_ -- from technical standardization and update approval, to

236services_ -- from technical standardization and update approval, to

242−certificate update broadcast, to reputation and friend lookup. All

237+certificate update broadcast, to reputation and friend lookup. All

243−these services are delivered by cooperating stars and galaxies. Bad

238+these services are delivered by cooperating stars and galaxies. Bad

244actors at this level should be rare.

239actors at this level should be rare.

245

240

246Especially when Urbit is young, the level of trust that a child places

241Especially when Urbit is young, the level of trust that a child places

247−in its parent is high. The trust implied by automatic kernel updates

242+in its parent is high. The trust implied by automatic kernel updates

248−is almost infinite. You can disable updates, but that's nowhere near

243+is almost infinite. You can disable updates, but that's nowhere near

249−practical yet. (Ideally we will be able to freeze the Arvo kernel,

244+practical yet. (Ideally we will be able to freeze the Arvo kernel,

250like Nock, and turn off kernel updates; but this will take years at

245like Nock, and turn off kernel updates; but this will take years at

251least.)

246least.)

252

247

253### Code is law: seeing like a pattern language of great cities

248### Code is law: seeing like a pattern language of great cities

254

249

255−Constitutional innovation is dangerous. Our vision of digital

250+Constitutional innovation is dangerous. Our vision of digital

256governance isn't ours, but is synthesized as best we can from the work

251governance isn't ours, but is synthesized as best we can from the work

257of four great 20th-century thinkers: the legal scholar Lawrence

252of four great 20th-century thinkers: the legal scholar Lawrence

258Lessig, the political scientist James C. Scott, the urbanist Jane

253Lessig, the political scientist James C. Scott, the urbanist Jane

259Jacobs and the architect Christopher Alexander.

254Jacobs and the architect Christopher Alexander.

260

255

261All decentralized computation systems rely to some extent on Lessig's

256All decentralized computation systems rely to some extent on Lessig's

262−principle: "code is law." Where law uses human interpretation to

257+principle: "code is law." Where law uses human interpretation to

263−determine an outcome, code uses mathematics. It is code, not law,

258+determine an outcome, code uses mathematics. It is code, not law,

264that decides who owns a Bitcoin wallet.

259that decides who owns a Bitcoin wallet.

265

260

266−But all these systems, including Bitcoin, need governance. They need

261+But all these systems, including Bitcoin, need governance. They need

267−as little as possible, but not none. In the digital world as in the

262+as little as possible, but not none. In the digital world as in the

268real world, _laissez-faire_ is always necessary, never sufficient.

263real world, _laissez-faire_ is always necessary, never sufficient.

269Governance is a human universal.

264Governance is a human universal.

270

265

271−That's why we call Urbit a "virtual city." And as a city, it can't be

266+That's why we call Urbit a "virtual city." And as a city, it can't be

272−a corporate gated community. It might start as that, but it has to

267+a corporate gated community. It might start as that, but it has to

273grow up into a true city-state: a self-governing digital republic.

268grow up into a true city-state: a self-governing digital republic.

274This pattern is not just blind clinging to Anglo-American tradition;

269This pattern is not just blind clinging to Anglo-American tradition;

275like every prudent constitution, it fits the actual virtues and vices

270like every prudent constitution, it fits the actual virtues and vices

276of its target population.

271of its target population.

277

272

278Urbit's galactic hierarchy resembles the natural patterns we find in

273Urbit's galactic hierarchy resembles the natural patterns we find in

279−many existing human political systems. As Alexander wrote:

274+many existing human political systems. As Alexander wrote:

280

275

281> Wherever possible, work toward the evolution of independent regions

276> Wherever possible, work toward the evolution of independent regions

282−> in the world, each with its own natural and geographic boundaries;

277+ in the world, each with its own natural and geographic boundaries;

283−> each with its own economy; each one autonomous and self-governing;

278+ each with its own economy; each one autonomous and self-governing;

284−> each with a seat in a world government, without the intervening power

279+ each with a seat in a world government, without the intervening power

285−> of larger states or countries.

280+ of larger states or countries.

286

281

287We adapt Alexander's vision to a digital republic as the pattern that

282We adapt Alexander's vision to a digital republic as the pattern that

288−_authority is proportional to property_. This pattern already has a

283+_authority is proportional to property_. This pattern already has a

289name in the cryptocurrency community, which calls it _proof of stake_.

284name in the cryptocurrency community, which calls it _proof of stake_.

290Urbit's launch hierarchy is a sort of built-in proof of stake.

285Urbit's launch hierarchy is a sort of built-in proof of stake.

291

286

292Another governance pattern, a political cliche but no less valuable

287Another governance pattern, a political cliche but no less valuable

293−for it, is the system of checks and balances. The address space of

288+for it, is the system of checks and balances. The address space of

294Urbit is covered by three independent tiers, galaxies, stars and

289Urbit is covered by three independent tiers, galaxies, stars and

295−planets; which should govern? The obvious design is a three-chambered

290+planets; which should govern? The obvious design is a three-chambered

296legislature balanced against itself.

291legislature balanced against itself.

297

292

298For more on Urbit's governance design, see our [beliefs and

293For more on Urbit's governance design, see our [beliefs and

content/blog/tools-of-our-own.md+18−11

@@ -1,21 +1,24 @@

1+++

1+++

2title = "Tools of Our Own"

2title = "Tools of Our Own"

3−date = "2020-05-12"

3+date = 2020-05-13

4description = "What is a digital environment? What does it mean to shape your own digital environment?"

4description = "What is a digital environment? What does it mean to shape your own digital environment?"

5−

6[extra]

5[extra]

7author = "Matilde Park"

6author = "Matilde Park"

8ship = "~haddef-sigwen"

7ship = "~haddef-sigwen"

9−image = "https://media.urbit.org/site/posts/essays/tools-of-our-own-1.png"

8+image ="https://media.urbit.org/site/posts/essays/tools-of-our-own-1.png"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/tools-of-our-own-1.png">

14+

15+<br>

13

16

14> People need only not to obtain things, they need above all the freedom to make things among which they can live, or give shape to them according to their own tastes, and to put them to use in caring for and about others.

17> People need only not to obtain things, they need above all the freedom to make things among which they can live, or give shape to them according to their own tastes, and to put them to use in caring for and about others.

15>

18>

16−> **Ivan Illich, *Tools for Conviviality***

19+> <cite>Ivan Illich, <em>Tools for Conviviality</em></cite>

17

20

18−One of the recent ways we've come to describe the mission of the Urbit project is to give communities [the power to shape, or evolve, their digital environments](https://urbit.org/blog/urbit-is-for-communities/). Of course, like many of our definitions, it requires some background to really contextualize the claim. When I describe this particular statement to people, they often ask, "What does that _mean_, though? What is a digital environment, and why would I need Urbit to do it?"

21+One of the recent ways we've come to describe the mission of the Urbit project is to give communities [the power to shape, or evolve, their digital environments](https://urbit.org/blog/urbit-is-for-communities/). Of course, like many of our definitions, it requires some background to really contextualize the claim. When I describe this particular statement to people, they often ask, "What does that *mean*, though? What is a digital environment, and why would I need Urbit to do it?"

19

22

20After all, we think of our slate of tools as our entire toolbox. This makes sense for physical tools. And for a lot of people in the real world (at least, I think), their tools remain physical notebooks and paper. I, however, left those tools behind ages ago, and found myself in a world that used my habits, my memory, to loosely organize a wide array of online tools, that were themselves shaped according to the values of their creators.

23After all, we think of our slate of tools as our entire toolbox. This makes sense for physical tools. And for a lot of people in the real world (at least, I think), their tools remain physical notebooks and paper. I, however, left those tools behind ages ago, and found myself in a world that used my habits, my memory, to loosely organize a wide array of online tools, that were themselves shaped according to the values of their creators.

21

24

@@ -23,13 +26,15 @@ The [Rube Goldberg machine](https://en.wikipedia.org/wiki/Rube_Goldberg_machine)

23

26

24And it's nobody's distinct fault that the experience of aligning all these disparate services into a workflow is a skill in itself. It's a collective restriction that comes from the systems beneath.

27And it's nobody's distinct fault that the experience of aligning all these disparate services into a workflow is a skill in itself. It's a collective restriction that comes from the systems beneath.

25

28

29+<br>

30+

26−

31+<img class="ba" src="https://media.urbit.org/site/posts/essays/tools-of-our-own-2.png">

27

32

28### Systems as masters

33### Systems as masters

29

34

30> If you don't understand a system you're using, you don't control it. If nobody understands the system, the system is in control.

35> If you don't understand a system you're using, you don't control it. If nobody understands the system, the system is in control.

31>

36>

32−> **Philip Monk, [Precepts](https://urbit.org/blog/precepts/)**

37+> <cite>Philip Monk, <a href="https://urbit.org/blog/precepts/">Precepts</a></cite>

33

38

34If you asked any of the creators of the social tools we use today what their mission was, it would seem neutral, a public good. To "bring the world closer," to "make a more open and connected world," to "easily see what's happening in the world." Ignore the fact that the net effects of their products are far more mixed than their mission suggests: for many users, the tools themselves come second to the power the tools have in capturing their social graph.

39If you asked any of the creators of the social tools we use today what their mission was, it would seem neutral, a public good. To "bring the world closer," to "make a more open and connected world," to "easily see what's happening in the world." Ignore the fact that the net effects of their products are far more mixed than their mission suggests: for many users, the tools themselves come second to the power the tools have in capturing their social graph.

35

40

@@ -45,15 +50,17 @@ But this is crazy: for decades, an aspect of the Internet stack that necessitate

45

50

46And for productivity tools—for the personal activities we do every day—the same problem ultimately applies. Either you wrangle more and more single-use "products" into a framework, wrangling combinatorial explosion, or you punt the problem to the user's brain, remembering the relation between tools.

51And for productivity tools—for the personal activities we do every day—the same problem ultimately applies. Either you wrangle more and more single-use "products" into a framework, wrangling combinatorial explosion, or you punt the problem to the user's brain, remembering the relation between tools.

47

52

48−This is why hybrid products are born _and_ why massive enterprises are shifting toward subscription models for office software. With the [clearnet](<https://en.wikipedia.org/wiki/Clearnet_(networking)>), using our own computers for everyday tasks that extend outside themselves is not easy. It's way easier to sign into an enterprise's server farm for your persistent data storage and manipulation. In 2020, the prefab parts for the exoskeleton only come in "left arm, right leg" pairs, or you can just give up and plug straight into SkyNet.

53+This is why hybrid products are born *and* why massive enterprises are shifting toward subscription models for office software. With the [clearnet](https://en.wikipedia.org/wiki/Clearnet_(networking)), using our own computers for everyday tasks that extend outside themselves is not easy. It's way easier to sign into an enterprise's server farm for your persistent data storage and manipulation. In 2020, the prefab parts for the exoskeleton only come in "left arm, right leg" pairs, or you can just give up and plug straight into SkyNet.

54+

55+<br>

49

56

50−

57+<img class="ba" src="https://media.urbit.org/site/posts/essays/tools-of-our-own-3.png">

51

58

52### The collective body

59### The collective body

53

60

54> “Autonomy” means that we make the **worlds that we are** grow.

61> “Autonomy” means that we make the **worlds that we are** grow.

55>

62>

56−> **Tiqqun, *The Cybernetic Hypothesis*

63+> <cite>Tiqqun, <em>The Cybernetic Hypothesis</em>

57

64

58So why does this matter for us? Me and you and everyone we know? We put up with the cost all the time. But the limitations of our tools—on the vulnerable side of a power dynamic that, unbeknownst to everyone involved, functions as a catalyzed and increasingly accelerated system bringing out the worst in all of us—range from the everyday annoyances to a pervasive alienation, an information malaise.

65So why does this matter for us? Me and you and everyone we know? We put up with the cost all the time. But the limitations of our tools—on the vulnerable side of a power dynamic that, unbeknownst to everyone involved, functions as a catalyzed and increasingly accelerated system bringing out the worst in all of us—range from the everyday annoyances to a pervasive alienation, an information malaise.

59

66

content/blog/toward-a-frozen-operating-system.md+83−89

@@ -1,58 +1,52 @@

1+++

1+++

2title = "Toward a Frozen Operating System"

2title = "Toward a Frozen Operating System"

3−date = "2017-05-09"

3+date = 2017-05-10

4description = "Is it possible to freeze an entire OS?"

4description = "Is it possible to freeze an entire OS?"

5−aliases = [

6− "/posts/essays/toward-a-frozen-operating-system",

5+aliases = ["/posts/essays/toward-a-frozen-operating-system", "/posts/toward-a-frozen-operating-system", "/blog/2017.5-frozen/"]

7− "/posts/toward-a-frozen-operating-system",

8− "/blog/2017.5-frozen/"

9−]

10−

11[extra]

6[extra]

12author = "Curtis Yarvin + Galen Wolfe-Pauly"

7author = "Curtis Yarvin + Galen Wolfe-Pauly"

13ship = "~sorreg-namtyv + ~ravmel-ropdyl"

8ship = "~sorreg-namtyv + ~ravmel-ropdyl"

14+++

9+++

15−

16Is it possible to freeze an entire OS, so that its codebase never changes and

10Is it possible to freeze an entire OS, so that its codebase never changes and

17−never has to change? Is the proposition even meaningful? Is it practical?

11+never has to change? Is the proposition even meaningful? Is it practical?

18And if so, why would we want a frozen OS?

12And if so, why would we want a frozen OS?

19

13

20−Think about it intuitively. There's a reason we call an OS a "platform." It's

14+Think about it intuitively. There's a reason we call an OS a "platform." It's

21−a piece of permanent infrastructure. Paul Graham wrote a

15+a piece of permanent infrastructure. Paul Graham wrote a

22[great essay](http://www.paulgraham.com/hundred.html) about the

16[great essay](http://www.paulgraham.com/hundred.html) about the

23"hundred-year language," but the language is only one part of any complete

17"hundred-year language," but the language is only one part of any complete

24−platform. And in infrastructure terms, a hundred years isn't that long.

18+platform. And in infrastructure terms, a hundred years isn't that long.

25

19

26−Why not think of structures that have lasted _thousands_ of years? An aqueduct,

20+Why not think of structures that have lasted _thousands_ of years? An aqueduct,

27−a pyramid, a Parthenon? Why set our sights lower? Why isn't it time to aim for

21+a pyramid, a Parthenon? Why set our sights lower? Why isn't it time to aim for

28−perfect and timeless code? If not now, when?

22+perfect and timeless code? If not now, when?

29

23

30## Scope of the problem

24## Scope of the problem

31

25

32−More prosaically, a frozen OS just means your OS never changes. A frozen OS

26+More prosaically, a frozen OS just means your OS never changes. A frozen OS

33−never gets any updates. Not because it can't update itself, just because it

27+never gets any updates. Not because it can't update itself, just because it

34doesn't need to.

28doesn't need to.

35

29

36−Is this even a meaningful concept? A frozen OS? First we'll have to decide

30+Is this even a meaningful concept? A frozen OS? First we'll have to decide

37−what "OS" even means. Certainly, if "OS" means "the code that your hardware

31+what "OS" even means. Certainly, if "OS" means "the code that your hardware

38boots into," hardware always changes and so will the OS.

32boots into," hardware always changes and so will the OS.

39

33

40A broader, more useful definition: the "OS" is _an opaque model of a persistent

34A broader, more useful definition: the "OS" is _an opaque model of a persistent

41−general-purpose computer_. This definition allows for arbitrary levels of

35+general-purpose computer_. This definition allows for arbitrary levels of

42−virtualization. Linux on a droplet is an OS. A browser is an OS, because it's

36+virtualization. Linux on a droplet is an OS. A browser is an OS, because it's

43−persistent (sorta) and opaque. But `node.js` is not an OS, because it's not

37+persistent (sorta) and opaque. But `node.js` is not an OS, because it's not

44opaque: it exports Linux system calls.

38opaque: it exports Linux system calls.

45

39

46Within this opaque model, we have to decide what's "system" and "user" software.

40Within this opaque model, we have to decide what's "system" and "user" software.

47−It clearly makes no sense to freeze userspace. Let's use the

41+It clearly makes no sense to freeze userspace. Let's use the

48[trusted codebase](https://en.wikipedia.org/wiki/Trusted_computing_base): code

42[trusted codebase](https://en.wikipedia.org/wiki/Trusted_computing_base): code

49is system software, if compromising it would compromise the whole system.

43is system software, if compromising it would compromise the whole system.

50

44

51## Infinite maturity

45## Infinite maturity

52

46

53It's important to remember that just because a system is designed to achieve

47It's important to remember that just because a system is designed to achieve

54−frozenness, doesn't mean it's useless until it's frozen. It doesn't even mean

48+frozenness, doesn't mean it's useless until it's frozen. It doesn't even mean

55−it's immature. It just means that in the very long term, the system's maturity

49+it's immature. It just means that in the very long term, the system's maturity

56goals are infinite.

50goals are infinite.

57

51

58Systems designed to diverge infinitely (with normal X.X.X semantic versioning),

52Systems designed to diverge infinitely (with normal X.X.X semantic versioning),

@@ -60,30 +54,30 @@ even those designed to converge infinitely (as with

60[Knuth versioning](http://www.tex.ac.uk/FAQ-TeXfuture.html)), also achieve

54[Knuth versioning](http://www.tex.ac.uk/FAQ-TeXfuture.html)), also achieve

61maturity, often great maturity, without being quite frozen.

55maturity, often great maturity, without being quite frozen.

62

56

63−For example, C is a very mature language. C has long since mastered backward

57+For example, C is a very mature language. C has long since mastered backward

64−compatibility. We can be sure that any C program which compiles on today's

58+compatibility. We can be sure that any C program which compiles on today's

65correct C compilers will compile on any future correct C compiler.

59correct C compilers will compile on any future correct C compiler.

66

60

67But, since C is not frozen, we can't be sure that today's C compilers will

61But, since C is not frozen, we can't be sure that today's C compilers will

68−compile any future C program. So C has not yet achieved perfect _forward_

62+compile any future C program. So C has not yet achieved perfect _forward_

69−compatibility. By definition, a frozen system is compatible both forward and

63+compatibility. By definition, a frozen system is compatible both forward and

70−backward. So C is mature, but it could still get more mature.

64+backward. So C is mature, but it could still get more mature.

71

65

72−The point of a frozen OS is to shoot for _infinite_ maturity. Obviously a

66+The point of a frozen OS is to shoot for _infinite_ maturity. Obviously a

73frozen platform is compatible forever in both directions.

67frozen platform is compatible forever in both directions.

74

68

75−Infinite maturity does exist in the real world. But only in a few simple file

69+Infinite maturity does exist in the real world. But only in a few simple file

76−formats and protocols — IP, JSON, XML. And not all this maturity is the result

70+formats and protocols — IP, JSON, XML. And not all this maturity is the result

77−of perfection. Some is just the accident of a missing update mechanism.

71+of perfection. Some is just the accident of a missing update mechanism.

78

72

79But IP, JSON, XML... this is how stable, how taken for granted, system software

73But IP, JSON, XML... this is how stable, how taken for granted, system software

80−should be. And can be. Certainly, any JSON parser today will parse any JSON

74+should be. And can be. Certainly, any JSON parser today will parse any JSON

81document made in the future.

75document made in the future.

82

76

83The dream of absolute zero is an OS whose core components are so simple, so

77The dream of absolute zero is an OS whose core components are so simple, so

84boring, and so mechanically straightforward that we can imagine them becoming

78boring, and so mechanically straightforward that we can imagine them becoming

85−finished and never changing. We need to freeze not just a format or a protocol,

79+finished and never changing. We need to freeze not just a format or a protocol,

86−but a language, a kernel, a standard library. To succeed, we need to flush out

80+but a language, a kernel, a standard library. To succeed, we need to flush out

87each quirk, complexity, and creeping feature, until the system is so boring and

81each quirk, complexity, and creeping feature, until the system is so boring and

88obvious that no one even wants to change it.

82obvious that no one even wants to change it.

89

83

@@ -91,19 +85,19 @@ obvious that no one even wants to change it.

91

85

92"Kelvin versioning" is one way to track a project designed to be frozen.

86"Kelvin versioning" is one way to track a project designed to be frozen.

93

87

94−In Kelvin versioning, a version is an integer in degrees Kelvin. Absolute zero

88+In Kelvin versioning, a version is an integer in degrees Kelvin. Absolute zero

95−is frozen — no further updates are possible. If your Kelvin versions don't

89+is frozen — no further updates are possible. If your Kelvin versions don't

96−track your actual progress, you run out of integers. This danger is a concrete

90+track your actual progress, you run out of integers. This danger is a concrete

97incentive for the project to track its own progress accurately.

91incentive for the project to track its own progress accurately.

98

92

99−(Kelvin versioning isn't useful only at lifecycle scale. It can be used for any

93+(Kelvin versioning isn't useful only at lifecycle scale. It can be used for any

100development process with an irreversible end — as build numbers for a release,

94development process with an irreversible end — as build numbers for a release,

101for example.)

95for example.)

102

96

103## The palm-tree dependency model

97## The palm-tree dependency model

104

98

105−A whole OS can't have a single Kelvin number. It has to consist of multiple

99+A whole OS can't have a single Kelvin number. It has to consist of multiple

106−components which depend on each other. What's the right dependency model for

100+components which depend on each other. What's the right dependency model for

107the parts of a frozen OS?

101the parts of a frozen OS?

108

102

109One way to think about dependencies across a whole OS is the "palm-tree model."

103One way to think about dependencies across a whole OS is the "palm-tree model."

@@ -112,11 +106,11 @@ components (where we have to choose one version of the code), and "inclusive"

112ones (where different users can see different versions).

106ones (where different users can see different versions).

113

107

114The exclusive components are the trunk of the palm tree: a stack of layers, each

108The exclusive components are the trunk of the palm tree: a stack of layers, each

115−of which has one active copy. For instance, you are only running one kernel at

109+of which has one active copy. For instance, you are only running one kernel at

116−a time. Different apps cannot use different versions of the kernel.

110+a time. Different apps cannot use different versions of the kernel.

117

111

118The inclusive components are the fronds, branching out in any direction they

112The inclusive components are the fronds, branching out in any direction they

119−want. Not only can two apps use different versions of the same library, in

113+want. Not only can two apps use different versions of the same library, in

120many situations _one_ app needs to be able to use two different versions of the

114many situations _one_ app needs to be able to use two different versions of the

121same library.

115same library.

122

116

@@ -124,28 +118,28 @@ same library.

124

118

125Any subsystem that serves as any kind of platform is exclusive, since anything

119Any subsystem that serves as any kind of platform is exclusive, since anything

126that runs on top of the platform has to choose one version of the platform to

120that runs on top of the platform has to choose one version of the platform to

127−run on. Since layers are good, this creates a natural stack which can get quite

121+run on. Since layers are good, this creates a natural stack which can get quite

128tall — and include components which are technically in userspace.

122tall — and include components which are technically in userspace.

129

123

130The right way for this trunk to approach absolute zero is to "telescope" its

124The right way for this trunk to approach absolute zero is to "telescope" its

131−Kelvin versions. The rules of telescoping are simple:

125+Kelvin versions. The rules of telescoping are simple:

132

126

1331. If tool B sits on platform A, either both A and B must be at absolute zero,

1271. If tool B sits on platform A, either both A and B must be at absolute zero,

134− or B must be warmer than A.

128+or B must be warmer than A.

135

129

1362. Whenever the temperature of A (the platform) declines, the temperature of B

1302. Whenever the temperature of A (the platform) declines, the temperature of B

137− (the tool) must also decline.

131+(the tool) must also decline.

138

132

139−3. B must state the version of A it was developed against. A, when loading B,

133+3. B must state the version of A it was developed against. A, when loading B,

140− must state its own current version, and the warmest version of itself with which

134+must state its own current version, and the warmest version of itself with which

141− it's backward-compatible.

135+it's backward-compatible.

142

136

143Of course, if B itself is a platform on which some higher-level tool C depends,

137Of course, if B itself is a platform on which some higher-level tool C depends,

144it must follow the same constraints recursively.

138it must follow the same constraints recursively.

145

139

146The important effect of obeying rule 2: in a tall trunk, it's sufficient to

140The important effect of obeying rule 2: in a tall trunk, it's sufficient to

147−state your dependency on the platform directly below you. Suppose C sits on B,

141+state your dependency on the platform directly below you. Suppose C sits on B,

148−which sits on A and exports features of A. C can state only the version of B

142+which sits on A and exports features of A. C can state only the version of B

149it's written against, because when A chills, B must also chill.

143it's written against, because when A chills, B must also chill.

150

144

151If A could chill without B chilling, we could modify C to use new features of A.

145If A could chill without B chilling, we could modify C to use new features of A.

@@ -154,73 +148,73 @@ received the A update.

154

148

155## The palm fronds: total flexibility

149## The palm fronds: total flexibility

156

150

157−The goal of the trunk is to get to the fronds. In the fronds, no one should

151+The goal of the trunk is to get to the fronds. In the fronds, no one should

158−ever worry about dependency conflicts. And nothing is ever frozen, or has to be

152+ever worry about dependency conflicts. And nothing is ever frozen, or has to be

159frozen.

153frozen.

160

154

161The right way to solve dependencies in userspace is: within an organization, use

155The right way to solve dependencies in userspace is: within an organization, use

162−a monorepo and link relative to its head. Between organizations, use pinned

156+a monorepo and link relative to its head. Between organizations, use pinned

163−version numbers that are as immutable as possible. Avoid programming

157+version numbers that are as immutable as possible. Avoid programming

164environments that create exclusion problems in userspace — for instance, that

158environments that create exclusion problems in userspace — for instance, that

165compel a single process to choose one version of a library when a diamond

159compel a single process to choose one version of a library when a diamond

166dependency exists.

160dependency exists.

167

161

168There is almost never any good reason to automatically update dependencies with

162There is almost never any good reason to automatically update dependencies with

169−fresh versions of foreign code. In the case of a security update, the

163+fresh versions of foreign code. In the case of a security update, the

170maintainer of an app which depends on a patched library needs to catch the

164maintainer of an app which depends on a patched library needs to catch the

171−patch and propagate the update in a new version of the app. An app shouldn't be

165+patch and propagate the update in a new version of the app. An app shouldn't be

172security-critical to begin with, and propagating updates is a basic function of

166security-critical to begin with, and propagating updates is a basic function of

173−a modern OS. Also, if the app is security-critical, it could have its own bugs,

167+a modern OS. Also, if the app is security-critical, it could have its own bugs,

174so it needs a maintainer and an update pathway anyway.

168so it needs a maintainer and an update pathway anyway.

175

169

176## Urbit: status and prospects

170## Urbit: status and prospects

177

171

178−Yes, we do believe it's possible to write a freezable OS. In fact, we wrote

172+Yes, we do believe it's possible to write a freezable OS. In fact, we wrote

179−one. And it works. It's not yet frozen (except at the bottom layer), but it's

173+one. And it works. It's not yet frozen (except at the bottom layer), but it's

180getting there.

174getting there.

181

175

182−Urbit, a clean-slate functional OS, has been under development since 2002. It

176+Urbit, a clean-slate functional OS, has been under development since 2002. It

183took a decade (as a one-man project) just to build a prototype of a freezable OS.

177took a decade (as a one-man project) just to build a prototype of a freezable OS.

184The result in 2017 (now with a small company) is a telescoping Kelvin stack of

178The result in 2017 (now with a small company) is a telescoping Kelvin stack of

185layers from VM to UI.

179layers from VM to UI.

186

180

187At the bottom (the VM Nock), this stack is slightly warmer than liquid helium

181At the bottom (the VM Nock), this stack is slightly warmer than liquid helium

188−(5K). It's easy for Nock to get this cold, because it's defined in a page of

182+(5K). It's easy for Nock to get this cold, because it's defined in a page of

189−axioms that gzips to 340 bytes. We are in no hurry to declare zero, but any

183+axioms that gzips to 340 bytes. We are in no hurry to declare zero, but any

190change at this point would be both very unlikely and very difficult to

184change at this point would be both very unlikely and very difficult to

191implement.

185implement.

192

186

193Urbit's typed functional language, Hoon, which compiles itself to Nock, is

187Urbit's typed functional language, Hoon, which compiles itself to Nock, is

194−closing in on liquid krypton at 143K. Hoon is defined in about 5,000 lines of

188+closing in on liquid krypton at 143K. Hoon is defined in about 5,000 lines of

195−Hoon, or 10,000 if you count the deep standard library. Nock will never need to

189+Hoon, or 10,000 if you count the deep standard library. Nock will never need to

196change; Hoon is perfectly serviceable but has some well-known rough spots.

190change; Hoon is perfectly serviceable but has some well-known rough spots.

197

191

198−Above Hoon, the stack rapidly gets much warmer. Arvo is an event-driven

192+Above Hoon, the stack rapidly gets much warmer. Arvo is an event-driven

199−microkernel that's 1,000 lines of Hoon. Above this are another 5,000 lines of

193+microkernel that's 1,000 lines of Hoon. Above this are another 5,000 lines of

200system library, then 12,000 lines of Arvo modules: a peer-to-peer network, a

194system library, then 12,000 lines of Arvo modules: a peer-to-peer network, a

201PKI and private ledger, a revision-control system, an HTTP gateway, a functional

195PKI and private ledger, a revision-control system, an HTTP gateway, a functional

202−build system, and an application sandbox. A trivial working system needs

196+build system, and an application sandbox. A trivial working system needs

203another 5,000 lines for basic chat and shell apps.

197another 5,000 lines for basic chat and shell apps.

204

198

205We haven't had meaningful Kelvin numbers for the Arvo layer, but this release

199We haven't had meaningful Kelvin numbers for the Arvo layer, but this release

206−will change that. About a third of Arvo has been or will be rewritten in the

200+will change that. About a third of Arvo has been or will be rewritten in the

207last year; we'll assign Kelvins once this code (which now compiles) is tested

201last year; we'll assign Kelvins once this code (which now compiles) is tested

208into existence, largely based on how close the last compiling draft was to the

202into existence, largely based on how close the last compiling draft was to the

209−first working draft. But you'll certainly be able to cook eggs on it.

203+first working draft. But you'll certainly be able to cook eggs on it.

210

204

211−(Once again, not being frozen doesn't mean not working. Until all these layers

205+(Once again, not being frozen doesn't mean not working. Until all these layers

212−are finished, we'll be updating them over the air. To be exact, Urbit

206+are finished, we'll be updating them over the air. To be exact, Urbit

213distributes its own updates through subscriptions in its own revision-control

207distributes its own updates through subscriptions in its own revision-control

214system.)

208system.)

215

209

216The actual status of Urbit is that in 2017, we hope to make our last

210The actual status of Urbit is that in 2017, we hope to make our last

217discontinuous update — meaning that instead of your Urbit node updating itself

211discontinuous update — meaning that instead of your Urbit node updating itself

218−silently, you destroy and recreate it. Urbit works today, but it isn't really

212+silently, you destroy and recreate it. Urbit works today, but it isn't really

219alive until today's Urbit data lives forever.

213alive until today's Urbit data lives forever.

220

214

221Even committing to continuity is a significant step toward the frozen OS,

215Even committing to continuity is a significant step toward the frozen OS,

222because we're committing to never making another change that the present

216because we're committing to never making another change that the present

223−platform can't install. Fortunately, the only layer that has to stay frozen for

217+platform can't install. Fortunately, the only layer that has to stay frozen for

224this is Nock.

218this is Nock.

225

219

226## The style of convergent system software

220## The style of convergent system software

@@ -229,22 +223,22 @@ We're obviously in no position to declare victory at any layer above Nock, but

229aiming at absolute zero creates a system design style we think works very well —

223aiming at absolute zero creates a system design style we think works very well —

230even if we never get to zero.

224even if we never get to zero.

231

225

232−Deep, onion-like layering is essential. A thin layer has no room to grow. A

226+Deep, onion-like layering is essential. A thin layer has no room to grow. A

233good example of this principle is the difference between Urbit and Lisp

227good example of this principle is the difference between Urbit and Lisp

234−machines. Both Nock and Lisp are very simple axiomatic definitions of

228+machines. Both Nock and Lisp are very simple axiomatic definitions of

235−computing. But practical Lisp systems expand by extending the model, whereas

229+computing. But practical Lisp systems expand by extending the model, whereas

236Urbit layers over a frozen axiom system.

230Urbit layers over a frozen axiom system.

237

231

238−Software that expands by extension is inevitable. But we need to be able to

232+Software that expands by extension is inevitable. But we need to be able to

239−kick it up to userspace. System software should be concerned with the

233+kick it up to userspace. System software should be concerned with the

240−fundamental problems of computing, which don't change. The few cases in which

234+fundamental problems of computing, which don't change. The few cases in which

241they do change — like crypto algorithms — are special cases, easily

235they do change — like crypto algorithms — are special cases, easily

242−encapsulated. And even these changes can be expected to slow down in the long

236+encapsulated. And even these changes can be expected to slow down in the long

243term.

237term.

244

238

245Perhaps the best example of the convergent style in existing, mature system

239Perhaps the best example of the convergent style in existing, mature system

246−software is the relational database. The genius of the relational model is that

240+software is the relational database. The genius of the relational model is that

247−it's designed to never grow hair. Even SQL, with its COBOL-era syntax, is

241+it's designed to never grow hair. Even SQL, with its COBOL-era syntax, is

248essentially invulnerable to any significant non-cosmetic improvement.

242essentially invulnerable to any significant non-cosmetic improvement.

249

243

250The lesson: when we see a system that seems to want to expand indefinitely, we

244The lesson: when we see a system that seems to want to expand indefinitely, we

@@ -254,7 +248,7 @@ Layering is what distinguishes true system software from the giant balls of mud

254that all deep codebases want to become.

248that all deep codebases want to become.

255

249

256Are all balls of mud, or at least all the muddy parts of an OS, susceptible to

250Are all balls of mud, or at least all the muddy parts of an OS, susceptible to

257−this transformation? We think so. But we'll see.

251+this transformation? We think so. But we'll see.

258

252

259−As usual, comments are on fora. Check out

253+As usual, comments are on fora. Check out

260[this thread](https://urbit.org/fora/posts/~2017.5.12..20.30.11..0050~/).

254[this thread](https://urbit.org/fora/posts/~2017.5.12..20.30.11..0050~/).

content/blog/toward-a-new-clay.md+227−233

@@ -1,68 +1,63 @@

1+++

1+++

2title = "Toward a New %clay"

2title = "Toward a New %clay"

3−date = "2016-07-13"

3+date = 2016-07-14

4description = "Urbit's revision-control system, %clay, is itself due for a (medium-sized) revision!"

4description = "Urbit's revision-control system, %clay, is itself due for a (medium-sized) revision!"

5−aliases = [

6− "/posts/essays/toward-a-new-clay",

5+aliases = ["/posts/essays/toward-a-new-clay", "/posts/toward-a-new-clay", "/blog/clay"]

7− "/posts/toward-a-new-clay",

8− "/blog/clay"

9−]

10−

11[extra]

6[extra]

12author = "Curtis Yarvin"

7author = "Curtis Yarvin"

13ship = "~sorreg-namtyv"

8ship = "~sorreg-namtyv"

14+++

9+++

15

10

16TLDR: (a) Urbit's revision-control system, `%clay`, is itself due

11TLDR: (a) Urbit's revision-control system, `%clay`, is itself due

17−for a (medium-sized) revision! (b) this time, you yourself can

12+for a (medium-sized) revision! (b) this time, you yourself can

18−really help! (c) please don't give away the buried spoiler!

13+really help! (c) please don't give away the buried spoiler!

19

14

20This explanation does not (or at least should not) require you to

15This explanation does not (or at least should not) require you to

21know anything about Urbit.

16know anything about Urbit.

22

17

23### But %clay is already pretty cool

18### But %clay is already pretty cool

24

19

25−Of course, nothing in Urbit is allowed to be _lame_. `%clay` is

20+Of course, nothing in Urbit is allowed to be _lame_. `%clay` is

26−actually quite cool. It does need some work. But first, let's

21+actually quite cool. It does need some work. But first, let's

27talk about what it is and why it's cool.

22talk about what it is and why it's cool.

28

23

29`%clay` is the Arvo vane (Urbit kernel module) for revision

24`%clay` is the Arvo vane (Urbit kernel module) for revision

30−control. It's an authenticated, human-memorable global immutable

25+control. It's an authenticated, human-memorable global immutable

31−namespace which is also a typed revision-control system. It's

26+namespace which is also a typed revision-control system. It's

32−also very good at subscription and synchronization. Urbit

27+also very good at subscription and synchronization. Urbit

33currently uses `%clay` to distribute live hotpatches; we

28currently uses `%clay` to distribute live hotpatches; we

34transparently upgrade the whole network with one checkin.

29transparently upgrade the whole network with one checkin.

35

30

36### Compared to other revision-control systems

31### Compared to other revision-control systems

37

32

38−`%clay` is clearly a vanilla DVCS in the modern `git` style. Of

33+`%clay` is clearly a vanilla DVCS in the modern `git` style. Of

39deployed DVCS these days, `%clay` is probably closest in spirit

34deployed DVCS these days, `%clay` is probably closest in spirit

40to `bzr` or maybe `fossil`.

35to `bzr` or maybe `fossil`.

41

36

42Obviously, as a part of a larger whole, you would expect any

37Obviously, as a part of a larger whole, you would expect any

43−Urbit RCS to be brutally spartan. `%clay` is. It's even more

38+Urbit RCS to be brutally spartan. `%clay` is. It's even more

44spartan than `bzr`.

39spartan than `bzr`.

45

40

46−(In fact, it's really too spartan to fully use at the moment. We

41+(In fact, it's really too spartan to fully use at the moment. We

47ourselves still use `%clay` mainly as a distribution system, and

42ourselves still use `%clay` mainly as a distribution system, and

48−do all internal development on GitHub. This is because the

43+do all internal development on GitHub. This is because the

49present `%clay` lacks a few little conveniences, like commit

44present `%clay` lacks a few little conveniences, like commit

50−messages. See upgrades, below.)

45+messages. See upgrades, below.)

51

46

52−There are lots of normal DVCS things in `%clay`. But there are

47+There are lots of normal DVCS things in `%clay`. But there are

53−also cool and unusual ones. Let's take a brief tour of the

48+also cool and unusual ones. Let's take a brief tour of the

54high-level system, then describe what we think should change

49high-level system, then describe what we think should change

55about it.

50about it.

56

51

57### Anatomy of a DVCS

52### Anatomy of a DVCS

58

53

59−A DVCS is a historical state graph. A point in this graph is a

54+A DVCS is a historical state graph. A point in this graph is a

60snapshot of some tree-structured system, like a filesystem.

55snapshot of some tree-structured system, like a filesystem.

61

56

62These snapshots, including recursive internal nodes, are stored in

57These snapshots, including recursive internal nodes, are stored in

63−a content-addressable store. Pointers in this store are used to

58+a content-addressable store. Pointers in this store are used to

64construct a revision graph, whose edges are edit and/or merge

59construct a revision graph, whose edges are edit and/or merge

65−actions. Some sort of namespace attaches meaningful names to

60+actions. Some sort of namespace attaches meaningful names to

66current revisions in this graph.

61current revisions in this graph.

67

62

68There are six big questions in the design of a DVCS:

63There are six big questions in the design of a DVCS:

@@ -78,16 +73,16 @@ There are six big questions in the design of a DVCS:

78

73

79A good way to summarize `%clay` (at present) is that its answers

74A good way to summarize `%clay` (at present) is that its answers

80to the first four questions are interesting, and its answers to

75to the first four questions are interesting, and its answers to

81−the last two are boring. We'll talk about all six, though.

76+the last two are boring. We'll talk about all six, though.

82

77

83### Global namespace: [ship desk case]

78### Global namespace: [ship desk case]

84

79

85−The permanent global name of a `%clay` snapshot is a `++beak`. A beak

80+The permanent global name of a `%clay` snapshot is a `++beak`. A beak

86is a triple: `[ship desk case]`.

81is a triple: `[ship desk case]`.

87

82

88−The `++ship` is an Urbit ship. A ship is a network address, a

83+The `++ship` is an Urbit ship. A ship is a network address, a

89−human-memorable name and a cryptographic identity. The address

84+human-memorable name and a cryptographic identity. The address

90−width is variable; shorter addresses are more desirable. Most

85+width is variable; shorter addresses are more desirable. Most

91users have 32-bit addresses, which we map to four-syllable

86users have 32-bit addresses, which we map to four-syllable

92synthetic names like `~sorreg-namtyv`.

87synthetic names like `~sorreg-namtyv`.

93

88

@@ -100,44 +95,44 @@ In the Urbit path syntax, the beak is the first three segments of

100the path: `/ship/desk/case/my/cat/picture`.

95the path: `/ship/desk/case/my/cat/picture`.

101

96

102In most cases, a path parser has a default ship, desk and case,

97In most cases, a path parser has a default ship, desk and case,

103−each of which can be replaced by `=`. So `/=home=/my/cat/picture`

98+each of which can be replaced by `=`. So `/=home=/my/cat/picture`

104is the data at `/my/cat/picture` on your own ship, in the `%home`

99is the data at `/my/cat/picture` on your own ship, in the `%home`

105−desk, right now. Immutability doesn't have to be inconvenient.

100+desk, right now. Immutability doesn't have to be inconvenient.

106

101

107−`%clay` has no concept of a mutable name or a magic `HEAD`. Use

102+`%clay` has no concept of a mutable name or a magic `HEAD`. Use

108−the current date. If you're referring to remote data and you're

103+the current date. If you're referring to remote data and you're

109worried about clock skew, subtract a second or three, or be

104worried about clock skew, subtract a second or three, or be

110−prepared to block. (Or keep your clock unskewed, which shouldn't

105+prepared to block. (Or keep your clock unskewed, which shouldn't

111−be _that_ hard.) It's not like mutable-name schemes work any

106+be _that_ hard.) It's not like mutable-name schemes work any

112better than this anyway.

107better than this anyway.

113

108

114−(Immutability is central to `%clay`. `git` merely adopted the

109+(Immutability is central to `%clay`. `git` merely adopted the

115−reflog. `%clay` was born in it, molded by it...)

110+reflog. `%clay` was born in it, molded by it...)

116

111

117`%clay` is objective; each Urbit node hosts only one ship, but

112`%clay` is objective; each Urbit node hosts only one ship, but

118−treats domestic and foreign data (almost) the same way. If you

113+treats domestic and foreign data (almost) the same way. If you

119ask your `%clay` repository for someone else's data, it will

114ask your `%clay` repository for someone else's data, it will

120block the request until it gets the data, which it then caches.

115block the request until it gets the data, which it then caches.

121At present, we always fulfill requests from the origin ship,

116At present, we always fulfill requests from the origin ship,

122though in future we could certainly use it as a tracker.

117though in future we could certainly use it as a tracker.

123

118

124If `%clay` discards cached data, it keeps a hash, so that your

119If `%clay` discards cached data, it keeps a hash, so that your

125−urbit can't violate the local illusion of immutability. We

120+urbit can't violate the local illusion of immutability. We

126can't, of course, prevent anyone else's ship from sending

121can't, of course, prevent anyone else's ship from sending

127−conflicting claims in different directions. But we can prevent

122+conflicting claims in different directions. But we can prevent

128programs on our own ship from hearing about them, meaning that we

123programs on our own ship from hearing about them, meaning that we

129retain local referential transparency.

124retain local referential transparency.

130

125

131### Local structure: dome, arch, leaf and mark

126### Local structure: dome, arch, leaf and mark

132

127

133−A `%clay` snapshot is called a `++dome`. A dome is the `%clay`

128+A `%clay` snapshot is called a `++dome`. A dome is the `%clay`

134equivalent of a tree-structured filesystem.

129equivalent of a tree-structured filesystem.

135

130

136Each node in this tree is one uniform structure, an `++arch`,

131Each node in this tree is one uniform structure, an `++arch`,

137−which is both file and directory. A `++leaf` or data value in

132+which is both file and directory. A `++leaf` or data value in

138this arch is a typed document.

133this arch is a typed document.

139

134

140−A logical document type is called a `++mark`. A mark is a

135+A logical document type is called a `++mark`. A mark is a

141symbolic pointer to a Hoon source file, in the same dome, for an

136symbolic pointer to a Hoon source file, in the same dome, for an

142engine that can validate, compare, and/or convert

137engine that can validate, compare, and/or convert

143documents of that mark.

138documents of that mark.

@@ -146,8 +141,8 @@ Let's go over arches and marks a little more closely...

146

141

147#### An arch is a uniform filesystem node

142#### An arch is a uniform filesystem node

148

143

149−Most filesystems and RCS have modal nodes. For instance, a git

144+Most filesystems and RCS have modal nodes. For instance, a git

150−data node can be a blob or a tree. `%clay` (and the Urbit

145+data node can be a blob or a tree. `%clay` (and the Urbit

151namespace in general) has one kind of node, an `arch`:

146namespace in general) has one kind of node, an `arch`:

152

147

153```

148```

@@ -156,24 +151,24 @@ namespace in general) has one kind of node, an `arch`:

156```

151```

157

152

158An arch has an optional typed-data leaf, and optional named

153An arch has an optional typed-data leaf, and optional named

159−children. In Unix terms, it's a file, a directory, or both. It

154+children. In Unix terms, it's a file, a directory, or both. It

160can't be neither: an empty arch, with no data and no children, is

155can't be neither: an empty arch, with no data and no children, is

161−auto-pruned. As in `git` (but not in Unix), the hierarchy is a

156+auto-pruned. As in `git` (but not in Unix), the hierarchy is a

162−pure function of its leaves. Paths exist only because of the

157+pure function of its leaves. Paths exist only because of the

163data they point to.

158data they point to.

164

159

165The `++knot` names in an arch path are also a little special.

160The `++knot` names in an arch path are also a little special.

166They're typed, in a sense; any knot can be parsed invertibly into

161They're typed, in a sense; any knot can be parsed invertibly into

167−a typed atom. The atom is an arbitrary unsigned integer. Its

162+a typed atom. The atom is an arbitrary unsigned integer. Its

168type (an `++aura` if you know Hoon) defines the semantics and

163type (an `++aura` if you know Hoon) defines the semantics and

169presentation of the atom: for instance, a symbol, a decimal,

164presentation of the atom: for instance, a symbol, a decimal,

170a date, etc.

165a date, etc.

171

166

172Ultimately a filesystem is a database, and a path is a primary

167Ultimately a filesystem is a database, and a path is a primary

173−key. It's very useful to be able to store simple data in this

168+key. It's very useful to be able to store simple data in this

174key, in a standard and unambiguous way.

169key, in a standard and unambiguous way.

175

170

176−Why uniform nodes? One, they map nicely to information trees

171+Why uniform nodes? One, they map nicely to information trees

177where a subtree may need some custom collective presentation,

172where a subtree may need some custom collective presentation,

178not an automatically generated Apache style directory listing.

173not an automatically generated Apache style directory listing.

179Two, non-uniform nodes introduce a whole pointless category of

174Two, non-uniform nodes introduce a whole pointless category of

@@ -181,34 +176,34 @@ node type conflicts -- for which life is far too short.

181

176

182#### A mark is an executable document type

177#### A mark is an executable document type

183

178

184−A mark is "like an executable MIME type." It's best defined as a

179+A mark is "like an executable MIME type." It's best defined as a

185symbolic mapping from a filesystem to a schema engine.

180symbolic mapping from a filesystem to a schema engine.

186

181

187If you have a MIME type `text/html`, you need to watch the

182If you have a MIME type `text/html`, you need to watch the

188−Internets to track what the W3C thinks HTML is. If you have an

183+Internets to track what the W3C thinks HTML is. If you have an

189Urbit mark `%html`, you can functionally construct (using our

184Urbit mark `%html`, you can functionally construct (using our

190insanely powerful functional build vane `%ford`) a core which

185insanely powerful functional build vane `%ford`) a core which

191can validate or normalize HTML, apply patch and diff logic, and

186can validate or normalize HTML, apply patch and diff logic, and

192−translate to and from other marks. `%ford` can even reason about

187+translate to and from other marks. `%ford` can even reason about

193translation paths and construct multistep conversions.

188translation paths and construct multistep conversions.

194

189

195(Urbit does not actually have this super-smart `%html` mark right

190(Urbit does not actually have this super-smart `%html` mark right

196−now. But it probably should, huh. And this page was composed in

191+now. But it probably should, huh. And this page was composed in

197Markdown and translated to HTML by `%ford`.)

192Markdown and translated to HTML by `%ford`.)

198

193

199−Where does the source code of a mark live? Within the same dome

194+Where does the source code of a mark live? Within the same dome

200−as the data it describes. `%html` files are described by the

195+as the data it describes. `%html` files are described by the

201Hoon source at `/===/mar/html`, which perhaps gets mapped into

196Hoon source at `/===/mar/html`, which perhaps gets mapped into

202your Unix filesystem at `$ship/home/mar/html.hoon`.

197your Unix filesystem at `$ship/home/mar/html.hoon`.

203

198

204−This Hoon file is not self-contained. It has dependencies. The

199+This Hoon file is not self-contained. It has dependencies. The

205`%html` mark may depend on various structures and libraries

200`%html` mark may depend on various structures and libraries

206−elsewhere in Urbit. But the source code for all them is within

201+elsewhere in Urbit. But the source code for all them is within

207this dome.

202this dome.

208

203

209One constraint this puts on domes is that _all domes are

204One constraint this puts on domes is that _all domes are

210−descendants of the base system dome_. Domes are versions of one

205+descendants of the base system dome_. Domes are versions of one

211−reality, not fragments of that reality. You can't create a new

206+reality, not fragments of that reality. You can't create a new

212empty dome -- you'd have no mark source, and be unable to install

207empty dome -- you'd have no mark source, and be unable to install

213any validated files.

208any validated files.

214

209

@@ -219,13 +214,13 @@ weird collisions between non-parallel things don't happen.

219

214

220### Unix mapping and mounting

215### Unix mapping and mounting

221

216

222−Every DVCS is its own filesystem in a sense. But every DVCS

217+Every DVCS is its own filesystem in a sense. But every DVCS

223works by mapping and mounting itself, in some sense, to Unix.

218works by mapping and mounting itself, in some sense, to Unix.

224

219

225#### Mapping arches to Unix

220#### Mapping arches to Unix

226

221

227−How do we map arches into Unix? The arch structure maps 1:1 to

222+How do we map arches into Unix? The arch structure maps 1:1 to

228−the Unix directory tree. When the arch has a leaf, we derive a

223+the Unix directory tree. When the arch has a leaf, we derive a

229dot extension from the file's mark.

224dot extension from the file's mark.

230

225

231So, supposing we have a leaf `foo` which is an HTML document

226So, supposing we have a leaf `foo` which is an HTML document

@@ -239,19 +234,19 @@ foo/moo.html

239```

234```

240

235

241This maps invertibly back into `%clay`, and it looks perfectly

236This maps invertibly back into `%clay`, and it looks perfectly

242−unremarkable from the Unix side. File completion sometimes gets

237+unremarkable from the Unix side. File completion sometimes gets

243a little annoying.

238a little annoying.

244

239

245It would be if nice every possible Unix tree, even every

240It would be if nice every possible Unix tree, even every

246plausible Unix tree, mapped cleanly and completely to a `%clay`

241plausible Unix tree, mapped cleanly and completely to a `%clay`

247−dome. There are always horrid exceptions, even in common use --

242+dome. There are always horrid exceptions, even in common use --

248−like extensionless Makefiles. The trivial solution is that if

243+like extensionless Makefiles. The trivial solution is that if

249`%clay` finds a file mysterious, it won't track it.

244`%clay` finds a file mysterious, it won't track it.

250

245

251One often unquestioned assumption in new system software is that

246One often unquestioned assumption in new system software is that

252−compatibility with old content is important. It's nice, but not

247+compatibility with old content is important. It's nice, but not

253−that important. Most content in a new system is new content.

248+that important. Most content in a new system is new content.

254−The important compatibility direction is export, not import. So

249+The important compatibility direction is export, not import. So

255the new system should subset, not superset, the ancient formats.

250the new system should subset, not superset, the ancient formats.

256

251

257### Mounting desks to Unix

252### Mounting desks to Unix

@@ -262,36 +257,36 @@ the Unix directory of the same name within the pier.

262When files in a mount directory change, `%clay` notices it

257When files in a mount directory change, `%clay` notices it

263through `libuv` filesystem watching (ultimately `inotify()` or

258through `libuv` filesystem watching (ultimately `inotify()` or

264`FSEvents`), computes diffs, and automatically commits them to

259`FSEvents`), computes diffs, and automatically commits them to

265−the desk. And if `%clay` creates a new version for its own

260+the desk. And if `%clay` creates a new version for its own

266urbity reasons, it will revise the Unix files.

261urbity reasons, it will revise the Unix files.

267

262

268Keeping all mounted files in the same Unix subdirectory makes it

263Keeping all mounted files in the same Unix subdirectory makes it

269−easy to move the whole pier in a tarfile. Edits applied while

264+easy to move the whole pier in a tarfile. Edits applied while

270the `urbit` process isn't running will be detected and applied

265the `urbit` process isn't running will be detected and applied

271the next time it starts.

266the next time it starts.

272

267

273In conventional DVCS terms, `%clay` has a 1:1 static mapping from

268In conventional DVCS terms, `%clay` has a 1:1 static mapping from

274−branches to working directories. Why?

269+branches to working directories. Why?

275

270

276−Why not? Do we need that "what branches are checked out in what

271+Why not? Do we need that "what branches are checked out in what

277−directories" piece of state? Why force the user to worry about

272+directories" piece of state? Why force the user to worry about

278−which branches are mounted to which directories? Why not just

273+which branches are mounted to which directories? Why not just

279−mount them under their own names? Is there some crippling global

274+mount them under their own names? Is there some crippling global

280shortage of disk space for source files? Our planet is running

275shortage of disk space for source files? Our planet is running

281−out of inodes? Wut?

276+out of inodes? Wut?

282

277

283### Queries, subscriptions and synchronization

278### Queries, subscriptions and synchronization

284

279

285There are two ways to get data out of `%clay`: dereference the Urbit

280There are two ways to get data out of `%clay`: dereference the Urbit

286−namespace, or send a request/subscription. Sync is in userspace.

281+namespace, or send a request/subscription. Sync is in userspace.

287

282

288#### Dereferencing the namespace

283#### Dereferencing the namespace

289

284

290−`%clay` is just part of the full Urbit namespace. The full namespace

285+`%clay` is just part of the full Urbit namespace. The full namespace

291has a two-character prefix which expresses what vane to query

286has a two-character prefix which expresses what vane to query

292−(always `%c` for `%clay`). The suffix is a mode flag; `%x` for

287+(always `%c` for `%clay`). The suffix is a mode flag; `%x` for

293data, `%y` for a list of children, `%z` for the whole arch

288data, `%y` for a list of children, `%z` for the whole arch

294−subtree, `%w` for the version number. (Each vane has its own

289+subtree, `%w` for the version number. (Each vane has its own

295modes.)

290modes.)

296

291

297For example, the full path to my cat picture is

292For example, the full path to my cat picture is

@@ -305,7 +300,6 @@ For example, the full path to my cat picture is

305If the data model is `++image` (hypothetical -- we don't really

300If the data model is `++image` (hypothetical -- we don't really

306do image processing in Urbit right now), the normal way to load

301do image processing in Urbit right now), the normal way to load

307this data in a Hoon program is

302this data in a Hoon program is

308−

309```

303```

310.^(image /cx/~sorreg-namtyv/home/[now]/my/cat/picture)

304.^(image /cx/~sorreg-namtyv/home/[now]/my/cat/picture)

311```

305```

@@ -322,15 +316,15 @@ learn it in future, `[~ ~]` if we know we'll never know it, or

322`[~ ~ value]` if we know it now.

316`[~ ~ value]` if we know it now.

323

317

324In high-level shell programming (`:dojo`), we can make apparently

318In high-level shell programming (`:dojo`), we can make apparently

325−"blocking" requests to `%clay`. What actually happens: when `%clay`

319+"blocking" requests to `%clay`. What actually happens: when `%clay`

326produces `~`, we stop trying to compute this expression and wait

320produces `~`, we stop trying to compute this expression and wait

327−on one or more blocking requests. When we are unblocked, we

321+on one or more blocking requests. When we are unblocked, we

328recompute again from scratch; the intermediate computation is not

322recompute again from scratch; the intermediate computation is not

329saved at all.

323saved at all.

330

324

331−Urbit doesn't like to block. It likes to save coherent data

325+Urbit doesn't like to block. It likes to save coherent data

332−structures, not incomplete computation contexts. When Urbit

326+structures, not incomplete computation contexts. When Urbit

333−pretends to block for you, this is a courtesy service. You

327+pretends to block for you, this is a courtesy service. You

334can return the courtesy of not expecting miracles from it.

328can return the courtesy of not expecting miracles from it.

335When in doubt, send an actual request.

329When in doubt, send an actual request.

336

330

@@ -341,7 +335,7 @@ namespace, but can (a) read across case (revision) ranges,

341and (b) filter by subtree.

335and (b) filter by subtree.

342

336

343If the revision range in a request stretches into the future, the

337If the revision range in a request stretches into the future, the

344−request becomes a subscription. Urbit messaging always regards a

338+request becomes a subscription. Urbit messaging always regards a

345single response as a special case of a subscription.

339single response as a special case of a subscription.

346

340

347Generally, the response stream created by a request starts with

341Generally, the response stream created by a request starts with

@@ -351,10 +345,10 @@ closed when the request range is complete.

351

345

352#### Userspace synchronization

346#### Userspace synchronization

353

347

354−Synchronization per se is done in userspace. In `%clay`, sync just

348+Synchronization per se is done in userspace. In `%clay`, sync just

355means an application (typically the `%kiln` module in the system

349means an application (typically the `%kiln` module in the system

356app `:hood`) subscribes to a remote desk, and saves its change

350app `:hood`) subscribes to a remote desk, and saves its change

357−stream locally. So sync is really an emergent feature of `%clay`.

351+stream locally. So sync is really an emergent feature of `%clay`.

358

352

359### Revision graph

353### Revision graph

360

354

@@ -362,16 +356,16 @@ stream locally. So sync is really an emergent feature of `%clay`.

362Some changes are proposed below, however.

356Some changes are proposed below, however.

363

357

364As in any DVCS, a dome is the child of one parent dome (an edit)

358As in any DVCS, a dome is the child of one parent dome (an edit)

365−or more parents (a merge). Often the parent of any revision is

359+or more parents (a merge). Often the parent of any revision is

366the previous version in the sequence, but it can be anything.

360the previous version in the sequence, but it can be anything.

367

361

368### Storage model

362### Storage model

369

363

370−`%clay`'s storage model is completely uninteresting. It's also a

364+`%clay`'s storage model is completely uninteresting. It's also a

371little funky and I want to change it, so I'll be super vague.

365little funky and I want to change it, so I'll be super vague.

372

366

373A `++lobe`, a 128-bit atom, is the Merkle hash of a `blob`, which

367A `++lobe`, a 128-bit atom, is the Merkle hash of a `blob`, which

374−is essentially a leaf. All blobs are stored in a hash table

368+is essentially a leaf. All blobs are stored in a hash table

375(`(map lobe blob)`), and reference each other through lobes.

369(`(map lobe blob)`), and reference each other through lobes.

376

370

377At present we don't GC this space at all, because we don't

371At present we don't GC this space at all, because we don't

@@ -380,12 +374,12 @@ actually delete any roots.

380A `blob` may be `%direct`, meaning it's defined as the data

374A `blob` may be `%direct`, meaning it's defined as the data

381itself, or `%delta`, defined as a change against another blob.

375itself, or `%delta`, defined as a change against another blob.

382This is motivated by the desire not to store a full snapshot

376This is motivated by the desire not to store a full snapshot

383−on every file change. But it may be misguided (see changes #0

377+on every file change. But it may be misguided (see changes #0

384and #1 below).

378and #1 below).

385

379

386We cache the full arch tree (`++ankh`) of the latest state in

380We cache the full arch tree (`++ankh`) of the latest state in

387−each desk. For current queries, this mitigates a lot of the

381+each desk. For current queries, this mitigates a lot of the

388−opportunities for slowness that this data model creates. But the

382+opportunities for slowness that this data model creates. But the

389disparity between the speed of the current version and the

383disparity between the speed of the current version and the

390speed previous version is an undesirable glitch in the API.

384speed previous version is an undesirable glitch in the API.

391

385

@@ -397,38 +391,38 @@ We actually have _three_ motivations for change...

397

391

398At present, we're still using `git` as a development platform.

392At present, we're still using `git` as a development platform.

399`%clay` is certainly used, but just for its strength --

393`%clay` is certainly used, but just for its strength --

400−deployment. This is starving Urbit of essential experience and

394+deployment. This is starving Urbit of essential experience and

401−basically keeping it lame. So, change is necessary.

395+basically keeping it lame. So, change is necessary.

402

396

403### Change must come from the community

397### Change must come from the community

404

398

405−"Why?" you ask? "Why must change come from the community?" Well,

399+"Why?" you ask? "Why must change come from the community?" Well,

406−one, duh. Change always comes from the community.

400+one, duh. Change always comes from the community.

407

401

408−But two, a great force for change has departed. Philip Monk,

402+But two, a great force for change has departed. Philip Monk,

409late maintainer of `%clay` (`~wictuc-folrex` in the old era,

403late maintainer of `%clay` (`~wictuc-folrex` in the old era,

410−`~wicdev-wisryt` in the new), is tired of types and typing. He

404+`~wicdev-wisryt` in the new), is tired of types and typing. He

411spent September roaming with the bison in Montana, and is now

405spent September roaming with the bison in Montana, and is now

412−literally on his way to Patagonia. On the one hand, Phil still

406+literally on his way to Patagonia. On the one hand, Phil still

413exists and is not at all unwilling to answer questions, even dumb

407exists and is not at all unwilling to answer questions, even dumb

414−questions. On the other hand, _Patagonia_.

408+questions. On the other hand, _Patagonia_.

415

409

416−So %clay needs a new owner, or owners. At this point, we think

410+So %clay needs a new owner, or owners. At this point, we think

417the community might be indoctrinated enough to take a stab.

411the community might be indoctrinated enough to take a stab.

418

412

419Alas, `%clay` already has a pretty checkered ownership history.

413Alas, `%clay` already has a pretty checkered ownership history.

420Long ago I built a `%clay` that was really the only serious

414Long ago I built a `%clay` that was really the only serious

421−design failure in Arvo. Then Jared Hance, a brilliant summer

415+design failure in Arvo. Then Jared Hance, a brilliant summer

422intern, took my broken `%clay` and reformed it into a minimal `git`

416intern, took my broken `%clay` and reformed it into a minimal `git`

423−in about a week. Then Philip modified Jared's `%clay` to be a

417+in about a week. Then Philip modified Jared's `%clay` to be a

424_typed_ revision-control system, which is a pretty cool thing.

418_typed_ revision-control system, which is a pretty cool thing.

425

419

426But... in none of these transitions did `%clay` actually get

420But... in none of these transitions did `%clay` actually get

427−_rewritten_ per se. While it's a reasonably good vane, it

421+_rewritten_ per se. While it's a reasonably good vane, it

428does contain one or two historical decisions.

422does contain one or two historical decisions.

429

423

430We know a lot more about Arvo than we used to, and I think we can

424We know a lot more about Arvo than we used to, and I think we can

431−revisit many of these decisions. The point of this post is to

425+revisit many of these decisions. The point of this post is to

432start a `%clay` design discussion that will evolve into actual

426start a `%clay` design discussion that will evolve into actual

433collective action.

427collective action.

434

428

@@ -438,41 +432,41 @@ We're planning a rewards program for contributions to `%clay`.

438It'll simply involve setting a time period and a pool of real

432It'll simply involve setting a time period and a pool of real

439estate, and allocating the pool by judged contribution.

433estate, and allocating the pool by judged contribution.

440

434

441−This is an experimental program. We'll say more about it later.

435+This is an experimental program. We'll say more about it later.

442−It may not even happen. It may happen very differently. When in

436+It may not even happen. It may happen very differently. When in

443doubt, don't talk about Fight Club.

437doubt, don't talk about Fight Club.

444

438

445## Some openings for change

439## Some openings for change

446

440

447−Change, of course, must come from the community. No one can

441+Change, of course, must come from the community. No one can

448−dictate change from the top down. We _know_ this. But...

442+dictate change from the top down. We _know_ this. But...

449

443

450This list of suggested changes for the next `%clay` is not in any

444This list of suggested changes for the next `%clay` is not in any

451−sort of order: priority, structure, difficulty, etc. Let's talk

445+sort of order: priority, structure, difficulty, etc. Let's talk

452−about the changes first; make actual plans second. The numbers

446+about the changes first; make actual plans second. The numbers

453here are just for convenience.

447here are just for convenience.

454

448

455−_All changes in this program will happen on the next-generation

449+*All changes in this program will happen on the next-generation

456−(`cc-release`) branch._

450+(`cc-release`) branch.*

457

451

458### Change #0: state reform

452### Change #0: state reform

459

453

460As mentioned above, the storage model in `%clay`, as the code is

454As mentioned above, the storage model in `%clay`, as the code is

461−at present, feels a little funky to me. There's nothing terribly

455+at present, feels a little funky to me. There's nothing terribly

462awful about it, but it doesn't feel quite right and its scaling

456awful about it, but it doesn't feel quite right and its scaling

463properties are very questionable.

457properties are very questionable.

464

458

465Briefly, `%clay` today actually derives the hierarchy from its

459Briefly, `%clay` today actually derives the hierarchy from its

466−leaves -- rather than _logically_ so deriving it. Only leaves

460+leaves -- rather than _logically_ so deriving it. Only leaves

467−are in the object store. This is just weird, and you can feel

461+are in the object store. This is just weird, and you can feel

468−`%clay` trying to be something other than what it is. (I blame

462+`%clay` trying to be something other than what it is. (I blame

469Jared, though it's actually my fault.)

463Jared, though it's actually my fault.)

470

464

471To store a dome snapshot (`++yaki`), the present code keeps a

465To store a dome snapshot (`++yaki`), the present code keeps a

472−`(map path blob)` at the root of the dome. This is enough to

466+`(map path blob)` at the root of the dome. This is enough to

473reconstruct the `++arch` structures the namespace exports.

467reconstruct the `++arch` structures the namespace exports.

474However, all kinds of basic arch operations, like basically `ls`,

468However, all kinds of basic arch operations, like basically `ls`,

475−become `O(n)` in the number of leaves in the dome. This is

469+become `O(n)` in the number of leaves in the dome. This is

476obviously not quite right.

470obviously not quite right.

477

471

478I believe the storage structure should be (removing everything

472I believe the storage structure should be (removing everything

@@ -493,46 +487,46 @@ Here a `++root` is the universal node, with children addressed by

493hash, but logically representing the abstract `++arch`.

487hash, but logically representing the abstract `++arch`.

494

488

495Users of hierarchical filesystems basically expect performance

489Users of hierarchical filesystems basically expect performance

496−qualities that match the filesystem structure. A huge directory

490+qualities that match the filesystem structure. A huge directory

497−in one place shouldn't affect search speeds somewhere else. And

491+in one place shouldn't affect search speeds somewhere else. And

498of course, `ls` can't be O(n) in the size of the filesystem.

492of course, `ls` can't be O(n) in the size of the filesystem.

499

493

500### Change #1: store edges, cache snapshots

494### Change #1: store edges, cache snapshots

501

495

502−The current `%clay` is snapshot-oriented, like `git`. The actual

496+The current `%clay` is snapshot-oriented, like `git`. The actual

503−changes are discarded. I think this is a bad choice.

497+changes are discarded. I think this is a bad choice.

504

498

505`%clay` is not a research project, and has no idea of going as

499`%clay` is not a research project, and has no idea of going as

506−far as `darcs` in the "set-of-patches" direction. However, at

500+far as `darcs` in the "set-of-patches" direction. However, at

507present we actually throw away the patch (`++nori`).

501present we actually throw away the patch (`++nori`).

508

502

509I think the right DVCS design for `%clay` is a snapshot-oriented

503I think the right DVCS design for `%clay` is a snapshot-oriented

510−system which also keeps the patches. The revision graph has the

504+system which also keeps the patches. The revision graph has the

511−same general shape as in the old `git` style. But rather than

505+same general shape as in the old `git` style. But rather than

512just deriving the diffs from the snapshots, we can also derive

506just deriving the diffs from the snapshots, we can also derive

513−the snapshots from the diffs. When in doubt, we save space by

507+the snapshots from the diffs. When in doubt, we save space by

514dropping the snapshot, not the diff.

508dropping the snapshot, not the diff.

515

509

516For an RCS which is also a general-purpose typed filesystem, it's

510For an RCS which is also a general-purpose typed filesystem, it's

517clear that considering edges (deltas, diffs, changes, etc) as the

511clear that considering edges (deltas, diffs, changes, etc) as the

518−primary state is optimal. You can use diff functions to derive

512+primary state is optimal. You can use diff functions to derive

519deltas from snapshots, but in many data models this will always

513deltas from snapshots, but in many data models this will always

520−risk losing information from the original action. When in

514+risk losing information from the original action. When in

521doubt, save what the user did.

515doubt, save what the user did.

522

516

523This is even more true for operations on the tree structure, not

517This is even more true for operations on the tree structure, not

524−on individual leaves. Consider the heuristic energy that `git` has

518+on individual leaves. Consider the heuristic energy that `git` has

525to go through to figure out when `mv` has been used -- even when

519to go through to figure out when `mv` has been used -- even when

526−`git mv` has been used! (According to the `git` faq, this is

520+`git mv` has been used! (According to the `git` faq, this is

527because the lowest common denominator remains Linus' style of

521because the lowest common denominator remains Linus' style of

528working with emailed patches.)

522working with emailed patches.)

529

523

530−Edges probably don't even need to be deduplicated. They also can

524+Edges probably don't even need to be deduplicated. They also can

531contain metadata such as commit messages (which `%clay` has no

525contain metadata such as commit messages (which `%clay` has no

532place for at present).

526place for at present).

533

527

534Once edges are recognized as unreclaimed primary state, snapshots

528Once edges are recognized as unreclaimed primary state, snapshots

535−can always be derived from the edges. So we can reclaim memory

529+can always be derived from the edges. So we can reclaim memory

536being used for snapshots.

530being used for snapshots.

537

531

538It's also straightforward to have a kind of edge which is a list

532It's also straightforward to have a kind of edge which is a list

@@ -540,27 +534,27 @@ of edges, letting us collapse feature branches trivially.

540

534

541Finally, I think references in edges should wherever possible

535Finally, I think references in edges should wherever possible

542indirect through the namespace, rather than directly to the

536indirect through the namespace, rather than directly to the

543−content address. The user has strictly more information if you

537+content address. The user has strictly more information if you

544say you merged `/~sorreg-namtyv/base/987/`, than if all you have

538say you merged `/~sorreg-namtyv/base/987/`, than if all you have

545is the hash that this reference refers to.

539is the hash that this reference refers to.

546

540

547### Change #2: unconfuse merge and rebase

541### Change #2: unconfuse merge and rebase

548

542

549The dispute between merge and rebase has all the bad smells of

543The dispute between merge and rebase has all the bad smells of

550−a historical wart. But here I'm just not sure what's right.

544+a historical wart. But here I'm just not sure what's right.

551

545

552The user has one _intent_ whether merging or rebasing, which is

546The user has one _intent_ whether merging or rebasing, which is

553−to combine changes on one desk into another. The _algorithm_

547+to combine changes on one desk into another. The _algorithm_

554used to construct this change, whether operational transformation

548used to construct this change, whether operational transformation

555(rebasing) or a 3-way diff (merging) has one goal: use all

549(rebasing) or a 3-way diff (merging) has one goal: use all

556available information to model the authors' editing intent as

550available information to model the authors' editing intent as

557−realistically as possible. If we save edges, we should use

551+realistically as possible. If we save edges, we should use

558edges.

552edges.

559

553

560Whether to define the resulting change graph with the typical

554Whether to define the resulting change graph with the typical

561structure of a merge, or the typical structure of a rebase,

555structure of a merge, or the typical structure of a rebase,

562strikes me as quite arbitrary, and well into the land of "pick

556strikes me as quite arbitrary, and well into the land of "pick

563−one and force everyone to stick with it." But this call demands

557+one and force everyone to stick with it." But this call demands

564a real expert on RCS workflow, which I'm not.

558a real expert on RCS workflow, which I'm not.

565

559

566Since `%clay` is a humble part of a larger system and needs to

560Since `%clay` is a humble part of a larger system and needs to

@@ -570,23 +564,23 @@ different preferences" is not usually the right answer.

570### Change #3: comment jihad

564### Change #3: comment jihad

571

565

572`%clay` needs to be brought up to the documentation standards of

566`%clay` needs to be brought up to the documentation standards of

573−`%jael`. This means (a) the formatting matches; (b) the comments

567+`%jael`. This means (a) the formatting matches; (b) the comments

574are at the same level of quality and ubiquity.

568are at the same level of quality and ubiquity.

575

569

576The basic commenting standards are: (a) every core (class) needs

570The basic commenting standards are: (a) every core (class) needs

577a block comment explanation; (b) every gate (function) needs a

571a block comment explanation; (b) every gate (function) needs a

578line comment; (c) every face (variable) needs a line comment.

572line comment; (c) every face (variable) needs a line comment.

579

573

580−This is obviously not just a clerical task. To write these

574+This is obviously not just a clerical task. To write these

581−comments, you need to actually understand the code. This is a

575+comments, you need to actually understand the code. This is a

582nontrivial but extremely rewarding task, even if the code you're

576nontrivial but extremely rewarding task, even if the code you're

583commenting will get replaced.

577commenting will get replaced.

584

578

585Also, the _symbols_ in `%clay` must be brought up to `%jael`

579Also, the _symbols_ in `%clay` must be brought up to `%jael`

586−quality. There is still far too much four-letterism here.

580+quality. There is still far too much four-letterism here.

587

581

588NB: `%clay` is about 3000 lines of pretty clean Hoon, which is

582NB: `%clay` is about 3000 lines of pretty clean Hoon, which is

589−certainly not at all undocumented. We're not exactly looking at

583+certainly not at all undocumented. We're not exactly looking at

590a Matterhorn of reverse engineering here.

584a Matterhorn of reverse engineering here.

591

585

592### Change #4: knot to coin internal paths

586### Change #4: knot to coin internal paths

@@ -597,26 +591,26 @@ ASCII symbol as an atom) must be within the range of the

597invertible noun printer, `++co`.

591invertible noun printer, `++co`.

598

592

599`++co` maps a described data value, a `++coin`, to an ASCII

593`++co` maps a described data value, a `++coin`, to an ASCII

600−string which is a valid URL segment and Unix filename. Its

594+string which is a valid URL segment and Unix filename. Its

601friend `++so` inverts the function, perfectly.

595friend `++so` inverts the function, perfectly.

602

596

603−Almost every knot is the simplest kind of `coin`, a `dime.` A

597+Almost every knot is the simplest kind of `coin`, a `dime.` A

604dime is a single atom with a rendering type (`aura` if you know

598dime is a single atom with a rendering type (`aura` if you know

605−Hoon). Auras include `@tas` for symbolic text, `@ud` for

599+Hoon). Auras include `@tas` for symbolic text, `@ud` for

606−unsigned decimal, `@p` for Urbit ship, etc. `++co` can also

600+unsigned decimal, `@p` for Urbit ship, etc. `++co` can also

607print arbitrary cells, though less prettily.

601print arbitrary cells, though less prettily.

608

602

609This feature is cool because it lets us stuff data into names in

603This feature is cool because it lets us stuff data into names in

610−a precise and predictable way. Usually the names in a namespace

604+a precise and predictable way. Usually the names in a namespace

611are human-meaningful and human-originated, and are therefore

605are human-meaningful and human-originated, and are therefore

612−symbolic, but there are exceptions. For example, blogposts may

606+symbolic, but there are exceptions. For example, blogposts may

613want to be named by date.

607want to be named by date.

614

608

615However, it is slightly retarded for the fundamental state of our

609However, it is slightly retarded for the fundamental state of our

616arches to store the _rendered_ string (`++knot`), not the source

610arches to store the _rendered_ string (`++knot`), not the source

617−data (`++coin`). It leads to all kinds of inefficiencies where

611+data (`++coin`). It leads to all kinds of inefficiencies where

618−we're doing way more parsing than we want to. (Parsing also

612+we're doing way more parsing than we want to. (Parsing also

619−should be jet-propelled, but is not.) It also makes it way too

613+should be jet-propelled, but is not.) It also makes it way too

620easy to sneak in bad data and make it `%clay`'s problem.

614easy to sneak in bad data and make it `%clay`'s problem.

621

615

622So, logically, we'd be shifting from

616So, logically, we'd be shifting from

@@ -631,7 +625,7 @@ So, logically, we'd be shifting from

631

625

632Also, a vanilla `++map` might not be quite the right data

626Also, a vanilla `++map` might not be quite the right data

633structure at this point -- we probably want a custom sorted tree,

627structure at this point -- we probably want a custom sorted tree,

634−which separates auras and imposes a custom order on each. This

628+which separates auras and imposes a custom order on each. This

635would let us serve simple range queries quite efficiently, so

629would let us serve simple range queries quite efficiently, so

636long as they match the standard aura order (eg, alphabetical

630long as they match the standard aura order (eg, alphabetical

637order for symbols).

631order for symbols).

@@ -639,23 +633,23 @@ order for symbols).

639### Change #5: dome semantics by reference

633### Change #5: dome semantics by reference

640

634

641While the principle that a dome contains its own mark source is

635While the principle that a dome contains its own mark source is

642−elegant, it's a pain in the ass to implement properly. `%clay`

636+elegant, it's a pain in the ass to implement properly. `%clay`

643certainly does not do it justice at present.

637certainly does not do it justice at present.

644

638

645The complexity is in checking every change to see whether it

639The complexity is in checking every change to see whether it

646includes a change to the mark source (which is very unlikely),

640includes a change to the mark source (which is very unlikely),

647or a dependency of the mark source (slightly less unlikely).

641or a dependency of the mark source (slightly less unlikely).

648And if so, do we have to update all the leaves in the dome?

642And if so, do we have to update all the leaves in the dome?

649−This is also very unlikely. And yet, it happens.

643+This is also very unlikely. And yet, it happens.

650

644

651Instead, we could simply designate, by beak (ship, desk, and

645Instead, we could simply designate, by beak (ship, desk, and

652−case) a dome which contains the canonical mark source. This

646+case) a dome which contains the canonical mark source. This

653would rarely change -- you could upgrade a desk to a new mark

647would rarely change -- you could upgrade a desk to a new mark

654dome, but it would be a manual operation and probably a rare one.

648dome, but it would be a manual operation and probably a rare one.

655

649

656The common case would just be that everyone uses the current

650The common case would just be that everyone uses the current

657version of the `%base` desk when a desk is created, and never

651version of the `%base` desk when a desk is created, and never

658−changes it. In practice, this means not every two-byte edit

652+changes it. In practice, this means not every two-byte edit

659needs to get involved in detecting and/or applying schema

653needs to get involved in detecting and/or applying schema

660evolution, a welcome simplification.

654evolution, a welcome simplification.

661

655

@@ -667,14 +661,14 @@ design is one mark per message structure, the mark namespace gets

667overloaded fast.

661overloaded fast.

668

662

669So we added an app hierarchy within the mark namespace, using hep

663So we added an app hierarchy within the mark namespace, using hep

670−`-` as a divider. The `:talk` app expects messages with the mark

664+`-` as a divider. The `:talk` app expects messages with the mark

671`talk-message`, whose sources is in `/===/mar/talk/message`.

665`talk-message`, whose sources is in `/===/mar/talk/message`.

672

666

673This helps, but it doesn't solve another two problems: trivial

667This helps, but it doesn't solve another two problems: trivial

674nouns and containers.

668nouns and containers.

675

669

676It's retarded to have to add a source file to send a `@ud` or a

670It's retarded to have to add a source file to send a `@ud` or a

677−`*`. An aura (see above under `coin`) should be a trivial mark.

671+`*`. An aura (see above under `coin`) should be a trivial mark.

678

672

679Also, we need to be able to construct standard containers of

673Also, we need to be able to construct standard containers of

680marks: lists, maps, sets, and tuples (or, as a database person

674marks: lists, maps, sets, and tuples (or, as a database person

@@ -686,32 +680,32 @@ Another kind of complex mark that needs to exist: conflict,

686difference, and invalid marks.

680difference, and invalid marks.

687

681

688Conflict data and difference data are two types of noun that are

682Conflict data and difference data are two types of noun that are

689−generated in normal RCS operation. If we have the concept of an

683+generated in normal RCS operation. If we have the concept of an

690`%html` noun, we also need the concept of an invertible change

684`%html` noun, we also need the concept of an invertible change

691from one `%html` file to another; a merge conflict between two

685from one `%html` file to another; a merge conflict between two

692`%html` files; and even a conflict between two marks.

686`%html` files; and even a conflict between two marks.

693

687

694There are two kinds of changes to a dome: manual and automatic.

688There are two kinds of changes to a dome: manual and automatic.

695Manual changes are initiated by the user and should crash, unless

689Manual changes are initiated by the user and should crash, unless

696−manually overridden. Automatic changes should not crash, ever,

690+manually overridden. Automatic changes should not crash, ever,

697−and should not lose data. If they create problems, which they

691+and should not lose data. If they create problems, which they

698shouldn't, these problems will need to be cleaned up manually.

692shouldn't, these problems will need to be cleaned up manually.

699

693

700This is a complex space to navigate, but it requires a conflicted

694This is a complex space to navigate, but it requires a conflicted

701merge to be able to resolve to a valid dome containing conflict

695merge to be able to resolve to a valid dome containing conflict

702−leaves, not crash. The present `%clay` goes halfway there and

696+leaves, not crash. The present `%clay` goes halfway there and

703resolves to a scratch desk, but we can go farther: the whole `git`

697resolves to a scratch desk, but we can go farther: the whole `git`

704−dumpster-fire of "merge state" deserves destruction. One change

698+dumpster-fire of "merge state" deserves destruction. One change

705is a merge that produces conflicts, the next is an edit that

699is a merge that produces conflicts, the next is an edit that

706resolves them.

700resolves them.

707

701

708−Similarly, all sorts of errors can produce invalid leaves. One

702+Similarly, all sorts of errors can produce invalid leaves. One

709particularly rare case which is nonetheless important is schema

703particularly rare case which is nonetheless important is schema

710evolution: what happens to files in a mark, when the mark source

704evolution: what happens to files in a mark, when the mark source

711−code changes. They all need to be re-normalized. And this

705+code changes. They all need to be re-normalized. And this

712−operation can fail, producing an invalid value. (We don't do any

706+operation can fail, producing an invalid value. (We don't do any

713of this now, BTW, although `%ford` has the dependency mechanism to

707of this now, BTW, although `%ford` has the dependency mechanism to

714−make it possible.) Again, in some cases this should crash the

708+make it possible.) Again, in some cases this should crash the

715update to the mark source; in other cases, there is no local way

709update to the mark source; in other cases, there is no local way

716to handle the crash.

710to handle the crash.

717

711

@@ -722,46 +716,46 @@ into using the bad content.

722

716

723The bottom line: a mark needs to be split into two models:

717The bottom line: a mark needs to be split into two models:

724`++mark`, the original symbolic mark with its source engine, and

718`++mark`, the original symbolic mark with its source engine, and

725−something like `++logo`, the meta-mark or mark container. The

719+something like `++logo`, the meta-mark or mark container. The

726mark is the building block; the logo is the building.

720mark is the building block; the logo is the building.

727

721

728### Change #8: filesystem hierarchy standard

722### Change #8: filesystem hierarchy standard

729

723

730While all filesystems remain forks of one ur-filesystem, the

724While all filesystems remain forks of one ur-filesystem, the

731−standard tends to enforce itself. But not define itself.

725+standard tends to enforce itself. But not define itself.

732

726

733−I've always hated the current `/mar` for marks, for instance. I

727+I've always hated the current `/mar` for marks, for instance. I

734−prefer `/mac`. But others hate this. And so on. Also, by

728+prefer `/mac`. But others hate this. And so on. Also, by

735necessity, our nascent "FHS" is heavily biased toward system

729necessity, our nascent "FHS" is heavily biased toward system

736−data, away from user data. This is retarded.

730+data, away from user data. This is retarded.

737

731

738−Please focus all bikeshedding energy on this problem! Better to

732+Please focus all bikeshedding energy on this problem! Better to

739bikeshed about what color to paint the bikeshed, then what shape

733bikeshed about what color to paint the bikeshed, then what shape

740the bike gears should be.

734the bike gears should be.

741

735

742### Change #9: security and access control

736### Change #9: security and access control

743

737

744−Oh, yeah, that! They always say not to design security in at the

738+Oh, yeah, that! They always say not to design security in at the

745−last minute. Unfortunately, this is exactly what we did. There

739+last minute. Unfortunately, this is exactly what we did. There

746−is no security at all in present `%clay`. (There is also no push

740+is no security at all in present `%clay`. (There is also no push

747operation in `%clay`, so it's not as mad as you think -- anyone

741operation in `%clay`, so it's not as mad as you think -- anyone

748can read anything, no one can write anything, which is fine in a

742can read anything, no one can write anything, which is fine in a

749young network where there are no secrets.)

743young network where there are no secrets.)

750

744

751Fortunately, we don't have anything super fancy planned in this

745Fortunately, we don't have anything super fancy planned in this

752−area, just basic access-control lists. These obviously need to

746+area, just basic access-control lists. These obviously need to

753be designed along with the filesystem-hierarchy standard (see

747be designed along with the filesystem-hierarchy standard (see

754elsewhere).

748elsewhere).

755

749

756−Is it even possible to do ACLs properly in `%clay`? At this

750+Is it even possible to do ACLs properly in `%clay`? At this

757−point, yes. There is an event-oriented security model in Arvo,

751+point, yes. There is an event-oriented security model in Arvo,

758though it isn't really hooked up to anything at the moment.

752though it isn't really hooked up to anything at the moment.

759−There is also a privilege badge system in `%jael`. The

753+There is also a privilege badge system in `%jael`. The

760combination of these two features is quite sufficient for a

754combination of these two features is quite sufficient for a

761decent ACL model.

755decent ACL model.

762

756

763The idea of event-based security is that every event passed to

757The idea of event-based security is that every event passed to

764−`%clay` has a security `++mask`. The mask tells us:

758+`%clay` has a security `++mask`. The mask tells us:

765

759

766- the set of ships that has _contaminated_ this event

760- the set of ships that has _contaminated_ this event

767- the set of ships that has _endorsed_ this event

761- the set of ships that has _endorsed_ this event

@@ -769,20 +763,20 @@ The idea of event-based security is that every event passed to

769

763

770To simplify this system a little and maybe explain it, the

764To simplify this system a little and maybe explain it, the

771security question in any event is: (a) who has _caused_ this

765security question in any event is: (a) who has _caused_ this

772−event? (b) who may receive its _effects_? (These sets never

766+event? (b) who may receive its _effects_? (These sets never

773include your urbit itself, of course, only neighbors.)

767include your urbit itself, of course, only neighbors.)

774

768

775For example, if we're doing something because ship X sent us a

769For example, if we're doing something because ship X sent us a

776packet, and we're going to leak the results of this something

770packet, and we're going to leak the results of this something

777back in a response to ship X, once `%clay` knows what our ship

771back in a response to ship X, once `%clay` knows what our ship

778thinks of its neighbor X, we should have a good picture of what

772thinks of its neighbor X, we should have a good picture of what

779−effects this event should be allowed to cause. If `%jael` knows

773+effects this event should be allowed to cause. If `%jael` knows

780that X is our friend, `%clay` can know that X can see our cat

774that X is our friend, `%clay` can know that X can see our cat

781picture.

775picture.

782

776

783Causality is separated out into contamination (data from ship X

777Causality is separated out into contamination (data from ship X

784got into the event) and endorsement (ship X signed the whole

778got into the event) and endorsement (ship X signed the whole

785−event). (This may be overdesign.) All these sets can be defined

779+event). (This may be overdesign.) All these sets can be defined

786as the empty set (eg, releasing to the empty set means no output)

780as the empty set (eg, releasing to the empty set means no output)

787or the universal set (input from the universal set could be from

781or the universal set (input from the universal set could be from

788anyone, ie, is unauthenticated).

782anyone, ie, is unauthenticated).

@@ -791,11 +785,11 @@ anyone, ie, is unauthenticated).

791

785

792When you read a leaf from a `%clay` dome, `%clay` is happy to

786When you read a leaf from a `%clay` dome, `%clay` is happy to

793perform any necessary mark conversions (the actual work is done

787perform any necessary mark conversions (the actual work is done

794−by the `%ford` build vane). You can also just ask for the leaf

788+by the `%ford` build vane). You can also just ask for the leaf

795in whatever mark `%clay` has it.

789in whatever mark `%clay` has it.

796

790

797It's confusing to think of this mark extension as part of the

791It's confusing to think of this mark extension as part of the

798−path. You shouldn't say `+cat /===/app/talk/hoon`. You should say

792+path. You shouldn't say `+cat /===/app/talk/hoon`. You should say

799`+cat /===/app/talk`, or maybe `+cat %hoon /===/app/talk`.

793`+cat /===/app/talk`, or maybe `+cat %hoon /===/app/talk`.

800

794

801A mark-extended namespace may be added to `%ford`, to compensate.

795A mark-extended namespace may be added to `%ford`, to compensate.

@@ -804,7 +798,7 @@ But type-converting reads are the rare case, not the common case.

804### Change #11: real queries and indexes

798### Change #11: real queries and indexes

805

799

806A filesystem should postpone being a database until it can no

800A filesystem should postpone being a database until it can no

807−longer do so. So, please don't think about this problem yet.

801+longer do so. So, please don't think about this problem yet.

808I'm joking, of course!

802I'm joking, of course!

809

803

810### Change #12: meta-query

804### Change #12: meta-query

@@ -813,24 +807,24 @@ Make it possible to query the list of desks in a ship :-)

813

807

814### Change #13: completely redesign Unix mounting

808### Change #13: completely redesign Unix mounting

815

809

816−This is actually a series of changes, described below. But

810+This is actually a series of changes, described below. But

817broadly...

811broadly...

818

812

819One of Urbit's experiments is live two-way synchronization

813One of Urbit's experiments is live two-way synchronization

820between the Unix filesystem and the revision-control store.

814between the Unix filesystem and the revision-control store.

821−Dropbox style, as it were. I think this experiment is basically

815+Dropbox style, as it were. I think this experiment is basically

822−a failure. It may be right for cat pictures, but I don't think

816+a failure. It may be right for cat pictures, but I don't think

823it's right for Urbit.

817it's right for Urbit.

824

818

825The fundamental problem is that there are all sorts of weird,

819The fundamental problem is that there are all sorts of weird,

826−flaky ways applications use a mutable filesystem. It's not at

820+flaky ways applications use a mutable filesystem. It's not at

827all unusual for an editor to change a file by deleting the old

821all unusual for an editor to change a file by deleting the old

828file, then writing the new one in its place.

822file, then writing the new one in its place.

829

823

830−You really don't want this to produce a delete change. A simple

824+You really don't want this to produce a delete change. A simple

831cooldown timer for the sync helps a lot with this, but causes

825cooldown timer for the sync helps a lot with this, but causes

832−other weirdnesses. In theory, a sync can even cause another

826+other weirdnesses. In theory, a sync can even cause another

833−change to the same version of the same desk. And so on.

827+change to the same version of the same desk. And so on.

834

828

835The thing we fear is just too funky to work (there is some

829The thing we fear is just too funky to work (there is some

836strange "reflux bug" still affecting it) is any sort of _two-way_

830strange "reflux bug" still affecting it) is any sort of _two-way_

@@ -841,8 +835,8 @@ cold storage, is that there's no useful workflow that actually

841uses it -- at least, when editing Urbit code.

835uses it -- at least, when editing Urbit code.

842

836

843It's actually really nice to have files on a disk that nothing

837It's actually really nice to have files on a disk that nothing

844−will automatically modify. If you're using `git` and `%clay` in

838+will automatically modify. If you're using `git` and `%clay` in

845−parallel, it's nice to mount your `git` working directory. The

839+parallel, it's nice to mount your `git` working directory. The

846original Urbit workflow was to work out of a mounted directory,

840original Urbit workflow was to work out of a mounted directory,

847but the two-way updates were just too weird and scary, so now we

841but the two-way updates were just too weird and scary, so now we

848tend to edit elsewhere and copy in -- which is lame.

842tend to edit elsewhere and copy in -- which is lame.

@@ -855,25 +849,25 @@ FUSE (in a somewhat experimental state), and filesystem watching

855

849

856The FUSE interface is a good one, though it needs more work.

850The FUSE interface is a good one, though it needs more work.

857Moreover, it exports the whole Urbit namespace to Unix, not just

851Moreover, it exports the whole Urbit namespace to Unix, not just

858−`%clay`. For reading Urbit data, FUSE is basically ideal.

852+`%clay`. For reading Urbit data, FUSE is basically ideal.

859

853

860−The obvious impulse is to make a read-write FUSE. But I don't

854+The obvious impulse is to make a read-write FUSE. But I don't

861think FUSE should be used for recording changes to an RCS, even

855think FUSE should be used for recording changes to an RCS, even

862though the FUSE API sends you changes as events.

856though the FUSE API sends you changes as events.

863

857

864−There are three reasons for this. One, the actual filesystem

858+There are three reasons for this. One, the actual filesystem

865writes that Unix apps make are typically of low quality and

859writes that Unix apps make are typically of low quality and

866−confusing. Some crack-brained editor will find it completely

860+confusing. Some crack-brained editor will find it completely

867normal and unremarkable to modify a byte in a file, by deleting

861normal and unremarkable to modify a byte in a file, by deleting

868−the file and rewriting it from scratch. You can use a cooldown

862+the file and rewriting it from scratch. You can use a cooldown

869timer to wait for this nonsense to converge, but leaving data in

863timer to wait for this nonsense to converge, but leaving data in

870heuristic limbo seems like a very bad idea in FUSE-land.

864heuristic limbo seems like a very bad idea in FUSE-land.

871

865

872The second is that people derive a lot of comfort from seeing

866The second is that people derive a lot of comfort from seeing

873−actual files on an actual disk. The idea that your datas are

867+actual files on an actual disk. The idea that your datas are

874stuck in Urbit is slightly terrifying as a user experience.

868stuck in Urbit is slightly terrifying as a user experience.

875−We claim to be reliable. It's actually hard to imagine datas that

869+We claim to be reliable. It's actually hard to imagine datas that

876−couldn't be recovered from either snapshot or log. But how can

870+couldn't be recovered from either snapshot or log. But how can

877you possibly believe us on this?

871you possibly believe us on this?

878

872

879So I think it's correct to lean all the weight of reading data

873So I think it's correct to lean all the weight of reading data

@@ -888,35 +882,35 @@ But this is a separate discussion.

888

882

889### Change #15: one-way, nonced working desk

883### Change #15: one-way, nonced working desk

890

884

891−A one-way mount is a much less crazy thing. It works the same

885+A one-way mount is a much less crazy thing. It works the same

892way our two-way mount works today, but with only one writer: the

886way our two-way mount works today, but with only one writer: the

893user, via Unix.

887user, via Unix.

894

888

895Since a mount is one-way, it needs to have an absolute write lock

889Since a mount is one-way, it needs to have an absolute write lock

896−on the desk it's writing to. We cannot have a `%home` desk which

890+on the desk it's writing to. We cannot have a `%home` desk which

897we are also editing with filesystem watching.

891we are also editing with filesystem watching.

898

892

899Instead, we have a temporary and anonymous state that's connected

893Instead, we have a temporary and anonymous state that's connected

900−itself with your `%home` desk. Desk names have to be valid

894+itself with your `%home` desk. Desk names have to be valid

901−symbols, but we can use `hep`, `-`. A reasonable choice is to

895+symbols, but we can use `hep`, `-`. A reasonable choice is to

902pick a random 32-bit name for each mount instance -- so the desk

896pick a random 32-bit name for each mount instance -- so the desk

903−name is not `%home`, but `%home-bosdut-sigder`. (Randomizing

897+name is not `%home`, but `%home-bosdut-sigder`. (Randomizing

904instead of always using a fixed suffix, say, `%home-work`,

898instead of always using a fixed suffix, say, `%home-work`,

905just makes all kinds of screwups less likely.)

899just makes all kinds of screwups less likely.)

906

900

907You create a mount simply by mkdiring the desk name in your pier.

901You create a mount simply by mkdiring the desk name in your pier.

908Just the base name, Urbit will come up with the `%bosdut-sigder`

902Just the base name, Urbit will come up with the `%bosdut-sigder`

909−part and put it in a `.desk` file at the desk root. To forget

903+part and put it in a `.desk` file at the desk root. To forget

910−the mount, just delete this file. This avoids the ugly confusion

904+the mount, just delete this file. This avoids the ugly confusion

911between unmounting a mount, and deleting all the data in it.

905between unmounting a mount, and deleting all the data in it.

912

906

913(Urbit will keep a set of the mount desks it's used and

907(Urbit will keep a set of the mount desks it's used and

914−forgotten, not reuse them, and block all requests into them. By

908+forgotten, not reuse them, and block all requests into them. By

915blocking, we can delete without losing referential transparency.

909blocking, we can delete without losing referential transparency.

916Yes, Virginia, Urbit can forget!)

910Yes, Virginia, Urbit can forget!)

917

911

918Note that the auto-reload behavior of applications is extremely

912Note that the auto-reload behavior of applications is extremely

919−useful when testing. When testing, you can either switch the

913+useful when testing. When testing, you can either switch the

920active application desk from `%home` to `%home-bosdut-sigder`,

914active application desk from `%home` to `%home-bosdut-sigder`,

921or activate autosync from the latter to the former.

915or activate autosync from the latter to the former.

922

916

@@ -939,7 +933,7 @@ Otherwise, you're basically, like, reinventing Perforce.

939

933

940More concretely, the Urbit experience today requires `:hood`

934More concretely, the Urbit experience today requires `:hood`

941pokes (Urbit shell commands, basically) for all nontrivial RCS

935pokes (Urbit shell commands, basically) for all nontrivial RCS

942−operations, from mounting to merging. Again, there are lots of

936+operations, from mounting to merging. Again, there are lots of

943situations in which you can write into a mounted filesystem (the

937situations in which you can write into a mounted filesystem (the

944protocol for Unix communication could be easily adapted to

938protocol for Unix communication could be easily adapted to

945communicate with a browser-based editor, for instance), but you

939communicate with a browser-based editor, for instance), but you

@@ -949,20 +943,20 @@ Even commands like mounting and merging are easily communicated,

949through filesystem writes that any Unix tool (including many

943through filesystem writes that any Unix tool (including many

950macro editors).

944macro editors).

951

945

952−This is very easy for a filesystem watcher. One such protocol:

946+This is very easy for a filesystem watcher. One such protocol:

953if you want to send the daemon a command relative to some

947if you want to send the daemon a command relative to some

954−directory, write a `.ur-command` metafile in that directory. The

948+directory, write a `.ur-command` metafile in that directory. The

955daemon accepts the command by deleting it.

949daemon accepts the command by deleting it.

956

950

957The user experience is that you configure your mounts by simply

951The user experience is that you configure your mounts by simply

958−making the directories and configuring dotfiles in them. Unlike

952+making the directories and configuring dotfiles in them. Unlike

959in the present system, Urbit will never modify your datas

953in the present system, Urbit will never modify your datas

960silently in the background.

954silently in the background.

961

955

962Here's what this looks like:

956Here's what this looks like:

963

957

964−Suppose you want to edit some data in the `%home` desk. Your

958+Suppose you want to edit some data in the `%home` desk. Your

965−data is in `/=home=/mar/talk`. You also want a read-only view

959+data is in `/=home=/mar/talk`. You also want a read-only view

966of `/=home=/arvo`.

960of `/=home=/arvo`.

967

961

968From Unix, you do something like this:

962From Unix, you do something like this:

@@ -975,18 +969,18 @@ From Unix, you do something like this:

975 $ touch home/arvo/.read

969 $ touch home/arvo/.read

976```

970```

977

971

978−Want to commit your changes? That means merging the working

972+Want to commit your changes? That means merging the working

979−desk, `%home-bosdut-sigder`, into the `%home`. Put a commit message

973+desk, `%home-bosdut-sigder`, into the `%home`. Put a commit message

980−into `home/.commit` and it'll happen. If there's an error, it

974+into `home/.commit` and it'll happen. If there's an error, it

981will appear as `.error`.

975will appear as `.error`.

982

976

983The mount has a .version file which simply contains the change

977The mount has a .version file which simply contains the change

984−number (of the working desk) which any edits are relative to. If

978+number (of the working desk) which any edits are relative to. If

985the urbit daemon is running and watching, edits will be absorbed

979the urbit daemon is running and watching, edits will be absorbed

986quickly (probably after a heuristic timeout), and the version

980quickly (probably after a heuristic timeout), and the version

987−incremented. But we always are confident that the edits are

981+incremented. But we always are confident that the edits are

988against the latest version, or at least we can use this as a

982against the latest version, or at least we can use this as a

989−sanity check. All kinds of insane things can happen to get a

983+sanity check. All kinds of insane things can happen to get a

990filesystem out of consistency.

984filesystem out of consistency.

991

985

992This design obviously needs a little fleshing out, but I'm quite

986This design obviously needs a little fleshing out, but I'm quite

@@ -995,12 +989,12 @@ from Unix.

995

989

996## In conclusion

990## In conclusion

997

991

998−There's obviously a lot of fun here! There are two things you

992+There's obviously a lot of fun here! There are two things you

999can do right now.

993can do right now.

1000

994

1001One, talk about `%clay` on [this forum

995One, talk about `%clay` on [this forum

1002thread](http://urbit.org/~~/fora/posts/~2016.10.25..17.37.47..6937~/) or

996thread](http://urbit.org/~~/fora/posts/~2016.10.25..17.37.47..6937~/) or

1003−on [:talk](http://urbit.org/stream). Both hosted on Urbit

997+on [:talk](http://urbit.org/stream). Both hosted on Urbit

1004itself!

998itself!

1005

999

1006Two, poke around the

1000Two, poke around the

content/blog/urbit-and-bitcoin.md+6−6

@@ -1,8 +1,7 @@

1+++

1+++

2title = "Urbit and Bitcoin"

2title = "Urbit and Bitcoin"

3description = "A sound money deserves a sound computer."

3description = "A sound money deserves a sound computer."

4−date = "2019-10-16"

4+date = 2019-10-17

5−tags = ["bitcoin"]

6[extra]

5[extra]

7author = "Christian Langalis"

6author = "Christian Langalis"

8ship = "~pindet-timmut"

7ship = "~pindet-timmut"

@@ -10,12 +9,13 @@ ship = "~pindet-timmut"

10

9

11Sound money deserves a sound computer.

10Sound money deserves a sound computer.

12

11

13−Urbit imagines a new model for an OS that – among other changes – includes money as a native service. Developers within the Urbit ecosystem will be able to securely use money in their applications as easily as they might use file systems or networking protocols. Creating a new sound currency, however is not our goal; Bitcoin has already done that.

12+Urbit imagines a new model for an OS that – among other changes – includes money as a native service. Developers within the Urbit ecosystem will be able to securely use money in their applications as easily as they might use file systems or networking protocols. Creating a new sound currency, however is not our goal; Bitcoin has already done that.

14

13

15−Running a Bitcoin node is very much like running a single purpose personal server (one that hosts the Bitcoin blockchain and verifies transactions). Urbit is designed to be the _final_ personal server, so this week we launched several grants to incorporate Bitcoin into our development cycle. The first of these are directed towards interacting with Bitcoin nodes directly from Urbit.

14+Running a Bitcoin node is very much like running a single purpose personal server (one that hosts the Bitcoin blockchain and verifies transactions). Urbit is designed to be the *final* personal server, so this week we launched several grants to incorporate Bitcoin into our development cycle. The first of these are directed towards interacting with Bitcoin nodes directly from Urbit.

16

15

17−Bitcoin and Urbit are complementary systems. Sound digital money requires sound computing to be used safely and effectively. Urbit’s OS is strictly-typed and entirely functional, and as a result, it’s orders of magnitude more secure than the Unix ecosystem when fully implemented.

16+Bitcoin and Urbit are complementary systems. Sound digital money requires sound computing to be used safely and effectively. Urbit’s OS is strictly-typed and entirely functional, and as a result, it’s orders of magnitude more secure than the Unix ecosystem when fully implemented.

18

17

19−Urbit and Bitcoin converge along the realization that the Virtual is subsuming the Real. In other words, the locus of control over your life is no longer embodied in the physical, but the digital. For example, what worries you more: a pickpocket or a sim-swapper? The bogeymen of today don’t target our physical selves; they target our private keys, our searches, and our data. The client-server computing paradigm is falling in upon itself, and cannot protect us in this new reality. Without peer-to-peer tools like Urbit and Bitcoin, our property and lives lie vulnerable to control by platforms.

18+Urbit and Bitcoin converge along the realization that the Virtual is subsuming the Real. In other words, the locus of control over your life is no longer embodied in the physical, but the digital. For example, what worries you more: a pickpocket or a sim-swapper? The bogeymen of today don’t target our physical selves; they target our private keys, our searches, and our data. The client-server computing paradigm is falling in upon itself, and cannot protect us in this new reality. Without peer-to-peer tools like Urbit and Bitcoin, our property and lives lie vulnerable to control by platforms.

20

19

21To integrate Bitcoin with Urbit, we’re starting with the basics: a Bitcoin wallet and a Bitcoin node solution for Urbit. These tools will bring Urbit’s Bitcoin functionality from 0 to 1, and will serve as building blocks for our upcoming push from 1 to `n`. We’ll be sharing more about this in the coming weeks and months. If this excites you, please feel free to get involved with some of our current Bitcoin bounties, found [here](https://grants.urbit.org/bounties).

20To integrate Bitcoin with Urbit, we’re starting with the basics: a Bitcoin wallet and a Bitcoin node solution for Urbit. These tools will bring Urbit’s Bitcoin functionality from 0 to 1, and will serve as building blocks for our upcoming push from 1 to `n`. We’ll be sharing more about this in the coming weeks and months. If this excites you, please feel free to get involved with some of our current Bitcoin bounties, found [here](https://grants.urbit.org/bounties).

21+

content/blog/urbit-and-the-blockchain.md+80−85

@@ -1,13 +1,8 @@

1+++

1+++

2title = "Urbit and the Blockchain Wars"

2title = "Urbit and the Blockchain Wars"

3−date = "2017-09-24"

3+date = 2017-09-25

4description = "A bit about the 'idea maze' of choosing to bootstrap from Ethereum."

4description = "A bit about the 'idea maze' of choosing to bootstrap from Ethereum."

5−aliases = [

6− "/posts/essays/urbit-and-the-blockchain",

5+aliases = ["/posts/essays/urbit-and-the-blockchain", "/posts/urbit-and-the-blockchain", "/blog/2017.9-critique/"]

7− "/posts/urbit-and-the-blockchain",

8− "/blog/2017.9-critique/"

9−]

10−

11[extra]

6[extra]

12author = "Curtis Yarvin"

7author = "Curtis Yarvin"

13ship = "~sorreg-namtyv"

8ship = "~sorreg-namtyv"

@@ -16,34 +11,34 @@ image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/urbit-

16

11

17

12

18

13

19−One core principle of the Urbit network is that _Urbit doesn't take sides_.

14+One core principle of the Urbit network is that *Urbit doesn't take sides*.

20This is true in all kinds of conflicts -- and especially blockchain wars.

15This is true in all kinds of conflicts -- and especially blockchain wars.

21

16

22We're [moving the Urbit PKI onto Ethereum](https://urbit.org/blog/2017.9.20-bootstrapping-urbit-from-ethereum/)

17We're [moving the Urbit PKI onto Ethereum](https://urbit.org/blog/2017.9.20-bootstrapping-urbit-from-ethereum/)

23not because we like Ethereum, but because it's the most practical thing for

18not because we like Ethereum, but because it's the most practical thing for

24−Urbit right now. This is not a moral or aesthetic choice.

19+Urbit right now. This is not a moral or aesthetic choice.

25

20

26−Some have objected to this decision. Some of these objections are excellent.

21+Some have objected to this decision. Some of these objections are excellent.

27The rest are understandable.

22The rest are understandable.

28

23

29−Let's review our decision, responding to objections along the way. Not everyone

24+Let's review our decision, responding to objections along the way. Not everyone

30−has to agree on everything. No one should stay confused. And we welcome

25+has to agree on everything. No one should stay confused. And we welcome

31further comment.

26further comment.

32

27

33## Urbit is not endorsing or supporting Ethereum

28## Urbit is not endorsing or supporting Ethereum

34

29

35−There are many technical criticisms of Ethereum. We agree with many of these

30+There are many technical criticisms of Ethereum. We agree with many of these

36−criticisms -- even most. But still more important: Bitcoin is the strongest

31+criticisms -- even most. But still more important: Bitcoin is the strongest

37−chain. If Bitcoin could directly enforce Urbit's PKI rules, we'd use Bitcoin,

32+chain. If Bitcoin could directly enforce Urbit's PKI rules, we'd use Bitcoin,

38−for this reason alone. (That said, Ethereum may be less exposed to Chinese

33+for this reason alone. (That said, Ethereum may be less exposed to Chinese

39politics.)

34politics.)

40

35

41−We chose ETH because it is the strongest _computational_ chain. It is certainly

36+We chose ETH because it is the strongest *computational* chain. It is certainly

42stronger than the way we're storing the Urbit land registry now: GitHub, plus

37stronger than the way we're storing the Urbit land registry now: GitHub, plus

43internal records.

38internal records.

44

39

45−Urbit is not endorsing Ethereum. Urbit is not creating any appreciable monetary

40+Urbit is not endorsing Ethereum. Urbit is not creating any appreciable monetary

46−demand for Ethereum. Urbit is not even locked in to Ethereum: with a fully

41+demand for Ethereum. Urbit is not even locked in to Ethereum: with a fully

47self-governing constitution, the Urbit galaxies can decide to migrate to another

42self-governing constitution, the Urbit galaxies can decide to migrate to another

48consensus engine, or no consensus engine, or even our own consensus engine, any

43consensus engine, or no consensus engine, or even our own consensus engine, any

49time we like.

44time we like.

@@ -51,20 +46,20 @@ time we like.

51And even if the whole Ethereum network unexpectedly implodes, and stops

46And even if the whole Ethereum network unexpectedly implodes, and stops

52generating meaningful new blocks, we (or more generally: the set of active

47generating meaningful new blocks, we (or more generally: the set of active

53Urbit galaxies) cannot abandon the social power to manually hard-fork the

48Urbit galaxies) cannot abandon the social power to manually hard-fork the

54−network. Ultimately, the Ethereum contract is just a hardcoded address in a

49+network. Ultimately, the Ethereum contract is just a hardcoded address in a

55piece of Urbit source code.

50piece of Urbit source code.

56

51

57Let's address each of these points at a little more length.

52Let's address each of these points at a little more length.

58

53

59## On moving to a blockchain

54## On moving to a blockchain

60

55

61−The first point to remember: our choice wasn't between Ethereum and nothing. It

56+The first point to remember: our choice wasn't between Ethereum and nothing. It

62−wasn't between a blockchain and nothing. It was a choice between 21st-century

57+wasn't between a blockchain and nothing. It was a choice between 21st-century

63tools and 20th-century tools.

58tools and 20th-century tools.

64

59

65The current Urbit land registry is divided into parts stored in various places:

60The current Urbit land registry is divided into parts stored in various places:

66GitHub commits, database records held by Tlon Corporation, and insecure keys on

61GitHub commits, database records held by Tlon Corporation, and insecure keys on

67−a test network. This might have been fine, for us, in 2015. In 2017, it's

62+a test network. This might have been fine, for us, in 2015. In 2017, it's

68borderline unacceptable.

63borderline unacceptable.

69

64

70## On choosing a chain

65## On choosing a chain

@@ -73,31 +68,31 @@ Our first decision point: whether the public chain enforces the rules of Urbit,

73or just logs raw data that anyone can interpret.

68or just logs raw data that anyone can interpret.

74

69

75The simplest procedure, with the strongest blockchain, would be just to encode

70The simplest procedure, with the strongest blockchain, would be just to encode

76−each Urbit event as raw (OP_RETURN) data on the Bitcoin blockchain. Or we could

71+each Urbit event as raw (OP_RETURN) data on the Bitcoin blockchain. Or we could

77use another simple layer on top of Bitcoin; classic "colored coins," for

72use another simple layer on top of Bitcoin; classic "colored coins," for

78instance.

73instance.

79

74

80The resemblance between Urbit land-registry titles and colored coins is one we

75The resemblance between Urbit land-registry titles and colored coins is one we

81−noticed a long time ago, of course. For a long time it wasn't that relevant,

76+noticed a long time ago, of course. For a long time it wasn't that relevant,

82because colored coins remained largely theoretical.

77because colored coins remained largely theoretical.

83

78

84The larger problem is just that a non-computational blockchain can't enforce the

79The larger problem is just that a non-computational blockchain can't enforce the

85specific rules of the Urbit land registry (like the right of a star to create

80specific rules of the Urbit land registry (like the right of a star to create

86specific planets).

81specific planets).

87

82

88−You can put arbitrary data into a blockchain and enforce it off-chain. This

83+You can put arbitrary data into a blockchain and enforce it off-chain. This

89−strikes us as unsatisfactory, though. For instance, you have to define the

84+strikes us as unsatisfactory, though. For instance, you have to define the

90−semantics of erroneous or malformed operations. If this is not done perfectly,

85+semantics of erroneous or malformed operations. If this is not done perfectly,

91−it's a short road to major weirdness. Also, your interpretation tools are a

86+it's a short road to major weirdness. Also, your interpretation tools are a

92special-purpose one-off not shared with anyone.

87special-purpose one-off not shared with anyone.

93

88

94There are other second-order "virtualchains" (Blockstack is one example), which

89There are other second-order "virtualchains" (Blockstack is one example), which

95build computation layers on top of arbitrary chains. These tools are interesting

90build computation layers on top of arbitrary chains. These tools are interesting

96−and cool. They are also quite young. As is Urbit, so we need all the maturity

91+and cool. They are also quite young. As is Urbit, so we need all the maturity

97we can get.

92we can get.

98

93

99Also, our use case, as a land registry, is quite simple -- we don't have any

94Also, our use case, as a land registry, is quite simple -- we don't have any

100−desire to pay (in complexity) for power we don't use. A two-layer solution

95+desire to pay (in complexity) for power we don't use. A two-layer solution

101just seems to leave more room for bad weirdness.

96just seems to leave more room for bad weirdness.

102

97

103## As normal Urbit state?

98## As normal Urbit state?

@@ -105,122 +100,122 @@ just seems to leave more room for bad weirdness.

105The original design was for Urbit to host its own primary copy of the PKI state,

100The original design was for Urbit to host its own primary copy of the PKI state,

106not mirror some external master.

101not mirror some external master.

107

102

108−As more people start believing in Urbit, this makes us extremely nervous. Being

103+As more people start believing in Urbit, this makes us extremely nervous. Being

109the single source of truth implies a strong commitment to security and

104the single source of truth implies a strong commitment to security and

110−continuity. Urbit needs to get there, but it isn't there yet.

105+continuity. Urbit needs to get there, but it isn't there yet.

111

106

112Trust in the security, continuity, and general maturity of Urbit needs to

107Trust in the security, continuity, and general maturity of Urbit needs to

113−develop gradually. An Urbit that isn't ready to store crypto-assets can still

108+develop gradually. An Urbit that isn't ready to store crypto-assets can still

114−be a great product. But it can't be a great product if its supposedly valuable

109+be a great product. But it can't be a great product if its supposedly valuable

115keys are in fact insecure, yet needed to operate on the network.

110keys are in fact insecure, yet needed to operate on the network.

116

111

117−In short: we can't follow this original plan. It has the same chicken-egg

112+In short: we can't follow this original plan. It has the same chicken-egg

118problem we discussed [last time](https://urbit.org/blog/2017.9.20-bootstrapping-urbit-from-ethereum/).

113problem we discussed [last time](https://urbit.org/blog/2017.9.20-bootstrapping-urbit-from-ethereum/).

119

114

120## An Urbit consensus engine?

115## An Urbit consensus engine?

121

116

122−Urbit is itself a deterministic computer. Building a consensus computer within

117+Urbit is itself a deterministic computer. Building a consensus computer within

123Urbit, which is actually a general-purpose OS, is an attractive long-term

118Urbit, which is actually a general-purpose OS, is an attractive long-term

124possibility.

119possibility.

125

120

126But Urbit lacks the principal feature of Ethereum: deterministic performance.

121But Urbit lacks the principal feature of Ethereum: deterministic performance.

127In both Ethereum and Urbit, the semantics of a computation are precisely

122In both Ethereum and Urbit, the semantics of a computation are precisely

128−defined. In Ethereum, the computation's cost is also precisely defined.

123+defined. In Ethereum, the computation's cost is also precisely defined.

129

124

130−This would be quite hard to do in Urbit. We traded deterministic performance

125+This would be quite hard to do in Urbit. We traded deterministic performance

131−off for semantic simplicity. Designing a consensus computer without a

126+off for semantic simplicity. Designing a consensus computer without a

132performance definition is a research problem.

127performance definition is a research problem.

133

128

134−We have solved a number of research problems here at Urbit. Could we build an

129+We have solved a number of research problems here at Urbit. Could we build an

135−Urbit blockchain? This problem doesn't seem utterly intractable. For instance,

130+Urbit blockchain? This problem doesn't seem utterly intractable. For instance,

136we could leverage the semi-trusted hierarchy in some direction resembling proof

131we could leverage the semi-trusted hierarchy in some direction resembling proof

137of stake.

132of stake.

138

133

139One thing is certain, though: research problems don't solve themselves

134One thing is certain, though: research problems don't solve themselves

140−overnight. If you have any ideas on this one, give us a holler.

135+overnight. If you have any ideas on this one, give us a holler.

141

136

142In any case, if Urbit got its own consensus engine, it's obvious that we'd

137In any case, if Urbit got its own consensus engine, it's obvious that we'd

143−simply copy the state of the Urbit PKI on Ethereum, and shut it down. Or we

138+simply copy the state of the Urbit PKI on Ethereum, and shut it down. Or we

144could migrate to another computational blockchain which works better than

139could migrate to another computational blockchain which works better than

145Ethereum.

140Ethereum.

146

141

147## An existing computational blockchain

142## An existing computational blockchain

148

143

149−So we need an existing, mature, computational blockchain. There are only two

144+So we need an existing, mature, computational blockchain. There are only two

150major candidates: ETH and ETC (Ethereum Classic).

145major candidates: ETH and ETC (Ethereum Classic).

151

146

152−It's no secret that we prefer the governance model of ETC. It's also no secret

147+It's no secret that we prefer the governance model of ETC. It's also no secret

153that the whole Ethereum system, especially Solidity, isn't exactly put together

148that the whole Ethereum system, especially Solidity, isn't exactly put together

154in the way we would do it.

149in the way we would do it.

155

150

156But an optimal governance model is just one virtue among many others we need to

151But an optimal governance model is just one virtue among many others we need to

157−consider. ETH's network capitalization is 25x that of ETC. Its hashrate is 15x.

152+consider. ETH's network capitalization is 25x that of ETC. Its hashrate is 15x.

158Its tooling support -- in software, hardware, vaulting, exchanging, etc -- is

153Its tooling support -- in software, hardware, vaulting, exchanging, etc -- is

159considerably stronger.

154considerably stronger.

160

155

161−ETC's governance model is Bitcoin's: code is law. For the network, this is

156+ETC's governance model is Bitcoin's: code is law. For the network, this is

162−better. But we are considering threats to Urbit, not threats to the rest of

157+better. But we are considering threats to Urbit, not threats to the rest of

163Ethereum.

158Ethereum.

164

159

165−ETH has embraced discretionary human governance. It's quite plausible that this

160+ETH has embraced discretionary human governance. It's quite plausible that this

166−will lead to total political collapse. But the human political structure of ETH

161+will lead to total political collapse. But the human political structure of ETH

167−seems reasonably strong at the moment. It's relatively difficult to imagine

162+seems reasonably strong at the moment. It's relatively difficult to imagine

168−successful, near-term "proof of Vitalik" attacks via Ethereum on Urbit. Political

163+successful, near-term "proof of Vitalik" attacks via Ethereum on Urbit. Political

169conflict tends to develop over longer periods of time, giving us room to migrate.

164conflict tends to develop over longer periods of time, giving us room to migrate.

170

165

171Ultimately we decided that the minority power of ETC outweighs the governance

166Ultimately we decided that the minority power of ETC outweighs the governance

172−issues with ETH. This is of course how imperfect standards win. Betamax had

167+issues with ETH. This is of course how imperfect standards win. Betamax had

173better resolution than VHS.

168better resolution than VHS.

174

169

175## One reminder

170## One reminder

176

171

177For Bitcoin maximalists in particular (some of our best friends are Bitcoin

172For Bitcoin maximalists in particular (some of our best friends are Bitcoin

178maximalists), it's important to note that (besides the gas price of

173maximalists), it's important to note that (besides the gas price of

179−transactions) putting Urbit on Ethereum _does not create any net monetary demand

174+transactions) putting Urbit on Ethereum *does not create any net monetary demand

180−for Ethereum_.

175+for Ethereum*.

181

176

182−Yes, you will get an Urbit ship through an Ethereum transaction. However, no

177+Yes, you will get an Urbit ship through an Ethereum transaction. However, no

183−value stays in ether. If you want to buy a ship with bitcoin, you are just

178+value stays in ether. If you want to buy a ship with bitcoin, you are just

184−going through a conversion layer. These conversion layers work pretty well

179+going through a conversion layer. These conversion layers work pretty well

185−these days. If you have a religious objection to handling altcoins, have a

180+these days. If you have a religious objection to handling altcoins, have a

186friend help.

181friend help.

187

182

188Bitcoin maximalists understand that all monetary energy should concentrate in a

183Bitcoin maximalists understand that all monetary energy should concentrate in a

189−single currency. But land isn't money. And the technical details of the

184+single currency. But land isn't money. And the technical details of the

190implementation of the Urbit registry -- whether `OP_RETURN`, Ethereum, or GitHub

185implementation of the Urbit registry -- whether `OP_RETURN`, Ethereum, or GitHub

191-- have no effect on Bitcoin supply and demand.

186-- have no effect on Bitcoin supply and demand.

192

187

193## Another reminder

188## Another reminder

194

189

195−Ethereum is not using Urbit. Urbit is using Ethereum. We know every cool

190+Ethereum is not using Urbit. Urbit is using Ethereum. We know every cool

196alternative band that gets signed to a major label says this, but we mean it.

191alternative band that gets signed to a major label says this, but we mean it.

197

192

198Urbit, as a land registry, is almost a textbook example of very weak, boring use

193Urbit, as a land registry, is almost a textbook example of very weak, boring use

199−of a computational blockchain. We're not expecting a lot out of Ethereum.

194+of a computational blockchain. We're not expecting a lot out of Ethereum.

200Ethereum does not feel like a system whose technical envelope should be pushed.

195Ethereum does not feel like a system whose technical envelope should be pushed.

201We have no intention of pushing it.

196We have no intention of pushing it.

202

197

203Moreover, the ability to vote formally in an Ethereum constitution will allow us

198Moreover, the ability to vote formally in an Ethereum constitution will allow us

204−to migrate in a cohesive way to _any other formalization of the Urbit PKI_.

199+to migrate in a cohesive way to *any other formalization of the Urbit PKI*.

205−This could be another Ethereum contract. Or another blockchain.

200+This could be another Ethereum contract. Or another blockchain.

206

201

207This "clean escape" implies that Ethereum is still operating normally, or at

202This "clean escape" implies that Ethereum is still operating normally, or at

208−least normally enough to conduct a galaxy vote. What could happen to Ethereum?

203+least normally enough to conduct a galaxy vote. What could happen to Ethereum?

209The blockchain could stop generating new blocks; it could fork; it could be

204The blockchain could stop generating new blocks; it could fork; it could be

210−filtered by some kind of collective attacker; it could even start accepting invalid transactions. What seems implausible is destruction of all copies of the whole chain.

205+filtered by some kind of collective attacker; it could even start accepting invalid transactions. What seems implausible is destruction of all copies of the whole chain.

211

206

212When Ethereum ceases to be functional or trustworthy for any reason, a "dirty

207When Ethereum ceases to be functional or trustworthy for any reason, a "dirty

213−escape" becomes necessary. The galaxy operators need to identify the last point

208+escape" becomes necessary. The galaxy operators need to identify the last point

214in the Ethereum chain at which the Urbit constitution remains valid, copy that

209in the Ethereum chain at which the Urbit constitution remains valid, copy that

215data to the new primary record, and resume from there.

210data to the new primary record, and resume from there.

216

211

217But unlike other blockchains that have wrestled with human-centric governance,

212But unlike other blockchains that have wrestled with human-centric governance,

218−Urbit still has a formal procedure for making this decision. With the Ethereum

213+Urbit still has a formal procedure for making this decision. With the Ethereum

219chain compromised, we no longer have an automated system that implements the

214chain compromised, we no longer have an automated system that implements the

220−rules. The rules remain, though. Humans have spent thousands of years

215+rules. The rules remain, though. Humans have spent thousands of years

221following non-automated rules.

216following non-automated rules.

222

217

223−Basically, we're just using ETH as a self-validating ownership record. So long

218+Basically, we're just using ETH as a self-validating ownership record. So long

224as the chain isn't destroyed and owners retain their secrets, Urbit retains the

219as the chain isn't destroyed and owners retain their secrets, Urbit retains the

225power to migrate to any record that works better.

220power to migrate to any record that works better.

226

221

@@ -234,30 +229,30 @@ the Urbit PKI at all.

234

229

235In Urbit, if your parent galaxy is sending you fraudulent reports about the

230In Urbit, if your parent galaxy is sending you fraudulent reports about the

236blockchain (any blockchain), you have a very serious problem which goes way

231blockchain (any blockchain), you have a very serious problem which goes way

237−past blockchains. It's time to switch galaxies.

232+past blockchains. It's time to switch galaxies.

238

233

239The trust relationship between an urbit and its parent is like the trust

234The trust relationship between an urbit and its parent is like the trust

240−relationship between you and a gas station. For all you know, what's coming

235+relationship between you and a gas station. For all you know, what's coming

241−out of the hose could be Welch's grape juice. But why have you never, ever worried about cheap surplus vegetable products destroying your engine?

236+out of the hose could be Welch's grape juice. But why have you never, ever worried about cheap surplus vegetable products destroying your engine?

242

237

243−ExxonMobil has no business motivation to ruin its customers' engines. If it

238+ExxonMobil has no business motivation to ruin its customers' engines. If it

244−did, it would just destroy its business, and gain… what? If you don't have an

239+did, it would just destroy its business, and gain… what? If you don't have an

245−attack motivation, you don't have a threat model. If you don't have a threat

240+attack motivation, you don't have a threat model. If you don't have a threat

246−model, you don't have a threat. This is why we don't tend to worry about

241+model, you don't have a threat. This is why we don't tend to worry about

247"parent attacks" in Urbit.

242"parent attacks" in Urbit.

248

243

249But that said: there's no reason not to make Urbit's cryptographic structure as

244But that said: there's no reason not to make Urbit's cryptographic structure as

250−strong as possible. If you don't want to trust your gas station -- you

245+strong as possible. If you don't want to trust your gas station -- you

251−shouldn't have to. We don't need to eliminate reliance on trust. We do prefer

246+shouldn't have to. We don't need to eliminate reliance on trust. We do prefer

252−to _minimize_ it.

247+to *minimize* it.

253

248

254Therefore, the Urbit Ethereum mirror needs to track all the Ethereum

249Therefore, the Urbit Ethereum mirror needs to track all the Ethereum

255transactions that touch the Urbit constitution, and propagate these raw

250transactions that touch the Urbit constitution, and propagate these raw

256−transactions into Urbit. Urbit nodes can check the transactions and their

251+transactions into Urbit. Urbit nodes can check the transactions and their

257−signatures themselves, without relying on Ethereum. Then, anyone in Urbit can

252+signatures themselves, without relying on Ethereum. Then, anyone in Urbit can

258validate the Urbit PKI without an Ethereum node.

253validate the Urbit PKI without an Ethereum node.

259

254

260−(We don't anticipate running a node _in_ Urbit, eg an EVM in Hoon -- for now,

255+(We don't anticipate running a node *in* Urbit, eg an EVM in Hoon -- for now,

261galaxies will just RPC to a local Unix node.)

256galaxies will just RPC to a local Unix node.)

262

257

263## And in closing

258## And in closing

@@ -265,7 +260,7 @@ galaxies will just RPC to a local Unix node.)

265We appreciate everyone's feedback and hope no one remains confused.

260We appreciate everyone's feedback and hope no one remains confused.

266

261

267We're happy to address any remaining concerns -- and happier still if someone

262We're happy to address any remaining concerns -- and happier still if someone

268−finds a mistake on our end. If you have a good counterargument, now is better

263+finds a mistake on our end. If you have a good counterargument, now is better

269than later!

264than later!

270

265

271Fora thread for discussion is here:

266Fora thread for discussion is here:

content/blog/urbit-creator-daos.mddeleted−74

@@ -1,74 +0,0 @@

1−+++

2−title = "Urbit + Creator DAOs with Justin Murphy"

3−date = "2022-10-05"

4−description = "Creator DAOs are blank slates, new foundational cryptographic patterns just beginning to take shape. Justin Murphy thinks Urbit is the most obvious place to start building one."

5−

6−[extra]

7−author = "Isaac Simpson"

8−ship = "~mogmet-tadnem"

9−image = "https://storage.googleapis.com/media.urbit.org/blog/creatordao-3.jpg"

10−+++

11−

12−

13−<div style="font-size:13px; text-align: center; color: #999">Photo by <a href="https://unsplash.com/@nathynmasters

14−">Nathyn Masters</a></div>

15−

16−# Other Life: Proto Creator DAO

17−

18−Justin Murphy runs a creator network. As a thinker, writer, and podcaster, he works to grow value within this network in order to stay independent. No ads. No branded content. Just varying degrees of membership, with members enjoying private channels and cohort-based courses all under the header “Philosophy and technology for the ungovernable.”

19−

20−Murphy’s “personal media company,” called Other Life, is composed of a newsletter, podcast, Youtube channel. It also extends to Urbit; [Other Life](https://urbit.org/groups/~hatryx-lastud/other-life) is one of the largest groups on the network. Followers and friends of Other Life create and share their own work within the network, aided by a catalog of courses. Murphy’s next logical step is building what we’re calling a Creator DAO: all the same stuff, but instead of a la carte memberships you secure your spot via ERC-20 tokens. In exchange, you get access to all levels of his community and content and attain the rights and responsibilities inherent to any DAO member.

21−

22−

23−

24−Since Creator DAOs are blank slates, primordial cryptographic objects just beginning to take shape, Murphy thinks Urbit is the most obvious place to start building one. Urbit lets creators spin up flexible DAOs to find, manage, keep members engaged in entirely new ways.

25−

26−

27−# Democratized Publishing

28−

29−In contrast to centralized programs like Discord, Urbit offers creators far more flexibility in interacting with their fanbases. Say, for example, you want to set up a trustless contribution program for guest writers. The Urbit app [Straw](https://urbit.org/applications/~pocwet/straw) supports group curation with voting on proposed articles. To increase guest engagement and expand participation while also maintaining quality control, Murphy can use Straw to initiate votes on his own pieces or potential guest pieces, which automates publication to the clear web when a vote passes.

30−

31−“Imagine I want to publish to the [Studio](https://urbit.org/applications/~tirrel/studio) newsletter, and when I go to click publish it first gets sent as a proposal to Straw, and it only actually gets published if a majority of the group agree that it passes the quality bar. As Straw develops, you can imagine that if the proposal is passed, two things happen. One: the post in the Urbit notebook gets sent to the email newsletter through Studio. Two: money is transferred.”

32−

33−Indeed, future functionality will enable automated payments after publication.

34−

35−

36−<div style="font-size:13px; text-align: center; color: #999;">The Straw App</div>

37−

38−“I’ll offer bounties, making a list of topics that I want people in the group to write about,” says Murphy. “They can publish permissionlessly to the group blog, through Studio and anyone in the group could potentially publish on any set of topics, kind of replicating a multi-author magazine.”

39−

40−Straw opens up a whole new way to decide what—and who—creators publish next. We’re the last to advocate art-by-democracy, but the potential is huge.

41−

42−# Decentralized Kicking and Adding

43−

44−Urbit also offers a novel solution with regards to vetting group members and weeding out bad ones. As Murphy points out, Holium’s Urbit app Ballot—which works like a decentralized [Snapshot](https://snapshot.org/#/) for Urbit Groups—allows creators to decentralize the expulsion process. A shift which many who run creator networks would much prefer.

45−

46−> If someone makes a proposal in [Ballot](https://urbit.org/applications/~lomder-librun/ballot), and maybe the owner gets to decide the threshold where if a certain amount of people want to kick someone out, they're kicked. It's actually a really annoying burden, in some ways, to know who to kick out. How bad does someone have to bet? You can have all the rules and regulations you want and try to be as objective as possible, but ultimately the owners and the admins have to use their judgment to decide. I would frankly much rather not have that responsibility. I would love for it to be hardwired such that only a super majority, or something like that, could do it. You can imagine that as a custom action on Ballot.

47−

48−One can imagine this custom action with a combination of Ballot and the [Forms](/applications/~donpub-datdux/forms) app. Since the form data is all on Urbit, it would be a simple matter for an app like Ballot to automatically access that information. With a few forms to vote on membership, this would make adding members equally simple, automated, and trustless as kicking them.

49−

50−“I think the Forms App is cool. You can use it on certain channels where if you want to get in, you fill out a form, then it's evaluated by Ballot. So the content of a form submission gets plugged into a proposal. People vote on the information supplied in the form and if the vote is approved, then the person gets added to the channel or group.”

51−

52−# An Owned Space

53−

54−These use cases help with DAO flexibility, usability, and decentralized automation. But another important reason to build a DAO on Urbit is that you’re building your network on P2P “real estate.” On Urbit, both creators and their communities own the address space and every action taken in it—it can’t be canceled or deleted or made inoperable, a far cry from other platforms where you can be suspended for arbitrary Terms of Service violations.

55−

56−“The main positive is you and your community getting to own the real estate that you operate on,” says Murphy. No other app, even dapps like Agora or Snapshot, allows for a genuinely P2P offchain operating environment. Your Urbit ID is self-owned and portable, and you build your community P2P. Your creations are yours and you can continue building them without corporate middlemen ripping your canvas out from under you, or changing your tools or access without notice.

57−

58−

59−<div style="font-size:13px; text-align: center; color: #999">~hatryx-lastud/other-life</div>

60−

61−Furthermore, the more work you put into building your Creator DAO on Urbit, the more valuable the Urbit address space becomes. When you use Facebook, you’re relegated to the role of a content serf. The more you produce, the more Facebook grows in value. On Urbit, the more your produce, the more Urbit grows in value—and you are an owner of Urbit.

62−

63−

64−<div style="font-size:13px; text-align: center; color: #999">Murphy already offers his members access to the Other Life urbit group.</div>

65−

66−Finally, Murphy cites Urbit’s durability.

67−

68−> The second most important Urbit trait after ownership is durability. The creator economy tools change all the time. Every time you try to move your people from one new app to another app, you lose a lot, right? You want to be an influencer, you want to be an important thinker and speaker. All of a sudden, you’ve got to be on Clubhouse! This means telling the people on your newsletter, telling your Patreon subscribers, telling the people on your podcast, hey, download this cool new app called Clubhouse and find me there. It's going to be awesome. It's so cringe and corny and only a small number of them will even make it over there. Then all of a sudden, no one's on Clubhouse and no one wants to use Clubhouse anymore. This is a major problem for people navigating the creator economy. I think one of the big selling points of Urbit is—this is the one place that I’ll always be. I (will have) been working on my Urbit for over 10 years. This thing is going to be the nuclear bunker of the internet.

69−

70−Creator DAOs are perhaps the smallest, most nimble type of DAO—a creator, his followers, and the content they share between them. For that reason, they’ve been underplayed as archetypal DAOs. But their small size and flexibility may make them the perfect candidate to realize the possibilities of immensely improved DAO experiences.

71−

72−—

73−

74−*Isaac Simpson is a Los Angeles based writer and the founder of the marketing agency [WILL](https://willtheagency.com/). You can read his work on his substack [The Carousel](https://thecarousel.substack.com/).*

content/blog/urbit-for-creators.mddeleted−47

@@ -1,47 +0,0 @@

1−+++

2−title = "Urbit Is for Creators"

3−date = "2021-12-09"

4−description = "Urbit is for creators who are ready to wake up from this bad dream."

5−[extra]

6−author = "Noah Kumin"

7−ship = "~librex-dozryc"

8−image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/romi%20creators%20blog.jpeg"

9−+++

10−

11−

12−

13−It’s no secret that there are huge problems with the way content is distributed on the internet today. Even five years ago these issues hadn’t quite hit the mainstream: the ability of platforms to capriciously alter their terms of service, the corrosive effects of algorithms designed to siphon off as much of our attention as possible, the uncanny effects of a world where tech companies arbitrate truth with behind-the-scenes moderation policies. Although they’re now discussed pretty openly, the horrid effects of this system actually tend to be _understated._ “If you’re not paying for it, you’re not the customer, you’re the product” has become a truism. And yet, as _You Are Not a Gadget_ author Jaron Lanier puts it, it’s not quite specific enough to say that _you_ are the product. Rather, “it’s the gradual, slight, imperceptible change in your own behavior and perception that is the product.”

14−

15−This product is selling very well, and it has seeped its way fully into the world of content creation, or what might once have been called the arts. Although it’s not so widely publicized, [Tik Tok basically runs the popular music industry at this point](https://www.browndailyherald.com/article/2021/09/for-better-or-worse-tiktok-is-driving-the-music-industry). Meanwhile, platforms like Spotify or YouTube filter what we see by deprecating the “long tails” of content. That is, if you’re searching for a tune on Spotify, it brings Spotify more profit, on average, to design a search feature that will automatically bring you to the most popular songs, even if you were really looking for less popular ones. The same goes for books, which are now purchased mostly according to the algorithm, and not according to what a person might stumble upon in a bookshop. (The upshot: expect more [cookbooks from Snoop Dogg](https://www.nytimes.com/2021/04/18/books/book-sales-publishing-pandemic-coronavirus.html), and fewer titles from authors who are not already celebrities.) Products such as Tik Tok, Spotify, YouTube, and Amazon like for you to think that they’re mere distributors of content. But actually they’re _producers_, and they’re producing the smarmy, anodyne style that has homogenized the globe.

16−

17−Urbit is for creators who are ready to wake up from this bad dream.

18−

19−The vibe of today’s internet applications—manipulative, erratic, overcomplicated, overbearing, and highly detrimental to society—is in contrast to the mechanics of the creator economy itself, which can actually be blissfully simple. In 2008 Kevin Kelley made famous the concept of “[1000 true fans](https://kk.org/thetechnium/1000-true-fans/).” That is, to make a living as a creator, you only need 1,000 fans who are interested enough to buy whatever you produce. Even $6.00 or $7.00 a month from such true fans is a boon for a creator—assuming not too much of that cash gets taken away by middlemen, and that fans can discover work from outside the corporate monoculture in the first place.

20−

21−In a limited sense, this 1,000 true fans model is already working. Creators with fanbases of the size Kelly imagined are able to use Patreon or YouTube or what-have-you to monetize their content. But the problem is, those platforms are not really peer-to-peer. Your fans aren’t your own: they belong to the platform. And with the big tech platforms running the show, we end up with the problems described above.

22−

23−To those of us who are interested in seeing a thriving culture of artists, musicians, podcasters and writers which is human-centered via a p2p network, rather than being brokered, managed, and manipulated, by the most venal and tasteless of data collectors and profiteers, it likely seems like the world of the arts has gone bottom-up. Urbit is for any creators who are ready to put it back on its feet again.

24−

25−Urbit is a peer-to-peer network designed to serve as simple, durable neutral infrastructure for whoever wants to build something on it. Like everything else on Urbit, creator content goes directly to the people it’s supposed to go to. No middlemen, no MEGACORP data mining, no capricious terms of service, no obscure algorithms determining what gets seen and what doesn’t. This is the zero-to-one shift that makes Urbit the natural destination for creators who want to both _own_ their work and share it.

26−

27−Urbit has already seen several communities get excited about the ways Urbit could help them fulfill their goals. Here are just a few examples:

28−

29−[HOLDERSLAND](https://twitter.com/holdersland), founded by Haleek Maul, a musician, music label owner, and NFT creator based in Barbados. Maul recently [sold](https://urbit.holders.land) a set of customized Urbit NFT artwork, which came bundled with actual Urbit IDs.

30−

31−[Other Life](https://www.otherlife.co), a community of philosophers and creators founded by the entrepreneurial Justin Murphy.

32−

33−[The Stack](https://orbisledger.news/), an entertaining and informative podcast with a decidedly Urbit flavor, hosted by Josh and Andy.

34−

35−[door.link](https://www.door.link), a vibey and idiosyncratic music collective.

36−

37−[Wet Brain](https://www.patreon.com/wetbrain), a numinous, post-everything New York podcast, hosted by Honor and Walt.

38−

39−Internet Weirdness Task Force, which has no legacy internet site to link to, so you’ll just have to get on Urbit to scope it out.

40−

41−Over the last ten years, we’ve already had a taste of what blockchains can do: they’re great so far for distributing a financial ledger so that payments are no longer centralized. But for online communities to go truly peer-to-peer and escape the grip of corporations, they’re going to need something like Urbit. As HOLDERSLAND founder Haleek Maul [puts it](https://urbit.org/blog/haleek-maul-interview) in a recent Q&A, decentralized technologies like blockchain or Urbit “allow . . . new financial relationships and funding structures to emerge. Rather than have a few people contribute $20k, you can have hundreds of people contribute $100.” In such a system, recording artists no longer need to hunt for a deal from sharky impresarios; their communities can comprise both the talent _and_ the executives. They no longer need to pay fealty to streaming services; they can sell their wares peer-to-peer, with the old-fashioned connoisseurship of a cool record shop, except that this record shop is available to anyone across the globe.

42−

43−Urbit makes this dream a real possibility. In an Urbit future, utilizing your own personalized payments system, which could take either fiat or crypto, should be as easy as sending or receiving money on apps like Venmo or Cash App is today. If _anyone_ can make a direct peer-to-peer payment to anyone else on the network, if _anyone_ can send a piece of writing or audio or video clip in a peer-to-peer way to anyone else on the network, then you’ve truly laid the groundwork for autonomous organizations of creators.

44−

45−Beyond that, Urbit is one of the very few platforms looking, with seriousness and deep technical consideration, into the distant future. Whereas no one can say whether a mainstream platform like Facebook or Twitter will even _exist_ in ten years (think just how much writing will disappear if those servers do shut down), Urbit is built with maximum durability in mind: one way to think of your urbit computer is as a [100-year computer](https://urbit.org/blog/the-100-year-computer). Whereas most software today is designed to break quickly and be replaced quickly, due to the instability of all of modern computing’s complex interlocking parts, Urbit was built as an overlay operating system, so that it can work no matter what’s running underneath, and thus serve as a resilient, permanent home for your digital world.

46−

47−Computers can still be used as magical tools for creative individuals, instead of as attention-draining machines—if that is indeed the future we want. For creators, the solution to the ever-growing problems of the internet is not in the hands of any national government, or some new application that mimics the architecture of old applications, or through some impracticable system of reduced screen time. The solution to these problems is, and always has been, to build a whole new system that works _for_ the people instead of against them. That’s what Urbit is here to do.

content/blog/urbit-for-normies.md+59−57

@@ -1,175 +1,177 @@

1+++

1+++

2title = "Urbit for Normies"

2title = "Urbit for Normies"

3−date = "2020-02-11"

3+date = 2020-02-12

4description = "A layperson’s guide to the coming new internet."

4description = "A layperson’s guide to the coming new internet."

5−

6[extra]

5[extra]

7author = "Erik Newton"

6author = "Erik Newton"

8ship = "~patnes-rigtyn"

7ship = "~patnes-rigtyn"

9−image = "https://media.urbit.org/site/posts/essays/normies-2.png"

8+image ="https://media.urbit.org/site/posts/essays/normies-2.png"

10+++

9+++

11

10

12Urbit is a challenging project to fully describe because, rather than a single product, it’s an entire system. Often when I talk about one of the individual elements of the system, someone will tell me that another company is already building that — and they’re usually right. What sets Urbit apart is that we’re building all these elements at once to work together seamlessly.

11Urbit is a challenging project to fully describe because, rather than a single product, it’s an entire system. Often when I talk about one of the individual elements of the system, someone will tell me that another company is already building that — and they’re usually right. What sets Urbit apart is that we’re building all these elements at once to work together seamlessly.

13

12

14−For that reason, this overview is long. I wanted to explain, at a very high level, as much of the system as possible, to share an image of the entire forest rather than spending too much time on any of the trees.

13+For that reason, this overview is long. I wanted to explain, at a very high level, as much of the system as possible, to share an image of the entire forest rather than spending too much time on any of the trees.

15

14

16My own path to Urbit was not predictable, so it turns out I’m a useful ambassador to describe what the heck we’re doing to my fellow normies.

15My own path to Urbit was not predictable, so it turns out I’m a useful ambassador to describe what the heck we’re doing to my fellow normies.

17

16

18I refer to myself as a normie because I’m a lawyer by training, not the typical code-savvy early Urbit adopter. I ran a law firm and, after retiring, founded a podcast and magazine about relationship dynamics. During that time I came to believe that humanity was in desperate need of better ways to relate. I didn’t know how, but I knew that my podcast about romance wasn’t going to move the needle. I began to look for a bigger project. I wanted something I truly could invest myself in; something that could have a real impact on this problem.

17I refer to myself as a normie because I’m a lawyer by training, not the typical code-savvy early Urbit adopter. I ran a law firm and, after retiring, founded a podcast and magazine about relationship dynamics. During that time I came to believe that humanity was in desperate need of better ways to relate. I didn’t know how, but I knew that my podcast about romance wasn’t going to move the needle. I began to look for a bigger project. I wanted something I truly could invest myself in; something that could have a real impact on this problem.

19

18

20−That’s when a friend introduced me to Urbit. Saying it was the most credible project he’d seen in years, he described it as “an open-source decentralized internet project,” and that it “would give control of computing back to regular people.” That sparked my interest, but I didn’t totally understand it. After looking over the website and watching a couple of obscure descriptive videos on YouTube my response was threefold:

19+That’s when a friend introduced me to Urbit. Saying it was the most credible project he’d seen in years, he described it as “an open-source decentralized internet project,” and that it “would give control of computing back to regular people.” That sparked my interest, but I didn’t totally understand it. After looking over the website and watching a couple of obscure descriptive videos on YouTube my response was threefold:

21

20

22−1. **This is huge** — if it actually works, it’s the future.

21+1) **This is huge** — if it actually works, it’s the future.

23−2. **This is real** — It’s got working code, dozens of engineers, and a very unorthodox solution.

22+2) **This is real** — It’s got working code, dozens of engineers, and a very unorthodox solution.

24−3. **I don’t truly understand this** — I can’t read the code, and I can barely comprehend the paradigm shift.

23+3) **I don’t truly understand this** — I can’t read the code, and I can barely comprehend the paradigm shift.

25

24

26So of course I asked for an intro.

25So of course I asked for an intro.

27

26

28−Fast forward: I ended up becoming COO at Tlon, the primary developer of Urbit. Urbit is exactly the sort of project I was looking for — one that represents an important promise for humanity. But, boy, did I have to fake my way through the technical elements of my new job those first few months.

27+Fast forward: I ended up becoming COO at Tlon, the primary developer of Urbit. Urbit is exactly the sort of project I was looking for — one that represents an important promise for humanity. But, boy, did I have to fake my way through the technical elements of my new job those first few months.

29

28

30−What I eventually came to realize is that if Urbit is only accessible to programmers, it’s dead on arrival. In order to be useful, Urbit has to be understandable by the non-technical user. Like me. And maybe like you.

29+What I eventually came to realize is that if Urbit is only accessible to programmers, it’s dead on arrival. In order to be useful, Urbit has to be understandable by the non-technical user. Like me. And maybe like you.

31

30

32I understand as well as anyone how complicated Urbit can appear. But, fundamentally, Urbit is quite simple and it promises a critical upgrade to human interaction. That might sound like hyperbole but it’s the reason I work here. This is my attempt to explain to fellow normies the scope and scale of this world-changing project called Urbit.

31I understand as well as anyone how complicated Urbit can appear. But, fundamentally, Urbit is quite simple and it promises a critical upgrade to human interaction. That might sound like hyperbole but it’s the reason I work here. This is my attempt to explain to fellow normies the scope and scale of this world-changing project called Urbit.

33

32

33+

34## What is Urbit?

34## What is Urbit?

35

35

36Let’s take this one step at a time and start with the most basic definition:

36Let’s take this one step at a time and start with the most basic definition:

37

37

38−Urbit is a peer-to-peer internet being built from scratch to be more private, secure, and durable than the current internet.

38+Urbit is a peer-to-peer internet being built from scratch to be more private, secure, and durable than the current internet.

39

39

40At its most basic level, an Urbit is:

40At its most basic level, an Urbit is:

41

41

42−1. A super-private computer, combined with

42+1) A super-private computer, combined with

43−2. an ID, which is

43+2) an ID, which is

44−3. connected peer-to-peer with other Urbit computers.

44+3) connected peer-to-peer with other Urbit computers.

45

45

46−Taking that a half-step deeper, each Urbit user gets a permanent identity, which allows them to access their personal computer in the cloud, and then talk to directly with other Urbit computers (i.e. other people) on the network, all without using an intermediary.

46+Taking that a half-step deeper, each Urbit user gets a permanent identity, which allows them to access their personal computer in the cloud, and then talk to directly with other Urbit computers (i.e. other people) on the network, all without using an intermediary.

47

47

48When I say “computer” I’m not talking about a physical device, but rather the software that computes. Urbit is a virtual computer, not a hardware device. Today that means you can access your Urbit computer from anywhere, on just about any device with a web browser. Eventually you won’t even need the web browser.

48When I say “computer” I’m not talking about a physical device, but rather the software that computes. Urbit is a virtual computer, not a hardware device. Today that means you can access your Urbit computer from anywhere, on just about any device with a web browser. Eventually you won’t even need the web browser.

49

49

50By “intermediary” I’m talking about all those centralized servers that we use every day to do our computing. Servers owned by Google, Facebook, YouTube, Instagram, Twitter, Slack, Amazon, Nest, Apple, and so on. All of these companies and products keep close tabs on our activity and use that information to sell us things and influence our opinions. Everything we do online is watched and recorded.

50By “intermediary” I’m talking about all those centralized servers that we use every day to do our computing. Servers owned by Google, Facebook, YouTube, Instagram, Twitter, Slack, Amazon, Nest, Apple, and so on. All of these companies and products keep close tabs on our activity and use that information to sell us things and influence our opinions. Everything we do online is watched and recorded.

51

51

52−Urbit will fundamentally change that — more about the privacy implications later.

52+Urbit will fundamentally change that — more about the privacy implications later.

53

53

54−

54+<img class="ba" src="https://media.urbit.org/site/posts/essays/normies-1.png">

55

55

56## What it looks like

56## What it looks like

57

57

58Another way of explaining Urbit is to describe how it feels and looks. Visually, Urbit belongs to a genre often called “calm computing.” Urbit is designed to be simple, basic, and non-addictive. You won’t find any flashy-blinky lights here; no zany colors; no wacky branding. Just calm, functional, purpose-built tools for people to connect and work together. (One of my favorite examples of calm computing is the [light phone](https://www.thelightphone.com/).)

58Another way of explaining Urbit is to describe how it feels and looks. Visually, Urbit belongs to a genre often called “calm computing.” Urbit is designed to be simple, basic, and non-addictive. You won’t find any flashy-blinky lights here; no zany colors; no wacky branding. Just calm, functional, purpose-built tools for people to connect and work together. (One of my favorite examples of calm computing is the [light phone](https://www.thelightphone.com/).)

59

59

60−Today Urbit’s interface looks like a tab in your web browser that has some limited functionality (chat, a weather app, a notebook, link sharing). Soon, you won’t even need the web browser — you’ll be able to access or run Urbit directly in its own window. Inside will be a super clean interface with all the functionality you might want from your computer, in one place and with one login (think document creation, email, social media access, accounting) — but it will run on your virtual Urbit computer, so it will be safe from corporate prying and data leaks, available on any device, and all inside one simple interface.

60+Today Urbit’s interface looks like a tab in your web browser that has some limited functionality (chat, a weather app, a notebook, link sharing). Soon, you won’t even need the web browser — you’ll be able to access or run Urbit directly in its own window. Inside will be a super clean interface with all the functionality you might want from your computer, in one place and with one login (think document creation, email, social media access, accounting) — but it will run on your virtual Urbit computer, so it will be safe from corporate prying and data leaks, available on any device, and all inside one simple interface.

61

61

62## What it’s for

62## What it’s for

63

63

64−Fundamentally, Urbit is neutral open-source infrastructure, so it can be for many things. From our highest level perspective Urbit is computing for real communities and normal people, not for corporations. To make that real, Urbit focuses on delivering a computing experience that is secure, private, durable, and calm.

64+Fundamentally, Urbit is neutral open-source infrastructure, so it can be for many things. From our highest level perspective Urbit is computing for real communities and normal people, not for corporations. To make that real, Urbit focuses on delivering a computing experience that is secure, private, durable, and calm.

65

65

66−For me, Urbit’s core purpose is to give us all back our privacy and our autonomy. It’s time for humanity to control its tools rather than the other way around.

66+For me, Urbit’s core purpose is to give us all back our privacy and our autonomy. It’s time for humanity to control its tools rather than the other way around.

67

67

68## Key elements

68## Key elements

69

69

70−One potential barrier to understanding Urbit is that we’re building out multiple layers of this new internet simultaneously, and each has its own explanations and value propositions. Remember, what sets Urbit apart is that we’re building of all these elements at once to work together as a system.

70+One potential barrier to understanding Urbit is that we’re building out multiple layers of this new internet simultaneously, and each has its own explanations and value propositions. Remember, what sets Urbit apart is that we’re building of all these elements at once to work together as a system.

71

71

72I’ll try to explain the most important of these without straying too deep into the technical weeds.

72I’ll try to explain the most important of these without straying too deep into the technical weeds.

73

73

741. **A peer-to-peer network**

741. **A peer-to-peer network**

75

75

76− Peer-to-peer networking is a really big deal. On the current internet, essentially all of our communications and activities go through centralized servers owned by corporations (Facebook, Google, etc.) — and those corporations can’t help but use all that information to make money. They’re capitalists, after all, and so we get constant privacy violations and interfaces built for maximum dopamine addiction.

76+ Peer-to-peer networking is a really big deal. On the current internet, essentially all of our communications and activities go through centralized servers owned by corporations (Facebook, Google, etc.) — and those corporations can’t help but use all that information to make money. They’re capitalists, after all, and so we get constant privacy violations and interfaces built for maximum dopamine addiction.

77

77

78− In an Urbit world, all those communications go directly between users (i.e. peer-to-peer) with nobody in the middle. That means there’s no data capture by any megacorp, less intrusion into your life online, and communications go back to the semi-private one-to-one or small group format that is most comfortable for humans. It’s more like real life.

78+ In an Urbit world, all those communications go directly between users (i.e. peer-to-peer) with nobody in the middle. That means there’s no data capture by any megacorp, less intrusion into your life online, and communications go back to the semi-private one-to-one or small group format that is most comfortable for humans. It’s more like real life.

79

79

802. **Your own server**

802. **Your own server**

81

81

82− Servers are complicated. Too complicated. Have you ever tried to use a command line? Exactly. It’s a terrible way to work, and that’s just a hint at how complex servers are to operate. To hide that complexity, we let corporations run our servers for us — they can afford teams of engineers. The problem is that today most of our computing is handled by these corporate servers — and that means we’re giving up control because of complexity.

82+ Servers are complicated. Too complicated. Have you ever tried to use a command line? Exactly. It’s a terrible way to work, and that’s just a hint at how complex servers are to operate. To hide that complexity, we let corporations run our servers for us — they can afford teams of engineers. The problem is that today most of our computing is handled by these corporate servers — and that means we’re giving up control because of complexity.

83

83

84− As an example, every time you use Siri, your message is sent to Apple’s servers, where it is processed, and the response is sent back to you (which is admittedly amazing). Unfortunately that’s why it never works if you’re offline, and it’s also why Apple knows what you’re saying to Siri. And this applies to all the apps we use: The actual computing happens on corporate servers. The problem is that we consumers aren’t in control and, again, the corporate entities watch, record, and gate-keep all of our activity.

84+ As an example, every time you use Siri, your message is sent to Apple’s servers, where it is processed, and the response is sent back to you (which is admittedly amazing). Unfortunately that’s why it never works if you’re offline, and it’s also why Apple knows what you’re saying to Siri. And this applies to all the apps we use: The actual computing happens on corporate servers. The problem is that we consumers aren’t in control and, again, the corporate entities watch, record, and gate-keep all of our activity.

85

85

86− Fundamentally, Urbit is a super simple server. That means Urbit can run those computations and hold all that data for you, eliminating the need for a corporate intermediary.

86+ Fundamentally, Urbit is a super simple server. That means Urbit can run those computations and hold all that data for you, eliminating the need for a corporate intermediary.

87

87

883. **Permanent, personal ownership of your digital identity and all your data**

883. **Permanent, personal ownership of your digital identity and all your data**

89

89

90− Urbit IDs are permanently ownable — and that ownership is backed by cryptography, not some corporate database. Once you take possession of your Urbit ID, no central authority can ever take it away from you. Sure, if you start spamming people on the network, word could get around and you might get blocked by other users, but none of them can prevent you from using your ID or accessing your Urbit computer. Compare that to the current internet where Facebook owns your Facebook profile, Google owns your Gmail account, Twitter owns your Twitter handle, etc. At any time and for any reason, those services can arbitrarily shut off your access, and you have little to no recourse — all that data, all those followers, and all that reputation is wiped out instantly. Your Urbit, on the other hand — both the identity, and all the data inside your Urbit computer — is yours permanently, so long as you know your secret key.

90+ Urbit IDs are permanently ownable — and that ownership is backed by cryptography, not some corporate database. Once you take possession of your Urbit ID, no central authority can ever take it away from you. Sure, if you start spamming people on the network, word could get around and you might get blocked by other users, but none of them can prevent you from using your ID or accessing your Urbit computer. Compare that to the current internet where Facebook owns your Facebook profile, Google owns your Gmail account, Twitter owns your Twitter handle, etc. At any time and for any reason, those services can arbitrarily shut off your access, and you have little to no recourse — all that data, all those followers, and all that reputation is wiped out instantly. Your Urbit, on the other hand — both the identity, and all the data inside your Urbit computer — is yours permanently, so long as you know your secret key.

91

91

92− A secure decentralized identity system like the one we’ve built leads to some very interesting use cases that are otherwise insurmountable. For example: decentralized Uber, decentralized delivery services, and a solid solution to the problem of fake reviews. To build any of these services, the problem of permanent identity needs to be solved first, and we’ve done that as part of our overall system. I’ll spend more time on use cases below.

92+ A secure decentralized identity system like the one we’ve built leads to some very interesting use cases that are otherwise insurmountable. For example: decentralized Uber, decentralized delivery services, and a solid solution to the problem of fake reviews. To build any of these services, the problem of permanent identity needs to be solved first, and we’ve done that as part of our overall system. I’ll spend more time on use cases below.

93

93

94− It’s worth noting that this problem has never been solved before. All of our communication channels on the internet today rely on someone else to authenticate our identity. Urbit is — to my knowledge — the first practical application of a decentralized ID system that actually works.

94+ It’s worth noting that this problem has never been solved before. All of our communication channels on the internet today rely on someone else to authenticate our identity. Urbit is — to my knowledge — the first practical application of a decentralized ID system that actually works.

95

95

96−4. **An incentive for good behavior**

96+4. **An incentive for good behavior**

97

97

98− On the Urbit network, identities are finite, and they accrue reputation. Compare that to the current internet where identity is infinite (anyone can create as many email addresses or social media profiles as they want, essentially for free) and so spam, scams, and DoS attacks (“denial-of-service”: when many disposable identities ‘attack’ a server at the same time) are rampant. On the Urbit network, there are just over 4 billion total IDs (2^32^ to be exact). Scarcity creates value. That scarcity, combined with reputation accrual, means there's an incentive for good behavior.

98+ On the Urbit network, identities are finite, and they accrue reputation. Compare that to the current internet where identity is infinite (anyone can create as many email addresses or social media profiles as they want, essentially for free) and so spam, scams, and DoS attacks (“denial-of-service”: when many disposable identities ‘attack’ a server at the same time) are rampant. On the Urbit network, there are just over 4 billion total IDs (2³² to be exact). Scarcity creates value. That scarcity, combined with reputation accrual, means there's an incentive for good behavior.

99

99

100− You might think 4 billion IDs sounds like too few given how many humans we have on the planet. I won’t go into the technical details here, but if we ever get to the point where that’s a problem (which would be a great problem to have), we’ve outlined several solutions that allow everyone alive to get on the network. We don’t intend to lock anyone out.

100+ You might think 4 billion IDs sounds like too few given how many humans we have on the planet. I won’t go into the technical details here, but if we ever get to the point where that’s a problem (which would be a great problem to have), we’ve outlined several solutions that allow everyone alive to get on the network. We don’t intend to lock anyone out.

101

101

1025. **Tools anyone can learn and use**

1025. **Tools anyone can learn and use**

103

103

104− Urbit is a system that anyone with patience can understand completely from top to bottom, from the integers of byte code to the complete OS and everything in between. Urbit in its entirety is just over 50,000 lines of code. That is tiny. Compare that to Linux (the open-source OS that most modern computing is built upon), which is tens of millions of lines of code, and you start to see how important this is for efficiency. Apple’s and Windows’ codebases are similarly massive. In our current computing system, nobody can understand the entire thing completely, and that means there are innumerable security holes. With Urbit, while it may demand something of you, any reasonably intelligent developer can grasp the whole thing. We’ve worked very hard to keep our system simple at each level. That makes it more efficient, more durable, and much more secure.

104+ Urbit is a system that anyone with patience can understand completely from top to bottom, from the integers of byte code to the complete OS and everything in between. Urbit in its entirety is just over 50,000 lines of code. That is tiny. Compare that to Linux (the open-source OS that most modern computing is built upon), which is tens of millions of lines of code, and you start to see how important this is for efficiency. Apple’s and Windows’ codebases are similarly massive. In our current computing system, nobody can understand the entire thing completely, and that means there are innumerable security holes. With Urbit, while it may demand something of you, any reasonably intelligent developer can grasp the whole thing. We’ve worked very hard to keep our system simple at each level. That makes it more efficient, more durable, and much more secure.

105

105

1066. **Lessons from the last half century**

1066. **Lessons from the last half century**

107

107

108− Bear with me — this is where some jargon kicks in. In many ways, Urbit is an attempt to apply lessons learned from the failures of 20th century computer development. From an engineer’s perspective, Urbit solves a series of problems that we end users rarely notice, but which cause extraordinary amounts of complexity and waste. The list of applied lessons is long, but rather than bullet them all, I’ll explain the one that surprised me the most.

108+ Bear with me — this is where some jargon kicks in. In many ways, Urbit is an attempt to apply lessons learned from the failures of 20th century computer development. From an engineer’s perspective, Urbit solves a series of problems that we end users rarely notice, but which cause extraordinary amounts of complexity and waste. The list of applied lessons is long, but rather than bullet them all, I’ll explain the one that surprised me the most.

109

109

110− Urbit is deterministic. That is, a given sequence of inputs always produces the same output. When I first heard that, I thought, “Wait, isn’t that what all operating systems do? Give you the same result every time?” Weirdly, the answer is no. Normal operating systems don’t work this way. Normal modern operating systems actually get varying results when they compute things. This is a deep problem that causes programmers countless hours of frustration. The most common implication of this that you’ve probably experienced is having to reboot your computer — either because it’s locked up, or because it simply won’t do something that it was totally doing a second ago. What’s annoying to a regular user, though, is absolutely crazy-making to developers.

110+ Urbit is deterministic. That is, a given sequence of inputs always produces the same output. When I first heard that, I thought, “Wait, isn’t that what all operating systems do? Give you the same result every time?” Weirdly, the answer is no. Normal operating systems don’t work this way. Normal modern operating systems actually get varying results when they compute things. This is a deep problem that causes programmers countless hours of frustration. The most common implication of this that you’ve probably experienced is having to reboot your computer — either because it’s locked up, or because it simply won’t do something that it was totally doing a second ago. What’s annoying to a regular user, though, is absolutely crazy-making to developers.

111

111

112− This determinism makes programming on an Urbit immensely more efficient than other environments.

112+ This determinism makes programming on an Urbit immensely more efficient than other environments.

113−

114− Urbit applies this and a whole list of other lessons from the past half-century of systems software to increase reliability and security in everything from file storage to networking to user-facing apps. All this adds up to more security and reliability and less service-lock-in with Urbit than with our current systems.

115

113

114+ Urbit applies this and a whole list of other lessons from the past half-century of systems software to increase reliability and security in everything from file storage to networking to user-facing apps. All this adds up to more security and reliability and less service-lock-in with Urbit than with our current systems.

115+

1167. **Private, human-sized, and efficient**

1167. **Private, human-sized, and efficient**

117

117

118− Because Urbit isn’t centralized or owned by any one company, there’s no incentive for it to dominate your life. Your Urbit isn’t designed to spy on you, get you addicted to clicking its buttons, manipulate your emotions to gain attention, or nudge you to buy something. Your Urbit is a simple, customizable, permanent place for you to do all your computer-based tasks with your friends in absolute privacy.

118+ Because Urbit isn’t centralized or owned by any one company, there’s no incentive for it to dominate your life. Your Urbit isn’t designed to spy on you, get you addicted to clicking its buttons, manipulate your emotions to gain attention, or nudge you to buy something. Your Urbit is a simple, customizable, permanent place for you to do all your computer-based tasks with your friends in absolute privacy.

119

119

120− This is so much the case, in fact, that it presents a bit of a problem for Tlon. We don’t know how many people use Urbit every day, who they talk to, or what they’re doing. While we think this is how things should be, it puts us in a bind when a VC wants to know about our user base; we can only make educated guesses. That said, we think this is the right problem to have.

120+ This is so much the case, in fact, that it presents a bit of a problem for Tlon. We don’t know how many people use Urbit every day, who they talk to, or what they’re doing. While we think this is how things should be, it puts us in a bind when a VC wants to know about our user base; we can only make educated guesses. That said, we think this is the right problem to have.

121

121

122− What all this adds up to is that the Urbit network is immensely more resource efficient, secure, easier to customize, and smaller in size than any other computing system in the world. If you care about data security, privacy, durability, or even just elegance, Urbit has the best design going.

122+ What all this adds up to is that the Urbit network is immensely more resource efficient, secure, easier to customize, and smaller in size than any other computing system in the world. If you care about data security, privacy, durability, or even just elegance, Urbit has the best design going.

123

123

124+ <br></br>

124

125

125−

126+<img class="ba" src="https://media.urbit.org/site/posts/essays/normies-2.png">

126

127

127## How it compares

128## How it compares

128

129

129−A final way to understand Urbit is to make comparisons between Urbit and current products we use today. This is limited, because ultimately Urbit will grow in directions we can’t predict, but comparisons are a useful starting place.

130+A final way to understand Urbit is to make comparisons between Urbit and current products we use today. This is limited, because ultimately Urbit will grow in directions we can’t predict, but comparisons are a useful starting place.

130

131

131Again, on the current internet, we all access megacorp software using our web browsers and app interfaces. This means that we each exist as a line in a megacorp database, and those megacorps use that data to make money, which results in rampant privacy violations and addictive interfaces. Urbit is the alternative to all that: it’s decentralized, private, and secure. And it’s yours.

132Again, on the current internet, we all access megacorp software using our web browsers and app interfaces. This means that we each exist as a line in a megacorp database, and those megacorps use that data to make money, which results in rampant privacy violations and addictive interfaces. Urbit is the alternative to all that: it’s decentralized, private, and secure. And it’s yours.

132

133

133−Let’s get to some real-world examples.

134+Let’s get to some real-world examples.

135+

134

136

135## Urbit vs. Reddit

137## Urbit vs. Reddit

136

138

137−Imagine you’d like to discuss a certain research topic with a group of friends. Say, Canadian small cap equities or the best cookie recipes. You’ll need a chat interface for live discussion, a notebook to record concepts, and a way to share links for discussion. You can do this in the default web if you want: use Reddit for the links (but make sure it’s a private group), use Google Docs for the notebook (but make sure everyone has Gmail), and use iMessage for the chat (but everyone needs a Mac). And don’t forget, each service has their own login and security holes, and they’re all mining your data.

139+Imagine you’d like to discuss a certain research topic with a group of friends. Say, Canadian small cap equities or the best cookie recipes. You’ll need a chat interface for live discussion, a notebook to record concepts, and a way to share links for discussion. You can do this in the default web if you want: use Reddit for the links (but make sure it’s a private group), use Google Docs for the notebook (but make sure everyone has Gmail), and use iMessage for the chat (but everyone needs a Mac). And don’t forget, each service has their own login and security holes, and they’re all mining your data.

138

140

139−The alternative is spin up a group on Urbit. All of that functionality is available today in one clean, simple interface. It’s private, you own the data, there’s only one login, and you can even learn to build apps for your group.

141+The alternative is spin up a group on Urbit. All of that functionality is available today in one clean, simple interface. It’s private, you own the data, there’s only one login, and you can even learn to build apps for your group.

140

142

141## Urbit vs. Facebook, Twitter, etc.

143## Urbit vs. Facebook, Twitter, etc.

142

144

143−Or let’s say you want to share pictures with your friends, post micro-messages to the world, write a blog, or share a podcast. There’s simply no reason you should use some centralized company (one that then owns your content) to broadcast any of those things. Instead, send it out from your Urbit. You’ll own the content, you’ll control the data, no company will spy on you, and nobody can ever take your ID from you. With Urbit we all finally own the tools, and that means we own the data by default.

145+Or let’s say you want to share pictures with your friends, post micro-messages to the world, write a blog, or share a podcast. There’s simply no reason you should use some centralized company (one that then owns your content) to broadcast any of those things. Instead, send it out from your Urbit. You’ll own the content, you’ll control the data, no company will spy on you, and nobody can ever take your ID from you. With Urbit we all finally own the tools, and that means we own the data by default.

144

146

145## Urbit vs. Nest

147## Urbit vs. Nest

146

148

147−Imagine, as I do, that you want a connected video camera in your house, but don’t want the Nest corporation (which is now owned by Google) to be able to spy on you. Or perhaps you just don’t want to have to sign up for yet another duplicative service in order to use the camera you just bought. If any of that is the case, you can run your camera through your Urbit instead. The video feed will never leave your control, because it no longer has to live on Nest’s servers. Your camera will talk over a secure channel only to your Urbit. Your Urbit is the server.

149+Imagine, as I do, that you want a connected video camera in your house, but don’t want the Nest corporation (which is now owned by Google) to be able to spy on you. Or perhaps you just don’t want to have to sign up for yet another duplicative service in order to use the camera you just bought. If any of that is the case, you can run your camera through your Urbit instead. The video feed will never leave your control, because it no longer has to live on Nest’s servers. Your camera will talk over a secure channel only to your Urbit. Your Urbit is the server.

148

150

149−You can apply this same concept to smart speakers, a Ring doorbell, connected baby monitor, smart fridge, or any of the innumerable connected devices that give someone else access to your personal life. Why should anyone else have access to that information?

151+You can apply this same concept to smart speakers, a Ring doorbell, connected baby monitor, smart fridge, or any of the innumerable connected devices that give someone else access to your personal life. Why should anyone else have access to that information?

150

152

151## Urbit vs. Google Docs

153## Urbit vs. Google Docs

152

154

153−Imagine you want to write a screenplay with a small group of friends, but you don’t want Google mining the content of your shared doc for advertising keywords, and you won’t want to use multiple services for chat, document sharing, email, etc. In that case, simply create an Urbit group with your friends and write together using Urbit’s writing tools. Your content will stay completely private to the team until you decide to release it to the world, and you’ll communicate using one simple interface. Even better, the archive of your multimodal work lives in one place, so looking back at your process doesn’t require reconstructing it from dozens of different apps. And everything is stored on your respective Urbit computers, not Google’s servers.

155+Imagine you want to write a screenplay with a small group of friends, but you don’t want Google mining the content of your shared doc for advertising keywords, and you won’t want to use multiple services for chat, document sharing, email, etc. In that case, simply create an Urbit group with your friends and write together using Urbit’s writing tools. Your content will stay completely private to the team until you decide to release it to the world, and you’ll communicate using one simple interface. Even better, the archive of your multimodal work lives in one place, so looking back at your process doesn’t require reconstructing it from dozens of different apps. And everything is stored on your respective Urbit computers, not Google’s servers.

154

156

155## Urbit for your protected health information

157## Urbit for your protected health information

156

158

157−Imagine, as is already becoming the case, that it becomes highly valuable to have your genome sequenced in order to make good healthcare decisions. In that scenario, most of us would want our health care providers to be able to make precise assessments of parts of our genome, but we wouldn’t want insurance companies or other third parties to have access without our permission. In the current paradigm, once you share the information, it’s out there and can be leaked or sold. So much so that we all sort of assume that leaks are the default. In the Urbit paradigm, that information lives on your Urbit computer and nowhere else, and any software necessary to process it can be run on your Urbit as well. In other words, there’s never any need to share the raw data with anyone; instead, you can download a small program, run it on your Urbit, and share the final analyses only without ever exposing your data.

159+Imagine, as is already becoming the case, that it becomes highly valuable to have your genome sequenced in order to make good healthcare decisions. In that scenario, most of us would want our health care providers to be able to make precise assessments of parts of our genome, but we wouldn’t want insurance companies or other third parties to have access without our permission. In the current paradigm, once you share the information, it’s out there and can be leaked or sold. So much so that we all sort of assume that leaks are the default. In the Urbit paradigm, that information lives on your Urbit computer and nowhere else, and any software necessary to process it can be run on your Urbit as well. In other words, there’s never any need to share the raw data with anyone; instead, you can download a small program, run it on your Urbit, and share the final analyses only without ever exposing your data.

158

160

159−Some of these cases are, admittedly, a bit speculative since we haven’t built all the functionality yet. But it’s coming, and quite soon.

161+Some of these cases are, admittedly, a bit speculative since we haven’t built all the functionality yet. But it’s coming, and quite soon.

160

162

161For now, if you like the way this sounds you can [get yourself an Urbit ID](https://urbit.org/getting-started/#id) and start learning about how to safely store cryptographic keys (it’s really not that hard, and we give you suggestions). If you’re feeling technical or adventurous, you can try booting our beta OS interface to see what it looks like. It’s fussy, but it exists. Soon it will be less fussy. You can check out our [roadmap](https://urbit.org/understanding-urbit/roadmap/) if you’d like to know when.

163For now, if you like the way this sounds you can [get yourself an Urbit ID](https://urbit.org/getting-started/#id) and start learning about how to safely store cryptographic keys (it’s really not that hard, and we give you suggestions). If you’re feeling technical or adventurous, you can try booting our beta OS interface to see what it looks like. It’s fussy, but it exists. Soon it will be less fussy. You can check out our [roadmap](https://urbit.org/understanding-urbit/roadmap/) if you’d like to know when.

162

164

163## Why we need Urbit

165## Why we need Urbit

164

166

165−We humans haven’t evolved enough to manage the firehose of information that modern technology blasts us with. There’s too much news, too many connections, too many opinions, and more agendas out there than any of us can mindfully comprehend. We’re designed for much smaller communities, one-to-one connections, and slower idea assimilation than our modern infrastructure allows. The pace of change is increasing, and we don’t know how to manage it.

167+We humans haven’t evolved enough to manage the firehose of information that modern technology blasts us with. There’s too much news, too many connections, too many opinions, and more agendas out there than any of us can mindfully comprehend. We’re designed for much smaller communities, one-to-one connections, and slower idea assimilation than our modern infrastructure allows. The pace of change is increasing, and we don’t know how to manage it.

166

168

167−We’re scared, and to manage that fear we’re becoming more insular, more entrenched. Layer on top of all that the incentives that big business and big politics have to manipulate our emotions, and we’re headed in a very dangerous direction.

169+We’re scared, and to manage that fear we’re becoming more insular, more entrenched. Layer on top of all that the incentives that big business and big politics have to manipulate our emotions, and we’re headed in a very dangerous direction.

168

170

169−We can’t turn back the technological clock; humanity can only ever press onward. This is where Urbit comes in. Urbit is a forward-looking solution to this particular set of problems around human-scale computing and personal autonomy. Urbit provides a means by which groups can live peacefully in parallel.

171+We can’t turn back the technological clock; humanity can only ever press onward. This is where Urbit comes in. Urbit is a forward-looking solution to this particular set of problems around human-scale computing and personal autonomy. Urbit provides a means by which groups can live peacefully in parallel.

170

172

171−Urbit is a computing environment that allows humans to do everything they want on computers, but in communities of their choosing, in a way that feels direct and natural, and in a way that allows true personal freedom. Urbit is calm, secure, and private in its most fundamental architecture. No spying corporations. No manipulative politicians.

173+Urbit is a computing environment that allows humans to do everything they want on computers, but in communities of their choosing, in a way that feels direct and natural, and in a way that allows true personal freedom. Urbit is calm, secure, and private in its most fundamental architecture. No spying corporations. No manipulative politicians.

172

174

173−And that is what we need. Humans need a way to at once take advantage of our vast technological advances but not be dominated by them. Urbit is an open-source tool that we all own, that anyone can understand down to its roots, that’s fully under its user’s control. It is human-scale computing for human-scale communities. Simple, durable, yours.

175+And that is what we need. Humans need a way to at once take advantage of our vast technological advances but not be dominated by them. Urbit is an open-source tool that we all own, that anyone can understand down to its roots, that’s fully under its user’s control. It is human-scale computing for human-scale communities. Simple, durable, yours.

174

176

175For me, this first iteration of Urbit is more than enough, and it’s exactly the sort of peaceful future I want to work towards.

177For me, this first iteration of Urbit is more than enough, and it’s exactly the sort of peaceful future I want to work towards.

content/blog/urbit-grants-and-mid-2019-gifts.md+4−9

@@ -1,16 +1,11 @@

1+++

1+++

2title = "Urbit Grants and mid-2019 Gifts"

2title = "Urbit Grants and mid-2019 Gifts"

3−date = "2019-06-09"

3+date = 2019-06-10

4description = "Announcing an upcoming Urbit grants program and star gifts for Mid-2019."

4description = "Announcing an upcoming Urbit grants program and star gifts for Mid-2019."

5−aliases = [

6− "/posts/essays/urbit-grants-and-mid-2019-gifts",

5+aliases = ["/posts/essays/urbit-grants-and-mid-2019-gifts", "/posts/urbit-grants-and-mid-2019-gifts"]

7− "/posts/urbit-grants-and-mid-2019-gifts"

8−]

9−

10[taxonomies]

6[taxonomies]

11−grant_type = [ "Gift" ]

7+grant_type = ["Gift"]

12−grant_category = [ ]

8+grant_category = []

13−

14[extra]

9[extra]

15author = "Galen Wolfe-Pauly + Alex Matzner"

10author = "Galen Wolfe-Pauly + Alex Matzner"

16ship = "~ravmel-ropdyl + ~mignyt-mogseb"

11ship = "~ravmel-ropdyl + ~mignyt-mogseb"

content/blog/urbit-is-for-communities.md+9−4

@@ -1,15 +1,16 @@

1+++

1+++

2title = "Urbit is for Communities"

2title = "Urbit is for Communities"

3−date = "2020-03-22"

3+date = 2020-03-23

4description = "Urbit is for giving communities the tools to shape their own environments; for us all to feel a sense of life and self-directedness in the digital world."

4description = "Urbit is for giving communities the tools to shape their own environments; for us all to feel a sense of life and self-directedness in the digital world."

5−

6[extra]

5[extra]

7author = "Galen Wolfe-Pauly"

6author = "Galen Wolfe-Pauly"

8ship = "~ravmel-ropdyl"

7ship = "~ravmel-ropdyl"

9−image = "https://media.urbit.org/site/posts/essays/urbit-is-for-communities.jpg"

8+image ="https://media.urbit.org/site/posts/essays/urbit-is-for-communities.jpg"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/urbit-is-for-communities.jpg">

13

14

14## Generated, not fabricated

15## Generated, not fabricated

15

16

@@ -33,6 +34,7 @@ We don’t often talk about it explicitly, but this is what Urbit is for. Urbit

33

34

34It’s not any single specific technical feature of Urbit that makes it well-suited for communities to homestead and develop. It’s the combination of the technology under the hood and the interfaces we build on top. Let’s talk about both.

35It’s not any single specific technical feature of Urbit that makes it well-suited for communities to homestead and develop. It’s the combination of the technology under the hood and the interfaces we build on top. Let’s talk about both.

35

36

37+

36## Technically capable

38## Technically capable

37

39

38I love [this tweet](https://twitter.com/devonzuegel/status/1221804267083718656) about becoming a ‘digital prepper’. It feels like it has already happened to me, too. I’ve seen enough centralized services shut down and disappear (often with my data) that I’m reluctant to try new ones. No matter how friendly and cozy their branding.

40I love [this tweet](https://twitter.com/devonzuegel/status/1221804267083718656) about becoming a ‘digital prepper’. It feels like it has already happened to me, too. I’ve seen enough centralized services shut down and disappear (often with my data) that I’m reluctant to try new ones. No matter how friendly and cozy their branding.

@@ -55,6 +57,7 @@ That means we have to solve the problems inherent to the legacy internet. There

55

57

56But even with a system that fixes all of these issues by default, it only matters if the system is usable and understandable. What we really want is a digital world that’s generated by the communities that inhabit it — which means it has to be generated by people with no technical knowledge.

58But even with a system that fixes all of these issues by default, it only matters if the system is usable and understandable. What we really want is a digital world that’s generated by the communities that inhabit it — which means it has to be generated by people with no technical knowledge.

57

59

60+

58## Communities are built by people

61## Communities are built by people

59

62

60In the physical world, you can arrange the furniture in your house, or go to Ikea, or build your own furniture, or figure out how to build a house from scratch. By taking your preferred approach to design, you contribute to the shape of your city. The world around us is a wonderfully loose collaboration between the more technically oriented architects and planners, and the everyday homeowners and residents.

63In the physical world, you can arrange the furniture in your house, or go to Ikea, or build your own furniture, or figure out how to build a house from scratch. By taking your preferred approach to design, you contribute to the shape of your city. The world around us is a wonderfully loose collaboration between the more technically oriented architects and planners, and the everyday homeowners and residents.

@@ -67,6 +70,7 @@ For most people, customizing your Urbit should be a matter of picking from an av

67

70

68We’re not quite to this level of sophistication, but we’re on the path. Let’s talk about where we are and where we’re going.

71We’re not quite to this level of sophistication, but we’re on the path. Let’s talk about where we are and where we’re going.

69

72

73+

70## OS 1

74## OS 1

71

75

72Our rough attempt to satisfy this goal is hovering on the horizon. We call it OS 1.

76Our rough attempt to satisfy this goal is hovering on the horizon. We call it OS 1.

@@ -81,6 +85,7 @@ Currently, our Ikea experience is pretty limited, there are only a few Legos to

81

85

82The system is ripe for experimentation, customization, and exploration. It’s ready for earnest homesteading. Come build.

86The system is ripe for experimentation, customization, and exploration. It’s ready for earnest homesteading. Come build.

83

87

88+

84## → N

89## → N

85

90

86OS 1 is really just the beginning. There are so many more modules and means of communicating and collaborating to add. There is so much we can do to make the system more customizable.

91OS 1 is really just the beginning. There are so many more modules and means of communicating and collaborating to add. There is so much we can do to make the system more customizable.

content/blog/urbithost-interview.mddeleted−116

@@ -1,116 +0,0 @@

1−+++

2−title = "An Interview with UrbitHost"

3−date = "2021-08-19"

4−description = "Interview with the founder of UrbitHost ~lavlyn-litmeg"

5−[extra]

6−author = "Matt"

7−ship = "~tirwyd-sarmes"

8−image = "https://media.urbit.org/site/posts/essays/nasa-star-cluster.jpg"

9−+++

10−

11−

12−

13−**An Interview with UrbitHost**

14−

15−Urbit has been making great strides to become accessible to those who are non-technical. Port enables a user to launch their Urbit ID from their personal computer without any knowledge of the command line. However, you only have access while you are running Port, which means you can&#39;t do things like check your DMs while on the move.

16−

17−Hosting your Urbit means that your Urbit is always on and available. All that is required to access the network is visiting a URL and logging in.That means you can access Urbit from your phone, laptop, or any device with a browser.

18−

19−The downside is that running your own server can be a complex and difficult process. Third-party hosting allows an expert to do that work for you. The hosting provider gets paid, and you get 24/7 access to your ship.

20−

21−[UrbitHost](https://urbithost.com) is one of the latest [hosting providers](https://subject.network/planet-sales/) to enter the market. As of now, it is one of the fastest and easiest ways onto the network. You pay the fee, and you get sent a link that you use to access Landscape. It&#39;s that easy.

22−

23−At least, it&#39;s that easy for the end user. For the guy running the operations, ~lavlyn-litmeg, it can be quite a complex operation. I sat down with him to find out about what it&#39;s like being a commercial developer on Urbit. We also talked about technology, the developer ecosystem, and the future of Urbit.

24−

25−If you want to get in touch you can reach him at ~lavlyn-litmeg, the ~sardys/uh group, or [urbithost.com](https://urbithost.com).

26−

27−---

28−

29−**Tell us a bit about yourself and your history with Urbit?**

30−

31−I&#39;m a software engineer who is currently working at one of the larger crypto currency companies. My history with Urbit goes back quite a long time. I saw one of those early demos by Curtis where he had two dojos running, sending messages back and forth, and I thought it looked interesting. Since then, I often checked in on the project, but I stayed at the sidelines because it felt not quite ready; there were constant breaches and so on. What kept me close by was that I believed in the vision of Urbit.

32−

33−I think the open internet only has a future if people retain control of their digital identities, which means that, in addition to a cryptographic identity, they need to be able to keep control over their data. This not only includes their social graph, but they also must be able to run computations on that data. Urbit checks all those boxes. The people behind Urbit and all the other contributors have been steadily marching towards these goals with incredible stamina. I&#39;m inspired by that. And, since the release of OS1, Urbit is very much usable, and I find myself spending more and more time on it instead of other corners of the internet.

34−

35−**Why did you decide to work on hosting rather than another Urbit project? If you weren&#39;t working on UrbitHost what would you be working on within the Urbit ecosystem?**

36−

37−I want my non-tech friends to be able to join Urbit. Most people I know can&#39;t be bothered with executing a blockchain transaction, many feel uncomfortable installing an app they don&#39;t understand, and almost all would shy away from the command line. For the vast majority of people, getting onto Urbit must be as easy as signing up for Gmail or Twitter, otherwise they won&#39;t come.

38−

39−I thought about how I could contribute to Urbit and decided that now is a good time to build a hosting provider. It&#39;s still early, but a non-technical person can actually spend time on the network and be productive. I think we are just now seeing a shift where we need community builders as much as we need engineers working on the internals of Urbit. It is important that those community builders have no barrier to entry for themselves or their communities.

40−

41−That is why ease of access has been my goal from the beginning. I wanted the site to be fully automated, meaning someone could sign up and be on Urbit within minutes. It was also important to me that users be able to choose their own Urbit ID. As far as I know, there was no offering like that yet, so I decided to build it—but I know that others are working on this too.

42−

43−If I was working on something else, it would be Urbit apps. We&#39;re waiting for the new release for it to be easier to distribute and access apps; there are a few tools I would really like to see. But other than that, I would like to spend more time community building.

44−

45−**Can you tell us about how you&#39;re implementing UrbitHost? You beat Tlon to the punch of having immediate hosted access to the Urbit network -- what&#39;re you doing differently? How will your implementation change when programmatic access becomes available via Khan (the new vane to replace Herb)?**

46−

47−UrbitHost runs on Kubernetes, which is a tool to orchestrate containers. What that means, concretely, is that each ship runs inside a Docker container, and Kubernetes makes sure that each container is running and has enough resources. For example, if a server goes down, Kubernetes will automatically move the ships that were on that server to a new server that is available. No data is lost and there should be very little down-time.

48−

49−People think Kubernetes should only be used for services that can be scaled horizontally, meaning there are multiple instances running of the same services. Scaling like this is obviously not an option for Urbit, because a ship must only run as a single instance. But in the last few years, Kubernetes has added many features to run single and stable instances of a container, for example a database. UrbitHost is making use of these features—permanent volumes, stateful sets, and so on—to provide a high-availability hosting for Urbit. It also scales well. I surmise, we could host thousands of ships, we would only have to add compute nodes.

50−

51−As for beating Tlon, I&#39;m not sure if it is a fair comparison. UrbitHost, as it is currently, is a minimal viable product. I tried to realize a simple goal: automated hosting. Tlon is hosting many more planets, not to speak of all the stars and galaxies that make up the network. As far as I can tell, Tlon and UrbitHost are doing things quite similarly. For example, I knew that Tlon is also hosting on Kubernetes, which gave me much more confidence that we could do it too.

52−

53−UrbitHost&#39;s programmatic interaction with hosted ships is quite minimal once it is booted. We use airlock to retrieve the access code and do a few more maintenance things, and we are using it for some upcoming features like automatic S3 configuration. But from what I can tell, Khan looks like a really important step forward, because interacting with the hosted ships via airlock is one of the most brittle areas, and I&#39;m looking forward to making it more robust once Khan is out.

54−

55−**What is most needed within the Urbit ecosystem — any particular apps or services? Which projects are you most excited about?**

56−

57−The ability to publish content directly from a planet to the regular internet would be cool. I would really love to see some bigger blogs being hosted on Urbit. The basic idea would be this: everyone can read the blog, but to join the conversation one would have to join Urbit and the group associated with that blog. Of course, a planet could publish other content too, possibly a mix of free and premium content. Either way, it would pull a lot of people into the gravity well of Urbit.

58−

59−Publishing could also be a good value proposition for Urbit hosting providers. If public content is hosted on a ship, then all the profit from new customers who are brought to the provider could somehow be split between the host and content producer. What is nice, though, is that a content producer can take his Urbit-native community anywhere, anytime, without disrupting the community much. The portability of Urbit at every level would really shine here as communities grow.

60−

61−There are incredible projects happening on every front. The Bitcoin integration is very exciting, it is being realized in a truly Urbit-native way and could prove to be a great catalyst for the ecosystem. However, as a hosting provider, the constant lower-level improvements are exciting too.

62−

63−**What will be the effect of two upcoming changes to Urbit:**

64−

65−1. **Built in software distribution and management**

66−2. **Layer 2 and the new &quot;Khan&quot; vane**

67−

68−**For #1, how would you pitch developers on the benefits of building on Urbit?**

69−

70−**With regard to #2, I think there is about to be an explosion of hosting providers. Will this unleash an Eternal September effect or does Urbit&#39;s &quot;walled garden&quot; style of communication make it more resilient? Urbit is not a single silo like Facebook, after all.**

71−

72−I think that once software distribution is as simple and easy as the iOS app store it will be a watershed moment for Urbit. Put bluntly, it will give users something to do on Urbit besides chat. There are several interesting apps out there already, but they are not easy to discover and install.

73−

74−Developers want reach. The most important pitch to developers will be that on Urbit they have access to a substantial audience. I remember developing for the iPhone in the early days. Objective-C was really a tough pill to swallow, but because the platform was interesting and promised to reach a large audience, I kept going with it. I think Urbit is an interesting platform for the various reasons already mentioned. But learning to develop for Urbit is really a time investment—I myself am still a novice Hoon developer —and for it to be worth it, there has to be a clear pay-off. For some, this is making system-level contributions, but for most it will be having that app show up in some centrally visible place and seeing people engage with it. Once this exists, it will be much easier to pitch Urbit to developers.

75−

76−The layer 2 solution which will make spawning planets much cheaper is an important next step, especially for hosting providers. Layer 2 will help us immensely because spawning and keying planets is very expensive right now, and it puts a damper on how much we are actively pursuing growth.

77−

78−If new hosting providers come online, it will not necessarily mean a huge influx of users. In my experience, building a provider is hard and takes time to mature. However, I would love to see fast user growth.

79−

80−I honestly don&#39;t think having our own Urbit Eternal September would be that bad. I would just see it as growing pains. If we enter a time of sustained growth and rapid user onboarding, the fact that some Urbit groups will get overwhelmed with all the new people will be a small price to pay. The current setup, with a few central groups that act like hubs and discovery points—for example, the fantastic Urbit Index—would have to change. People would need to be funneled into their own Urbit universes that might not overlap much with other areas on Urbit. The nice thing is that all this is accounted for in the Urbit infrastructure.

81−

82−If a certain hosting provider ends up bringing thousands upon thousands of users to Urbit, like AOL did back then with Usenet, then it will be the provider&#39;s responsibility to onboard those users sensibly and not just dump them on the existing groups. In other words, providers, in my opinion, also have a community building responsibility. Of course, this does not mean that providers should be overbearing parents, allowing only this or that, but simply that they should have sensible defaults that don&#39;t overwhelm or destroy the network.

83−

84−**What is the role of commercial providers in the open-source ecosystem?**

85−

86−Commercial providers will be incredibly important to make Urbit succeed. I think if Urbit attracts a large number of users, many, if not most, will run their ship via a hosting provider. It is the easiest way to get started.

87−

88−However, using a hosting provider to get onto Urbit might at first seem antithetical to the spirit of the project. If someone is trying to get away from mega-corporations, why would they go right back to another company and give them their data?

89−

90−Well, because it&#39;s a completely different relationship. The relationship between us, the provider, and you, the customer, is transparently straight forward. You are not the product. We have a more traditional provider-customer relationship where we just do the dev ops work. It is in our interest to keep your data private and keep your ship running. We give you an Urbit ID, which you can keep forever, and host your ship as long as you wish. When you want to leave, you can download your pier and Urbit ID and use it with a different provider or on your own computer in minutes. On the other hand, you cannot leave Facebook and run your profile off of your laptop. Basically, we cannot count on customer lock-in, we must provide good and honest service. Again, the portability promise of Urbit is essential here and ensures that we are on an equal footing.

91−

92−**Once the Urbit payment ecosystem gets built out more, would you consider accepting payments over the Urbit network?**

93−

94−Of course. Having an Urbit-native economy would be a key marker of success, and I would love to participate in it. Moreover, we are planning to offer a Bitcoin node to our customers soon.

95−

96−**Are you coming to Assembly 2021?**

97−

98−Yes. At least, I&#39;m planning to! I would love to meet all the people behind Urbit in real life.

99−

100−**I know you are a Christopher Alexander fan, how has he influenced your work?**

101−

102−I&#39;ve been interested in Christopher Alexander for quite a long time. When I realized that many of the people building Urbit are also inspired by him, I understood why much of the Urbit vibe resonated with me. Critics of Urbit either focus on the technical details or on Curtis Yarvin&#39;s writings, sometimes conflating the two. That&#39;s fine and perhaps a valid point to start, but what they don&#39;t understand is that so many other ideas and ideals have since become driving forces behind the project. This is at least what I observe as an outsider.

103−

104−Alexander&#39;s ideas are all about how to build beautiful houses. He wants us to inhabit places that feel life-giving, places that make us more fully human. The same should be asked of the technology we use. So much of the current internet is the equivalent of a fluorescent-lit cubicle, a brutalist government building, or a flashy central square. It might be interesting to travel through these places, but they do not make good homes.

105−

106−To explore what makes a building beautiful, Alexander had to wade into metaphysics, because he wanted to give a much more objective account of how beauty is present in physical artifacts, which led him to treat beauty as a universal. I think to build more meaningful technology we need to do the same. We do not have a good metaphysics of technology, and this is something I&#39;m really interested in.

107−

108−**Give me a brief summary about your personal philosophy of technology. Do all tools fall under the umbrella of &quot;technology&quot;? Or do some tools hit an inflection point where they acquire radically different characteristics (compare a shovel and a computer)? It seems to me that the philosophy of technology often boils down to trying to define what &quot;technology&quot; actually is. What do you make of all this?**

109−

110−Yeah, I definitely think there is an inflection point once technology becomes digital, but I believe there is something all technology has in common. My approach here is classical. Artifacts have to be distinguished from living things because human made things have their origin outside themselves, meaning they are manufactured (in Aristotelian terms, and stated somewhat simplistically, artifacts have an efficient cause outside themselves, whereas biological things have an innate efficient cause). We are often tempted to think of living organisms simply as elaborate self-replicating machines, but that is putting the cart before the horse. We should rather look to the world of living things to be inspired to build our artifacts.

111−

112−The question of inspiration becomes even more pressing when discussing modern technology, and you put your finger on it with the inflection point. There is no tradition to fall back on when we are building digital technologies. Someone like Christopher Alexander, who is working on architecture, has thousands of years of architecture to look at. He can read the past and see what worked and what did not. On the other hand, when we build things like Urbit, we must look for inspiration in other places because there is no corpus of, say, thousands of years of constructing digital social networks where we can simply choose the best parts. So far, we have mostly bad examples, how not to do it. And considering how new the internet is, most of it is still a blank slate. So while I&#39;m definitely interested in the ontology of technology, I think it is an even more pressing question to learn the principles of the living world around us in order to build digital places that feel organic and life-giving.

113−

114−**Thanks for chatting!**

115−

116−See you on the network!

content/blog/using-urbit-in-2023.mddeleted−55

@@ -1,55 +0,0 @@

1−+++

2−title = "Using Urbit in 2023"

3−date = "2023-02-06"

4−description = "There are more ways to run Urbit than ever, and more options coming soon."

5−[extra]

6−image = "https://storage.googleapis.com/media.urbit.org/blog/usingurbit-2023.jpg"

7−author = "Josh Lehman"

8−ship = "~wolref-podlex"

9−+++

10−

11−

12−

13−Recent years have seen several iterations on ways to run an Urbit node and join the network. [Port](https://github.com/latterbolden/port) and support for running Urbit from Windows were added a couple of years ago and have previously been recommended ways of running Urbit. We no longer recommend these options for the vast majority of users in favor of better options that are now available.

14−

15−Read on to learn about the background underpinning these decisions and your options for joining the network going forward.

16−

17−

18−

19−# Background

20−

21−With the introduction of Landscape in 2020 the demand for being on the network rose substantially from what it had been, yet the only way of running Urbit was through the command line, which was a significant barrier for entry.

22−

23−In 2021 Port and a native Windows binary were both introduced via contributions from the open source community: Port was built via our [grants](https://urbit.org/grants/cross-platform-desktop-urbit-app) [program](https://urbit.org/grants), and the Windows binary was contributed via a [pull request](https://github.com/urbit/urbit/pull/4675). Together, these two projects enabled users to run Urbit locally without requiring command-line knowledge. Port was summarily added as an officially recommended way to run Urbit.

24−

25−Over the course of 2022 it became clear that, while often useful for trying Urbit out, the experience of running Urbit locally via Port was fundamentally limited: Urbit runs best as a server, and laptops provide neither a stable running environment nor consistent web-based access from other devices.

26−

27−Windows presented further challenges, particularly around maintenance: our team of runtime engineers has had their progress stymied by the need to support Windows, which has substantially different requirements from macOS and Linux. It’s ultimately much more important to our team that we make progress on the versions of the runtime that run well in a server environment, which is the best way to use Urbit, than for local installations.

28−

29−Going forward we no longer recommend Port as an officially supported option for joining the network, and have dropped support for the native Windows binary as of version [1.16](https://groups.google.com/a/urbit.org/g/dev/c/3S6A8Qf8Qzg) of the runtime. That said, it’s worth noting that Port *is not deprecated*! It is still actively [maintained here](https://github.com/latterbolden/port) by the same people that have been maintaining it since the beginning.

30−

31−Let’s move on and talk about your options for getting on the network going forward.

32−

33−

34−# Joining the Network Today

35−

36−Over the course of 2022 many companies emerged and built products that will get you on Urbit, and their teams are constantly working to provide you with a great experience.

37−

38−If you’re not comfortable at the command line you should use a [hosting provider](https://urbit.org/getting-started/hosted). Hosting providers run your Urbit for you and take care of any ongoing maintenance required. If you eventually want to transition to running Urbit yourself, they’ll let you pack up your node and run it however you want: whether that’s at a different hosting provider or your own infrastructure. Learn about [recommended hosting providers in our getting started guide.](https://urbit.org/getting-started/hosting-providers)

39−

40−For more technical users the [command line](https://urbit.org/getting-started/cli) is still a reliable option. For casual testing you can boot a planet or comet on your local macOS or Linux-based machine, and for more serious usage you should refer to our [cloud hosting guide](https://urbit.org/getting-started/cloud-hosting) to get set up on a VPS. A newer option for self-hosting is [Native Planet’s](https://nativeplanet.io) suite of [software](https://www.nativeplanet.io/software) for turning a local computer into an Urbit server complete with DNS.

41−

42−

43−# Coming soon

44−

45−New options for joining Urbit are just around the corner.

46−

47−Word has it that [Tlon](https://tlon.io/hosting) will soon allow you to invite your friends to groups directly from within their [suite of applications](https://tlon.io/landscape), with onboarding handled seamlessly through their hosting service.

48−

49−[Holium’s Realm app](https://www.youtube.com/watch?v=gdu4QtFR-Bs), a collaborative desktop computing environment available on macOS (for now), allows users to sign up with an existing Urbit or brand new hosted one — all seamlessly surfaced through Realm’s signup flow. You can sign up for the private alpha [here](https://holium.com).

50−

51−Tirrel’s [Scene](https://planet.one/scene) is a desktop application with built-in hosting, like Realm, that works on macOS, Windows and Linux, and it’s available now. Hosting is powered by their [Planet One](https://planet.one) service.

52−

53−For the self-hosting enthusiasts out there Native Planet has created [purpose-built Urbit home servers](https://www.nativeplanet.io/hardware) that [make self-hosting easy](https://twitter.com/jmrphy/status/1616196970384887808) and look great doing it.

54−

55−Joining Urbit has never been easier, and it’s constantly getting easier. See you on the network!

content/blog/value-of-address-space-pt1.md+14−11

@@ -1,17 +1,20 @@

1+++

1+++

2title = "The Value of Urbit Address Space (1 of 3)"

2title = "The Value of Urbit Address Space (1 of 3)"

3−date = "2020-04-06"

3+date = 2020-04-07

4description = "An expansion of our position on Urbit's address space value."

4description = "An expansion of our position on Urbit's address space value."

5−

6[extra]

5[extra]

7author = "Erik Newton + Galen Wolfe-Pauly"

6author = "Erik Newton + Galen Wolfe-Pauly"

8ship = "~patnes-rigtyn + ~ravmel-ropdyl"

7ship = "~patnes-rigtyn + ~ravmel-ropdyl"

9−image = "https://media.urbit.org/site/posts/essays/value-of-address-space-pt1.jpg"

8+image ="https://media.urbit.org/site/posts/essays/value-of-address-space-pt1.jpg"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt1.jpg">

14+

15+<br>

13

16

14−_This is the first in a series of three posts on Urbit address space. See also [part 2](https://urbit.org/blog/value-of-address-space-pt2/) and [part 3](https://urbit.org/blog/value-of-address-space-pt3/)._

17+*This is the first in a series of three posts on Urbit address space. See also [part 2](https://urbit.org/blog/value-of-address-space-pt2/) and [part 3](https://urbit.org/blog/value-of-address-space-pt3/).*

15

18

16## Part One – What/why, a history, and some analogies

19## Part One – What/why, a history, and some analogies

17

20

@@ -47,15 +50,15 @@ We’ve often said that Urbit IDs have value because they’re useful and scarce

47

50

48The network of IDs is structured as a sponsorship tree consisting of 256 galaxies, ~65,000 stars, ~4B planets.

51The network of IDs is structured as a sponsorship tree consisting of 256 galaxies, ~65,000 stars, ~4B planets.

49

52

50−Galaxies are the root nodes on the network. They each have a vote on upgrades to the rules that govern the network, they provide packet-routing and peer-discovery services, and they spawn stars. Each galaxy has 256 (2^8^) stars to spawn.

53+Galaxies are the root nodes on the network. They each have a vote on upgrades to the rules that govern the network, they provide packet-routing and peer-discovery services, and they spawn stars. Each galaxy has 256 (2⁸) stars to spawn.

51

54

52−Stars similarly provide packet-routing and peer-discovery services, and spawn planets. Each unbooted star contains ~65,000 planets (2^16^).

55+Stars similarly provide packet-routing and peer-discovery services, and spawn planets. Each unbooted star contains ~65,000 planets (2¹⁶).

53

56

54−Planets are the individual IDs that most people use on the network. There are a total of ~4B (2^32^) planets all combined. Planets can also each spawn ~4B ‘moons,’ which are Urbit IDs intended to be used for IoT and other devices. Moons are permanently locked to their planets for security and to protect the network from sybil attacks.

57+Planets are the individual IDs that most people use on the network. There are a total of ~4B (2³²) planets all combined. Planets can also each spawn ~4B ‘moons,’ which are Urbit IDs intended to be used for IoT and other devices. Moons are permanently locked to their planets for security and to protect the network from sybil attacks.

55

58

56Stars and planets can leave their sponsors (i.e. the star or galaxy currently providing peer discovery and packet routing) if they wish, and sponsors can choose to stop servicing any given star or planet. This is intended to prevent lock-in and to encourage good behavior from both parties. This mutual accountability is important in a network of finite identities that accrue reputation.

59Stars and planets can leave their sponsors (i.e. the star or galaxy currently providing peer discovery and packet routing) if they wish, and sponsors can choose to stop servicing any given star or planet. This is intended to prevent lock-in and to encourage good behavior from both parties. This mutual accountability is important in a network of finite identities that accrue reputation.

57

60

58−Essentially Urbit ID is 2^32^ individual names that are bundled into blocks that are larger and larger in size. You might think of a planet like an individual house, a star like a town or a city, and a galaxy like a county or a state.

61+Essentially Urbit ID is 2³² individual names that are bundled into blocks that are larger and larger in size. You might think of a planet like an individual house, a star like a town or a city, and a galaxy like a county or a state.

59

62

60The Urbit ID registry and its rules are built on a set of smart contracts called [Azimuth](https://github.com/urbit/azimuth). These contracts are registered on the Ethereum blockchain. Galaxies can upgrade the mechanics of Azimuth by majority vote.

63The Urbit ID registry and its rules are built on a set of smart contracts called [Azimuth](https://github.com/urbit/azimuth). These contracts are registered on the Ethereum blockchain. Galaxies can upgrade the mechanics of Azimuth by majority vote.

61

64

@@ -81,7 +84,7 @@ So how did these ~4B names get initialized and distributed? Urbit address space

81

84

82Now that the system is up and running, Urbit address space has steadily become more distributed. This arguably follows the distribution patterns of the Bitcoin UTXO set, and even historical distribution patterns of physical land.

85Now that the system is up and running, Urbit address space has steadily become more distributed. This arguably follows the distribution patterns of the Bitcoin UTXO set, and even historical distribution patterns of physical land.

83

86

84−Let’s take a look at how this came to be.

87+Let’s take a look at how this came to be.

85

88

86Urbit was originally an experimental personal project. The original Urbit address space registry was just a text file in the source code at that time. At the very beginning, all of the address space was owned by Curtis — its creator — and it was all pretty much worthless. In the years leading up to 2013, Curtis gave away galaxies to anyone who would help or contribute to the project, and to several people who were simply in the right place at the right time.

89Urbit was originally an experimental personal project. The original Urbit address space registry was just a text file in the source code at that time. At the very beginning, all of the address space was owned by Curtis — its creator — and it was all pretty much worthless. In the years leading up to 2013, Curtis gave away galaxies to anyone who would help or contribute to the project, and to several people who were simply in the right place at the right time.

87

90

@@ -93,7 +96,7 @@ It was then decided that a public key infrastructure was the most logical way to

93

96

94## Analogues and the intrinsic value of address space

97## Analogues and the intrinsic value of address space

95

98

96−We’ve often said that Urbit address space, particularly stars and galaxies, have intrinsic value that should be understood beyond simply the price of the planets they contain. Another way of putting this is that, because stars and galaxies are infrastructure nodes, they’re uniquely positioned to generate cash flow from activities on the network beyond simply selling their planets.

99+We’ve often said that Urbit address space, particularly stars and galaxies, have intrinsic value that should be understood beyond simply the price of the planets they contain. Another way of putting this is that, because stars and galaxies are infrastructure nodes, they’re uniquely positioned to generate cash flow from activities on the network beyond simply selling their planets.

97

100

98This cash flow won't likely come from passive activity, but from actively working to develop businesses located on stars and galaxies. Let’s dig a bit deeper into these activities through the lens of some analogues to the existing world.

101This cash flow won't likely come from passive activity, but from actively working to develop businesses located on stars and galaxies. Let’s dig a bit deeper into these activities through the lens of some analogues to the existing world.

99

102

content/blog/value-of-address-space-pt2.md+73−59

@@ -1,141 +1,155 @@

1+++

1+++

2title = "The Value of Urbit Address Space (2 of 3)"

2title = "The Value of Urbit Address Space (2 of 3)"

3−date = "2020-04-12"

3+date = 2020-04-13

4description = "Scarcity, utility, liquidity, and network effect."

4description = "Scarcity, utility, liquidity, and network effect."

5−

6[extra]

5[extra]

7author = "Erik Newton + Galen Wolfe-Pauly"

6author = "Erik Newton + Galen Wolfe-Pauly"

8ship = "~patnes-rigtyn + ~ravmel-ropdyl"

7ship = "~patnes-rigtyn + ~ravmel-ropdyl"

9−image = "https://media.urbit.org/site/posts/essays/value-of-address-space-pt2.jpg"

8+image ="https://media.urbit.org/site/posts/essays/value-of-address-space-pt2.jpg"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt2.jpg">

14+

15+<br>

13

16

14−_This is the second in a series of three posts on Urbit address space. See also [part 1](https://urbit.org/blog/value-of-address-space-pt1/) and [part 3](https://urbit.org/blog/value-of-address-space-pt3/)._

17+*This is the second in a series of three posts on Urbit address space. See also [part 1](https://urbit.org/blog/value-of-address-space-pt1/) and [part 3](https://urbit.org/blog/value-of-address-space-pt3/).*

15

18

16## Measuring value

19## Measuring value

17

20

18Value and price are distinct concepts that often get conflated. In our view, Urbit address space has value for four fundamental reasons: it’s scarce; it has utility; it has some limited liquidity; and it has network effect. Price, on the other hand, is always a function of supply and demand, and it's not something we – as builders – concern ourselves with very much. Let’s take a look at these fundamentals within the Urbit ecosystem.

21Value and price are distinct concepts that often get conflated. In our view, Urbit address space has value for four fundamental reasons: it’s scarce; it has utility; it has some limited liquidity; and it has network effect. Price, on the other hand, is always a function of supply and demand, and it's not something we – as builders – concern ourselves with very much. Let’s take a look at these fundamentals within the Urbit ecosystem.

19

22

23+

24+

20## Scarcity

25## Scarcity

26+256 galaxies, ~65,000 stars, ~4B planets.

21

27

22−256 galaxies, ~65,000 stars, ~4B planets.

28+<br>

23

29

24−

30+<img class="ba w-100" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt2a.svg">

25

31

26−A foundational design principle of the Urbit network is that the address space is limited. This rarity helps qualify Urbit as a [collectible](https://nakamotoinstitute.org/shelling-out/), and thus creates a non-zero acquisition cost for an address. This cost discourages abuses like spam and bot-net attacks. Traditionally, these attacks are made with quasi-unlimited access to IP addresses. The unit economics of acquiring planets for these nefarious purposes is a strong deterrent.

32+<br>

27

33

28−There are 256 galaxies on the network. Each galaxy is initialized with ownership of 255 stars. Galaxies act as root nodes for peer discovery and packet routing within the Urbit network, and they are each also entitled to vote on updates to the smart contracts which govern the network. To date, galaxies trade primarily on OTC (over the counter) desks, and rarely appear on the open market.

34+A foundational design principle of the Urbit network is that the address space is limited. This rarity helps qualify Urbit as a [collectible](https://nakamotoinstitute.org/shelling-out/), and thus creates a non-zero acquisition cost for an address. This cost discourages abuses like spam and bot-net attacks. Traditionally, these attacks are made with quasi-unlimited access to IP addresses. The unit economics of acquiring planets for these nefarious purposes is a strong deterrent.

29

35

30−There are 65,280 total stars on the network. In turn, each star is initialized with ownership of 65,535 planets. Stars currently trade on platforms independent of Tlon, such as [urbit.live](https://urbit.live/) and [opensea.io](https://opensea.io/). The current price range can easily be ascertained on those sites, but as of the time of this writing, stars are selling at a price that greatly discounts their planet holdings.

36+There are 256 galaxies on the network. Each galaxy is initialized with ownership of 256 stars. Galaxies act as root nodes for peer discovery and packet routing within the Urbit network, and they are each also entitled to vote on updates to the smart contracts which govern the network. To date, galaxies trade primarily on OTC (over the counter) desks, and rarely appear on the open market.

31

37

32−One would expect that in an efficient market the relative pricing of stars on one hand, and planets on the other hand would eventually align (so to speak). This may come to pass as the Urbit community increases education about Urbit, and as additional planet sellers and hosting providers enter the space.

38+There are 65,536 total stars on the network. In turn, each star is initialized with ownership of 65,536 planets. Stars currently trade on platforms independent of Tlon, such as [urbit.live](https://urbit.live/) and [opensea.io](https://opensea.io/). The current price range can easily be ascertained on those sites, but as of the time of this writing, stars are selling at a price that greatly discounts their planet holdings.

33

39

34−Finally, there are 4,294,901,760 (or ~2^32^) planets on the network. Planets currently trade largely in a range of $10 to $15. We expect planet prices to fluctuate from provider to provider as described in the previous post, based on the quality of services various providers offer. That said, it's worth noting that the cost to configure addresses for distribution is fairly static and this may act as something of a lower bound.

40+One would expect that in an efficient market the relative pricing of stars on one hand, and planets on the other hand would eventually align (so to speak). This may come to pass as the Urbit community increases education about Urbit, and as additional planet sellers and hosting providers enter the space.

35

41

36−That said, we also anticipate that planet prices will be abstracted away from most purchasers, and will be included in bundled annual packages of hosting and data routing services. For this reason, infrastructure service providers (i.e. hosting providers) will likely be the best positioned parties to capture value from planet distribution.

42+Finally, there are 4,294,967,296 (or 2³²) planets on the network. Planets currently trade largely in a range of $10 to $15. We expect planet prices to fluctuate from provider to provider as described in the previous post, based on the quality of services various providers offer. That said, it's worth noting that the cost to configure addresses for distribution is fairly static and this may act as something of a lower bound.

37

43

44+That said, we also anticipate that planet prices will be abstracted away from most purchasers, and will be included in bundled annual packages of hosting and data routing services. For this reason, infrastructure service providers (i.e. hosting providers) will likely be the best positioned parties to capture value from planet distribution.

45+

38−While an increase in the supply of Urbit address space is a technical possibility, it would run counter to the economic incentives of Urbit address space owners. This is why we view a galaxy vote to dilute address space as improbable.

46+While an increase in the supply of Urbit address space is a technical possibility, it would run counter to the economic incentives of Urbit address space owners. This is why we view a galaxy vote to dilute address space as improbable.

39

47

40Scarcity may be sufficient alone to drive value, but it’s much more impactful when the unit has some underlying purpose, which brings us to utility.

48Scarcity may be sufficient alone to drive value, but it’s much more impactful when the unit has some underlying purpose, which brings us to utility.

41

49

42## Utility

50## Utility

43−

44Utility (i.e. what Urbit addresses can be used for) has largely been addressed in the previous installation of this series. Briefly, our view is that stars and galaxies are useful for more than simply selling their subsidiary address space. Their use value encompasses their unique functionality on the network and the business models that functionality represents.

51Utility (i.e. what Urbit addresses can be used for) has largely been addressed in the previous installation of this series. Briefly, our view is that stars and galaxies are useful for more than simply selling their subsidiary address space. Their use value encompasses their unique functionality on the network and the business models that functionality represents.

45

52

46−As a refresher, this use value falls in five broad categories.

53+As a refresher, this use value falls in five broad categories.

47−

481. Authentication technology is broadly useful. All Urbit identities — planets, stars, and galaxies — can be used for authenticating one’s Urbit computer, and for authentication in general. Urbit ID was designed for Urbit-specific authentication, but a lot of general functionality can be built on top of this infrastructure. Urbit ID is simple, extensible, and easy to use, making PGP style claims much more useful than they are today.

541. Authentication technology is broadly useful. All Urbit identities — planets, stars, and galaxies — can be used for authenticating one’s Urbit computer, and for authentication in general. Urbit ID was designed for Urbit-specific authentication, but a lot of general functionality can be built on top of this infrastructure. Urbit ID is simple, extensible, and easy to use, making PGP style claims much more useful than they are today.

492. Network infrastructure services represent a potential revenue stream. Stars and galaxies specifically should be understood as providing their owners the opportunity to develop and use network infrastructure. We anticipate that stars and galaxies will eventually charge for infrastructure related services, like hosting and packet routing, and will distinguish themselves on quality and service.

552. Network infrastructure services represent a potential revenue stream. Stars and galaxies specifically should be understood as providing their owners the opportunity to develop and use network infrastructure. We anticipate that stars and galaxies will eventually charge for infrastructure related services, like hosting and packet routing, and will distinguish themselves on quality and service.

50−3. Stars and galaxies are well positioned to offer additional services. Because of their role as high level network nodes, stars and galaxies are uniquely positioned to offer additional services, including content delivery networks (CDNs), Bitcoin and other blockchain-related nodes, 0x relays, and Tor exit nodes.

56+3. Stars and galaxies are well positioned to offer additional services. Because of their role as high level network nodes, stars and galaxies are uniquely positioned to offer additional services, including content delivery networks (CDNs), Bitcoin and other blockchain-related nodes, 0x relays, and Tor exit nodes.

514. Schelling points have value. Because stars and galaxies hold a certain authority on the network (by dint of their relationship to their subsidiary nodes), they act as [Schelling points](https://nav.al/schelling-point), or default hubs, for various activities that will arise as the network grows. Already various groups and communities are beginning to collect around stars. This gravity has value and will eventually be priced.

574. Schelling points have value. Because stars and galaxies hold a certain authority on the network (by dint of their relationship to their subsidiary nodes), they act as [Schelling points](https://nav.al/schelling-point), or default hubs, for various activities that will arise as the network grows. Already various groups and communities are beginning to collect around stars. This gravity has value and will eventually be priced.

52−5. Voting has value. Galaxies exclusively hold a vote on the network. This voting right can be separated from the galaxy itself and transferred, and we anticipate that this will happen eventually. The value of this right has not and may never be priced into the market, though as Urbit adoption grows, the value of a vote may emerge.

58+5. Voting has value. Galaxies exclusively hold a vote on the network. This voting right can be separated from the galaxy itself and transferred, and we anticipate that this will happen eventually. The value of this right has not and may never be priced into the market, though as Urbit adoption grows, the value of a vote may emerge.

53

59

54Utility is only one component of a value calculation. To further develop the inquiry into value, let’s move on to trading factors.

60Utility is only one component of a value calculation. To further develop the inquiry into value, let’s move on to trading factors.

55

61

56## Trading, volume, and liquidity

62## Trading, volume, and liquidity

63+Urbit IDs are individually represented by non-fungible ERC-721 tokens, and can therefore be sold by any platform that supports this token standard. Currently there are three known Urbit-exclusive sales platforms and one generalized ERC-721 platform that list Urbit IDs. Prices for stars and planets are readily available. Volume is low, as no effort has been made to promote the fact of availability, yet the number of [total transactions](https://azimuth.network/stats/events.txt) has increased steadily since the network was launched to Ethereum in 2019, even absent public messaging.

57

64

58−Urbit IDs are individually represented by non-fungible ERC-721 tokens, and can therefore be sold by any platform that supports this token standard. Currently there are three known Urbit-exclusive sales platforms and one generalized ERC-721 platform that list Urbit IDs. Prices for stars and planets are readily available. Volume is low, as no effort has been made to promote the fact of availability, yet the number of [total transactions](https://azimuth.network/stats/events.txt) has increased steadily since the network was launched to Ethereum in 2019, even absent public messaging.

65+<br>

59−

60−

66+<img class="" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt2-tps.svg">

67+<br>

61

68

69+<br>

62−

70+<img class="" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt2-tss.svg">

71+<br>

63

72

64−Buying non-fungible tokens like Urbit IDs is rather different than trading quasi-fungible tokens like Bitcoin (even setting aside the issue of volume). Each Urbit ID is unique, and so they tend to be purchased by end users for their specific characteristics, rather than generically. As an example, the planet `~parret-barret` sold for about $1,000 at a time when most planets were selling for $10-20, perhaps due to its rhyming name. Planets with circular sigils also often sell for significantly more than other planets — we’re not entirely sure why this is the case.

73+Buying non-fungible tokens like Urbit IDs is rather different than trading quasi-fungible tokens like Bitcoin (even setting aside the issue of volume). Each Urbit ID is unique, and so they tend to be purchased by end users for their specific characteristics, rather than generically. As an example, the planet `~parret-barret` sold for about $1,000 at a time when most planets were selling for $10-20, perhaps due to its rhyming name. Planets with circular sigils also often sell for significantly more than other planets — we’re not entirely sure why this is the case.

65

74

66## Planet Sales

75## Planet Sales

67

76

77+<br>

68−

78+<img class="" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt2e-price-eth.svg">

79+<br>

69

80

81+<br>

70−

82+<img class="" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt2e-price-btc.svg">

83+<br>

71

84

72## Star Sales

85## Star Sales

73

86

87+<br>

74−

88+<img class="w-100" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt2e-price-btc-usd.svg">

89+<br>

75

90

76−This ID-specific trading pattern is generally appropriate in our view: Urbit ID isn’t designed to be rapidly traded at high volume. Urbit is more like a house than a fungible good like a currency.

91+This ID-specific trading pattern is generally appropriate in our view: Urbit ID isn’t designed to be rapidly traded at high volume. Urbit is more like a house than a fungible good like a currency.

77

92

78−For the time being buying and selling of Urbit IDs happens through auctions on specific platforms, and via person-to-person transactions, because each transaction is for a _specific_ Urbit ID. Again, Urbit ID is designed in the spirit of property titles, rather than currencies, so this makes sense.

93+For the time being buying and selling of Urbit IDs happens through auctions on specific platforms, and via person-to-person transactions, because each transaction is for a _specific_ Urbit ID. Again, Urbit ID is designed in the spirit of property titles, rather than currencies, so this makes sense.

79

94

80Strictly speaking, liquidity is a measure of the degree to which a given asset will change in value due to a given transaction. In that sense, Urbit address space is likely fairly illiquid. But liquidity can’t be properly understood without volume. As noted above, the volume of transactions on the network has been steadily increasing since inception, and yet the price has remained fairly constant. This seems to indicate a healthy ratio.

95Strictly speaking, liquidity is a measure of the degree to which a given asset will change in value due to a given transaction. In that sense, Urbit address space is likely fairly illiquid. But liquidity can’t be properly understood without volume. As noted above, the volume of transactions on the network has been steadily increasing since inception, and yet the price has remained fairly constant. This seems to indicate a healthy ratio.

81

96

82−

97+<br>

83

98

84−A further impact on liquidity and volume is that of available supply. At present, the majority of Urbit address space is locked by smart contracts. These lockups began to release at varying linear rates in January 2019. All address space will be completely unlocked and tradeable by January 2025. Eventually as both understanding and demand increase, we anticipate that planets will find an equilibrium price, and stars will be repriced accordingly.

99+<img class="ba w-100" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt2b.svg">

85

100

101+<br>

102+

103+A further impact on liquidity and volume is that of available supply. At present, the majority of Urbit address space is locked by smart contracts. These lockups began to release at varying linear rates in January 2019. All address space will be completely unlocked and tradeable by January 2025. Eventually as both understanding and demand increase, we anticipate that planets will find an equilibrium price, and stars will be repriced accordingly.

104+

86−We’ll discuss lockups and spawning limits in more detail in the third installment of this series.

105+We’ll discuss lockups and spawning limits in more detail in the third installment of this series.

87

106

88In our view, this combination of scarcity, utility, and the above trading factors is a useful description of existing market dynamics for Urbit address space. A further description of why Urbit has value lies not just in its trading characteristics, but in the utility of human interaction. This brings us to network effect.

107In our view, this combination of scarcity, utility, and the above trading factors is a useful description of existing market dynamics for Urbit address space. A further description of why Urbit has value lies not just in its trading characteristics, but in the utility of human interaction. This brings us to network effect.

89

108

90## Network effect

109## Network effect

91−

92−Much is made of the concept of network effect and its impact on network valuations generally. The concept is fairly straightforward so long as numbers aren’t applied. Broadly speaking, networks are interconnected systems of people or things. Network effects are mechanisms wherein every new user of a given system makes the system more valuable to every other user.

110+Much is made of the concept of network effect and its impact on network valuations generally. The concept is fairly straightforward so long as numbers aren’t applied. Broadly speaking, networks are interconnected systems of people or things. Network effects are mechanisms wherein every new user of a given system makes the system more valuable to every other user.

93

111

94Urbit is a network of networks, and it’s designed specifically for communities — for communication and collaboration. The more people who use Urbit, the more communities get started by design. The more communities there are, the more likely outsiders get pulled in to join them, and so the virtuous network effect cycle continues.

112Urbit is a network of networks, and it’s designed specifically for communities — for communication and collaboration. The more people who use Urbit, the more communities get started by design. The more communities there are, the more likely outsiders get pulled in to join them, and so the virtuous network effect cycle continues.

95

113

96−Digging deeper, Urbit is unusual as a network for the following interrelated reasons:

114+Digging deeper, Urbit is unusual as a network for the following interrelated reasons:

97−

98−1. Urbit is a platform in the true sense; wherein

115+1. Urbit is a platform in the true sense; wherein

99−2. connections are peer-to-peer;

116+2. connections are peer-to-peer;

100−3. privacy is high;

117+3. privacy is high;

101−4. discoverability is low;

118+4. discoverability is low;

102−5. customization and autonomy are nearly limitless; and yet

119+5. customization and autonomy are nearly limitless; and yet

103−6. the number of possible groups and node connections is essentially unbounded.

120+6. the number of possible groups and node connections is essentially unbounded.

104

121

105The upshot is that Urbit can serve as the meta-network for many different kinds of individual networks, each with their own value. Urbit is much more akin to the internet itself than it is to, say, Facebook. Reed’s and Metcalf’s laws therefore apply to Urbit in some very interesting ways.

122The upshot is that Urbit can serve as the meta-network for many different kinds of individual networks, each with their own value. Urbit is much more akin to the internet itself than it is to, say, Facebook. Reed’s and Metcalf’s laws therefore apply to Urbit in some very interesting ways.

106

123

107## Network laws

124## Network laws

125+Before diving into a discussion of network effect, it's worth noting that although individual tokens and users of those tokens benefit in various ways from a thriving network, the structure of the Urbit network does not grant token holders any rights to profits or losses "generated by the network" as a whole. In fact the very notion is counter to the intent of Urbit's ethos of decentralization. Individuals on the network may profit by their own activities, but there is no central authority profiting off activity in the aggregate; there is no ownership of the network as a whole, and so there are no centralized profits and losses to share. Address space tokens represent one's ownership of their own parcel of land as it were.

108

126

109−Before diving into a discussion of network effect, it's worth noting that although individual tokens and users of those tokens benefit in various ways from a thriving network, the structure of the Urbit network does not grant token holders any rights to profits or losses "generated by the network" as a whole. In fact the very notion is counter to the intent of Urbit's ethos of decentralization. Individuals on the network may profit by their own activities, but there is no central authority profiting off activity in the aggregate; there is no ownership of the network as a whole, and so there are no centralized profits and losses to share. Address space tokens represent one's ownership of their own parcel of land as it were.

127+That said, an entire continent may have aggregate value even though it is distributed. To explore this notion with regards to Urbit, it's worth reviewing the three laws typically cited to express the value of a network as a whole:

128+- Sarnoff’s law states that the value of a network increases proportionally to its size. This is widely understood to understate the value of most modern networks.

129+- Metcalf’s law states that the value of a network is the square of the number of users (n^2).

130+- Reed’s law states that the value of a network increases with the number of groups that can be built on the network. This is expressed as 2^n, where n is the number of groups.

110

131

111−That said, an entire continent may have aggregate value even though it is distributed. To explore this notion with regards to Urbit, it's worth reviewing the three laws typically cited to express the value of a network as a whole:

132+Reed’s law captures the notion that groups vastly increase the density of connections on a network and so scale value more quickly.

112

133

113−- Sarnoff’s law states that the value of a network increases proportionally to its size. This is widely understood to understate the value of most modern networks.

134+Urbit is a network of networks, and so is best described by Reed’s law.

114−- Metcalf’s law states that the value of a network is the square of the number of users (n^2).

115−- Reed’s law states that the value of a network increases with the number of groups that can be built on the network. This is expressed as 2^n, where n is the number of groups.

116

135

117−Reed’s law captures the notion that groups vastly increase the density of connections on a network and so scale value more quickly.

136+Urbit’s unique approach to groups also helps resolve two other problems which lead to value loss in many networks: Urbit’s design significantly reduces both network pollution (i.e. irrelevant feeds) and network congestion (clogged bandwidth), as individual clusters can easily separate their activity from other networks on the platform.

118

137

119−Urbit is a network of networks, and so is best described by Reed’s law.

120

138

121−Urbit’s unique approach to groups also helps resolve two other problems which lead to value loss in many networks: Urbit’s design significantly reduces both network pollution (i.e. irrelevant feeds) and network congestion (clogged bandwidth), as individual clusters can easily separate their activity from other networks on the platform.

122

139

123## Urbit is a platform network

140## Urbit is a platform network

141+It’s important to note that Urbit has utility absent the network, as Urbit OS is in fact a Turing-complete virtual computer. Though the system is designed around communities, individuals can use Urbit to create personal documents, archive data, and write code for the system. This is how Urbit’s total network size can be relatively small and still provide value for individual users and clusters. However, Urbit already has users, and for many of these, critical mass — the point at which the network is more valuable than its cost — has already been reached. In addition, as each of these individual clusters writes code for the platform, positive indirect network effects increase (more utility arises from these individual development efforts).

124

142

125−It’s important to note that Urbit has utility absent the network, as Urbit OS is in fact a Turing-complete virtual computer. Though the system is designed around communities, individuals can use Urbit to create personal documents, archive data, and write code for the system. This is how Urbit’s total network size can be relatively small and still provide value for individual users and clusters. However, Urbit already has users, and for many of these, critical mass — the point at which the network is more valuable than its cost — has already been reached. In addition, as each of these individual clusters writes code for the platform, positive indirect network effects increase (more utility arises from these individual development efforts).

126−

127−This combination of effects makes Urbit significantly more robust than non-platform networks which can’t rely on this intrinsic utility.

143+This combination of effects makes Urbit significantly more robust than non-platform networks which can’t rely on this intrinsic utility.

128

144

129−That said, we do not intend to ever rely simply on this individuated computing utility alone. Urbit is for communities, and Tlon’s primary focus is to increase adoption of the system as a whole, including the network. To this end we’re working steadily to increase functionality of the system, improve messaging, and actively onboard communities.

145+That said, we do not intend to ever rely simply on this individuated computing utility alone. Urbit is for communities, and Tlon’s primary focus is to increase adoption of the system as a whole, including the network. To this end we’re working steadily to increase functionality of the system, improve messaging, and actively onboard communities.

130

146

131## Network identity

147## Network identity

132−

133−Another distinguishing characteristic of Urbit is that identities are pseudonymous but can easily be de-pseudonymized by users at will (though not by outside authorities). This flexibility combined with identity reputation accrual means people can behave in different ways depending on the social context. People can communicate privately, publicly, or in small groups, and they can do it anonymously or otherwise. This natural and extensible approach to social engagement results in personal comfort and drives adoption.

148+Another distinguishing characteristic of Urbit is that identities are pseudonymous but can easily be de-pseudonymized by users at will (though not by outside authorities). This flexibility combined with identity reputation accrual means people can behave in different ways depending on the social context. People can communicate privately, publicly, or in small groups, and they can do it anonymously or otherwise. This natural and extensible approach to social engagement results in personal comfort and drives adoption.

134

149

135## Extensibility

150## Extensibility

136−

137Because Urbit is vastly customizable, and because it’s a network platform for other networks, it can and should grow in ways we can’t predict. Each new use case that develops creates a new market, new communities, and new hubs. Each of these contributes to the diversity of the overall ecosystem, making it vastly more interesting and diverse than anything we might create alone. We expect this extensibility to contribute greatly to retention as users are able to build the world they want to inhabit.

151Because Urbit is vastly customizable, and because it’s a network platform for other networks, it can and should grow in ways we can’t predict. Each new use case that develops creates a new market, new communities, and new hubs. Each of these contributes to the diversity of the overall ecosystem, making it vastly more interesting and diverse than anything we might create alone. We expect this extensibility to contribute greatly to retention as users are able to build the world they want to inhabit.

138

152

139−Urbit is a deeply extensible platform for communities: it’s a network of networks. Users join to be part of communities, then launch communities of their own, further driving growth and engagement in a virtuous cycle.

153+Urbit is a deeply extensible platform for communities: it’s a network of networks. Users join to be part of communities, then launch communities of their own, further driving growth and engagement in a virtuous cycle.

140

154

141−In the next installment of this series, we’ll describe lockups and availability in more detail and will share the data we’ve managed to compile about address space distribution.

155+In the next installment of this series, we’ll describe lockups and availability in more detail and will share the data we’ve managed to compile about address space distribution.

content/blog/value-of-address-space-pt3.md+48−35

@@ -1,45 +1,48 @@

1+++

1+++

2title = "The Value of Urbit Address Space (3 of 3)"

2title = "The Value of Urbit Address Space (3 of 3)"

3−date = "2020-07-09"

3+date = 2020-07-10

4description = ""

4description = ""

5−

6[extra]

5[extra]

7author = "Erik Newton + Galen Wolfe-Pauly"

6author = "Erik Newton + Galen Wolfe-Pauly"

8ship = "~patnes-rigtyn + ~ravmel-ropdyl"

7ship = "~patnes-rigtyn + ~ravmel-ropdyl"

9−image = "https://media.urbit.org/site/posts/essays/value-of-address-space-pt3.jpg"

8+image ="https://media.urbit.org/site/posts/essays/value-of-address-space-pt3.jpg"

10+++

9+++

11

10

11+<br>

12+

12−

13+<img class="ba" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt3.jpg">

14+

15+<br>

13

16

14−_This is the third in a series of three posts on Urbit address space. See also [part 1](https://urbit.org/blog/value-of-address-space-pt1/) and [part 2](https://urbit.org/blog/value-of-address-space-pt2/)._

17+*This is the third in a series of three posts on Urbit address space. See also [part 1](https://urbit.org/blog/value-of-address-space-pt1/) and [part 2](https://urbit.org/blog/value-of-address-space-pt2/).*

15

18

16−It has been some time since we revisited this series of posts, so let’s start with a summary.

19+It has been some time since we revisited this series of posts, so let’s start with a summary.

17

20

18Our framework for understanding the value of Urbit address space is that it’s useful, it’s rare, it’s easy to exchange, and the more that people use it, the more useful it becomes. Let’s briefly review each concept in a little more detail.

21Our framework for understanding the value of Urbit address space is that it’s useful, it’s rare, it’s easy to exchange, and the more that people use it, the more useful it becomes. Let’s briefly review each concept in a little more detail.

19

22

20−First, utility. Urbit address space was designed for logging into Urbit OS, but Urbit ID can be used as an identity primitive for any internet service. That means it’s vastly extensible. Perhaps more importantly, because Urbit IDs at the star and galaxy level represent network infrastructure for the Urbit network, users have already begun to build a range of business models upon them, from hosting providers to community hubs. We explored several of these possibilities in detail in the [first post](https://urbit.org/blog/value-of-address-space-pt1/) in the series, and we also provide a primer on Urbit ID itself.

23+First, utility. Urbit address space was designed for logging into Urbit OS, but Urbit ID can be used as an identity primitive for any internet service. That means it’s vastly extensible. Perhaps more importantly, because Urbit IDs at the star and galaxy level represent network infrastructure for the Urbit network, users have already begun to build a range of business models upon them, from hosting providers to community hubs. We explored several of these possibilities in detail in the [first post](https://urbit.org/blog/value-of-address-space-pt1/) in the series, and we also provide a primer on Urbit ID itself.

21

24

22Second, Urbit address space is finite, and that means it’s scarce. This design, which we explained in more detail in the [second post](https://urbit.org/blog/value-of-address-space-pt2/) in the series, was intended to promote good behavior and to limit spam. So far, that has worked. Scarcity is also impacted by availability of supply, which we’ll explore in this post.

25Second, Urbit address space is finite, and that means it’s scarce. This design, which we explained in more detail in the [second post](https://urbit.org/blog/value-of-address-space-pt2/) in the series, was intended to promote good behavior and to limit spam. So far, that has worked. Scarcity is also impacted by availability of supply, which we’ll explore in this post.

23

26

24−Third, network effects, also described in the second post in this series, have the potential to build upon themselves quite rapidly within the Urbit ecosystem. Urbit is essentially a network of other networks, each owned and controlled by their individual users. For this reason, Urbit’s network effect is best described by Reed’s law, which argues that the value of a network increases with the number of groups that can be built on the network. In Urbit’s case, this number is essentially bounded only by the amount of data that can be stored in Urbit itself, which today is 2GB. That size is already enough to support vastly more groups than anyone has tried to launch, and we plan to grow beyond that limit in the coming year.

27+Third, network effects, also described in the second post in this series, have the potential to build upon themselves quite rapidly within the Urbit ecosystem. Urbit is essentially a network of other networks, each owned and controlled by their individual users. For this reason, Urbit’s network effect is best described by Reed’s law, which argues that the value of a network increases with the number of groups that can be built on the network. In Urbit’s case, this number is essentially bounded only by the amount of data that can be stored in Urbit itself, which today is 2GB. That size is already enough to support vastly more groups than anyone has tried to launch, and we plan to grow beyond that limit in the coming year.

25

28

26−Also in Part 2, we explored trading of Urbit address space. We look at the current price of stars and planets as denominated in both BTC, and USD, and we see that the price of Urbit address space has remained fairly constant since its launch on-chain, while volume has been steadily increasing. The market is continually developing, with more ways to buy and sell Urbit address space cropping up.

29+Also in Part 2, we explored trading of Urbit address space. We look at the current price of stars and planets as denominated in both BTC, and USD, and we see that the price of Urbit address space has remained fairly constant since its launch on-chain, while volume has been steadily increasing. The market is continually developing, with more ways to buy and sell Urbit address space cropping up.

27

30

28−So, to recap: our view is that the value of Urbit address space is a function of its utility, scarcity, network effects, and ease of trade.

31+So, to recap: our view is that the value of Urbit address space is a function of its utility, scarcity, network effects, and ease of trade.

29

32

30−In this post, we don’t expand that framework, but rather explore two elements that are important to actually using the framework. We’ll explain lockups, since they impact scarcity, and we’ll discuss usage metrics — including why we don’t (and in most cases can’t) track them.

33+In this post, we don’t expand that framework, but rather explore two elements that are important to actually using the framework. We’ll explain lockups, since they impact scarcity, and we’ll discuss usage metrics — including why we don’t (and in most cases can’t) track them.

31

34

32−## Lockups and spawning limits

35+## Lockups and spawning limits

33

36

34−One way to think about galaxies, stars, and planets is that they’re different-sized buckets of Urbit IDs. A star contains 2^16^ (~65K) planets, a galaxy contains 2^8^ (256) stars and, in turn, 2^24^ planets (16,777,216). Beyond this nesting pattern, there are three further considerations to note: booted versus unbooted addresses, locked versus unlocked addresses, and planet spawning limits.

37+One way to think about galaxies, stars, and planets is that they’re different-sized buckets of Urbit IDs. A star contains 2¹⁶ (~65K) planets, a galaxy contains 2⁸ (256) stars and, in turn, 2²⁴ planets (16,777,216). Beyond this nesting pattern, there are three further considerations to note: booted versus unbooted addresses, locked versus unlocked addresses, and planet spawning limits.

35

38

36Booted and Unbooted Addresses –

39Booted and Unbooted Addresses –

37

40

38−A booted address is one that has actually been used to boot Urbit OS. By convention, booted addresses are expected to have some existing reputation outside of their name alone, since they’ve been used on the network. Reputation, good and bad, comes in many forms. Did the address operate any useful infrastructure? Did it get placed on any blacklists for spam or abuse? Did it simply send and receive messages? The ability to programatically track reputation is still in its infancy, but we expect the tooling to develop as Urbit grows.

41+A booted address is one that has actually been used to boot Urbit OS. By convention, booted addresses are expected to have some existing reputation outside of their name alone, since they’ve been used on the network. Reputation, good and bad, comes in many forms. Did the address operate any useful infrastructure? Did it get placed on any blacklists for spam or abuse? Did it simply send and receive messages? The ability to programatically track reputation is still in its infancy, but we expect the tooling to develop as Urbit grows.

39

42

40−Unbooted addresses, on the other hand, have no reputation. Both booted and unbooted addresses can be transferred between owners, but booted addresses will likely vary widely in price depending on the reputation each of them has acquired, and how they’ve been used.

43+Unbooted addresses, on the other hand, have no reputation. Both booted and unbooted addresses can be transferred between owners, but booted addresses will likely vary widely in price depending on the reputation each of them has acquired, and how they’ve been used.

41

44

42−For the purposes of this discussion, we’re primarily referring to unbooted addresses, as they have no reputation, and so are more similar to one another. We anticipate that booted addresses will trade infrequently — and likely via broker or auction, since users will prefer to control the reputation of the ID they’ve developed, rather than transfer that reputation to another.

45+For the purposes of this discussion, we’re primarily referring to unbooted addresses, as they have no reputation, and so are more similar to one another. We anticipate that booted addresses will trade infrequently — and likely via broker or auction, since users will prefer to control the reputation of the ID they’ve developed, rather than transfer that reputation to another.

43

46

44Locked vs. Unlocked Addresses –

47Locked vs. Unlocked Addresses –

45

48

@@ -47,44 +50,54 @@ At present, the majority of Urbit address space is locked by smart contracts. Wh

47

50

48A locked star is held in a contract and can neither be booted nor issue planets. The lockup contracts can be examined on [GitHub](https://github.com/urbit/azimuth).

51A locked star is held in a contract and can neither be booted nor issue planets. The lockup contracts can be examined on [GitHub](https://github.com/urbit/azimuth).

49

52

50−In practice, the only Urbit IDs that are ‘locked’ are stars. A galaxy that is said to be locked is simply a galaxy whose stars are currently held by a lockup contract. A locked galaxy can be transferred (i.e. sold or simply moved to a new key) and booted (importantly, any galaxy—booted or not—can vote), but it can’t issue stars until the lockup contract expires.

53+In practice, the only Urbit IDs that are ‘locked’ are stars. A galaxy that is said to be locked is simply a galaxy whose stars are currently held by a lockup contract. A locked galaxy can be transferred (i.e. sold or simply moved to a new key) and booted (importantly, any galaxy—booted or not—can vote), but it can’t issue stars until the lockup contract expires.

51

54

55+<br>

52−

56+<img class="ba" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt3-graph1.png">

57+<br>

53

58

59+<br>

54−

60+<img class="ba" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt3-graph2.png">

61+<br>

55

62

56−These lockups all began to release at varying linear rates in January 2019 (specifically on Tue Jan 08 23:34:41 2019 UTC).

63+These lockups all began to release at varying linear rates in January 2019 (specifically on Tue Jan 08 23:34:41 2019 UTC).

57

64

58The various linear unlocking schedules are grouped as follows:

65The various linear unlocking schedules are grouped as follows:

59

66

60- The urbit.org addresses, and early prize winners unlock linearly from 2019-2021.

67- The urbit.org addresses, and early prize winners unlock linearly from 2019-2021.

61−- Tlon, its founders, employees, and most purchasers from Tlon were frozen for a year, and now unlock linearly from 2020-2024.

68+- Tlon, its founders, employees, and most purchasers from Tlon were frozen for a year, and now unlock linearly from 2020-2024.

62−- 2018 private buyers were frozen for a year, and then began to unlock linearly over the course of one or three years, depending on the terms of their respective contracts.

69+- 2018 private buyers were frozen for a year, and then began to unlock linearly over the course of one or three years, depending on the terms of their respective contracts.

63- Earlier private buyer addresses—including those in our first two crowdsales—were unlocked right away.

70- Earlier private buyer addresses—including those in our first two crowdsales—were unlocked right away.

64

71

65−As of January 2020, 17,283 stars were unlocked and tradeable. By January 2021, 33,355 will be available. On January 9, 2024, all 65,536 stars will be unlocked and available for trading.

66

72

73+As of January 2020, 17,283 stars were unlocked and tradeable. By January 2021, 33,355 will be available. On January 9, 2024, all 65,536 stars will be unlocked and available for trading.

74+

67−Being unlocked does not necessarily mean that a star can spawn all of its planets. For that calculation, we must turn to spawning limits.

75+Being unlocked does not necessarily mean that a star can spawn all of its planets. For that calculation, we must turn to spawning limits.

76+

68

77

69Spawning Limits –

78Spawning Limits –

70

79

71−Unlocked stars are further gated by the number of planets they’re able to spawn. Every unlocked star was immediately able to spawn 1024 planets from the moment Urbit went live on the blockchain in January 2019—we wanted everyone to be able to invite some friends to their communities right away. From that date forward, the spawnable amount doubles every year (365 days), maxing out at 65,535 spawnable planets after 6 years.

80+Unlocked stars are further gated by the number of planets they’re able to spawn. Every unlocked star was immediately able to spawn 1024 planets from the moment Urbit went live on the blockchain in January 2019—we wanted everyone to be able to invite some friends to their communities right away. From that date forward, the spawnable amount doubles every year (365 days), maxing out at 65,535 spawnable planets after 6 years.

72

81

82+<br>

73−

83+<img class="ba" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt3-graph3.png">

84+<br>

74

85

75When we layer the spawning limits over the various lockup contracts, we find that all Urbit address space is both unlocked and spawnable by January 9, 2025.

86When we layer the spawning limits over the various lockup contracts, we find that all Urbit address space is both unlocked and spawnable by January 9, 2025.

76

87

77## Address space distribution

88## Address space distribution

78

89

79−Address space has continued to change hands since we put Urbit on-chain in January 2019. At that time, we had a fairly granular understanding of who owned what. Today we only have precise numbers for the Tlon and urbit.org owned address space. Galaxies change hands quite infrequently, so we know more about that ownership than stars and planets. We know next to nothing about the distribution of planets.

90+Address space has continued to change hands since we put Urbit on-chain in January 2019. At that time, we had a fairly granular understanding of who owned what. Today we only have precise numbers for the Tlon and urbit.org owned address space. Galaxies change hands quite infrequently, so we know more about that ownership than stars and planets. We know next to nothing about the distribution of planets.

80

91

81−We consider the opacity of our understanding about transactions on the network to be a privacy feature rather than a bug. To be specific about the information we can collect here: first, we don’t know anything about users beyond their ETH address, and second, we can’t tell the difference between a transfer of an address, and the re-keying of an address. This means we’re never entirely sure if a transfer has in fact occurred; we only know that the address has changed.

92+We consider the opacity of our understanding about transactions on the network to be a privacy feature rather than a bug. To be specific about the information we can collect here: first, we don’t know anything about users beyond their ETH address, and second, we can’t tell the difference between a transfer of an address, and the re-keying of an address. This means we’re never entirely sure if a transfer has in fact occurred; we only know that the address has changed.

82

93

83−The chart below is an estimate (as of January 2020) based on our general understanding of how galaxies are distributed. Much of this is anecdotal, and it’s largely based on the very few transactions we’ve observed within the galaxy table since Urbit went on chain in 2019. This chart should therefore be understood as incomplete, and an estimate only.

94+The chart below is an estimate (as of January 2020) based on our general understanding of how galaxies are distributed. Much of this is anecdotal, and it’s largely based on the very few transactions we’ve observed within the galaxy table since Urbit went on chain in 2019. This chart should therefore be understood as incomplete, and an estimate only.

84

95

96+<br>

85−

97+<img class="ba" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt3-graph4.png">

98+<br>

86

99

87−Address space distribution is best understood in terms of galaxies and stars independently, as they’re distinct assets. The chart above only illustrates galaxy distribution, but describes Tlon’s “naked” galaxy holdings, which are galaxies empty of their stars. These galaxies are empty because the stars they once contained have been distributed, primarily to Tlon contractors, employees, and to certain private buyers.

100+Address space distribution is best understood in terms of galaxies and stars independently, as they’re distinct assets. The chart above only illustrates galaxy distribution, but describes Tlon’s “naked” galaxy holdings, which are galaxies empty of their stars. These galaxies are empty because the stars they once contained have been distributed, primarily to Tlon contractors, employees, and to certain private buyers.

88

101

89We believe that wide distribution is important to the health of the network and the growth of Urbit as a whole. Our own distribution efforts are focused on disbursing Urbit address space ownership as broadly as possible to those interested in using and developing the network.

102We believe that wide distribution is important to the health of the network and the growth of Urbit as a whole. Our own distribution efforts are focused on disbursing Urbit address space ownership as broadly as possible to those interested in using and developing the network.

90

103

@@ -98,19 +111,19 @@ First, it’s too early. Urbit’s current users are a fanbase of pioneers who a

98

111

99We’re laying the groundwork so that we can, in earnest, invite our friends and communities to a network they will love. That means we’re designing smooth onboarding, an elegant user interface, and increasing the stability of both the system and network. Tlon’s forthcoming hosting services will vastly reduce barriers to entry, and will be our first major push into the public sphere.

112We’re laying the groundwork so that we can, in earnest, invite our friends and communities to a network they will love. That means we’re designing smooth onboarding, an elegant user interface, and increasing the stability of both the system and network. Tlon’s forthcoming hosting services will vastly reduce barriers to entry, and will be our first major push into the public sphere.

100

113

101−Second, and perhaps more importantly, capturing data about traction on the network is difficult by design. Due to Urbit's privacy-forward architecture, there’s quite a lot we will never know. Once an Urbit ID is up and running, we don’t know how often it operates, where it’s hosted, or what it’s doing. This makes capturing usage metrics challenging, but we think this is the right problem to have.

114+Second, and perhaps more importantly, capturing data about traction on the network is difficult by design. Due to Urbit's privacy-forward architecture, there’s quite a lot we will never know. Once an Urbit ID is up and running, we don’t know how often it operates, where it’s hosted, or what it’s doing. This makes capturing usage metrics challenging, but we think this is the right problem to have.

102

115

103The Network Explorer –

116The Network Explorer –

104

117

105In the next several months we plan to roll out the first iteration of a network explorer that will allow users to visualize the structure and composition of the network as well as some basic activity data. Our first version of the network explorer will include representations of how the various layers of address space fit together, the finiteness of address space, historical uptime for nodes, and the various unlocking schedules.

118In the next several months we plan to roll out the first iteration of a network explorer that will allow users to visualize the structure and composition of the network as well as some basic activity data. Our first version of the network explorer will include representations of how the various layers of address space fit together, the finiteness of address space, historical uptime for nodes, and the various unlocking schedules.

106−The network explorer will also allow users to zoom in on various nodes to learn more about them and what they offer.

119+The network explorer will also allow users to zoom in on various nodes to learn more about them and what they offer.

107Urbit’s privacy-forward design makes collection of data appropriately impossible in many cases. That said, the network explorer should begin to collect all the elements of the value framework we’ve laid out here in one dynamic visualization.

120Urbit’s privacy-forward design makes collection of data appropriately impossible in many cases. That said, the network explorer should begin to collect all the elements of the value framework we’ve laid out here in one dynamic visualization.

108

121

109Closing –

122Closing –

110

123

111−We have long said that Urbit address space had value because it was both useful and scarce. Taking a deeper look, we found that some limited liquidity, and network effect also play an important role in the value framework.

124+We have long said that Urbit address space had value because it was both useful and scarce. Taking a deeper look, we found that some limited liquidity, and network effect also play an important role in the value framework.

112

125

113−All of the factors that make up our framework are, in turn, impacted by availability of supply and by user growth. In the Urbit ecosystem, supply is effectively gated—as described above—in order to prevent flooding of the network.

126+All of the factors that make up our framework are, in turn, impacted by availability of supply and by user growth. In the Urbit ecosystem, supply is effectively gated—as described above—in order to prevent flooding of the network.

114

127

115User growth, on the other hand, is something we simply have not yet pursued in earnest. Instead, our development efforts have been focused on enhancing usability and stability of the platform. Our focus on user growth will begin as we roll out hosting. Once that happens, usage metrics will become both more interesting and more relevant.

128User growth, on the other hand, is something we simply have not yet pursued in earnest. Instead, our development efforts have been focused on enhancing usability and stability of the platform. Our focus on user growth will begin as we roll out hosting. Once that happens, usage metrics will become both more interesting and more relevant.

116

129

content/blog/what-is-urbit-for.md+62−67

@@ -1,90 +1,85 @@

1+++

1+++

2title = "What is Urbit For?"

2title = "What is Urbit For?"

3−date = "2016-05-10"

3+date = 2016-05-11

4description = "A vision of the Urbit-powered future."

4description = "A vision of the Urbit-powered future."

5−aliases = [

6− "/posts/essays/what-is-urbit-for",

5+aliases = ["/posts/essays/what-is-urbit-for", "/posts/what-is-urbit-for"]

7− "/posts/what-is-urbit-for"

8−]

9−

10[extra]

6[extra]

11author = "Galen Wolfe-Pauly"

7author = "Galen Wolfe-Pauly"

12ship = "~ravmel-ropdyl"

8ship = "~ravmel-ropdyl"

13−image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/what-is-urbit-for.jpg"

9+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/what-is-urbit-for.jpg"

14+++

10+++

15−

16

11

17

12

18Open platforms don't beat closed systems just because they're open.

13Open platforms don't beat closed systems just because they're open.

19−They win because you can do more exciting things with them. We

14+They win because you can do more exciting things with them. We

20believe we're overdue for new infrastructure not purely on principle:

15believe we're overdue for new infrastructure not purely on principle:

21but because we think you can build better products on top.

16but because we think you can build better products on top.

22

17

23We look forward to a future where your fleet of Urbits run the devices

18We look forward to a future where your fleet of Urbits run the devices

24throughout your house, keep your biometric data in sync with the data

19throughout your house, keep your biometric data in sync with the data

25−center and hold your secure medical and financial data. Today Urbit

20+center and hold your secure medical and financial data. Today Urbit

26is just a proof of concept — but we see a road from here to there.

21is just a proof of concept — but we see a road from here to there.

27

22

28## Today

23## Today

29

24

30−These are things that work but are under development today. We expect

25+These are things that work but are under development today. We expect

31them to improve and stabilize in the coming months.

26them to improve and stabilize in the coming months.

32

27

33### Making the web programmable

28### Making the web programmable

34

29

35The first thing your Urbit can do is act as a transparent layer to

30The first thing your Urbit can do is act as a transparent layer to

36−your existing services. We'd like urbit to be usable as a self-hosted

31+your existing services. We'd like urbit to be usable as a self-hosted

37−IFTTT for geeks. Your urbit can hold your keys, store data, run

32+IFTTT for geeks. Your urbit can hold your keys, store data, run

38−programs and seamlessly connect to your existing services. Plus, with

33+programs and seamlessly connect to your existing services. Plus, with

39a global revision controlled filesystem it's easy to share API

34a global revision controlled filesystem it's easy to share API

40connectors and keep them up to date.

35connectors and keep them up to date.

41

36

42With an Urbit running on your machine you can `ls` your Gmail from

37With an Urbit running on your machine you can `ls` your Gmail from

43−Unix. Write a short script to poll Twitter on a keyword and deliver

38+Unix. Write a short script to poll Twitter on a keyword and deliver

44−the results to your email or into a Slack channel. Send an SMS when

39+the results to your email or into a Slack channel. Send an SMS when

45−an HTTP request doesn't resolve. These are just a few examples. Your

40+an HTTP request doesn't resolve. These are just a few examples. Your

46Urbit is designed to make data trapped in your existing services feel

41Urbit is designed to make data trapped in your existing services feel

47like an extension of your local programming environment.

42like an extension of your local programming environment.

48

43

49### Self-hosted publishing and communication

44### Self-hosted publishing and communication

50

45

51Additionally your Urbit is a flexible platform for publishing data to

46Additionally your Urbit is a flexible platform for publishing data to

52−the web and communicating with others. Sort of like a self-hosted

47+the web and communicating with others. Sort of like a self-hosted

53−Slack, WordPress and Wiki in one. It's more common to use many tools

48+Slack, WordPress and Wiki in one. It's more common to use many tools

54−for sharing our content and communicating. Urbit is designed to bring

49+for sharing our content and communicating. Urbit is designed to bring

55those tools together; giving the individual control over their

50those tools together; giving the individual control over their

56creative output.

51creative output.

57

52

58Simply write markdown in your favorite editor and have an Urbit sync

53Simply write markdown in your favorite editor and have an Urbit sync

59−them to the cloud. Use React components to control your layout and

54+them to the cloud. Use React components to control your layout and

60−extend our toolset. Host your own discussion channels and comment

55+extend our toolset. Host your own discussion channels and comment

61−threads. On a computer you own and control, whose source is 100%

56+threads. On a computer you own and control, whose source is 100%

62open.

57open.

63

58

64### Cryptographic identity

59### Cryptographic identity

65

60

66Your Urbit is your digital identity, cryptographically secured but not

61Your Urbit is your digital identity, cryptographically secured but not

67−controlled by any central authority. The Urbit PKI fills a gap that

62+controlled by any central authority. The Urbit PKI fills a gap that

68−remains unsolved on the web. We can send encrypted messages, securely

63+remains unsolved on the web. We can send encrypted messages, securely

69exchange digital currency, but how do I know who anyone is?

64exchange digital currency, but how do I know who anyone is?

70

65

71Your Urbit can post public proof to your third party services and its

66Your Urbit can post public proof to your third party services and its

72−validity is easily auditable. Using Urbit as an identity scheme for

67+validity is easily auditable. Using Urbit as an identity scheme for

73new services would be a great decentralized alternative to 'Sign in

68new services would be a great decentralized alternative to 'Sign in

74with [company x]'.

69with [company x]'.

75

70

76## Tomorrow

71## Tomorrow

77

72

78Urbit's crypto isn't tested, the network still gets rebooted from time

73Urbit's crypto isn't tested, the network still gets rebooted from time

79−to time. The next milestone comes when Urbit matures to the point

74+to time. The next milestone comes when Urbit matures to the point

80that it's as reliable as its SaaS counterparts.

75that it's as reliable as its SaaS counterparts.

81

76

82### Lifestreams, finally

77### Lifestreams, finally

83

78

84The combination of great API tools and great publishing tools means we

79The combination of great API tools and great publishing tools means we

85can finally build an integrated interface for today's social networks.

80can finally build an integrated interface for today's social networks.

86−The web is full of streams of data. For the user there's not much

81+The web is full of streams of data. For the user there's not much

87−utility in bouncing from service to service. Instead, it'd be great

82+utility in bouncing from service to service. Instead, it'd be great

88to have general-purpose tools for consuming and publishing data.

83to have general-purpose tools for consuming and publishing data.

89Imagine a Medium-quality interface that makes no distinction between

84Imagine a Medium-quality interface that makes no distinction between

90Facebook and Twitter; SMS and Skype.

85Facebook and Twitter; SMS and Skype.

@@ -92,54 +87,54 @@ Facebook and Twitter; SMS and Skype.

92### Secret storage, web3

87### Secret storage, web3

93

88

94Bitcoin and Ethereum are both part of a new era of decentralized

89Bitcoin and Ethereum are both part of a new era of decentralized

95−infrastructure that's just beginning. For the blockchain to realize

90+infrastructure that's just beginning. For the blockchain to realize

96its potential individuals need ought to have a way to host their own

91its potential individuals need ought to have a way to host their own

97−nodes. At the very least, individuals need a reliable place to keep

92+nodes. At the very least, individuals need a reliable place to keep

98−their secrets. What's more, the blockchain isn't designed for

93+their secrets. What's more, the blockchain isn't designed for

99−computation. It's great for contracts and currency, but too slow for

94+computation. It's great for contracts and currency, but too slow for

100practical computing.

95practical computing.

101

96

102−Urbit is a great complement to the blockchain. Your Urbit can safely

97+Urbit is a great complement to the blockchain. Your Urbit can safely

103store your keys, providing an always-available keychain on the

98store your keys, providing an always-available keychain on the

104−network. Even better, your Urbit can hold your blockchain assets and

99+network. Even better, your Urbit can hold your blockchain assets and

105−provide an off-chain computation layer. Urbit's computation doesn't

100+provide an off-chain computation layer. Urbit's computation doesn't

106provide any kind of distributed consensus, but our computation model

101provide any kind of distributed consensus, but our computation model

107−is very simple and lends itself well to auditing. This makes it a

102+is very simple and lends itself well to auditing. This makes it a

108very blockchain-friendly platform.

103very blockchain-friendly platform.

109

104

110## Over the horizon

105## Over the horizon

111

106

112If there's one thing we know from the history of personal computers

107If there's one thing we know from the history of personal computers

113it's that computers are always expanding into more and more of our

108it's that computers are always expanding into more and more of our

114−lives. The more _personal_ our computers get the more they need to

109+lives. The more _personal_ our computers get the more they need to

115−reflect our thinking and our relationships. We don't know exactly

110+reflect our thinking and our relationships. We don't know exactly

116what this will look like, but we can certainly speculate on the areas

111what this will look like, but we can certainly speculate on the areas

117that deserve the most attention.

112that deserve the most attention.

118

113

119### Data permanence and software competition

114### Data permanence and software competition

120

115

121Right now applications and data are practically the same thing.

116Right now applications and data are practically the same thing.

122−There's no practical way for the user to separate them. Apps come and

117+There's no practical way for the user to separate them. Apps come and

123−go, either by falling out of fashion or actually shutting down. In

118+go, either by falling out of fashion or actually shutting down. In

124−both cases our data becomes orphaned. There's no practical way for us

119+both cases our data becomes orphaned. There's no practical way for us

125−to get it back. The raw data from your LiveJournal is as good as a

120+to get it back. The raw data from your LiveJournal is as good as a

126−floppy disk from the 80s. Computers hold the records of our lives.

121+floppy disk from the 80s. Computers hold the records of our lives.

127Losing the history of the world to bitrot is a preventable problem.

122Losing the history of the world to bitrot is a preventable problem.

128

123

129Since each person owns their own Urbit there's no way to separate the

124Since each person owns their own Urbit there's no way to separate the

130−user from their data. When you run software on your Urbit you

125+user from their data. When you run software on your Urbit you

131_actually run it_ and your programs manipulate data that _you own_.

126_actually run it_ and your programs manipulate data that _you own_.

132−The individual has permanent access to their data by design. Ensuring

127+The individual has permanent access to their data by design. Ensuring

133its durability is a technical problem, not a license agreement

128its durability is a technical problem, not a license agreement

134problem.

129problem.

135

130

136When individuals are running their own software it's no longer

131When individuals are running their own software it's no longer

137−possible to lock them in by controlling their data. Instead, software

132+possible to lock them in by controlling their data. Instead, software

138−has to actually compete on utility. If one could trivially replace

133+has to actually compete on utility. If one could trivially replace

139the interface for Evernote with one from another developer for $10

134the interface for Evernote with one from another developer for $10

140−wouldn't it be worth it? Even more so with Urbit, since after

135+wouldn't it be worth it? Even more so with Urbit, since after

141installing software you're not dependent on the developer staying

136installing software you're not dependent on the developer staying

142−alive. You're running a local copy. This model puts pressure on

137+alive. You're running a local copy. This model puts pressure on

143applications to interoperate better and become more modular.

138applications to interoperate better and become more modular.

144

139

145### Reputation

140### Reputation

@@ -150,14 +145,14 @@ Just like the marriage of applications and data, reputation is

150permanently tethered to and jealously guarded by the services we use.

145permanently tethered to and jealously guarded by the services we use.

151

146

152For example, today we have karma systems on a per-site basis, like

147For example, today we have karma systems on a per-site basis, like

153−Reddit. Is there any reason that individuals shouldn't have karma

148+Reddit. Is there any reason that individuals shouldn't have karma

154−scores per-topic? An individual's authority on a certain topic could

149+scores per-topic? An individual's authority on a certain topic could

155−be verified by other experts while still denied by detractors. It's

150+be verified by other experts while still denied by detractors. It's

156−easy to extend this to services like Yelp. With a strong identity

151+easy to extend this to services like Yelp. With a strong identity

157system it's possible for pseudonymous reviews to be counted with real

152system it's possible for pseudonymous reviews to be counted with real

158−value. We'd no longer need a central authority for deciding on the

153+value. We'd no longer need a central authority for deciding on the

159reputation of a restaurant, but just a way to pseudonymously aggregate

154reputation of a restaurant, but just a way to pseudonymously aggregate

160−individual opinions. There's a broad swath of territory ripe for

155+individual opinions. There's a broad swath of territory ripe for

161exploration here.

156exploration here.

162

157

163### Privacy

158### Privacy

@@ -165,32 +160,32 @@ exploration here.

165With a reliably secure place to store your data on the network,

160With a reliably secure place to store your data on the network,

166wouldn't you want to store even more personal information yourself?

161wouldn't you want to store even more personal information yourself?

167Why is it that we don't store our own medical records, biometric data

162Why is it that we don't store our own medical records, biometric data

168−or financial data? In a world where we have a safe place to keep them

163+or financial data? In a world where we have a safe place to keep them

169we wouldn't require anyone else to keep them for us.

164we wouldn't require anyone else to keep them for us.

170

165

171−Furthermore, we'd be able to share them pseudonymously. One could

166+Furthermore, we'd be able to share them pseudonymously. One could

172imagine medical research or census-like polling being done without

167imagine medical research or census-like polling being done without

173−compromising the privacy of those involved. This also lowers the

168+compromising the privacy of those involved. This also lowers the

174−barrier to entry for fintech and medical software developers. If I

169+barrier to entry for fintech and medical software developers. If I

175can run my own personal health and finance software that can reliably

170can run my own personal health and finance software that can reliably

176access my own transactions and medical records, what would developers

171access my own transactions and medical records, what would developers

177come up with?

172come up with?

178

173

179### IoT

174### IoT

180

175

181−What needs a network _and_ computation? Devices. Turning a unix box

176+What needs a network _and_ computation? Devices. Turning a unix box

182into a usable platform for hardware isn't something that any

177into a usable platform for hardware isn't something that any

183−individual manufacturer is incentivized to do. For the internet of

178+individual manufacturer is incentivized to do. For the internet of

184things to actually work we need a platform for devices to interoperate

179things to actually work we need a platform for devices to interoperate

185−simply and securely. Urbit is up to the task. Your Urbit isn't just

180+simply and securely. Urbit is up to the task. Your Urbit isn't just

186a single instance, it can sign the keys for a whole network of Urbits

181a single instance, it can sign the keys for a whole network of Urbits

187intended to be used for your devices, sensors, appliances, machines,

182intended to be used for your devices, sensors, appliances, machines,

188robots, VR helmet, etc.

183robots, VR helmet, etc.

189

184

190The future of the individual's computing experience may very likely be

185The future of the individual's computing experience may very likely be

191−among many different devices. Bret Victor's 'Seeing Spaces' is a

186+among many different devices. Bret Victor's 'Seeing Spaces' is a

192−great exploration of what this future may look like. For the

187+great exploration of what this future may look like. For the

193industrial enterprise there's a whole other set of parallel problems:

188industrial enterprise there's a whole other set of parallel problems:

194tracking inventory, controlling a vast array of machines, and managing

189tracking inventory, controlling a vast array of machines, and managing

195−logistics. In both cases we need a decentralized network and

190+logistics. In both cases we need a decentralized network and

196−computing platform. Urbit is up to the task.

191+computing platform. Urbit is up to the task.

content/blog/why-hoon.md+9−11

@@ -1,8 +1,7 @@

1+++

1+++

2title = "Why Hoon?"

2title = "Why Hoon?"

3−date = "2019-11-13"

3+date = 2019-11-14

4description = "The promise of Urbit lies in its reimagination of the digital world using components that are as constrained and limited as possible."

4description = "The promise of Urbit lies in its reimagination of the digital world using components that are as constrained and limited as possible."

5−

6[extra]

5[extra]

7author = "Ted Blackman"

6author = "Ted Blackman"

8ship = "~rovnys-ricfer"

7ship = "~rovnys-ricfer"

@@ -20,7 +19,6 @@ sense.

20

19

21In particular, the problems Hoon solves that aren't solved by other

20In particular, the problems Hoon solves that aren't solved by other

22functional languages are:

21functional languages are:

23−

24- Compile and run other code in a typesafe manner at full speed,

22- Compile and run other code in a typesafe manner at full speed,

25- Typesafe metaprogramming, and

23- Typesafe metaprogramming, and

26- Hot code reload and online data migration.

24- Hot code reload and online data migration.

@@ -125,17 +123,17 @@ Hoon and Nock have several unusual properties:

125 converted to each other. Lisp dialects are also homoiconic, but Hoon

123 converted to each other. Lisp dialects are also homoiconic, but Hoon

126 and Nock are arguably even more so, since things like closures and the

124 and Nock are arguably even more so, since things like closures and the

127 environment are just Nock trees. We even have a statically typed

125 environment are just Nock trees. We even have a statically typed

128− metacircular interpreter called `+mule`. We run userspace code

126+ metacircular interpreter called <code>+mule</code>. We run userspace code

129 metacircularly with negligible performance overhead because of Urbit's

127 metacircularly with negligible performance overhead because of Urbit's

130− jet system. In Lisp, "eval is evil" is a common saying, but in Urbit,

128+ jet system. In Lisp "eval is evil" is a common saying but, in Urbit,

131 eval is a first-class feature.

129 eval is a first-class feature.

132

130

133- **Universally serializable**. There's one serialization format, called

131- **Universally serializable**. There's one serialization format, called

134 "jam", for any piece of code or data in the system. This makes it so

132 "jam", for any piece of code or data in the system. This makes it so

135 that deserialization has just one function, a few hundred lines of C,

133 that deserialization has just one function, a few hundred lines of C,

136 as its security attack surface. It also facilitates portability of

134 as its security attack surface. It also facilitates portability of

137− the virtual machine state, since this function can be called on the

135+ the virtual machine state, and it turns out to be useful in a bunch of

138− top-level VM state itself to generate a portable snapshot.

136+ places in the system.

139

137

140- **Jetted**. A jet is a piece of code that the Nock interpreter has that

138- **Jetted**. A jet is a piece of code that the Nock interpreter has that

141 reimplements a Nock function in some other, faster language. The `+dec`

139 reimplements a Nock function in some other, faster language. The `+dec`

@@ -145,7 +143,7 @@ Hoon and Nock have several unusual properties:

145 the runtime has a matching jet, it will use that instead of the Nock

143 the runtime has a matching jet, it will use that instead of the Nock

146 implementation. Nock isn't as slow as you might think, especially

144 implementation. Nock isn't as slow as you might think, especially

147 considering it's a minimal, dynamic, axiomatic language.

145 considering it's a minimal, dynamic, axiomatic language.

148−

146+<br/><br/>

149 This arrangement has the deeper implication that all code written in

147 This arrangement has the deeper implication that all code written in

150 Nock is best considered as a specification for a program, which can be

148 Nock is best considered as a specification for a program, which can be

151 executed directly but might never run at all due to being jetted.

149 executed directly but might never run at all due to being jetted.

@@ -185,8 +183,8 @@ Hoon and Nock have several unusual properties:

185 consists of the standard library (itself a stack of cores), and

183 consists of the standard library (itself a stack of cores), and

186 possibly a "sample" (function argument).

184 possibly a "sample" (function argument).

187

185

188−- **The type system has several unusual features**. It's intensional, in

186+- **The type system has several unusual features**. It's intentional, in

189− the sense that all constructs are first-class and can be up-cast to

187+ the sense that all constructs are first-class and can be down-cast to

190 `noun`, Hoon's "any" or "top" type that matches all Nock nouns. Types

188 `noun`, Hoon's "any" or "top" type that matches all Nock nouns. Types

191 are also used as scopes, so they store all of Hoon's variable names

189 are also used as scopes, so they store all of Hoon's variable names

192 and docstrings. The type system uses an unusual macro-like feature

190 and docstrings. The type system uses an unusual macro-like feature

@@ -199,7 +197,7 @@ Hoon and Nock have several unusual properties:

199 lot of the system manipulates types. In particular, the `!>` rune, when

197 lot of the system manipulates types. In particular, the `!>` rune, when

200 applied to a piece of data, uses compile-time type reflection to

198 applied to a piece of data, uses compile-time type reflection to

201 produce something called a "vase": a pair of type and data, similar to

199 produce something called a "vase": a pair of type and data, similar to

202− a `Data.Dynamic` in Haskell, or a limited form of a dependent pair.

200+ a <code>Data.Dynamic</code> in Haskell, or a limited form of a dependent pair.

203 Since the Arvo kernel does a lot of dynamic compilation, it uses vases

201 Since the Arvo kernel does a lot of dynamic compilation, it uses vases

204 to implement something akin to a dynamically typed language using

202 to implement something akin to a dynamically typed language using

205 Hoon. This allows for type-safe dynamic program loading, program

203 Hoon. This allows for type-safe dynamic program loading, program

content/blog/why-urbit-probably-does-not-need-a-blockchain.md+154−160

@@ -1,19 +1,13 @@

1+++

1+++

2title = "Why Urbit Probably Doesn't Need a Blockchain"

2title = "Why Urbit Probably Doesn't Need a Blockchain"

3−date = "2016-07-13"

3+date = 2016-07-14

4description = "Urbit (probably) doesn't need a blockchain, because the Urbit address-space PKI is a special case of a consensus ledger."

4description = "Urbit (probably) doesn't need a blockchain, because the Urbit address-space PKI is a special case of a consensus ledger."

5−aliases = [

6− "/posts/essays/why-urbit-probably-does-not-need-a-blockchain/",

5+aliases = ["/posts/essays/why-urbit-probably-does-not-need-a-blockchain/", "/posts/why-urbit-probably-does-not-need-a-blockchain/", "/blog/blockchain/"]

7− "/posts/why-urbit-probably-does-not-need-a-blockchain/",

8− "/blog/blockchain/"

9−]

10−

11[extra]

6[extra]

12author = "Curtis Yarvin"

7author = "Curtis Yarvin"

13ship = "~sorreg-namtyv"

8ship = "~sorreg-namtyv"

14image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/why-urbit-probably-does-not-need-a-blockchain.jpg"

9image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/why-urbit-probably-does-not-need-a-blockchain.jpg"

15+++

10+++

16−

17

11

18

12

19TLDR: Urbit (probably) doesn't need a blockchain, because the Urbit

13TLDR: Urbit (probably) doesn't need a blockchain, because the Urbit

@@ -32,27 +26,27 @@ Gabriel's famous

32["worse is better"](https://en.wikipedia.org/wiki/Worse_is_better) essay.

26["worse is better"](https://en.wikipedia.org/wiki/Worse_is_better) essay.

33

27

34There are two kinds of mindsets when approaching hard technical

28There are two kinds of mindsets when approaching hard technical

35−problems. The "MIT" mindset, more typical among mathematicians and

29+problems. The "MIT" mindset, more typical among mathematicians and

36scientists, wants to attack the problem as its simplest and broadest

30scientists, wants to attack the problem as its simplest and broadest

37−case, producing the most general and powerful solution available. In

31+case, producing the most general and powerful solution available. In

38short: better-is-better.

32short: better-is-better.

39

33

40The "New Jersey" worse-is-better mentality, more typical among

34The "New Jersey" worse-is-better mentality, more typical among

41programmers and engineers, wants to do everything possible to _not_

35programmers and engineers, wants to do everything possible to _not_

42−attack the problem. Can I produce a serviceable approximation to a

36+attack the problem. Can I produce a serviceable approximation to a

43−true solution? Do I actually have to solve the general problem, or

37+true solution? Do I actually have to solve the general problem, or

44−can I reduce it to an easier special case? Can I change the product

38+can I reduce it to an easier special case? Can I change the product

45so it doesn't have this problem?

39so it doesn't have this problem?

46

40

47Ideally, anyone building anything has both these mindsets in their

41Ideally, anyone building anything has both these mindsets in their

48−toolbox. But it's worth noting that (a) Jersey designs (meaning the

42+toolbox. But it's worth noting that (a) Jersey designs (meaning the

49Bell Labs school that produced Unix, C, and Go) tend to beat MIT

43Bell Labs school that produced Unix, C, and Go) tend to beat MIT

50designs in the marketplace, and (b) there are very few pure-functional

44designs in the marketplace, and (b) there are very few pure-functional

51systems built with the true Jersey spirit.

45systems built with the true Jersey spirit.

52

46

53## Why Urbit (probably) doesn't need a blockchain

47## Why Urbit (probably) doesn't need a blockchain

54

48

55−Nakamoto consensus is an example of better-is-better. The blockchain

49+Nakamoto consensus is an example of better-is-better. The blockchain

56design is actually more powerful than it needs to be. It's not just a

50design is actually more powerful than it needs to be. It's not just a

57trustless decentralized ledger; it's a trustless decentralized

51trustless decentralized ledger; it's a trustless decentralized

58database and (as Ethereum has realized; but this idea is clearly

52database and (as Ethereum has realized; but this idea is clearly

@@ -60,29 +54,29 @@ present in Bitcoin's scripting language) a general-purpose, zero-trust

60decentralized computer.

54decentralized computer.

61

55

62Again, Urbit is not a general-purpose decentralized database or

56Again, Urbit is not a general-purpose decentralized database or

63−consensus computer. It's a special case of the former, which is a

57+consensus computer. It's a special case of the former, which is a

64−special case of the latter. Urbit is nothing but a digital title

58+special case of the latter. Urbit is nothing but a digital title

65−chain for network addresses. Our belief is that the special case is

59+chain for network addresses. Our belief is that the special case is

66much easier than the general case, which is why Urbit (probably)

60much easier than the general case, which is why Urbit (probably)

67doesn't need a blockchain.

61doesn't need a blockchain.

68

62

69The rest of this essay describes what makes this special case special,

63The rest of this essay describes what makes this special case special,

70−and how we can use that to not need full Nakamoto consensus, or any

64+and how we can use that to not need full Nakamoto consensus, or any

71kind of general-purpose Byzantine agreement.

65kind of general-purpose Byzantine agreement.

72

66

73## The double-sell problem

67## The double-sell problem

74

68

75−Urbit has the same basic "double-spend" issue as Bitcoin. As Satoshi

69+Urbit has the same basic "double-spend" issue as Bitcoin. As Satoshi

76puts it: "The problem of course is the payee can't verify that one of

70puts it: "The problem of course is the payee can't verify that one of

77the owners did not double-spend the coin." But Urbit is not a

71the owners did not double-spend the coin." But Urbit is not a

78currency, so we say "double-selling."

72currency, so we say "double-selling."

79

73

80−"Double-selling" means signing over an Urbit address (_ship_) to two

74+"Double-selling" means signing over an Urbit address (_ship_) to two

81different parties at the same time, presumably with the intent to sell

75different parties at the same time, presumably with the intent to sell

82it to both and skip town with the loot.

76it to both and skip town with the loot.

83

77

84−Again, the logical problem is the same. Bitcoin attacks it as a broad

78+Again, the logical problem is the same. Bitcoin attacks it as a broad

85−theoretical breakthrough: better-is-better. Urbit attacks it as a

79+theoretical breakthrough: better-is-better. Urbit attacks it as a

86narrow special case: worse-is-better.

80narrow special case: worse-is-better.

87

81

88Intuitively, Urbit's answer is that a real-estate transaction is

82Intuitively, Urbit's answer is that a real-estate transaction is

@@ -96,40 +90,40 @@ a quick look at the Urbit address space and PKI.

96## The Urbit address space and PKI

90## The Urbit address space and PKI

97

91

98(NB: this description differs in minor ways from the running code.

92(NB: this description differs in minor ways from the running code.

99−Where they differ, the description is right. Urbit is not at present

93+Where they differ, the description is right. Urbit is not at present

100secure: use for entertainment purpose only.)

94secure: use for entertainment purpose only.)

101

95

102An Urbit ship is an unsigned integer that serves four purposes: a

96An Urbit ship is an unsigned integer that serves four purposes: a

103cryptographic identity, a packet routing address, a stateful virtual

97cryptographic identity, a packet routing address, a stateful virtual

104computer, and a unique, human-memorable name.

98computer, and a unique, human-memorable name.

105

99

106−Each ship is owned by a private key. To transfer a ship to a new

100+Each ship is owned by a private key. To transfer a ship to a new

107−keypair, sign the new public key with the old private key. This

101+keypair, sign the new public key with the old private key. This

108−revokes the old key and activates the new key. Propagating this

102+revokes the old key and activates the new key. Propagating this

109−update globally makes the revocation global. This is essentially the

103+update globally makes the revocation global. This is essentially the

110digital title system a smart 12-year-old would design.

104digital title system a smart 12-year-old would design.

111

105

112### Ships and wills

106### Ships and wills

113

107

114−Ships are 128-bit numbers classified into tiers by bitwidth. An 8-bit

108+Ships are 128-bit numbers classified into tiers by bitwidth. An 8-bit

115−ship (a number less than 256) is a _galaxy_. A 16-bit ship is a

109+ship (a number less than 256) is a _galaxy_. A 16-bit ship is a

116−_star_. A 32-bit ship is a _planet_. A 64-bit ship is a _moon_. A

110+_star_. A 32-bit ship is a _planet_. A 64-bit ship is a _moon_. A

117128-bit ship is a _comet_.

111128-bit ship is a _comet_.

118

112

119−The chain of signatures for each ship is called a _will_. Unlike most

113+The chain of signatures for each ship is called a _will_. Unlike most

120certificate systems, there is no metadata in an Urbit will. Nothing is

114certificate systems, there is no metadata in an Urbit will. Nothing is

121−signed but the public-key fingerprint. The length of the will is the

115+signed but the public-key fingerprint. The length of the will is the

122−keypair version that owns the ship. This version is called its

116+keypair version that owns the ship. This version is called its

123−_life_. Each new signed fingerprint in the will is a _deed_.

117+_life_. Each new signed fingerprint in the will is a _deed_.

124

118

125−Who gets to create a ship? Comets are fingerprints of a random

119+Who gets to create a ship? Comets are fingerprints of a random

126−keypair. Moons, planets and stars are created by their _prefix_, the

120+keypair. Moons, planets and stars are created by their _prefix_, the

127ship whose bits are the bottom half of their formal width. For

121ship whose bits are the bottom half of their formal width. For

128instance, the star `0xbeef` is the prefix of the planet `0xdeadbeef`.

122instance, the star `0xbeef` is the prefix of the planet `0xdeadbeef`.

129Galaxies have their fingerprints hardcoded in the official kernel.

123Galaxies have their fingerprints hardcoded in the official kernel.

130

124

131−Ship numbers are not generally written in hex. They're written in

125+Ship numbers are not generally written in hex. They're written in

132−Hoon's `@p` syntax, a phonemic base-256. `@p` also permutes within

126+Hoon's `@p` syntax, a phonemic base-256. `@p` also permutes within

133tiers, to superficially conceal prefix structure; for instance,

127tiers, to superficially conceal prefix structure; for instance,

134`0xdead.beef` is `~firbyr-napbes`, while `0xcafe.beef` is

128`0xdead.beef` is `~firbyr-napbes`, while `0xcafe.beef` is

135`~nissep-sopnub`.

129`~nissep-sopnub`.

@@ -139,18 +133,18 @@ tiers, to superficially conceal prefix structure; for instance,

139The prefix of a moon, planet, or star also becomes its _parent_. The

133The prefix of a moon, planet, or star also becomes its _parent_. The

140parent of a ship is its natural locus of federated services. The most

134parent of a ship is its natural locus of federated services. The most

141basic such service is to mediate P2P routing, as a so-called

135basic such service is to mediate P2P routing, as a so-called

142−"supernode." But the set of potential federated services is

136+"supernode." But the set of potential federated services is

143unbounded.

137unbounded.

144

138

145−For moons, each new key update is signed by the parent. Planets and

139+For moons, each new key update is signed by the parent. Planets and

146−stars sign their own updates, making them independent. To prevent

140+stars sign their own updates, making them independent. To prevent

147denial-of-service attacks by parents against children, stars and

141denial-of-service attacks by parents against children, stars and

148−planets can _exit_, choosing a new parent. An exit deed is a key

142+planets can _exit_, choosing a new parent. An exit deed is a key

149update also signed by the new parent.

143update also signed by the new parent.

150

144

151The full public cryptographic record of a ship is its _dossier_. The

145The full public cryptographic record of a ship is its _dossier_. The

152dossier is the set of ship-will pairs, including all parents and

146dossier is the set of ship-will pairs, including all parents and

153−prefixes recursively, needed to validate the ship's current key. A

147+prefixes recursively, needed to validate the ship's current key. A

154ship can process a dossier from an untrusted source.

148ship can process a dossier from an untrusted source.

155

149

156The full set of ship-will pairs a ship knows is its _cabinet_. So the

150The full set of ship-will pairs a ship knows is its _cabinet_. So the

@@ -161,11 +155,11 @@ accepted into a ship's cabinet.

161

155

162The rule is simple: any deeds in the dossier which are new (not

156The rule is simple: any deeds in the dossier which are new (not

163already in the cabinet) must not use keys superseded in the cabinet.

157already in the cabinet) must not use keys superseded in the cabinet.

164−Otherwise revocation doesn't work. But revocation affects only

158+Otherwise revocation doesn't work. But revocation affects only

165dossiers received in the future; nothing already in the cabinet can be

159dossiers received in the future; nothing already in the cabinet can be

166revoked.

160revoked.

167

161

168−Intuitively, this algorithm creates a propagation race. Life `2` of

162+Intuitively, this algorithm creates a propagation race. Life `2` of

169`~firbyr-napbes` revokes life `1` of `~firbyr-napbes`, so propagating

163`~firbyr-napbes` revokes life `1` of `~firbyr-napbes`, so propagating

170life `2` to the whole network ensures that anyone who steals the

164life `2` to the whole network ensures that anyone who steals the

171private key for life `1` can't use it in any way -- whether to launch

165private key for life `1` can't use it in any way -- whether to launch

@@ -187,15 +181,15 @@ As the Karame ["Two Bitcoins at the Price of

187One"](http://eprint.iacr.org/2012/248.pdf) paper points out:

181One"](http://eprint.iacr.org/2012/248.pdf) paper points out:

188

182

189> An efficient countermeasure to combat double-spending on fast

183> An efficient countermeasure to combat double-spending on fast

190−> Bitcoin payments would be for Bitcoin peers to propagate alerts

184+ Bitcoin payments would be for Bitcoin peers to propagate alerts

191−> whenever they receive two or more transactions that share common

185+ whenever they receive two or more transactions that share common

192−> inputs and different outputs.

186+ inputs and different outputs.

193

187

194"Fast Bitcoin payments" means zero-confirmation, ie, Bitcoin without

188"Fast Bitcoin payments" means zero-confirmation, ie, Bitcoin without

195−the blockchain. These double-spend alerts have never been integrated

189+the blockchain. These double-spend alerts have never been integrated

196into Bitcoin Core, despite frequent proposals. Given that Bitcoin

190into Bitcoin Core, despite frequent proposals. Given that Bitcoin

197_does_ have a blockchain, it seems quite sensible for purists to shun

191_does_ have a blockchain, it seems quite sensible for purists to shun

198−hacks that make zero-conf transactions somewhat more secure. Also,

192+hacks that make zero-conf transactions somewhat more secure. Also,

199double-spend alerts in Bitcoin are a DoS vulnerability; Bitcoin has

193double-spend alerts in Bitcoin are a DoS vulnerability; Bitcoin has

200fees to control the cost of propagating transactions, but who pays for

194fees to control the cost of propagating transactions, but who pays for

201an alert?

195an alert?

@@ -207,29 +201,29 @@ An accepted transaction is simply one that propagates to one or more

207randomly chosen observer nodes.

201randomly chosen observer nodes.

208

202

209This design, for the problem that Bitcoin is solving, intuitively

203This design, for the problem that Bitcoin is solving, intuitively

210−feels weak and a little hacky. The Karame paper is not actually

204+feels weak and a little hacky. The Karame paper is not actually

211−advocating for removing the blockchain from Bitcoin. At the same

205+advocating for removing the blockchain from Bitcoin. At the same

212time, low-value zero-confirmation payments are commonly used.

206time, low-value zero-confirmation payments are commonly used.

213

207

214One way to think about security is to flip the tables and think of the

208One way to think about security is to flip the tables and think of the

215−defender as the attacker, and vice versa. Just imagine you have some

209+defender as the attacker, and vice versa. Just imagine you have some

216−moral right to double spend. The rest of the world is unfairly trying

210+moral right to double spend. The rest of the world is unfairly trying

217−to stop you. Can you defend yourself?

211+to stop you. Can you defend yourself?

218

212

219In the context of a gossip network that shares all the things, a

213In the context of a gossip network that shares all the things, a

220procedure that involves telling one person one thing, and another

214procedure that involves telling one person one thing, and another

221person another conflicting thing, and not getting "hacked" by the

215person another conflicting thing, and not getting "hacked" by the

222unfair world which believes there should be only one truth, is

216unfair world which believes there should be only one truth, is

223−inherently quite fragile. And where the attack is fragile, the

217+inherently quite fragile. And where the attack is fragile, the

224defense is robust.

218defense is robust.

225

219

226Most of the security in any digital title system comes from the PKI

220Most of the security in any digital title system comes from the PKI

227−itself. The double-spend problem, the general issue of Byzantine

221+itself. The double-spend problem, the general issue of Byzantine

228−failures in information propagation, is already a corner case. So

222+failures in information propagation, is already a corner case. So

229perhaps we can solve it as a corner case.

223perhaps we can solve it as a corner case.

230

224

231Again: _even Bitcoin_ isn't that far from being able to build a

225Again: _even Bitcoin_ isn't that far from being able to build a

232−practical decentralized ledger without a blockchain. The same gossip

226+practical decentralized ledger without a blockchain. The same gossip

233model that broadcasts nonconflicting transactions is not at all

227model that broadcasts nonconflicting transactions is not at all

234incapable of reacting to conflicting transactions. We're not really

228incapable of reacting to conflicting transactions. We're not really

235recommending that Bitcoin ditch the blockchain, but this gives us hope

229recommending that Bitcoin ditch the blockchain, but this gives us hope

@@ -238,41 +232,41 @@ with our fundamentally easier problem.

238## Various specific specialnesses

232## Various specific specialnesses

239

233

240What are the differences between the Urbit double-sell problem and the

234What are the differences between the Urbit double-sell problem and the

241−Bitcoin double-spend problem? Is our special case really, truly,

235+Bitcoin double-spend problem? Is our special case really, truly,

242special?

236special?

243

237

244In worse-is-better mode, we want every special-case advantage we can

238In worse-is-better mode, we want every special-case advantage we can

245−get. Every difference we find is one we can use as a leverage point.

239+get. Every difference we find is one we can use as a leverage point.

246

240

247### Minimal transaction interdependency

241### Minimal transaction interdependency

248

242

249The first major technical difference between the Urbit title history

243The first major technical difference between the Urbit title history

250and the Bitcoin blockchain is that Bitcoin and its relatives are

244and the Bitcoin blockchain is that Bitcoin and its relatives are

251designed to secure a complete, interdependent, collective transaction

245designed to secure a complete, interdependent, collective transaction

252−history. Except for the parent-child relationship, Urbit wills are

246+history. Except for the parent-child relationship, Urbit wills are

253independent of each other.

247independent of each other.

254

248

255Bitcoin's use of UTXOs rather than balances reduces interdependency

249Bitcoin's use of UTXOs rather than balances reduces interdependency

256−somewhat. But the validity of each transaction is still dependent on

250+somewhat. But the validity of each transaction is still dependent on

257−all the transactions that created its inputs. (Ethereum drops the

251+all the transactions that created its inputs. (Ethereum drops the

258UTXO model, whose value in reducing dependencies may not match its

252UTXO model, whose value in reducing dependencies may not match its

259cost in complexity.)

253cost in complexity.)

260

254

261−Urbit is not a payment system or a shared ledger. Bitcoins are

255+Urbit is not a payment system or a shared ledger. Bitcoins are

262−divisible, but Urbit ships aren't. An Urbit will containing its

256+divisible, but Urbit ships aren't. An Urbit will containing its

263parent chain is self-validating and has no dependencies. There is no

257parent chain is self-validating and has no dependencies. There is no

264−collective history. There is no Merkle tree. There is no chain, with

258+collective history. There is no Merkle tree. There is no chain, with

265or without blocks.

259or without blocks.

266

260

267This simplification doesn't eliminate the double-sell problem in

261This simplification doesn't eliminate the double-sell problem in

268−theory, but makes it much more tractable in practice. The set of past

262+theory, but makes it much more tractable in practice. The set of past

269transactions (key transfers) that a new transaction could conflict

263transactions (key transfers) that a new transaction could conflict

270with is much smaller.

264with is much smaller.

271

265

272### Trust hierarchy and governance structure

266### Trust hierarchy and governance structure

273

267

274The second major technical difference is that Bitcoin is a flat,

268The second major technical difference is that Bitcoin is a flat,

275−trustless, fully decentralized system. Urbit has a hierarchical,

269+trustless, fully decentralized system. Urbit has a hierarchical,

276polycentric governance system which is a trust hierarchy.

270polycentric governance system which is a trust hierarchy.

277

271

278Now and for quite some time, urbits default to automatically accepting

272Now and for quite some time, urbits default to automatically accepting

@@ -282,41 +276,41 @@ You trust your browser quite a bit, which means you trust your browser

282vendor.

276vendor.

283

277

284And since few Bitcoin node operators code their own daemons, the same

278And since few Bitcoin node operators code their own daemons, the same

285−dependency on a source distribution exists in Bitcoin. It's informal

279+dependency on a source distribution exists in Bitcoin. It's informal

286and off-chain, though, which is not really a good thing. (Urbit is

280and off-chain, though, which is not really a good thing. (Urbit is

287like if Bitcoin Core hotpatched itself automatically by publishing

281like if Bitcoin Core hotpatched itself automatically by publishing

288source-code diffs on the blockchain.)

282source-code diffs on the blockchain.)

289

283

290To be on the safe side, we should think of Urbit as a centralized

284To be on the safe side, we should think of Urbit as a centralized

291system until the OS update that turns off automatic updates is

285system until the OS update that turns off automatic updates is

292−shipped. This of course requires a certain measure of perfection,

286+shipped. This of course requires a certain measure of perfection,

293which cannot in any way be predicted.

287which cannot in any way be predicted.

294

288

295After Arvo proper becomes "deciduous" (apps will of course always be

289After Arvo proper becomes "deciduous" (apps will of course always be

296remotely hotpatched), child-to-parent trust should diminish to the

290remotely hotpatched), child-to-parent trust should diminish to the

297−power of the parent to deny service to the child. This will always be

291+power of the parent to deny service to the child. This will always be

298present without some major redesign.

292present without some major redesign.

299

293

300But it's opposed by the equal and opposite power of the child to

294But it's opposed by the equal and opposite power of the child to

301switch to a different parent, creating a competitive market in

295switch to a different parent, creating a competitive market in

302−governance. This should deliver service at the highest quality and

296+governance. This should deliver service at the highest quality and

303−lowest price, fortifying trust with incentives. The power of a

297+lowest price, fortifying trust with incentives. The power of a

304restaurant owner to deny you service does not give the food industry

298restaurant owner to deny you service does not give the food industry

305the power to starve you to death.

299the power to starve you to death.

306

300

307And if no parent wants your business, with 2^16 stars who could accept

301And if no parent wants your business, with 2^16 stars who could accept

308it, you probably shouldn't be on the network at all. Urbit, like a

302it, you probably shouldn't be on the network at all. Urbit, like a

309real society, is designed to be a network of incentives that holds

303real society, is designed to be a network of incentives that holds

310−everyone in productive tension. We want everyone to be free, and no

304+everyone in productive tension. We want everyone to be free, and no

311one to be unaccountable.

305one to be unaccountable.

312

306

313For example: a parent which extends its will also needs to send

307For example: a parent which extends its will also needs to send

314−updated signatures to its children and former children. Either will

308+updated signatures to its children and former children. Either will

315otherwise be unable to propagate their dossiers to ships whose

309otherwise be unable to propagate their dossiers to ships whose

316cabinets have the updated parent will, _even if some other parent

310cabinets have the updated parent will, _even if some other parent

317adopts them_.

311adopts them_.

318

312

319−But Urbit is a collectively governed and updatable system. A star or

313+But Urbit is a collectively governed and updatable system. A star or

320galaxy which denies service to its own children will (a) get a bad

314galaxy which denies service to its own children will (a) get a bad

321reputation, (b) drive its children to other parents, and (c) force the

315reputation, (b) drive its children to other parents, and (c) force the

322network to hardcode a ship-specific exception into the propagation

316network to hardcode a ship-specific exception into the propagation

@@ -325,29 +319,29 @@ algorithm, overriding stale-key revocation.

325In theory, a parent can extort its children by denying service. In

319In theory, a parent can extort its children by denying service. In

326practice, since Urbit is self-governing, not ungoverned, and its

320practice, since Urbit is self-governing, not ungoverned, and its

327government can right this wrong with a source-code patch, the

321government can right this wrong with a source-code patch, the

328−extortion won't work. So it won't happen. So the act of government

322+extortion won't work. So it won't happen. So the act of government

329won't be necessary, and won't happen either.

323won't be necessary, and won't happen either.

330

324

331−Of course a perfectly decentralized system would be freer. But worse,

325+Of course a perfectly decentralized system would be freer. But worse,

332−as usual, is better. And since we are paying for this worseness,

326+as usual, is better. And since we are paying for this worseness,

333imperfect decentralization, we'd like to get all the mileage out of it

327imperfect decentralization, we'd like to get all the mileage out of it

334that we can.

328that we can.

335

329

336Again, Urbit, not being a trustless system, does not have to solve the

330Again, Urbit, not being a trustless system, does not have to solve the

337trustless consensus problem -- although we still very much want to

331trustless consensus problem -- although we still very much want to

338−minimize and bound the delegation of trust. This is an obvious

332+minimize and bound the delegation of trust. This is an obvious

339relaxation of Bitcoin's hard theoretical problem.

333relaxation of Bitcoin's hard theoretical problem.

340

334

341### Routing: security through topology

335### Routing: security through topology

342

336

343−Please don't laugh. Security through routing topology isn't a joke --

337+Please don't laugh. Security through routing topology isn't a joke --

344−unless firewalls are a joke. Cisco sells too many firewalls for them

338+unless firewalls are a joke. Cisco sells too many firewalls for them

345to be a joke.

339to be a joke.

346

340

347In Bitcoin we may have all sorts of reasons to ask what ship holds

341In Bitcoin we may have all sorts of reasons to ask what ship holds

348−what coins. In Urbit, when we ask what key controls an ship, we are

342+what coins. In Urbit, when we ask what key controls an ship, we are

349−either sending or receiving a message. Is our outgoing message safely

343+either sending or receiving a message. Is our outgoing message safely

350−sealed to the current owner? Is our incoming message properly signed

344+sealed to the current owner? Is our incoming message properly signed

351by the current owner?

345by the current owner?

352

346

353When the parent also forwards all packets until a P2P link is

347When the parent also forwards all packets until a P2P link is

@@ -356,29 +350,29 @@ full cone NAT, TURN if not), we can design in all kinds of

356interactions between routing and certificate management.

350interactions between routing and certificate management.

357

351

358In particular, a parent which is a single source of truth in some

352In particular, a parent which is a single source of truth in some

359−sense is a very attractive design element. Again, we're paying for

353+sense is a very attractive design element. Again, we're paying for

360−our imperfect decentralization. We might as well use it.

354+our imperfect decentralization. We might as well use it.

361

355

362−For example: I want to send a packet to ship X. Two parties, A and B,

356+For example: I want to send a packet to ship X. Two parties, A and B,

363−are competing for ownership of X. A is the rightful owner. I am

357+are competing for ownership of X. A is the rightful owner. I am

364secure against B if either of these conditions are true: my packet can

358secure against B if either of these conditions are true: my packet can

365−only be decoded by A, or my packet is not sent to B. Both would be

359+only be decoded by A, or my packet is not sent to B. Both would be

366−ideal, of course. Either will do.

360+ideal, of course. Either will do.

367

361

368### Latency and friction tolerance

362### Latency and friction tolerance

369

363

370Confirmed Bitcoin payments aren't especially low-latency by payment

364Confirmed Bitcoin payments aren't especially low-latency by payment

371−standards. They're reasonably low-friction by payment standards. But

365+standards. They're reasonably low-friction by payment standards. But

372fees are certainly a thing.

366fees are certainly a thing.

373

367

374−Urbit is digital real estate, not digital money. When we look at the

368+Urbit is digital real estate, not digital money. When we look at the

375standards of latency and friction in actual real estate -- where a

369standards of latency and friction in actual real estate -- where a

376transaction that takes a week is super-fast, a 5% payment overhead is

370transaction that takes a week is super-fast, a 5% payment overhead is

377normal, and a third-party intermediary is standard -- we see a much,

371normal, and a third-party intermediary is standard -- we see a much,

378much weaker set of requirements.

372much weaker set of requirements.

379

373

380Obviously a week and a 5% overhead are incredibly sucky levels of

374Obviously a week and a 5% overhead are incredibly sucky levels of

381−latency and friction. The point is that even if this is the only

375+latency and friction. The point is that even if this is the only

382level of performance Urbit can achieve, that's not necessarily the end

376level of performance Urbit can achieve, that's not necessarily the end

383of the world for Urbit.

377of the world for Urbit.

384

378

@@ -390,48 +384,48 @@ just not that hard.

390(One little-made point about Bitcoin, by the way, is that Bitcoin

384(One little-made point about Bitcoin, by the way, is that Bitcoin

391enables trust-free _payments_, but not trust-free _exchanges_. The

385enables trust-free _payments_, but not trust-free _exchanges_. The

392seller still needs to deliver the goods either before or after the

386seller still needs to deliver the goods either before or after the

393−payment; in either case, there is trust. Only Ethereum can solve this

387+payment; in either case, there is trust. Only Ethereum can solve this

394problem -- and only for digital exchanges.)

388problem -- and only for digital exchanges.)

395

389

396## We can afford to be patient

390## We can afford to be patient

397

391

398With a better-is-better, general-purpose solution, one size fits all

392With a better-is-better, general-purpose solution, one size fits all

399−until the end of time. With a worse-is-better, special-case solution,

393+until the end of time. With a worse-is-better, special-case solution,

400the details of that case are critical.

394the details of that case are critical.

401

395

402−But we actually don't know these details. One rule of the

396+But we actually don't know these details. One rule of the

403worse-is-better school: never solve a problem before you have to. You

397worse-is-better school: never solve a problem before you have to. You

404−don't know all the details, and you need those details. (Of course,

398+don't know all the details, and you need those details. (Of course,

405with the better-is-better approach, the details don't matter at all.)

399with the better-is-better approach, the details don't matter at all.)

406

400

407−Is there such a thing as a transitive adjective? Grammarians are

401+Is there such a thing as a transitive adjective? Grammarians are

408−unclear. But technically, the adjective "secure" is always an error.

402+unclear. But technically, the adjective "secure" is always an error.

409−Nothing is "secure." "Secure against X" is the correct usage, where X

403+Nothing is "secure." "Secure against X" is the correct usage, where X

410is some threat model.

404is some threat model.

411

405

412Urbit is an insecure test network with no sensitive data on it. This

406Urbit is an insecure test network with no sensitive data on it. This

413−will remain true for a while. No Urbit ship has ever been transferred

407+will remain true for a while. No Urbit ship has ever been transferred

414−cryptographically. This will also remain the status quo for quite a

408+cryptographically. This will also remain the status quo for quite a

415while.

409while.

416

410

417−We _don't know the threat model_. We _can't solve the problem_. It's

411+We _don't know the threat model_. We _can't solve the problem_. It's

418−as simple as that. The best Urbit can do, at the present time, is map

412+as simple as that. The best Urbit can do, at the present time, is map

419out the ballpark of solutions.

413out the ballpark of solutions.

420

414

421−And we have time to proceed patiently. One way to think about the

415+And we have time to proceed patiently. One way to think about the

422−timing of cryptographic decentralization is to look at the DNS. It's

416+timing of cryptographic decentralization is to look at the DNS. It's

423clear that now, a decentralized DNS with cryptographic domain-name

417clear that now, a decentralized DNS with cryptographic domain-name

424−titles would be extremely desirable. It was never designed to happen.

418+titles would be extremely desirable. It was never designed to happen.

425It will probably never happen.

419It will probably never happen.

426

420

427But if we look at when cryptographic DNS with allodial title _should_

421But if we look at when cryptographic DNS with allodial title _should_

428have happened, it's probably sometime in the mid-90s. Ie, after over a

422have happened, it's probably sometime in the mid-90s. Ie, after over a

429−decade of production use of the Domain Name System. In short: there's

423+decade of production use of the Domain Name System. In short: there's

430no need to hurry here.

424no need to hurry here.

431

425

432## A map of the solution space

426## A map of the solution space

433

427

434−But we still need a map of the worse-is-better ballpark. Let's look

428+But we still need a map of the worse-is-better ballpark. Let's look

435at some options, from least secure to most.

429at some options, from least secure to most.

436

430

437The essential question we can't answer, without a better sense of the

431The essential question we can't answer, without a better sense of the

@@ -440,19 +434,19 @@ especially are not sure about the threat model of malicious stars

440(16-bit ships) and/or galaxies (8-bit ships).

434(16-bit ships) and/or galaxies (8-bit ships).

441

435

442We need to know what kinds of double-sell attacks are plausible. Since

436We need to know what kinds of double-sell attacks are plausible. Since

443−we don't know this yet, we need not one propagation design, but a

437+we don't know this yet, we need not one propagation design, but a

444range of designs -- stretching all the way up to a full blockchain.

438range of designs -- stretching all the way up to a full blockchain.

445

439

446### Acceptance model

440### Acceptance model

447

441

448−What doesn't change is the will _acceptance_ model. A ship will

442+What doesn't change is the will _acceptance_ model. A ship will

449always accept a new will if (a) the new will extends the old will, (b)

443always accept a new will if (a) the new will extends the old will, (b)

450the parent signature on the initial public key is at least as recent

444the parent signature on the initial public key is at least as recent

451as the ship's current version of that parent.

445as the ship's current version of that parent.

452

446

453The parent clause implies that when a parent extends its will, it

447The parent clause implies that when a parent extends its will, it

454needs to send updated initial signatures to all the children it's

448needs to send updated initial signatures to all the children it's

455−launched. Otherwise, their own future updates will not be accepted by

449+launched. Otherwise, their own future updates will not be accepted by

456ships that have seen the parent's update.

450ships that have seen the parent's update.

457

451

458This is not a big deal in the world of parent responsibilities. But

452This is not a big deal in the world of parent responsibilities. But

@@ -466,30 +460,30 @@ Scarcity rules.

466

460

467### Level 0: passive propagation only

461### Level 0: passive propagation only

468

462

469−The Ames protocol can piggyback a will on any packet. Each ship also

463+The Ames protocol can piggyback a will on any packet. Each ship also

470permanently records which other ships hold which version of its own

464permanently records which other ships hold which version of its own

471−will. An update is automatically sent when needed.

465+will. An update is automatically sent when needed.

472

466

473With level 0 propagation, all key exchanges in Ames are passive and

467With level 0 propagation, all key exchanges in Ames are passive and

474−invisible to the programmer. When the sender has no will or symmetric

468+invisible to the programmer. When the sender has no will or symmetric

475key for the receiver, the packet is signed, bundled with the will, and

469key for the receiver, the packet is signed, bundled with the will, and

476sent as cleartext.

470sent as cleartext.

477

471

478−Signed cleartext? If you have no will for a peer, you've never talked

472+Signed cleartext? If you have no will for a peer, you've never talked

479−to this ship before. Your first words to a stranger probably won't be

473+to this ship before. Your first words to a stranger probably won't be

480−super secret. If this isn't true, the programmer has to send an

474+super secret. If this isn't true, the programmer has to send an

481−innocuous message first and wait for it to be acknowledged. Kicking a

475+innocuous message first and wait for it to be acknowledged. Kicking a

482rare corner case up to the programmer is a classic worse-is-better

476rare corner case up to the programmer is a classic worse-is-better

483move.

477move.

484

478

485With level 0 propagation only (the current implementation, because we

479With level 0 propagation only (the current implementation, because we

486don't even care about key updates yet), an updated does not

480don't even care about key updates yet), an updated does not

487−effectively revoke the old key. If Alice updates to a new key,

481+effectively revoke the old key. If Alice updates to a new key,

488Mallory steals the old key, then Mallory talks to Bob before Alice

482Mallory steals the old key, then Mallory talks to Bob before Alice

489does, Mallory can impersonate Alice.

483does, Mallory can impersonate Alice.

490

484

491So not only does level 0 not solve double-sell, it's also quite

485So not only does level 0 not solve double-sell, it's also quite

492−insecure. But it's still fine for now (because Urbit isn't really

486+insecure. But it's still fine for now (because Urbit isn't really

493decentralized yet).

487decentralized yet).

494

488

495### Level 1: neighbor-only propagation with parent filtering

489### Level 1: neighbor-only propagation with parent filtering

@@ -497,7 +491,7 @@ decentralized yet).

497The list of other ships which hold your will, essentially the list of

491The list of other ships which hold your will, essentially the list of

498all ships you've talked to, is your list of _neighbors_. You

492all ships you've talked to, is your list of _neighbors_. You

499essentially have permanent, if perhaps very sporadic, conversations

493essentially have permanent, if perhaps very sporadic, conversations

500−with all your cryptographic neighbors. Symmetric keys time out fast,

494+with all your cryptographic neighbors. Symmetric keys time out fast,

501but wills are held forever.

495but wills are held forever.

502

496

503By proactively pinging all your neighbors when you extend your will,

497By proactively pinging all your neighbors when you extend your will,

@@ -505,99 +499,99 @@ you prevent anyone who finds the old private key (ideally you update

505when your old key is stale, not when it's actually been _stolen_) from

499when your old key is stale, not when it's actually been _stolen_) from

506jumping into these conversations.

500jumping into these conversations.

507

501

508−What about non-neighbors? We add a second feature: a parent will only

502+What about non-neighbors? We add a second feature: a parent will only

509−forward a packet if its sender matches the current will. So updating

503+forward a packet if its sender matches the current will. So updating

510your parent (who is always your neighbor) transforms it

504your parent (who is always your neighbor) transforms it

511

505

512There are two cases: where Alice's parent Trent is also Bob's parent,

506There are two cases: where Alice's parent Trent is also Bob's parent,

513−and where Bob has a separate parent Walter. In the first case, the

507+and where Bob has a separate parent Walter. In the first case, the

514expected packet flow is that Alice will send the packet to Trent, who

508expected packet flow is that Alice will send the packet to Trent, who

515−sends it to Bob. In the second case, Trent sends it to Walter, who

509+sends it to Bob. In the second case, Trent sends it to Walter, who

516sends it to Bob.

510sends it to Bob.

517

511

518In either flow, Bob or Walter is sure that the packet came through

512In either flow, Bob or Walter is sure that the packet came through

519−Trent. Since Trent is Alice's parent and hence Alice's neighbor, and

513+Trent. Since Trent is Alice's parent and hence Alice's neighbor, and

520−hence is updated, Trent will forward no packets from Mallory. So

514+hence is updated, Trent will forward no packets from Mallory. So

521Mallory has no way to reach Bob.

515Mallory has no way to reach Bob.

522

516

523Non-neighborly packets not matching this flow can't be accepted.

517Non-neighborly packets not matching this flow can't be accepted.

524−Suppose Mallory gets Bob's public IP address directly? If Bob gets a

518+Suppose Mallory gets Bob's public IP address directly? If Bob gets a

525non-forwarded packet marked "Alice," but Alice is not his neighbor,

519non-forwarded packet marked "Alice," but Alice is not his neighbor,

526−that's super weird. He must reject the packet.

520+that's super weird. He must reject the packet.

527

521

528Level 1 is nice because it provides a reasonable level of security,

522Level 1 is nice because it provides a reasonable level of security,

529−but it's still extremely simple. Not only does it not use a

523+but it's still extremely simple. Not only does it not use a

530blockchain, it doesn't even need a gossip flood!

524blockchain, it doesn't even need a gossip flood!

531

525

532And level 1 propagation also does a competent worse-is-better job on

526And level 1 propagation also does a competent worse-is-better job on

533−the double-sell problem. Trent simply becomes the single source of

527+the double-sell problem. Trent simply becomes the single source of

534−truth. The buyer of Alice needs to check that Trent, her parent, has

528+truth. The buyer of Alice needs to check that Trent, her parent, has

535Alice's latest will from the buyer's perspective. If Alice's seller

529Alice's latest will from the buyer's perspective. If Alice's seller

536propagates a different fork to other ships, this damages Alice's

530propagates a different fork to other ships, this damages Alice's

537ability to communicate, but produces no obvious gain for the seller.

531ability to communicate, but produces no obvious gain for the seller.

538

532

539−Level 1 puts a lot of security weight on the parent. If Trent

533+Level 1 puts a lot of security weight on the parent. If Trent

540misbehaves, for example by not filtering Mallory's packets, Alice can

534misbehaves, for example by not filtering Mallory's packets, Alice can

541−be impersonated. And its solution to the double-sell problem is

535+be impersonated. And its solution to the double-sell problem is

542−adequate, but not ideal. Level 1 is the worse-is-better sweet spot

536+adequate, but not ideal. Level 1 is the worse-is-better sweet spot

543for a young Urbit, but will probably give way to level 2.

537for a young Urbit, but will probably give way to level 2.

544

538

545### Level 2: broadcast all wills

539### Level 2: broadcast all wills

546

540

547−We can't say definitively that level 1 will be inadequate. But

541+We can't say definitively that level 1 will be inadequate. But

548−intuitively, it feels slightly weak. We will probably need a gossip

542+intuitively, it feels slightly weak. We will probably need a gossip

549protocol.

543protocol.

550

544

551The only ships that can be transferred are galaxies, stars and

545The only ships that can be transferred are galaxies, stars and

552planets; if all updates of all wills of all these major ships are

546planets; if all updates of all wills of all these major ships are

553−broadcast, we hardly have a scaling problem like Bitcoin's. Even if

547+broadcast, we hardly have a scaling problem like Bitcoin's. Even if

554changing the lock on your front door counted as a real-estate

548changing the lock on your front door counted as a real-estate

555transaction, there are a lot fewer real-estate transactions than

549transaction, there are a lot fewer real-estate transactions than

556credit-card payments.

550credit-card payments.

557

551

558Moreover, conflict detection (double-sell alerts) is a natural part of

552Moreover, conflict detection (double-sell alerts) is a natural part of

559−any gossip protocol. Gossip should be between stars, not directly

553+any gossip protocol. Gossip should be between stars, not directly

560between planets; horizontal gossip, vertical distribution.

554between planets; horizontal gossip, vertical distribution.

561Star-to-planet distribution may still be limited.

555Star-to-planet distribution may still be limited.

562

556

563Especially since stars are somewhat trusted, ganking a gossip protocol

557Especially since stars are somewhat trusted, ganking a gossip protocol

564with random update edges is incredibly hard and requires a pretty

558with random update edges is incredibly hard and requires a pretty

565−preposterous conspiracy. And flooding all planet wills does a lot to

559+preposterous conspiracy. And flooding all planet wills does a lot to

566−keep stars honest. It would be incredibly stupid for a star to try a

560+keep stars honest. It would be incredibly stupid for a star to try a

567double-sell attack against its own planets, but code is always more

561double-sell attack against its own planets, but code is always more

568powerful than mere incentives.

562powerful than mere incentives.

569

563

570Finally, the exit model isn't fully baked yet, but it will probably

564Finally, the exit model isn't fully baked yet, but it will probably

571−have more aggressive propagation needs. What's clear is that an exit

565+have more aggressive propagation needs. What's clear is that an exit

572statement is another type of will entry, involving a signature both

566statement is another type of will entry, involving a signature both

573−from the previous key and the new parent. You can only escape to

567+from the previous key and the new parent. You can only escape to

574another ship of your parent's class that agrees to adopt you.

568another ship of your parent's class that agrees to adopt you.

575

569

576In general, because escaping need to work for routing (without the

570In general, because escaping need to work for routing (without the

577cooperation of the former parent), wills containing an exit statement

571cooperation of the former parent), wills containing an exit statement

578(a planet moving to a new star, or a star moving to a new galaxy)

572(a planet moving to a new star, or a star moving to a new galaxy)

579exit) probably need to be flooded globally among all 8-bit galaxies

573exit) probably need to be flooded globally among all 8-bit galaxies

580−and 16-bit stars. Exits should be rare, so they shouldn't present

574+and 16-bit stars. Exits should be rare, so they shouldn't present

581much of a scaling problem.

575much of a scaling problem.

582

576

583### Level 3: full blockchain

577### Level 3: full blockchain

584

578

585−Obviously a blockchain can solve Urbit's problem. Probably the right

579+Obviously a blockchain can solve Urbit's problem. Probably the right

586thing to do would be to use the Bitcoin blockchain, and confirm the

580thing to do would be to use the Bitcoin blockchain, and confirm the

587−current Urbit key version with a "colored coin" of some kind. (This

581+current Urbit key version with a "colored coin" of some kind. (This

588should not be confused with the orthogonal idea of representing Urbit

582should not be confused with the orthogonal idea of representing Urbit

589_invitations_ as colored coins.)

583_invitations_ as colored coins.)

590

584

591This involves making all Urbit ships into Bitcoin SPV nodes at the

585This involves making all Urbit ships into Bitcoin SPV nodes at the

592−least. Not the worst fate in the world, but also a cost.

586+least. Not the worst fate in the world, but also a cost.

593Alternatively, Urbit could have its own "altcoin" blockchain, with

587Alternatively, Urbit could have its own "altcoin" blockchain, with

594actual Urbit-specific mining.

588actual Urbit-specific mining.

595

589

596Again, given that level 2 seems like it should work quite well, it's

590Again, given that level 2 seems like it should work quite well, it's

597−hard to see why level 3 propagation would be needed. But we can't

591+hard to see why level 3 propagation would be needed. But we can't

598−really know at this point. There's a reason Urbit can update itself

592+really know at this point. There's a reason Urbit can update itself

599−over the air. That's why we say: Urbit (probably) doesn't need a

593+over the air. That's why we say: Urbit (probably) doesn't need a

600−blockchain. If it does, we can retrofit it.

594+blockchain. If it does, we can retrofit it.

601

595

602## Retrospective note

596## Retrospective note

603

597

@@ -606,18 +600,18 @@ stripped-down, worse-is-better variation of Nakamoto consensus.

606That's clearly the right way to introduce it in 2016.

600That's clearly the right way to introduce it in 2016.

607

601

608Actually, though, this part of Urbit was designed before the Bitcoin

602Actually, though, this part of Urbit was designed before the Bitcoin

609−paper was published. There were other academic approaches to

603+paper was published. There were other academic approaches to

610Byzantine consensus, but certainly none validated on a large scale as

604Byzantine consensus, but certainly none validated on a large scale as

611−Nakamoto consensus has been. It never seemed appropriate to treat

605+Nakamoto consensus has been. It never seemed appropriate to treat

612cryptographic titles to network addresses as a case of generalized

606cryptographic titles to network addresses as a case of generalized

613Byzantine consensus, and without the existence of Bitcoin there was no

607Byzantine consensus, and without the existence of Bitcoin there was no

614temptation in this direction.

608temptation in this direction.

615

609

616−In a sense the secret of PKIs is that PKIs are easy. What's hard is

610+In a sense the secret of PKIs is that PKIs are easy. What's hard is

617adapting an existing identity and authorization structure into a PKI.

611adapting an existing identity and authorization structure into a PKI.

618If you build the simplest possible PKI, then force the human processes

612If you build the simplest possible PKI, then force the human processes

619to fit themselves to the protocol instead of vice versa, you have a

613to fit themselves to the protocol instead of vice versa, you have a

620−much easier job. Similarly, if you are not adding PKI to an existing

614+much easier job. Similarly, if you are not adding PKI to an existing

621network, but building the network and the PKI as one system, many

615network, but building the network and the PKI as one system, many

622−simplifications are possible. This is once again the classic

616+simplifications are possible. This is once again the classic

623worse-is-better method.

617worse-is-better method.

content/blog/your-last-computer.md+5−5

@@ -1,8 +1,7 @@

1+++

1+++

2title = "Your Last Computer"

2title = "Your Last Computer"

3−date = "2019-10-16"

3+date = 2019-10-17

4description = "Your Urbit is a simpler computer, a quieter computer, a more private computer. We want it to feel predictable, safe, and reliable — things only a complete, sealed system can do. This, we hope, can get us a world where technology keeps us connected, but doesn’t dominate our lives."

4description = "Your Urbit is a simpler computer, a quieter computer, a more private computer. We want it to feel predictable, safe, and reliable — things only a complete, sealed system can do. This, we hope, can get us a world where technology keeps us connected, but doesn’t dominate our lives."

5−

6[extra]

5[extra]

7image = "https://media.urbit.org/site/understanding-urbit/your-last-computer/your-last-computer-waves%402x.png"

6image = "https://media.urbit.org/site/understanding-urbit/your-last-computer/your-last-computer-waves%402x.png"

8+++

7+++

@@ -11,13 +10,14 @@ This whole ‘simple, durable, yours’ thing may sound good, but what does it a

11

10

12First, let’s talk about what it should feel like in the future.

11First, let’s talk about what it should feel like in the future.

13

12

13+

14−

14+<img class="mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/your-last-computer/your-last-computer-waves%402x.png">

15

15

16Imagine that you can log in from anywhere with one simple, memorable name and password. And when you do, an entire OS appears for you. Inside is your whole digital life. Every conversation you’ve ever had, all your biometric data — every step and heartbeat. Your personal mesh of devices: your doors, your car, your irrigation. All of your communities, every message you’ve shared with friends and family. Every connection you’ve made and every archival piece of data, in one place. Secure and private, forever.

16Imagine that you can log in from anywhere with one simple, memorable name and password. And when you do, an entire OS appears for you. Inside is your whole digital life. Every conversation you’ve ever had, all your biometric data — every step and heartbeat. Your personal mesh of devices: your doors, your car, your irrigation. All of your communities, every message you’ve shared with friends and family. Every connection you’ve made and every archival piece of data, in one place. Secure and private, forever.

17

17

18You own and control this OS completely. Your system doesn’t live on someone else’s server, so there’s no risk of leaking it in a mass data breach or losing it when a service shuts down. Your Urbit is a sealed, secure, and durable system.

18You own and control this OS completely. Your system doesn’t live on someone else’s server, so there’s no risk of leaking it in a mass data breach or losing it when a service shuts down. Your Urbit is a sealed, secure, and durable system.

19

19

20−

20+<img class="ba mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/your-last-computer/your-last-computer-is-rock%402x.png">

21

21

22We’re on our way to this future, building it step by step, but we’re not there yet. The Urbit of today is much more stripped down.

22We’re on our way to this future, building it step by step, but we’re not there yet. The Urbit of today is much more stripped down.

23

23

@@ -31,6 +31,6 @@ It’s a simple system for intentional digital communities. A first step away fr

31

31

32We think that a new system like this, even in a simple form, will be a relief from the chaos of the current web. Think of it as a “back to the land” computing movement. If we’re ever going to build new digital cities, they’ll have to start as a few colonies on the frontier.

32We think that a new system like this, even in a simple form, will be a relief from the chaos of the current web. Think of it as a “back to the land” computing movement. If we’re ever going to build new digital cities, they’ll have to start as a few colonies on the frontier.

33

33

34−

34+<img class="mv5 w-100" src="https://media.urbit.org/site/understanding-urbit/your-last-computer/your-last-computer-ocean%402x.png">

35

35

36Your Urbit is a simpler computer, a quieter computer, a more private computer. We want it to feel predictable, safe, and reliable — things only a complete, sealed system can do. This, we hope, can get us a world where technology keeps us connected, but doesn’t dominate our lives.

36Your Urbit is a simpler computer, a quieter computer, a more private computer. We want it to feel predictable, safe, and reliable — things only a complete, sealed system can do. This, we hope, can get us a world where technology keeps us connected, but doesn’t dominate our lives.

content/bounties.md+4−49

@@ -1,54 +1,9 @@

1+++

1+++

2−title = "Guide to Bounties"

2+title = "Bounties"

3−date = "2023-01-04"

4−weight = 1

5−description = "A guide to posting and claiming bounties"

6+++

3+++

7

4

8−Bounties are opportunities to do work on Urbit in exchange for address space or other funding. Bounties can be provided by companies, DAOs or individuals ("sponsors") in the Urbit universe. To the extent that they benefit the rest of the universe, the Urbit Foundation will [chip in on funding](#funding).

5+We run a security bug bounty program with [HackerOne](https://hackerone.com). See the [Tlon Corp](https://hackerone.com/tlon/) page at HackerOne for more information.

9

6

10−For **workers**, bounties offer substantial funding opportunities and, compared to [apprenticeships](/grants/apprenticeships), are a way to take on larger challenges in a more autonomous manner. Learn how to [work on a bounty here](#work-on-a-bounty).

7+If you've found a vulnerablity, and you'd like to claim a bounty, please submit a report there. Note that our bounty program is currently focused on [Azimuth](https://github.com/urbit/azimuth) vulnerabilities.

11

8

12−For **sponsors**, bounties allow you to scale your workforce through the Urbit community, get critical tools built, or just fund cool projects that you want to see exist. Learn how to [post a bounty here](#post-a-bounty).

9+For general inquiries and disclosures, please contact our security team at [security@tlon.io](mailto:security@tlon.io).

13−

14−## Work on a Bounty

15−

16−You can see [open bounties here](/grants?program=bounty&open=true&wip=false&completed=false#view-grants), which can claimed by filling out the form on each individual bounty.

17−

18−### How it works

19−

20−After applying, the Urbit Foundation will circulate the details of your application to the sponsor and schedule a follow-up interview to see if you would be a good fit for the project. Should your application be accepted, you will undergo a quick KYC process and recieve a contract for signature. Some bounties may also entail additional direct compensation from the sponsor for which the Urbit Foundation is not responsible for managing; please discuss these parameters directly with your sponsor.

21−

22−The sponsor of the bounty is ultimately responsible for signing off on completed work. They'll also be the primary point of contact while work is underway, although the Urbit Foundation may assign personnel to assist on bounties that it is particularly invested in.

23−

24−Sponsors are vetted by the Urbit Foundation as trustworthy to ensure their ability to fund the work that they post. The Urbit Foundation also collaborates heavily with sponsors to ensure that the bounty is [well-specified](#well-specified-bounties), which ensures that your project is both properly scoped and technically viable.

25−

26−### Getting Paid

27−

28−After you've finished your work on a given milestone, you will need to get signoff from your sponsor. To do this, contact your sponsor with the details of the milestone completed, any relevant instructions, github repos, or app download links, and solicit review from your sponsor. They can submit their approval to the Foundation by contacting `~marfun-pacpet`, at which point you are ready to [submit an invoice](https://airtable.com/shrXXCs1uaxtNSBcg). Once the Urbit Foudnation receives approval from your sponsor and an invoice for the amount agreed upon in your grant or milestone, the Foundation will pay your star allocation to the Ethereum address you have provided.

29−

30−We approve and issue payments within 30 days of invoice receipt and approval, although often payment is made more quickly. If you have any questions regarding getting paid or submitting an invoice, please contact `~marfun-pacpet` for assistance.

31−

32−## Post a Bounty

33−

34−To get started posting a new bounty, [submit it via this form](https://airtable.com/shr6ky4yshlhhqSm0).

35−

36−We at the Urbit Foundation will work with you to ensure that all bounties have [clear specifications](#well-specified-bounties) &mdash; this ensures that they get what you pay for. If your bounty submission is missing details or could be otherwise improved, we'll provide that feedback and work with you to refine your bounty.

37−

38−### Well-specified Bounties

39−

40−A well-specified bounty generally has these elements:

41−

42−- **Overview**: A clear description of what the worker will do to complete this bounty. It's a good idea to include a problem statement or rationale for the work.

43−- **Project Requirements**: An articulation of what constitutes complete work. User stories, Figma designs, interface specifications, and other technical constraints are all examples of requirements. It is recommended to reference any specific requirements &mdash; such as key user stories &mdash; on a milestone level to ensure clarity in which requirements need to be met at each stage of the project.

44−- **Worker Requirements**: A description of the skills and/or qualifications required of a prospective worker. Technologies or skills known, years of experience, work schedule (e.g. time availability), and demonstrable accomplishments are all examples of this.

45−- **Milestones**: Logical segments of work that can be considered done on their own. Breaking the project up into smaller pieces will help a new worker pick up the work should that be necessary, keeps the worker motivated with incremental achievement and remuneration, and is generally a sign of a clear specification. Milestones don't always make sense; sometimes there's only one.

46−- **Timeline**: If you're trying hit a certain deadline, make sure to specify absolute dates on the milestones. Otherwise, use relative dates (e.g. _two months_) to give the worker an idea of how long each milestone will take. This helps form an agreement between the sponsor and worker on volume of work, and grounds to seek other arrangements should schedules be missed.

47−

48−The more detail in the bounty's specification, the better the results and the smoother your working relationship will be with a contributor. Once a contributor has been selected, parameters such as absolute dates or other open ended questions will be updated prior to contract to ensure there are clear expectations for all parties involved

49−

50−### Funding

51−

52−You're free to fund your bounty with as much of your own capital as you'd like. You can also request funding from the Urbit Foundation.

53−

54−We fund projects based on their benefit to the whole network. If your bounty is for contributions to Urbit itself, or other technical infrastructure, we might fund all of it. If the bounty is to build or contribute to your company's product, we'll be open to funding less of it.

content/campus/_index.mddeleted−37

@@ -1,37 +0,0 @@

1−+++

2−title = "Software Developers"

3−slug = "software-developers"

4−description = "Getting started as a software developer on Urbit"

5−sort_by = "weight"

6−+++

7−

8−

9−Urbit offers foundational primitives that make it easy to build decentralized applications. This means developers can focus on creativity and application logic instead of operations to make sure the server or database doesn't go down.

10−

11−

12−Here are a few links to resources for developers:

13−

14−

15−### [Urbit Developers Overview](https://developers.urbit.org/)

16−An overview of using Urbit for development.

17−

18−### [Lightning Tutorials](https://developers.urbit.org/guides/quickstart/intro)

19−Get a feel for the process of making and deploying an Urbit app in half an hour, no previous experience required.

20−

21−### [Core Curriculum](https://developers.urbit.org/guides/core)

22−Learn the Urbit stack at your own pace.

23−

24−The Foundation also regularly runs a series of cohort-based live courses that go over the core curriculum, free and open to all. One lesson per week over the course of about eight weeks.

25−

26−### [Live Courses](https://developers.urbit.org/courses)

27−Learn the Urbit stack as part of a group.

28−

29−### [New Hooniverse](https://urbit.org/groups/~hiddev-dannut/new-hooniverse)

30−Discussion group for learning the Urbit stack. Open to beginner, intermediate, and advanced developers.

31−

32−

33−### [TomeDB](https://holium.gitbook.io/tomedb/)

34−A framework for building Urbit apps solely with Javascript.

35−

36−### [Grants](https://urbit.org/grants)

37−Build on Urbit and take ownership of the network in the process.

content/campus/blockchain-enthusiasts.mddeleted−35

@@ -1,35 +0,0 @@

1−+++

2−title = "Blockchain Enthusiasts"

3−slug = "blockchain-enthusiasts"

4−description = "Learn how sound computing and sound money fit together"

5−weight = 4

6−[extra]

7−flatten_pagination = "true"

8−hide_next_title = "true"

9−hide_previous_title = "true"

10−image = "https://media.urbit.org/site/understanding-urbit/urbit-id/urbit-id-cards%402x.png"

11−+++

12−

13−We have yet to see the promised Cambrian explosion of general-purpose decentralized applications promised by blockchains. What happened?

14−

15−While blockchains are good for some problems, there remain others where a more general purpose computing solution is more useful. This is precisely what Urbit is for. Urbit’s vision of sound, easy-to-use, decentralized computing dovetails neatly with that of sound, easy-to-use, decentralized money.

16−

17−Learn more on how Urbit and blockchains work together:

18−

19−### [Bitcoin on Urbit: The Sovereign Stack](https://urbit.org/bitcoin)

20−How Urbit and Bitcoin fit together

21−

22−### [Azimuth](https://developers.urbit.org/reference/azimuth/azimuth)

23−Urbit’s PKI system on Ethereum

24−

25−### [Uqbar](https://uqbar.network)

26−The Urbit-native blockchain

27−

28−The leader in this space is Uqbar, an Urbit-native layer 2 blockchain that settles on Ethereum.

29−

30−From their [clearpaper](https://uqbar-network.gitbook.io/uqbar-clearpaper/uqbar-clearpaper/uqbar-clearpaper):

31−

32−>Leveraging Urbit’s peer-to-peer infrastructure, Uqbar provides a blockchain-native decentralized operating system uniquely positioned to deliver the composable primitives necessary to build a rich, functional distributed application layer. It fuses the trusted settlement of Ethereum with the decentralization, security, and interoperability benefits of full-scale peer-to-peer networking, unlocking the latent power of programmable blockchains.

33−

34−

35−

content/campus/creatives.mddeleted−21

@@ -1,21 +0,0 @@

1−+++

2−title = "Creatives"

3−slug = "creatives"

4−description = "Urbit for everyone"

5−weight = 5

6−[extra]

7−+++

8−

9−Urbit offers creatives the means to truly own the distribution of their work. An application becomes a tool you own rather than a service whose terms can change overnight. And with digital ownership on a decentralized network, the incentives of advertising based centralized services and an attention economy no longer apply.

10−

11−What would the world look like with more decentralized digital ownership? Check out the links below for a preview.

12−

13−### [Tirrel Studio](https://urbit.studio)

14−

15−Host, publish, and earn on Urbit. See the [Mars Review of Books.](https://marsreview.org/)

16−

17−

18−### [Meetup Grant](https://urbit.org/grants/community-meetups)

19−

20−Through our Grants program, the foundation rewards community-builders who

21−host regular meetups and help people learn about the project.

content/coinmarketcap.mddeleted−8

@@ -1,8 +0,0 @@

1−+++

2−title = "CoinMarketCap"

3−[extra]

4−hidetitle = "true"

5−index = "true"

6−+++

7−

8−The ticket number for CoinMarketCap verification is 429809.

content/communities/urbit-austin.mddeleted−11

@@ -1,11 +0,0 @@

1−+++

2−title = "Urbit Austin"

3−description = ""

4−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/communities/urbit-austin.png"

5−+++

6−

7−Curious about Urbit? Questions about Hoon syntax? Fed up with the current state of the internet? Join us to talk about the internet's future.

8−

9−––

10−

11−[Meetup page](https://www.meetup.com/Urbit-Austin/)

content/communities/urbit-berlin.mddeleted−16

@@ -1,16 +0,0 @@

1−+++

2−title = "Urbit Berlin"

3−description = ""

4−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/communities/urbit-berlin.png"

5−+++

6−

7−If you are sick of the current state of the web, of handing over your data and entire online presence to a handful of American corporations, of a web fueled with ads, then Urbit might be for you.

8−

9−Are you curious about Urbit and want to try it? Are you an Urbit OG looking to find to find others? Do you want to build your own peer-to-peer apps and leave the centralized web behind?

10−

11−We meet regularly in Berlin, and we try to have a theme or presentation for each meetup.

12−

13−

14−––

15−

16−[Meetup page](https://www.meetup.com/urbit-berlin/)

content/communities/urbit-christchurch.mddeleted−13

@@ -1,13 +0,0 @@

1−+++

2−title = "Urbit Christchurch"

3−description = ""

4−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/communities/urbit-christchurch.jpg"

5−+++

6−

7−Curious about Urbit? Questions about Hoon syntax? Fed up with the current state of the internet? Join us to talk about the internet's future.

8−

9−––

10−

11−[Eventbrite](https://chchurbit.eventbrite.com)

12−

13−[Telegram](https://t.me/chchurbit)

content/communities/urbit-cph.mddeleted−11

@@ -1,11 +0,0 @@

1−+++

2−title = "Urbit København"

3−description = ""

4−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/communities/urbit-cph.png"

5−+++

6−

7−~norsyr-torryn/nordics

8−

9−––

10−

11−[Twitter](https://twitter.com/UrbitCPH)

content/communities/urbit-dc.mddeleted−19

@@ -1,19 +0,0 @@

1−+++

2−title = "DC Metro Urbit Meetup Group"

3−description = ""

4−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/communities/urbit-dc.png"

5−+++

6−

7−This is a DC/Northern Virginia/Southern Maryland Urbit discussion group.

8−

9−It is for Urbit users or the urbit-curious or people who like to think and talk about decentralization, independence, and freedom on the internet.

10−

11−We will socialize, discuss urbit and related topics, and support lab and learning activities.

12−

13−Find us on urbit chat at ~tillys-fasryp/nova-urbit-meetup-lobby-3347

14−

15−––

16−

17−[Meetup page](https://www.meetup.com/dc-urbit-meetup-group/)

18−

19−[Twitter](https://twitter.com/dcurbit)

content/communities/urbit-denver.mddeleted−19

@@ -1,19 +0,0 @@

1−+++

2−title = "Urbit Denver"

3−description = ""

4−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/communities/urbit-denver.png"

5−+++

6−

7−While Urbit is the animating force behind this group, people of all interest levels & familiarity with the project - be they long-time users, or newcomers simply wondering what the heck Urbit is - are welcome & encouraged to attend these meet-ups. The conversations are lively and span a wide variety of topics, ranging from Urbit to philosophy, tech, crypto, the arts, health and well-being, and much more.

8−

9−Our goal is simply to build a community of people interested in the project and the future it envisions, in which members can freely connect and discuss the project and the various ideas & values adjacent to it.

10−

11−And for those wondering what the heck is Urbit? Urbit is an ambitious reimagining of what the internet can be; it is a virtual computer and peer-to-peer network, built on a philosophy of human-scale computing, where you own all your data and identity. Urbit strives to once again make the computer a useful tool under the control of the user, and not vice versa. Still confused? Stop by and we'll (try to) explain it.

12−

13−––

14−

15−~nospex-larsut/mile-high-mars

16−

17−[Meetup page](https://www.meetup.com/mile-high-mars-denver-urbit-group/)

18−

19−[Organizer's Twitter](https://twitter.com/OnAPersonaLevel)

content/communities/urbit-london.mddeleted−15

@@ -1,15 +0,0 @@

1−+++

2−title = "Urbit London"

3−description = ""

4−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/communities/urbit-london.jpg"

5−+++

6−

7−Urbit London is a monthly, occasionally biweekly, meet-up series aiming to establish a long-lasting community within the London tech and cultural scene.

8−

9−––

10−

11−~tichus-holnet/urblon

12−

13−[Twitter](https://twitter.com/urblon)

14−

15−[Telegram](https://t.me/urblon)

content/communities/urbit-mst.mddeleted−13

@@ -1,13 +0,0 @@

1−+++

2−title = "Urbit MST (Utah)"

3−description = ""

4−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/communities/urbit-utah.png"

5−+++

6−

7−Are you looking for more than the options presented to you?

8−

9−Come to our Urbit (MST) meetup. All are welcome. Bring a computer and we can onboard you with a planet and hosting for free on site. Whether you are new to Urbit or fluent in Hoon, come and meet others in Utah interested in Urbit.

10−

11−––

12−

13−[Website](https://urbitmst.org/)

content/communities/urbit-ny.mddeleted−11

@@ -1,11 +0,0 @@

1−+++

2−title = "Urbit NY"

3−description = ""

4−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/communities/urbit-ny.png"

5−+++

6−

7−We love experimenting with Urbit & tinkering with Arvo, Hoon, & Nock

8−

9−––

10−

11−[Meetup page](https://www.meetup.com/Urbit-New-York/)

content/communities/urbit-paris.mddeleted−23

@@ -1,23 +0,0 @@

1−+++

2−title = "Urbit Paris"

3−description = ""

4−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/communities/urbitparis.png"

5−+++

6−

7−Join us for our monthly Urbit meetups in Paris!

8−

9−Whether you're a tech enthusiast, an established Urbit aficionado, or a newcomer to the scene, our community is meant to welcome and engage everyone.

10−

11−If you're confused about what Urbit is, no worries, most people are at first. Drop by and we'll give you our best explanations of what Urbit is and how it's going to change the internet as we know it.

12−

13−We'll introduce Urbit, help you boot your own ship, and make sure you go back home all set!

14−

15−See you there!

16−

17−––

18−

19−~solsup-soplyd/urbit-paris

20−

21−[Twitter](https://twitter.com/urbitparis)

22−

23−[Meetup](https://www.meetup.com/urbit-paris/)

content/communities/urbit-seattle.mddeleted−14

@@ -1,14 +0,0 @@

1−+++

2−title = "Urbit Seattle"

3−description = ""

4−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/communities/urbit-seattle.png"

5−+++

6−

7−Urbit is a simple, durable computer that you own 100% and forever. In this group, we'll discuss ongoing project developments, technical details, and how to use Urbit. With occasional speakers that will present on various topics.

8−

9−

10−––

11−

12−[Meetup page](https://www.meetup.com/urbit-seattle/)

13−

14−[Twitter](https://twitter.com/SeattleUrbit)

content/communities/urbit-sf.mddeleted−15

@@ -1,15 +0,0 @@

1−+++

2−title = "Urbit SF"

3−description = ""

4−image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/communities/urbit-sf.png"

5−+++

6−

7−Want to own and control the server side? Your digital identity, data and computation?

8−

9−So do we — so we're building Urbit. We set this group up for anyone excited about this kind of stuff, even those who think we're totally crazy.

10−

11−Come join us to talk about what the future of the internet might look like.

12−

13−––

14−

15−[Meetup page](https://www.meetup.com/urbit-sf/)

content/community/_index.mdnew file+5

@@ -0,0 +1,5 @@

1++++

2+title = "Community"

3+sort_by = "weight"

4+template = "list.html"

5++++

content/community/community-grants.mdnew file+14

@@ -0,0 +1,14 @@

1++++

2+title = "Community Grants"

3+description = "Select Urbit address space grants for your group or community."

4+weight = 3

5+[extra]

6+hideprevious = "true"

7+hidenext = "true"

8++++

9+

10+Interested in getting your community on Urbit? We are currently accepting applications for select groups to get started on Urbit together using an [invite pool](/using/id/creating-an-invite-pool).

11+

12+To get started, fill out the application below. Any information you share will be held privately, and only for the purpose of consideration for the grant.

13+

14+<iframe src="https://docs.google.com/forms/d/e/1FAIpQLSf_uD5fUw6xqoxtzUhSwURFYO57XQl067N3vEdy7_rTD8T2VQ/viewform?embedded=true" width="640" height="1394" frameborder="0" marginheight="0" marginwidth="0">Loading…</iframe>

content/community/governance.mdnew file+25

@@ -0,0 +1,25 @@

1++++

2+title = "Governance"

3+description = "On the governance of the project, including both the senate of galaxies and the core developers."

4+aliases = ["/governance"]

5+weight = 4

6+[extra]

7+hideprevious = "true"

8+hidenext = "true"

9++++

10+

11+Our goal is to design Urbit simply, such that as many decisions as possible are made by the architecture of the system itself – that is, code should be law whenever possible. Code can’t anticipate every eventuality, however, and so the system design must include mechanisms that allow decisions to be made outside of the code.

12+

13+Within Urbit, this form of governance is conducted by two groups: the senate of galaxies, and the body of core developers. The senate of galaxies is empowered to make changes to the solidity contracts which define Azimuth, Urbit’s PKI, by majority vote. This process is defined by the contracts themselves.

14+

15+An owner of a galaxy (or a delegate) can propose a new iteration of the contract logic. The proposal can then be voted on for a period of thirty days. Once that period is over, if at least a quarter of the galaxies has voted, and the majority is in favor, the old logic contract will hand over the reigns to the new one.

16+

17+In a similar process, document hashes can be proposed. While their off-chain documents can't be "technically enforced", this mechanism is useful for the Senate to record more abstract decisions.

18+

19+For off-chain process around proposals, as suggested by core developers, please see [senate.md](https://github.com/urbit/azimuth/blob/master/senate.md).

20+

21+The group of core developers manages Urbit’s [GitHub repository](https://github.com/urbit/), which controls Arvo, Urbit’s operating system. Changes and upgrades are decided upon by consensus.

22+

23+You can participate in the governance of the senate by acquiring a galaxy. If you would like to be involved with the governance of Arvo, check out our [developer guide](/docs/development/develop) to learn how you can contribute to core development.

24+

25+

content/community/hoonschool.mdnew file+15

@@ -0,0 +1,15 @@

1++++

2+title = "Hoon School"

3+description = "A free, instructed, asynchronous program to learn Hoon with peers."

4+weight = 0

5+aliases = ["/hoonschool"]

6+[extra]

7+hideprevious = "true"

8+hidenext = "true"

9++++

10+

11+Hoon School and Hooniversity (the community run Hoon School project) are currently on hiatus pending a rework of the course.

12+

13+You can still apply below and we'll let you know when the new course is ready!

14+

15+<iframe id="apply" src="https://docs.google.com/forms/d/e/1FAIpQLSdcEoEqpFvB1WCTKPaYUSbJcjQ2nHk_z4XcZPIQc0SFD1rgmA/viewform?embedded=true" width="640" height="1350" frameborder="0" marginheight="0" marginwidth="0">Loading…</iframe>

content/community/hosting-a-meetup.mdnew file+82

@@ -0,0 +1,82 @@

1++++

2+title = "Hosting a Meetup"

3+description = "Best practices for hosting your Urbit meetups."

4+weight = 2

5+[extra]

6+flatten_pagination = "true"

7+hidenext = "true"

8+hide_previous_title = "true"

9++++

10+

11+There are already [a few](../meetups) Urbit meetups that take place in cities around the United States. Want to start a meetup in your home town? Consider these best practices.

12+

13+### Create the Meetup Group Online

14+

15+The most straightforward way to start a meetup group online, like on [meetup.com](www.meetup.com). Services like this offer messaging, calendaring, payments, discussion boards, and basic group profiles.

16+

17+There are other options available but, regardless of what you choose, there should be a public place on the Web for people to access the group.

18+

19+Group suggestions:

20+

21+- Meetup.com

22+- Google groups

23+- Dedicated Website

24+

25+### Spread the word

26+

27+It’s not much fun if people don’t actually show up, so it’s important to get the word out. Use your existing network to tell people about your event. Remember it takes time to build a community, so don’t be discouraged if only a few people show up at first. Post to social media and email your friends. Also, be sure to email [support@urbit.org](mailto:support@urbit.org), and we'll promote your meetup.

28+

29+Outreach methods:

30+

31+- Post to social media

32+- Email your friends

33+- Put up signs

34+

35+### Format

36+

37+Meetups are about sharing ideas and meeting like-minded people. There are a few formats that can help achieve this goal. As the organizer, take the lead and prepare ahead of time. Think of some topics for the group to discuss, and try to ensure that the conversation isn’t dominated by one or two people.

38+

39+Presentations and guided group discussions are great ways to share ideas. If you have a speaker for your event, coordinate ahead of time and make sure they have everything they will need to make a great presentation and ask them to arrive early to the event. If you have a speaker, be sure to record the talk so that it can be posted online.

40+

41+Format considerations:

42+

43+- Guided group discussion

44+- Presentation

45+

46+### Venue

47+

48+Your meeting location can determine the success of your event. Ideally, you’d want to be away from congested areas and find locations with good parking and transit options nearby. However, this isn’t always possible, so just do your best to accommodate. It’s also a good idea to locate the event near bars or restaurants so people can continue the conversation after the event officially ends.

49+

50+Location considerations:

51+

52+- Easily reachable

53+- Consider parking and distance to transit

54+- Check out public libraries

55+- Coworking spaces

56+- [peerspace.com](https://www.peerspace.com/)

57+

58+### Date and time

59+

60+Most people are able to attend meetups after work on non-holiday weekdays, between about 6-8pm. This isn’t true for everyone but it’s a good rule of thumb. It’s also a good idea to avoid holidays and days when there are large sporting events happening.

61+

62+Date considerations:

63+

64+- Weekdays

65+- Between 6pm and 8pm

66+- Avoid holidays and weekends

67+

68+### Stay consistent

69+

70+Like basically anything worth doing, meetups take time, patience, and consistency. Come prepared to engage with people and have a good time. The more often you can meet the stronger the community can become, so schedule meetups regularly.

71+

72+### Bonus

73+

74+Here are a few tips and tricks to consider with hosting a meetup. You don’t have to have all these things at your first meeting, but try adding them in as you go.

75+

76+- Names tags

77+- Door signs

78+- Projector

79+- Extension cords and power strips

80+- Video camera

81+- Lapel microphone

82+- Bring your own internet

content/community/meetups.mdnew file+51

@@ -0,0 +1,51 @@

1++++

2+title = "Meetups"

3+aliases = ["/meetups"]

4+description = "Information on Urbit meetups and other community-led, Urbit IRL groups."

5+weight = 1

6+[extra]

7+flatten_pagination = "true"

8+hideprevious = "true"

9+hide_next_title = "true"

10++++

11+

12+<picture>

13+<source src="https://media.urbit.org/site/meetup1.jpg">

14+<img class="mt4" src="https://media.urbit.org/site/meetup1.jpg"/>

15+</picture>

16+

17+Turns out that getting Urbit fans together in one room is pretty fun. Here's an incomplete list of community-led Urbit IRL groups. These events are generally informal and very approachable – feel free to dive in.

18+

19+Interested in hosting an Urbit event of your own? Follow our [guide to meetup best-practices](../hosting-a-meetup). Send an email to [support@urbit.org](mailto:support@urbit.org) and we'll list your meetup on this page.

20+

21+### Asia

22+

23+Location | Contact information

24+:------------ | :-------------

25+Moscow, RU | [Timepad](https://urbitmoscow.timepad.ru/events/)

26+

27+### Europe

28+

29+Location | Contact information

30+:------------ | :-------------

31+Copenhagen, DK | [Twitter](https://twitter.com/UrbitCPH), [Meetup.com](https://www.meetup.com/Urbit-Copenhagen/)

32+

33+### North America

34+

35+Location | Contact information

36+:------------ | :-------------

37+Phoenix, AZ | [Twitter](https://twitter.com/UrbitPHX), [Meetup.com](https://www.meetup.com/urbit-phx/)

38+San Francisco, CA | [Meetup.com](https://www.meetup.com/urbit-sf/)

39+New York, NY | [Meetup.com](https://www.meetup.com/Urbit-New-York/)

40+Toronto, ON | [Twitter](https://twitter.com/UrbitToronto), [Meetup.com](https://www.meetup.com/Urbit-Toronto/)

41+Eugene, OR | [Twitter](https://twitter.com/EugeneUrbit)

42+Austin, TX | [Meetup.com](https://www.meetup.com/Urbit-Austin/)

43+Denton, TX | [Twitter](https://twitter.com/UrbitDFW)

44+Seattle, WA | [Meetup.com](https://www.meetup.com/urbit-seattle/)

45+

46+

47+### Oceania

48+

49+Location | Contact information

50+:------------ | :-------------

51+Sydney, AU | [Meetup.com](https://www.meetup.com/Urbit-Sydney)

content/docs/_index.mdnew file+56

@@ -0,0 +1,56 @@

1++++

2+title = "Development Docs"

3+weight = 1

4+template = "sections/docs.html"

5++++

6+

7+Welcome to the developer documentation for the Urbit project. This documentation

8+is maintained by [Tlon](https://tlon.io) and the Urbit community in a public

9+[Github repository](https://github.com/urbit/docs). Issues and contributions are

10+welcome.

11+

12+This documentation provides a series of explainers, guides, tutorials and

13+reference material for assisting you in developing on the Urbit platform, or

14+contributing to the Urbit project. If you're looking for documentation on how to

15+*use* your Urbit ship, see our [usage docs](/using/).

16+

17+### [Development](/docs/development/)

18+

19+The Development section is recommended reading for developers interested in

20+contributing to Urbit itself, or building apps on top of Urbit. It serves as a

21+high-level orientation to how to set up a development environment, the various

22+codebases that comprise the project, our grants program, and the precepts that

23+drive the development of Urbit.

24+

25+### [System Overview](/docs/system-overview/)

26+

27+This section gives a high-level overview to all the major components of the

28+Urbit tech stack - namely, the operating system Arvo, the programming languages

29+Nock and Hoon, the runtime Vere, and the decentralized ID system Azimuth.

30+

31+### [Arvo (Urbit OS)](/docs/arvo/)

32+

33+This section covers the kernel of Urbit OS, called Arvo, as well as its kernel modules.

34+

35+### [Hoon (High-level Language)](/docs/hoon/)

36+

37+Here is contained all official documentation on Hoon, the high-level purely

38+functional programming language in which Arvo and much of userspace is written.

39+

40+### [Nock (Low-level Language)](/docs/nock/)

41+

42+Official guidance on Nock, the functional assembly-level language which serves

43+as the basis for Hoon.

44+

45+### [Vere (Interpreter)](/docs/vere/)

46+

47+Documentation on Vere, the Nock virtual machine which serves as the interface

48+between Urbit and Unix.

49+

50+### [Azimuth (Urbit ID)](/docs/azimuth/)

51+

52+The workings of Azimuth, the decentralized ID system utilized by Urbit.

53+

54+### [Userspace](/docs/userspace/)

55+

56+Developer guides for Gall (the vane for controlling userspace apps), Landscape (the web client by which most users interact with their ship), and Threads (transient apps for IO).

content/docs/arvo/_index.mdnew file+55

@@ -0,0 +1,55 @@

1++++

2+title = "Arvo"

3+weight = 300

4+sort_by = "weight"

5+template = "sections/docs/chapters.html"

6+aliases = ["/docs/learn/arvo/"]

7++++

8+

9+Resources about the Urbit OS.

10+

11+## [Overview](/docs/arvo/overview)

12+

13+Arvo is Urbit's functional operating system, written in [Hoon](/docs/hoon/hoon-school/). It's composed of modules called _vanes_, each of which has its own folder:

14+

15+## [Ames](/docs/arvo/ames/ames)

16+

17+Ames is the name of our network and the vane that communicates over it. It's an encrypted P2P network composed of instances of the Arvo operating system.

18+

19+## [Behn](/docs/arvo/behn/behn)

20+

21+Behn is our timer. It allows vanes and applications to set and timer events, which are managed in a simple priority queue.

22+

23+## [Clay](/docs/arvo/clay/clay)

24+

25+Clay is our filesystem and revision-control system.

26+

27+## [Dill](/docs/arvo/dill/dill)

28+

29+Dill is our terminal driver. Unix sends keyboard events to dill from the terminal, and dill produces terminal output.

30+

31+## [Eyre](/docs/arvo/eyre/eyre)

32+

33+Eyre is our HTTP server. Unix sends HTTP messages to `%eyre`, and `%eyre` produces HTTP messages in response.

34+

35+## [Ford](/docs/arvo/ford/ford)

36+

37+Ford is our build system. It handles resources and publishing.

38+

39+## [Gall](/docs/arvo/gall/overview)

40+

41+Gall is the vane for controlling userspace apps.

42+

43+## [Iris](/docs/arvo/iris/iris-api)

44+

45+Iris is our HTTP client.

46+

47+## [Concepts](/docs/arvo/concepts/)

48+

49+Explanations of design decisions that are pervasive throughout Arvo.

50+

51+## [Tutorials](/docs/arvo/tutorials/)

52+

53+Walkthroughs that teach you more about how Arvo works.

54+

55+

content/docs/arvo/ames/_index.mdnew file+7

@@ -0,0 +1,7 @@

1++++

2+title = "Ames"

3+weight = 10

4+sort_by = "weight"

5+template = "sections/docs/chapters.html"

6+insert_anchor_links = "right"

7++++

content/docs/arvo/ames/ames-api.mdnew file+292

@@ -0,0 +1,292 @@

1++++

2+title = "API Reference"

3+weight = 10

4+template = "doc.html"

5++++

6+

7+In this document we describe the public interface for Ames. Namely, we describe

8+each `task` that Ames can be `%pass`ed, and which `gift`(s) Ames can `%give` in return.

9+

10+Some `task`s appear to have more than one arm associated to them, e.g. there are

11+four `+on-hear` arms. We denote this where it occurs, but always refer to the

12+`on-hear:event-core` arm.

13+

14+Ames `task`s can be naturally divided into two categories: messaging tasks and

15+system/lifecycle tasks.

16+

17+## Messaging Tasks

18+

19+### `%hear`

20+

21+`%hear` handles raw packet receipt. This `task` only ever originates from Unix.

22+It does the initial processing of a packet, namely by passing the raw packet

23+information to `+decode-packet` which deserializes the packet and giving that data and the origin of the

24+packet to `+on-hear-packet`, which begins the transformation of the packet into

25+a new event in the form of a `+event-core`.

26+

27+There are multiple `+on-hear` arms in `ames.hoon`. Here we refer to

28+`on-hear:event-core`, as that is the one called by a `%hear` `task`. The other ones are used

29+primarily for ack and nack processing, or receiving message fragments.

30+

31+#### Accepts

32+

33+```hoon

34+[=lane =blob]

35+```

36+

37+`%hear` takes in a `blob`, which is essentially a large atom (around 1kB or less)

38+that is the raw data of the message, and a `lane`, which is the origin of the

39+message (typically an IP address).

40+

41+#### Returns

42+

43+`%hear` can trigger a number of possible returns. It can trigger the release of

44+zero or more additional packets via `%send` `gift`s. It may also trigger a `%boon`

45+or `%plea` `gift` (collectively referred to as a `%memo` within Ames) to a local vane in the case of a completed message.

46+

47+

48+### `%heed`

49+

50+A vane can pass Ames a `%heed` `task` to request Ames track a peer's

51+responsiveness. If our `%boon`s to it start backing up locally,

52+Ames will `give` a `%clog` back to the requesting vane containing the

53+unresponsive peer's Urbit address.

54+

55+Stop tracking a peer by sending Ames a

56+`%jilt` `task`.

57+

58+

59+#### Accepts

60+

61+```hoon

62+=ship

63+```

64+

65+The ship to be tracked.

66+

67+#### Returns

68+

69+If the `ship` is indeed being unresponsive, as measured by backed up `%boon`s,

70+Ames will `give` a `%clog` `gift` to the requesting vane containing the

71+unresponsive peer's urbit address.

72+

73+

74+### `%hole`

75+

76+`%hole` handles packet crash notification. `%hole` works much like `%hear`, in

77+that it passes an incoming raw packet to `+decode-packet` to be deserialized,

78+and then passes that data along with the source of the packet to

79+`+on-hear-packet` along with a `?` set to `%.n` denoting that there is something wrong with

80+the packet.

81+

82+#### Accepts

83+

84+```hoon

85+[=lane =blob]

86+```

87+`%hole` takes in a `blob`, which is essentially a large atom (around 1kB or less)

88+that is the raw data of the message, and a `lane`, which is the origin of the

89+message (typically an IP address).

90+

91+#### Returns

92+

93+Like `%hear`, `%hole` can trigger additional packets in the form of `%send`

94+`gift`s, and may also yield a `%boon` or `%plea` `gift` to a local vane.

95+

96+

97+### `%jilt`

98+

99+`%jilt` stops tracking a potentially unresponsive peer that was previously being

100+tracked as a result of the `%heed` `task`.

101+

102+There are two `+on-jilt` arms, this `task` utilizes `on-hear:event-core`.

103+

104+#### Accepts

105+

106+```hoon

107+=ship

108+```

109+

110+The `ship` we no longer wish to track.

111+

112+#### Returns

113+

114+This `task` returns no `gift`s.

115+

116+

117+### `%plea`

118+

119+`%plea` is the `task` used to instruct Ames to send a message. It extends the

120+`%pass`/`%give` semantics across the network. As such, it is the most

121+fundamental `task` in Ames and the primary reason for its existence.

122+

123+Ames also `pass`es a `%plea` `note` to another vane when it receives a message on a

124+"forward flow" from a peer, originally passed from one of the peer's vanes to the

125+peer's Ames.

126+

127+Ultimately `%plea` causes `%send` `gift`(s) to be sent to Unix, which tells

128+Unix to send packets. In terms of `%pass`/`%give` semantics, this is in

129+response to the `%born` `task`, which came along the Unix `duct`, rather than a

130+response to the `%plea`.

131+

132+#### Accepts

133+

134+```hoon

135+[=ship =plea]

136+```

137+

138+A `%plea` `task` takes in the `ship` the `plea` is addressed to, and a `$plea`,

139+which is

140+

141+```hoon

142+ +$ plea [vane=@tas =path payload=*]

143+```

144+Here, `vane` is the destination vane on the remote ship, `path` is the internal

145+route on the receiving ship, and `payload` is the semantic message content.

146+

147+#### Returns

148+

149+This `task` returns no `gift`s.

150+

151+## System and Lifecycle Tasks

152+

153+### `%born`

154+

155+Each time you start your Urbit, the Arvo kernel calls the `%born` task for Ames.

156+

157+#### Accepts

158+

159+`%born` takes no arguments.

160+

161+#### Returns

162+

163+In response to a `%born` `task`, Ames `%give`s Jael a `%turf` `gift`.

164+

165+The `duct` along which `%born` comes is Ames' only duct to Unix, so `%send`

166+`gift`s (which are instructions for Unix to send a packet) are also returned in

167+response to `%born`.

168+

169+

170+### `%crud`

171+

172+`%crud` is called whenever an error involving Ames occurs. It produces a crash

173+report in response.

174+

175+#### Accepts

176+

177+```hoon

178+=error

179+```

180+

181+A `$error` is a `[tag=@tas =tang]`.

182+

183+#### Returns

184+

185+Ames does not `give` a `gift` in response to a `%crud` `task`, but it does

186+`%pass` Dill a `%flog` `task` instructing it to print `error`.

187+

188+

189+## `%init`

190+

191+`%init` is called a single time during the very first boot process, immediately

192+after the [larval stage](/docs/arvo/overview#larval-stage-core)

193+is completed. This initializes the vane. Jael is initialized first, followed by

194+other vanes such as Ames.

195+

196+In response to receiving the `%init` `task`, Ames subscribes to the information

197+contained by Jael.

198+

199+#### Accepts

200+

201+```hoon

202+our=ship

203+```

204+

205+`%init` takes in the name of our ship, which is a `@p`.

206+

207+#### Returns

208+

209+```hoon

210+ =~ (emit duct %pass /turf %j %turf ~)

211+ (emit duct %pass /private-keys %j %private-keys ~)

212+```

213+

214+`%init` sends two moves that subscribe to `%turf` and `%private-keys` in Jael.

215+

216+

217+### `%sift`

218+

219+This `task` filters debug output by ship.

220+

221+#### Accepts

222+

223+```hoon

224+ships=(list ship)

225+```

226+

227+The list of ships for which debug output is desired.

228+

229+#### Returns

230+

231+This `task` returns no `gift`s.

232+

233+

234+### `%spew`

235+

236+Sets verbosity toggles on debug output. These toggles are as follows.

237+

238+* `%snd` - sending packets

239+* `%rcv` - receiving packets

240+* `%odd` - unusual events

241+* `%msg` - message-level events

242+* `%ges` - congestion control

243+* `%for` - packet forwarding

244+* `%rot` - routing attempts

245+

246+Each toggle is a flag set to `%.n` by default.

247+

248+#### Accepts

249+

250+```hoon

251+verbs=(list verb)

252+```

253+

254+`%spew` takes in a `list` of `verb`, which are verbosity flags for Ames.

255+

256+```hoon

257++$ verb ?(%snd %rcv %odd %msg %ges %for %rot)

258+```

259+

260+`%spew` flips each toggle given in `verbs`.

261+

262+#### Returns

263+

264+This `task` returns no `gift`s.

265+

266+

267+### `%vega`

268+

269+`%vega` is called whenever the kernel is updated. Ames currently does not do

270+anything in response to this.

271+

272+#### Accepts

273+

274+`%vega` takes no arguments.

275+

276+#### Returns

277+

278+This `task` returns no `gift`s.

279+

280+

281+### `%wegh`

282+

283+This `task` is a request to Ames to produce a memory usage report.

284+

285+#### Accepts

286+

287+This `task` has no arguments.

288+

289+#### Returns

290+

291+In response to this `task,` Ames `%give`s a `%mass` `gift` containing Ames'

292+current memory usage.

content/docs/arvo/ames/ames.mdnew file+423

@@ -0,0 +1,423 @@

1++++

2+title = "Overview"

3+weight = 1

4+template = "doc.html"

5+aliases = ["/docs/learn/arvo/ames/"]

6++++

7+Our networking protocol.

8+

9+Ames is the name of both our network and the vane that communicates

10+over it. When Unix receives a packet over the correct UDP port, it pipes

11+it straight into Ames for handling. Also, all packets sent over the

12+Ames network are sent by the Ames vane. Apps and vanes may use

13+Ames to directly send messages to other ships. In general, apps use

14+[Gall](/docs/userspace/gall/gall) and [Clay](/docs/arvo/clay/clay)

15+to communicate with other ships rather than using Ames

16+directly, but this isn't a requirement. Of course, Gall and Clay use

17+Ames behind the scenes to communicate across the network. Jael is the only other

18+vane to utilize Ames.

19+

20+Ames includes several significant components. Although the actual

21+crypto algorithms are defined in `zuse`, they're used extensively in

22+Ames for encrypting and decrypting packets. Congestion control and

23+routing is handled entirely in Ames. Finally, the actual Ames

24+protocol itself, including how to route incoming packets to the correct

25+vane or app, is defined in Ames.

26+

27+## Technical Overview

28+This section summarizes the design of Ames. Beyond this section are deeper

29+elaborations on the concepts presented here.

30+

31+Ames extends [Arvo's](/docs/arvo/overview) `%pass`/`%give` `move` semantics across the network.

32+

33+Ames receives packets as Arvo events and emits packets as Arvo

34+effects. The runtime is responsible for transferring the bytes in

35+an Ames packet across a physical network to another ship.

36+

37+The runtime tells Ames which physical address a packet came from,

38+represented as an opaque atom. Ames can emit a packet effect to

39+one of those opaque atoms or to the Urbit address of a galaxy

40+(root node), which the runtime is responsible for translating to a

41+physical address. One runtime implementation sends UDP packets

42+using IPv4 addresses for ships and DNS lookups for galaxies, but

43+other implementations may overlay over other kinds of networks.

44+

45+A local vane can pass Ames a `%plea` request message. Ames

46+transmits the message over the wire to the peer ship's Ames, which

47+passes the message to the destination vane.

48+

49+Once the peer has processed the `%plea` message, it sends a

50+message-acknowledgment packet over the wire back to the local

51+Ames. This "ack" can either be positive to indicate the request was

52+processed, or negative to indicate the request failed, in which

53+case it's called a "nack". (Don't confuse Ames nacks with TCP

54+nacks, which are a different concept).

55+

56+When the local Ames receives either a positive message-ack or a

57+combination of a nack and "naxplanation" (explained in more detail

58+below), it gives an `%done` `move` to the local vane that had

59+requested the original `%plea` message be sent.

60+

61+A local vane can give Ames zero or more `%boon` response messages in

62+response to a `%plea`, on the same duct that Ames used to pass the

63+`%plea` to the vane. Ames transmits a `%boon` over the wire to the

64+peer's Ames, which gives it to the destination vane on the same

65+duct the vane had used to pass the original `%plea` to Ames.

66+

67+`%boon` messages are acked automatically by the receiver Ames. They

68+cannot be nacked, and Ames only uses the ack internally, without

69+notifying the client vane that gave Ames the `%boon`.

70+

71+If the Arvo event that completed receipt of a `%boon` message

72+crashes, Ames instead sends the client vane a `%lost` message

73+indicating the `%boon` was missed.

74+

75+`%plea` messages can be nacked, in which case the peer will send

76+both a message-nack packet and a naxplanation message, which is

77+sent in a way that does not interfere with normal operation. The

78+naxplanation is sent as a full Ames message, instead of just a

79+packet, because the contained error information can be arbitrarily

80+large. A naxplanation can only give rise to a positive ack --

81+never ack an ack, and never nack a naxplanation.

82+

83+Ames guarantees a total ordering of messages within a "flow",

84+identified in other vanes by a duct and over the wire by a `bone`:

85+an opaque number. Each flow has a FIFO (first-in-first-out) queue of `%plea` requests

86+from the requesting ship to the responding ship and a FIFO queue

87+of `%boon`'s in the other direction.

88+

89+Message order across flows is not specified and may vary based on

90+network conditions.

91+

92+Ames guarantees that a message will only be delivered once to the

93+destination vane.

94+

95+Ames encrypts every message using symmetric-key encryption by

96+performing an elliptic curve Diffie-Hellman using our private key

97+and the public key of the peer. For ships in the Jael PKI

98+(public-key infrastructure), Ames looks up the peer's public key

99+from Jael. Comets (128-bit ephemeral addresses) are not

100+cryptographic assets and must self-attest over Ames by sending a

101+single self-signed packet containing their public key.

102+

103+When a peer suffers a continuity breach, Ames removes all

104+messaging state related to it. Ames does not guarantee that all

105+messages will be fully delivered to the now-stale peer. From

106+Ames's perspective, the newly restarted peer is a new ship.

107+Ames's guarantees are not maintained across a breach.

108+

109+A vane can pass Ames a `%heed` `$task` to request Ames track a peer's

110+responsiveness. If our `%boon`'s to it start backing up locally,

111+Ames will give a `%clog` back to the requesting vane containing the

112+unresponsive peer's urbit address. This interaction does not use

113+ducts as unique keys. Stop tracking a peer by sending Ames a

114+`%jilt` `$task`.

115+

116+Debug output can be adjusted using `%sift` and `%spew` `$task`'s.

117+

118+## Packets

119+

120+Ames datagram packets are handled as nouns internally by Arvo but as serial data

121+by Unix. In this section we describe how packets are formed, serialized, and relayed.

122+

123+### Packet format

124+

125+There is a 32-bit header followed by a variable width body.

126+

127+#### Header

128+

129+The 32-bit header is given by the following data, presented in order:

130+

131+ - 3 bits: Ames `protocol-version`,

132+ - 20 bits: a checksum as a truncated insecure hash of the body, done with

133+ [`+mug`](/docs/hoon/reference/stdlib/2e#mug),

134+ - 2 bits: the bit width of the sender address encoded as a 2-bit enum,

135+ - 2 bits: the bit width of the receiver address encoded as a 2-bit enum,

136+ - 1 bit: whether the packet is encrypted or not,

137+ - 4 bits: unused.

138+

139+ Every packet sent between ships is encrypted except for self-signed attestation packets from 128-bit comets.

140+

141+#### Body

142+

143+The body is of variable length and consists of three parts in this order:

144+

145+ - The `@p` of the sending ship,

146+ - The `@p` of the receiving ship,

147+ - The payload, which is the [`+jam`](/docs/hoon/reference/stdlib/2p#jam) (i.e. serialization) of the noun `[origin content]`.

148+

149+ `origin` is the IP and port of the original sender if the packet was proxied

150+ through a relay and null otherwise. `content` is a noun that is either an encrypted ack or an

151+ encrypted message fragment, unless it is a comet attestation packet in which

152+ case it is unencrypted. `content` is always 1kB in size or less.

153+

154+ The sender and receiver live outside of the jammed data section to simplify

155+ packet filtering for the interpreter.

156+

157+### Packeting

158+

159+When Ames has a message to be sent it must first determine how many packets are

160+required to send the message. To do this, it first `+jam`s the

161+message, producing an atom. Ames checks how large the atom is, and if it is

162+bigger than a kilobyte it will split it into packets whose payloads are 1 kB or

163+less. It then numbers each one - this is message 17, packet 12, this is message

164+17, packet 13, etc., so that when the receiver receives these packets it knows

165+which number they are. Finally it encrypts each individual packet and enqueues

166+them to be sent along their stated flow.

167+

168+Network packets aren't always received in order, so this numbering is important

169+for reconstruction, and also packets may get lost. So Ames does transmission

170+control (the TC in TCP) to solve this problem. It makes sure that all packets

171+eventually get through, and when the other side gets them it can put them in the

172+correct order. If Ames doesn't get an ack on a packet then it will resend it

173+until it does. The logic for determining how many packets to send or re-send at what time is performed by an Ames-specific variant of TCP's "NewReno" congestion control algorithm.

174+

175+As each packet in a message is received, Ames decrypts it and stores the message fragment. Once it's received every packet for a message, Ames concatenates the fragments back into a single large atom and uses `+cue` to deserialize that back into the original message noun.

176+

177+

178+

179+### Acks and Nacks

180+

181+In this section we discuss acks and nacks. In Ames, an "ack", short for "acknowledgment", is a small packet attesting that a piece of information (either a packet or a whole message) was received. Ames makes use of

182+acks to maintain synchronization between two communicating parties. Nacks are 'negative

183+acknowledgments' and are used when something goes wrong.

184+

185+#### Acks

186+

187+Every message (i.e. a `%plea` or `%boon`) is split up by Ames into some number

188+of _fragments_ that are 1kB in size or less. The fragments are then encrypted

189+and encapsulated into

190+packets and sent along a flow. The message will be considered successfully

191+received once the sender has received the appropriate set of acks in response,

192+defined as follows.

193+

194+There are two types of acks: fragment acks and message acks. Acks are

195+not considered messages, and thus are not `%plea`s or `%boon`s. Given a message split into N

196+fragments, the sender of the message will expect N-1 fragment acks followed

197+by exactly one message ack (ignoring any duplicate packets, which are idempotent

198+from the perspective of the application). This is because the receiver

199+will send a fragment ack for the first N-1 packets it received, and what

200+would have been the final fragment ack will instead be a message ack.

201+

202+Acks are considered to be part of the flow in which that `%plea` or

203+`%boon` lives, as the packets containing their fragments and packets acking the

204+receipt of those packets are considered to be what makes up a given message.

205+Thus a message-level ack must be received before the next message on the flow

206+can begin. The full story is more complicated than this; see the section on

207+[flows](#flows).

208+

209+

210+#### Nacks

211+

212+A nack indicates a negative acknowledgement to a `%plea`, meaning that the

213+requested action was not performed.

214+

215+`%boon`s and naxplanations are never nacked.

216+Individual packets are also never nacked, only complete `%plea` messages are.

217+Whether a malformed packet causes a `%plea` to be nacked depends on its content.

218+In the case of an incorrect checksum or a failure to decrypt then Ames drops the

219+packet and it is as though it never happened. However, if the packet does

220+decrypt and has invalid ciphertext (i.e. something other than a jammed

221+`$shutpacket` data structure), then Ames will nack the whole `%plea` since that

222+indicates that the peer is misbehaving. Eventually Ames should also present a

223+warning to the user that the peer is untrustworthy.

224+

225+A nack will be accompanied by a naxplanation, which is a special type of`%boon`

226+that uses its own `bone` (see [flows](#flows)). Ames won't give the vane that requested the

227+initial `%plea` a nack until it also receives the naxplanation, which it will send to

228+the vane as a `%done` gift. Naxplanations may only be acked, never nacked.

229+Furthermore, naxplanations can only ever be sent as a rejection of a `%plea` -

230+the receiver will never both perform a `%plea` and return a naxplanation.

231+

232+#### (N)ack packets

233+

234+A fragment ack's contents (before encryption) are a pure function of the

235+following noun:

236+```hoon

237+[our-life her-life bone message-num fragment-num]

238+```

239+This means all re-sends of an ack packet will be bitwise identical to each other, unless one of the peers changes its encryption keys.

240+

241+Each datum in this noun is an atom with the aura `@ud` or an aura that nests

242+under `@ud`.

243+

244+Here, `our-life` refers to the [`life`](/docs/glossary/breach), or revision

245+number, of the acking ship's networking keys, and `her-life` is the `life` of

246+the ack-receiving ship's networking keys. `bone` is an opaque number identifying

247+the flow. `message-num` denotes the number of the

248+message in the flow identified by `bone`. `fragment-num` denotes the number of

249+the fragment of the message identified by `message-num` that is being acked.

250+

251+A message (n)ack is a different kind of ack that is obtained by encrypting the

252+`+jam` of the following noun:

253+

254+```hoon

255+[our-life her-life bone message-num ok=? lag=@dr]

256+```

257+`ok` is a flag that is set to `%.y` for a message ack and `%.n` for a message

258+nack. In the future, `lag` will be used to

259+describe the time it took to process a message, but for now it is always zero.

260+

261+

262+### Flows

263+

264+Flows are asymmetric communication channels along which two ships send and

265+receive packets, and all Ames packets are part of some flow.

266+

267+To create a new flow, a ship sends a

268+`%plea` to another ship. Only the creator of the flow may send `%plea`s, and the

269+other party may only send `%boon`s. In this sense flows are asymmetric.

270+

271+The sequence of `%plea`s in a flow is totally ordered, though

272+the packets which make them up need not be. `%boon`s are totally ordered in the

273+same fashion, but there is not a coordinated ordering between `%plea`s and

274+`%boon`s in a given flow beyond the implicit one arising from the fact that a

275+`%boon` is always a response to a `%plea`. A `%plea` can give rise to zero, one,

276+or many `%boon`s.

277+

278+Inside of Ames, each flow has four sequential opaque `@ud`s

279+called bones that are unique to that flow. Thus the flow itself is often

280+referred to by its first bone. Each bone is a one-way street

281+for packets to travel along, so e.g. acks to packets making up a `%plea` are

282+sent along a different bone than the `%plea`.

283+

284+We give an example of such a partition. Let flow 12 be a flow between `~bacbel-tagfeg` and `~worwel-sipnum` with

285+`~bacbel-tagfeg` as the `%plea` sender. Then bones 12-15 are associated with the

286+flow, and the types of packets for each bone are:

287+

288+ - bone 12, `%plea`s and acks to `~worwel-sipnum`,

289+ - bone 13, `%boon`s and (n)acks to `~bacbel-tagfeg`,

290+ - bone 14, acks of naxplanations to `~worwel-sipnum`,

291+ - bone 15, naxplanations to `~bacbel-tagfeg`.

292+

293+Each bone is handled separately by congestion control, and this is one reason

294+for their segregation. For example, say a two-packet `%plea` is sent on bone 12,

295+with `~bacbel-tagfeg` requesting to join a group on `~worwel-sipnum`.

296+Then `~worwel-sipnum` can ack the first packet on bone 13, and then send a nack

297+on bone 13 as well. A nack by itself contains no information as to why the nack

298+happened. Then `~worwel-sipnum` can also send a naxplanation on bone 15 saying

299+to `~bacbel-tagfeg` that they cannot join the group, to which an ack is received

300+on bone 14.

301+

302+Another reason to separate bones is to avoid race conditions. If

303+`~worwel-sipnum` and `~bacbel-tagfeg` attempt to start a flow with each other at

304+the same time we do not wish there to be a conflict when they receive each

305+others' packets. Flipping the last bit of the bone based on whether a packet is

306+an ack or a message fragment allows for `~worwel-sipnum` to create flow 8 with

307+`~bacbel-tagfeg` without coming into conflict with the flow 8 `~bacbel-tagfeg`

308+created for `~worwel-sipnum`.

309+

310+`%plea`s and `%boon`s are handled on separate bones so that e.g. sending a large

311+`%boon` doesn't stop an additional `%plea` from being received. It is also

312+simply cleaner to make each bone one-way. Acks and nacks are very small packets

313+as well as integral to controlling the total orderings on `%plea`s and `%boon`s

314+and so they are included on these bones as well.

315+

316+Naxplanations can potentially be very large, as they often contain things like stack

317+traces or other crash reports. Thus it is undesirable to have them share a bone

318+with `%boon`s and create congestion there. So naxplanations have their own bone,

319+and so do acks to packets that make up a naxplanation, as well as the

320+message-level naxplanation ack.

321+

322+### Packet relaying

323+

324+Here we describes how the Ames network relays packets. We ignore all details

325+about UDP, which occurs at a lower layer than Ames.

326+

327+When a ship first contacts another ship, it may only know its `@p`, but an IP

328+address and port are necessary for peer-to-peer communication to occur.

329+Thus the initial correspondence between two ships, or additional correspondence

330+following a change in IP or port of one of the parties, will need to be relayed

331+by an intermediary that knows the IP and port of the receiving ship.

332+

333+For now packet relaying is handled entirely by galaxies. Every galaxy is

334+responsible for knowing the IP and port of every planet underneath it. In the

335+future, galaxies will only need to know the star sponsoring a planet, and stars

336+will be responsible for the final step of the relay.

337+

338+The following diagram summarizes the packet creation and forwarding process.

339+

340+<div style="text-align:center">

341+<img src="https://media.urbit.org/docs/arvo/datagram-long.png">

342+</div>

343+

344+We elaborate on the above diagram.

345+

346+A typical relay will look something like this: `~bacbel-tagfeb` wishes to

347+contact `~worwel-sipnum` but does not know the IP address and port at which

348+`~worwel-sipnum` resides. Both planets live under `~zod`, which knows both of

349+their IP and port numbers by virtue of being the galaxy that both live under.

350+

351+To prepare, `~bacbel-tagfeb` forms a Diffie-Hellman symmetric key with their own

352+private key and the public key of `~worwel-sipnum`, obtained via Jael. Then

353+`~bacbel-tagfeb` sends a packet addressed to `~worwel-sipnum` to `~zod`.

354+

355+The packet has the following format:

356+ - The standard Ames header described in [header](#header), where the checksum

357+ is the `+mug` of the body, and the sender and receiver ship types are `01`,

358+ denoting that the sender and receiver are planets. The remainder of the

359+ packet is the body.

360+ - The body of this packet will be the `@p` of the

361+sender `~bacbel-tagfeb`, followed by the `@p` of the receiver `~worwel-sipnum`,

362+followed by the payload.

363+ - The payload of this packet will be the `+jam` of `[origin content]`. `origin`

364+for this initial packet will be `~`, which implies that the packet is

365+originating from the sender. `content` is the `+jam` of the message, encrypted

366+using the Diffie-Hellman symmetric key that was previously computed.

367+

368+`~zod` receives the packet and reads the body. It sees that it is not the

369+intended recipient of the packet, and so gets ready to forward it to

370+`~worwel-sipnum`. First, it [`+cue`s](/docs/hoon/reference/stdlib/2p#cue)

371+(deserializes) the payload and changes the `origin` to the IP and port of

372+`~bacbel-tagfeb`. Then it `+jam`s `[origin content]` to form a new payload, and

373+`+mug`s that payload to get a new checksum. It replaces the old payload and

374+checksum with the new, and then sends the packet along to `~worwel-sipnum`.

375+

376+Once `~worwel-sipnum` processes the packet, it will know the IP and port of

377+`~bacbel-tagfeb` since `~zod` included it when it forwarded the packet. Thus

378+`~worwel-sipnum` will send an ack packet directly to `~bacbel-tagfeb`, unless a

379+NAT and/or firewall prevents a direct peer-to-peer connection, in which case

380+`~zod` will continue to relay packets. Absent these factors preventing a

381+peer-to-peer connection, communication between the two ships will now be direct

382+until one of them changes their IP address, port, or networking keys.

383+

384+

385+## The Serf and the King

386+

387+Urbit's functionality is split between the two binaries `urbit-worker` (sometimes

388+called the Serf) and `urbit-king` (sometimes called the King). This division of

389+labor is currently not well-documented outside of the [Vere documents](/docs/vere/), but we summarize it here.

390+

391+In short, the Serf is the Nock runtime and so keeps track of the current state

392+of Arvo as a Nock noun and updates the state by `%poke`ing it with nouns, and

393+then informs the King of the new state. The King manages snapshots of the Arvo

394+state and handles I/O with Unix, among other things. The Serf only ever talks to

395+the King, while the King talks with both the Serf and Unix.

396+

397+### Ames I/O submodule

398+

399+The King has several submodules, one of them being an Ames I/O submodule. This

400+submodule is responsible for wrapping outgoing Ames packets as UDP packets, and

401+unwrapping incoming UDP packets into Ames packets and forwarding them to the

402+worker. It also maintains an incoming packet queue.

403+

404+This division is summarized in the following diagram, describing how

405+`~bacbel-tagfeb` requests a subscription to the `recipes` notebook of

406+`~worwel-sipnum` in the Publish app.

407+

408+<div style="text-align:center">

409+<img src="https://media.urbit.org/docs/arvo/packet.png">

410+</div>

411+

412+Ames, as a part of Arvo, handles `+jam`ming, packetizing, encryption, and

413+forming Ames packets. Once it is ready to send an Ames packet, it `%give`s to

414+Unix a `%send` `gift` containing that packet. This will be a Nock noun

415+containing the `@tas` `%send` as well as the serialized packet.

416+

417+"Unix", in this case, is actually the King. The King receives the `%send`

418+instruction, wraps the packet contained within as a UDP packet, and immediately

419+hands it off the the Unix network interface to be sent.

420+

421+Now the receiving King is handed a UDP packet by Unix. The King removes the UDP

422+wrapper, `+jam`s the `lane` on which it heard the packet, and delivers the packet

423+to the Ames vane as an atom by copying the bytes it heard on the UDP port.

content/docs/arvo/behn/_index.mdnew file+7

@@ -0,0 +1,7 @@

1++++

2+title = "Behn"

3+weight = 20

4+sort_by = "weight"

5+template = "sections/docs/chapters.html"

6+insert_anchor_links = "right"

7++++

content/docs/arvo/behn/behn-api.mdnew file+246

@@ -0,0 +1,246 @@

1++++

2+title = "API Reference"

3+weight = 10

4+template = "doc.html"

5++++

6+

7+In this document we describe the public interface for Behn. Namely, we describe

8+each `task` that Behn can be `pass`ed, and which `gift`(s) Behn can `give` in return.

9+

10+

11+## Tasks

12+

13+### `%born`

14+

15+Each time you start your Urbit, the Arvo kernel calls the `%born` task for Behn. When

16+called, Behn gets the current time from Unix and updates its list of timers

17+accordingly.

18+

19+#### Accepts

20+

21+```hoon

22+[~]

23+```

24+

25+#### Returns

26+

27+`%born` does not return a `gift`.

28+

29+

30+### `%crud`

31+

32+`%crud` is called whenever an error involving Behn occurs, such as trying to

33+`%wake` a program that has crashed.

34+

35+When called, it checks to see if the set of timers is empty. If so, it prints

36+an error report containing `error`, otherwise it passes the error to `+wake`.

37+

38+#### Accepts

39+

40+```hoon

41+[tag=@tas error=tang]

42+```

43+Here, `tag` is a `@tas` denoting the type of error, and `error` is an error message.

44+

45+#### Returns

46+

47+```hoon

48+[%wake %behn-crud-no-timer tag error]

49+```

50+

51+If the set of timers is nonempty when Behn is `%pass`ed a `%crud` `task`, Behn

52+`%give`s a `%wake` `card` containing the error to the next client in the set of timers.

53+

54+

55+#### Example

56+

57+The most common error that occurs is when Behn tries to `%wake` up a program that has crashed. When this happens

58+the entire event (i.e. sequence of `move`s) that led up to the `%wake` is thrown

59+away, and Vere then causes the kernel to `pass` Behn a `%crud` `task` containing

60+the stack trace.

61+

62+

63+### `%drip`

64+

65+`%drip` allows one to delay a `gift` until a timer set for `now` fires.

66+

67+A Client `%slip`s Behn a `%drip` task wrapping a `gift` to be `give`n to a Target.

68+This launches a sequence of `move`s as written here:

69+

70+```

71+Client -- %slip %drip --> Behn -- %pass %wait --> Behn -- %give %wake --> Behn -- %give %meta --> Target

72+```

73+Here the `%meta` `move` is a wrapper for the `%gift` inside of the initial `%drip` wrapper.

74+

75+`%drip` only handles `gift`s, and can only schedule `gift`s for as soon as

76+possible after the prescribed timer fires.

77+

78+

79+#### Accepts

80+

81+```hoon

82+mov=vase

83+```

84+

85+`%drip` takes in a `%give` `move` in a `vase`.

86+

87+#### Returns

88+

89+In response to a `%drip` `task`, Behn will `%pass` a `%wait` to itself, which

90+then triggers a `%wake` `gift` to itself, which then causes Behn to `%give` a `%meta` `gift` containing

91+the `gift` originally `%give`n to Behn when `%drip` was first called. That makes

92+Behn its own client for `%drip`.

93+

94+#### Example

95+

96+

97+Say an app (the Target) is subscribed to updates from Clay (the Client). If Clay `%give`s

98+updates to the app directly and the app crashes, this may cause Clay to crash as

99+well. If instead Clay `%pass`es Behn a `%drip` `task` wrapping the update

100+`gift`, Behn will set a timer for `now` that, when fired, will cause the update

101+`gift` to be given. If it causes a crash then it will have been in response to

102+the `%drip` move, thereby isolating Clay from the crash. Thus `%drip` acts as a sort of buffer against cascading

103+sequences of crashes.

104+

105+

106+

107+### `%huck`

108+

109+Immediately gives back an input move.

110+

111+#### Accepts

112+

113+```hoon

114+mov=vase

115+```

116+

117+Behn takes in a `move` contained in a `vase`.

118+

119+#### Returns

120+

121+```hoon

122+[%give %meta mov]

123+```

124+

125+Behn returns the input `move` as a `%meta` `gift`.

126+

127+

128+

129+### `%rest`

130+

131+Cancels a timer that was previously set.

132+

133+Behn takes in a `@da` and cancels the timer at that time if it exists, then

134+adjusts the next wakeup call from Unix if necessary.

135+

136+#### Task

137+

138+```hoon

139+@da

140+```

141+

142+

143+#### Gift

144+

145+This `task` returns no `gift`s.

146+

147+

148+

149+### `%trim`

150+

151+This `task` is sent by the interpreter in order to free up memory.

152+ This `task` is empty for Behn, since it is not a good idea to forget your timers.

153+

154+#### Accepts

155+

156+This `task` has no arguments.

157+

158+#### Returns

159+

160+This task returns nothing.

161+

162+### `%vega`

163+

164+This `task` informs the vane that the kernel has been upgraded. Behn does not do

165+anything in response to this.

166+

167+#### Accepts

168+

169+This `task` has no arguments.

170+

171+#### Returns

172+

173+This `task` returns nothing.

174+

175+

176+

177+### `%wait`

178+

179+This `task` takes in a `@da` which Behn then adds to `timers.state`, the list of timers.

180+

181+#### Accepts

182+

183+```hoon

184+@da

185+```

186+

187+#### Returns

188+

189+This `task` returns a `%wake` `gift` once the timer has fired.

190+

191+

192+### `%wake`

193+

194+This `task` is sent by the kernel when the Unix timer tells the kernel that it

195+is time for Behn to wake up. This is often caused by a `%doze` `gift` that

196+Behn originally sent to the kernel that is then forwarded to Unix, which is

197+where the real timekeeping occurs.

198+

199+Upon receiving this `task`, Behn processes the elapsed timer and then sets

200+`:next-wake`.

201+

202+`%wake` is also a `gift` that Behn can `%give`. This is done to inform other

203+vanes or apps that a timer has expired, and may include an error message.

204+

205+#### Accepts

206+

207+As a `task`, `%wake` takes in `~`.

208+

209+As a `gift`, `%wake` may include an error message.

210+

211+```hoon

212+error=(unit tang)

213+```

214+

215+

216+#### Returns

217+

218+In response to receiving this `task`, Behn may `%give` a `%doze` `gift`

219+containing the `@da` of the next timer to elapse. Behn may also `%give` a

220+`%wake` `gift` to itself.

221+

222+

223+

224+### `%wegh`

225+

226+This `task` asks Behn to product a memory usage report.

227+

228+#### Accepts

229+

230+This `task` has no arguments.

231+

232+#### Returns

233+

234+```hoon

235+:_ state :_ ~

236+ :^ duct %give %mass

237+ :+ %behn %|

238+ :~ timers+&+timers.state

239+ dot+&+state

240+```

241+

242+When Behn is `%pass`ed this `task`, it will `%give` a `%mass` `gift` in response

243+containing Behn's current memory usage.

244+

245+

246+

content/docs/arvo/behn/behn.mdnew file+21

@@ -0,0 +1,21 @@

1++++

2+title = "Overview"

3+weight = 1

4+template = "doc.html"

5++++

6+Our simple timer.

7+

8+It allows vanes and applications to set and timer events, which are

9+managed in a simple priority queue. `%behn` produces effects to start

10+the unix timer, and when the requested `%behn` passes, unix sends wake

11+events to `%behn`, which time routes back to original sender. We don't

12+guarantee that a timer event will happen at exactly the `%behn` it was

13+set for, or even that it'll be particularly close. A timer event is a

14+request to not be woken until after the given time.

15+

16+`%eyre` uses `%behn` for timing out sessions, and `%clay` uses `%behn`

17+for keeping track of time-specified file requests. `%ames` should

18+probably use `%behn` to keep track of things like network timeouts and

19+retry timing, but it currently uses its own alarm system.

20+

21+This article is a stub. For more information, see either `behn.hoon` or [Lesson 2.6 - Behn](/docs/hoon/hoon-school/behn) of the Hoon tutorial.

content/docs/arvo/clay/_index.mdnew file+36

@@ -0,0 +1,36 @@

1++++

2+title = "Clay"

3+weight = 30

4+sort_by = "weight"

5+template = "sections/docs/chapters.html"

6+insert_anchor_links = "right"

7++++

8+

9+[Overview](/docs/arvo/clay/clay)

10+

11+High-level overview of Clay.

12+

13+[Architecture](/docs/arvo/clay/architecture)

14+

15+A conceptual overview of how Clay was designed.

16+

17+[Using Clay](/docs/arvo/clay/using)

18+

19+A quick overview of how the most common tasks involving Clay are performed:

20+reading and subscribing, syncing to Unix, and merging.

21+

22+[Data Types](/docs/arvo/clay/data-types)

23+

24+Explanations of the many data types found throughout Clay.

25+

26+[Scry Reference](/docs/arvo/clay/scry)

27+

28+Reference for Clay's various scry endpoints.

29+

30+[API Reference](/docs/arvo/clay/tasks)

31+

32+Details of the various `task`s you can use to interact with Clay.

33+

34+[Examples](/docs/arvo/clay/examples)

35+

36+Example usage of the various Clay `task`s.

content/docs/arvo/clay/architecture.mdnew file+254

@@ -0,0 +1,254 @@

1++++

2+title = "Architecture"

3+weight = 2

4+template = "doc.html"

5++++

6+

7+Clay is the primary filesystem for the [Arvo](/docs/arvo/overview) operating system,

8+which is the [core](/docs/glossary/core/) of an urbit. The architecture of Clay is

9+intrinsically connected with Arvo, but for this section we assume no knowledge of

10+either Arvo or Urbit. We will point out only those features of

11+Arvo that are necessary for an understanding of Clay, and we will

12+do so only when they arise.

13+

14+The first relevant feature of Arvo is that it is a deterministic

15+system where input and output are defined as a series of events

16+and effects. The state of Arvo is simply a pure function of its event

17+log. None of the effects from an event are emitted until the

18+event is entered in the log and persisted, either to disk or

19+another trusted source of persistence, such as a Kafka cluster.

20+Consequently, Arvo is a single-level store: everything in its

21+state is persistent.

22+

23+In a more traditional OS, everything in RAM can be erased at any

24+time by power failure, and is always erased on reboot. Thus, a

25+primary purpose of a filesystem is to ensure files persist across

26+power failures and reboots. In Arvo, both power failures and

27+reboots are special cases of suspending computation, which is

28+done safely since our event log is already persistent. Therefore,

29+Clay is not needed in Arvo for persistence. Why, then, do we have a

30+filesystem? There are two answers to this question.

31+

32+First, Clay provides a filesystem tree, which is a convenient

33+user interface for some applications. Unix has the useful concept

34+of virtual filesystems, which are used for everything from direct

35+access to devices, to random number generators, to the /proc

36+tree. It is easy and intuitive to read from and write to a

37+filesystem tree.

38+

39+Second, Clay has a distributed revision-control system baked into

40+it. Traditional filesystems are not revision controlled, so

41+userspace software -- such as git -- is written on top of them to

42+do so. Clay natively provides the same functionality as modern

43+DVCSes, and more.

44+

45+Clay has two other unique properties that we'll cover later on:

46+it supports typed data and is referentially transparent.

47+

48+### Revision Control

49+

50+Every urbit has one or more `desk`s, which are independently

51+revision-controlled branches. Each `desk` contains its own `mark`

52+definitions, apps, and so forth.

53+

54+Traditionally, an urbit has at least a `%home` `desk` and `%kids` `desk`. The

55+`%home` `desk` has all the system software from the distribution, along with your

56+personal files. The `%home` `desk` is a fork of the `%kids` desk of whichever ship

57+you download [OTAs](/docs/glossary/ota-updates) from - typically your sponsor,

58+but theoretically may be any ship. You will also find references to a `%base`

59+`desk` - which is not a real `desk`, rather it just a hash associated to the

60+`desk` from which your `%home` `desk` was forked.

61+

62+A `desk` is a series of numbered commits, the most recent of which

63+represents the current state of the `desk`. A commit is composed of

64+(1) an absolute time when it was created, (2) a list of zero or

65+more parents, and (3) a map from paths to data.

66+

67+Most commits have exactly one parent, but the initial commit on a

68+`desk` may have zero parents, and merge commits have more than one

69+parent.

70+

71+The non-metadata is stored as a `map` of `path`s to data. It's

72+worth noting that no constraints are put on this `map`, so, for

73+example, both `/a/b` and `/a/b/c` could have data. This is impossible

74+in a traditional Unix filesystem since it means that `/a/b` is both

75+a file and a directory. Conventionally, the final element in the

76+path is its `mark` -- much like a filename extension in Unix. Thus,

77+`/doc/readme.md` in Unix is stored as `/doc/readme/md` in urbit.

78+

79+The data is not stored directly in the `map`; rather, a hash of the

80+data is stored, and we maintain a master blob store. Thus, if the

81+same data is referred to in multiple commits (as, for example,

82+when a file doesn't change between commits), only the hash is

83+duplicated.

84+

85+In the master blob store, we either store the data directly, or

86+else we store a diff against another blob. The hash is dependent

87+only on the data within and not on whether or not it's stored

88+directly, so we may on occasion rearrange the contents of the

89+blob store for performance reasons.

90+

91+Recall that a `desk` is a series of numbered commits. Not every

92+commit in a `desk` must be numbered. For example, if the base `desk`

93+has had 50 commits since home was forked from it, then a merge

94+from base to home will only add a single revision number to home,

95+although the full commit history will be accessible by traversing

96+the parentage of the individual commits.

97+

98+We do guarantee that the first commit is numbered 1, commits are

99+numbered consecutively after that (i.e. there are no "holes"),

100+the topmost commit is always numbered, and every numbered commit

101+is an ancestor of every later numbered commit.

102+

103+There are three ways to refer to particular commits in the

104+revision history. Firstly, one can use the revision number.

105+Secondly, one can use any absolute time between the one numbered

106+commit and the next (inclusive of the first, exclusive of the

107+second). Thirdly, every `desk` has a `map` of labels to revision

108+numbers. These labels may be used to refer to specific commits.

109+

110+Additionally, Clay is a global filesystem, so data on other urbits

111+is easily accessible the same way as data on our local urbit. In

112+general, the path to a particular revision of a `desk` is

113+`/~urbit-name/desk-name/revision`. Thus, to get `/try/readme/md`

114+from revision 5 of the home `desk` on `~sampel-sipnym`, we refer to

115+`/~sampel-sipnym/home/5/try/readme/md`. Clay's namespace is thus

116+global and referentially transparent.

117+

118+### A Typed Filesystem

119+

120+Since Clay is a general filesystem for storing data of arbitrary

121+types, in order to revision control correctly it needs to be

122+aware of types all the way through. Traditional revision control

123+does an excellent job of handling source code, so for source code

124+we act very similar to traditional revision control. The

125+challenge is to handle other data similarly well.

126+

127+For example, modern VCSs generally support "binary files", which

128+are files for which the standard textual diffing, patching, and

129+merging algorithms are not helpful. A "diff" of two binary files

130+is just a pair of the files, "patching" this diff is just

131+replacing the old file with the new one, and "merging"

132+non-identical diffs is always a conflict, which can't even be

133+helpfully annotated. Without knowing anything about the structure

134+of a blob of data, this is the best we can do.

135+

136+Often, though, "binary" files have some internal structure, and

137+it is possible to create diff, patch, and merge algorithms that

138+take advantage of this structure. An image may be the result of a

139+base image with some set of operations applied. With algorithms

140+aware of this set of operations, not only can revision control

141+software save space by not having to save every revision of the

142+image individually, these transformations can be made on parallel

143+branches and merged at will.

144+

145+Suppose Alice is tasked with touching up a picture, improving the

146+color balance, adjusting the contrast, and so forth, while Bob

147+has the job of cropping the picture to fit where it's needed and

148+adding textual overlay. Without type-aware revision control,

149+these changes must be made serially, requiring Alice and Bob to

150+explicitly coordinate their efforts. With type-aware revision

151+control, these operations may be performed in parallel, and then

152+the two changesets can be merged programmatically.

153+

154+Of course, even some kinds of text files may be better served by

155+diff, patch, and merge algorithms aware of the structure of the

156+files. Consider a file containing a pretty-printed JSON object.

157+Small changes in the JSON object may result in rather significant

158+changes in how the object is pretty-printed (for example, by

159+addding an indentation level, splitting a single line into

160+multiple lines).

161+

162+A text file wrapped at 80 columns also reacts suboptimally with

163+unadorned Hunt-McIlroy diffs. A single word inserted in a

164+paragraph may push the final word or two of the line onto the

165+next line, and the entire rest of the paragraph may be flagged as

166+a change. Two diffs consisting of a single added word to

167+different sentences may be flagged as a conflict. In general,

168+prose should be diffed by sentence, not by line.

169+

170+As far as we are aware, Clay is the first generalized,

171+type-aware revision control system. We'll go into the workings

172+of this system in some detail.

173+

174+### Marks

175+

176+Central to a typed filesystem is the idea of types. In Clay, we

177+call these `mark`s. A `mark` is a file that defines a type,

178+conversion routines to and from the `mark`, and diff, patch, and

179+merge routines.

180+

181+For example, a `%txt` mark may be a list of lines of text, and it

182+may include conversions to `%mime` to allow it to be serialized

183+and sent to a browser or to the Unix filesystem. It will also

184+include Hunt-McIlroy diff, patch, and merge algorithms.

185+

186+A `%json` `mark` would be defined as a JSON object in the code, and

187+it would have a parser to convert from `%txt` and a printer to

188+convert back to `%txt`. The diff, patch, and merge algorithms are

189+fairly straightforward for JSON, though they're very different

190+from the text ones.

191+

192+More formally, a `mark` is a core with three [arms](/docs/glossary/arm/): `+grab`,

193+`+grow`, and `+grad`. In `+grab` is a series of functions to

194+convert from other `mark`s to the given `mark`. In `+grow` is a

195+series of functions to convert from the given `mark` to other

196+`mark`s. In `+grad` is `+diff`, `+pact`, `+join`, and `+mash`, and

197+`+form`.

198+

199+The types are as follows, in an informal pseudocode:

200+

201+```

202+ ++ grab:

203+ ++ mime: <mime> -> <mark-type>

204+ ++ txt: <txt> -> <mark-type>

205+ ...

206+ ++ grow:

207+ ++ mime: <mark-type> -> <mime>

208+ ++ txt: <mark-type> -> <txt>

209+ ...

210+ ++ grad

211+ ++ form: <mark-type>

212+ ++ diff: (<mark-type>, <mark-type>) -> <diff-type>

213+ ++ pact: (<mark-type>, <diff-type>) -> <mark-type>

214+ ++ join: (<diff-type>, <diff-type>) -> <diff-type> or NULL

215+ ++ mash: (<diff-type>, <diff-type>) -> <diff-type>

216+```

217+

218+These types are basically what you would expect. Not every `mark`

219+has each of these functions defined -- all of them are optional

220+in the general case.

221+

222+In general, for a particular `mark`, the `+grab` and `+grow` entries

223+(if they exist) should be inverses of each other.

224+

225+In `+grad`, `+diff` takes two instances of a `mark` and produces a diff of them

226+whose `mark` is given by `+form`. `+pact` takes an instance of a `mark` and

227+patches it with the given diff. `+join` takes two diffs and attempts to merge

228+them into a single diff. If there are conflicts, it produces null. `+mash` takes

229+two diffs and forces a merge, annotating any conflicts.

230+

231+In general, if `+diff` called with A and B produces diff D, then

232+`+pact` called with A and D should produce B. Also, if `+join`

233+of two diffs does not produce null, then `+mash` of the same

234+diffs should produce the same result.

235+

236+Alternately, instead of `+diff`, `+pact`, `+join`, and

237+`+mash`, a `mark` can provide the same functionality by defining

238+`+grad` to be the name of another `mark` to which we wish to

239+delegate the revision control responsibilities. Then, before

240+running any of those functions, Clay will convert to the other

241+`mark`, and convert back afterward. For example, the `%hoon` `mark`

242+is revision-controlled in the same way as `%txt`, so its `+grad`

243+is simply `++ grad %txt`. Of course, `+txt` must be defined in

244+`+grow` and `+grab` as well.

245+

246+Every file in Clay has a `mark`, and that `mark` must have a

247+fully-functioning `+grad`. `Mark`s are used for more than just

248+Clay, and other `mark`s don't need a `+grad`, but if a piece of

249+data is to be saved to Clay, we must know how to revision-control

250+it.

251+

252+Additionally, if a file is to be synced out to Unix, then it must

253+have conversion routines to and from the `%mime` `mark`.

254+

content/docs/arvo/clay/clay.mdnew file+58

@@ -0,0 +1,58 @@

1++++

2+title = "Overview"

3+weight = 1

4+template = "doc.html"

5+aliases = ["/docs/learn/arvo/clay/"]

6++++

7+

8+

9+Our filesystem.

10+

11+`%clay` is version-controlled, referentially-transparent, and global.

12+While this filesystem is stored in `%clay`, it is mirrored to Unix for

13+convenience. Unix tells `%clay`s whenever a file changes in the Unix

14+copy of the filesystem so that the change may be applied. `%clay` tells

15+unix whenever an app or vane changes the filesystem so that the change

16+can be effected in Unix. Apps and vanes may use `%clay` to write to the

17+filesystem, query it, and subscribe to changes in it. Ford and gall use

18+`%clay` to serve up apps and web pages.

19+

20+`%clay` includes three components. First is the filesystem/version

21+control algorithms, which are mostly defined in `++ze` and `++zu` in

22+zuse. Second is the write, query, and subscription logic. Finally, there

23+is the logic for communicating requests to, and receiving requests from,

24+foreign ships.

25+

26+### User documentation

27+

28+[Filesystem](/using/os/filesystem)

29+

30+How to interact with the Clay filesystem via Dojo. This includes basics such as

31+mounting to Unix, changing directory, merging, and listing files.

32+

33+### Developer Documentation

34+

35+[Architecture](/docs/arvo/clay/architecture)

36+

37+A conceptual overview of how Clay was designed.

38+

39+[Using Clay](/docs/arvo/clay/using)

40+

41+A quick overview of how the most common tasks involving Clay are performed:

42+reading and subscribing, syncing to Unix, and merging.

43+

44+[Data Types](/docs/arvo/clay/data-types)

45+

46+Explanations of the many data types found throughout Clay.

47+

48+[Scry Reference](/docs/arvo/clay/scry)

49+

50+Reference for Clay's various scry endpoints.

51+

52+[API Reference](/docs/arvo/clay/tasks)

53+

54+Details of the various `task`s you can use to interact with Clay.

55+

56+[Examples](/docs/arvo/clay/examples)

57+

58+Example usage of the various Clay `task`s.

content/docs/arvo/clay/data-types.mdnew file+688

@@ -0,0 +1,688 @@

1++++

2+title = "Data Types"

3+weight = 4

4+template = "doc.html"

5++++

6+

7+This section will be reference documentation for the data types used by our

8+filesystem.

9+

10+As a general guide, we recommend reading and attempting to understand the data

11+structures used in any Hoon code before you try to read the code itself.

12+Although complete understanding of the data structures is impossible without

13+seeing them used in the code, an 80% understanding greatly clarifies the code.

14+As another general guide, when reading Hoon, it rarely pays off to understand

15+every line of code when it appears. Try to get the gist of it, and then move on.

16+The next time you come back to it, it'll likely make a lot more sense.

17+

18+### Data Models

19+

20+As you're reading through this section, remember you can always come

21+back to this when you run into these types later on. You're not going to

22+remember everything the first time through, but it is worth reading, or

23+at least skimming, this so that you get a rough idea of how our state is

24+organized.

25+

26+The types that are certainly worth reading are `++raft`, `++room`,

27+`++dome:clay`, `++ankh:clay`, `++rung:clay`, `++rang:clay`, `++blob:clay`,

28+`++yaki:clay`, and `++nori:clay` (possibly in that order). All in all, though,

29+this section isn't too long, so many readers may wish to quickly read through

30+all of it. If you get bored, though, just skip to the next section. You can

31+always come back when you need to.

32+

33+### `$raft`, formal state

34+

35+```hoon

36++$ raft :: filesystem

37+ $: rom=room :: domestic

38+ hoy=(map ship rung) :: foreign

39+ ran=rang :: hashes

40+ mon=(map term beam) :: mount points

41+ hez=(unit duct) :: sync duct

42+ cez=(map @ta crew) :: permission groups

43+ pud=(unit [=desk =yoki]) :: pending update

44+ == ::

45+```

46+

47+This is the state of the vane. Anything that must be remembered between

48+calls to Clay is stored in this state.

49+

50+`ran` is the store of all commits and deltas, keyed by hash. The is

51+where all the "real" data we know is stored; the rest is "just

52+bookkeeping".

53+

54+`rom` is the state for all local desks. It consists of a `duct` to

55+[Dill](/docs/arvo/dill/dill) and a collection of `desk`s.

56+

57+`hoy` is the state for all foreign desks.

58+

59+`ran` is the global, hash-addressed object store. It has maps of commit hashes

60+to commits and content hashes to content.

61+

62+`mon` is a collection of Unix mount points. `term` is the mount point (relative

63+to th pier) and `beam` is a domestic Clay directory.

64+

65+`hez` is the duct used to sync with Unix.

66+

67+`cez` is a collection of named permission groups.

68+

69+`pud` is an update that's waiting on a kernel upgrade.

70+

71+

72+#### `$room`, filesystem per domestic ship

73+

74+```hoon

75++$ room :: fs per ship

76+ $: hun=duct :: terminal duct

77+ dos=(map desk dojo) :: native desk

78+ == ::

79+```

80+

81+This is the representation of the filesystem of a ship on our pier.

82+

83+`hun` is the duct we use to send messages to [Dill](/docs/arvo/dill/dill) to

84+display notifications of filesystem changes. Only `%note` `%gift`s should be

85+produced along this `duct`. This is set by the `%init` `move`.

86+

87+`dos` is a well-known operating system released in 1981. It is also the

88+set of `desk`s on this ship, mapped to their `desk` state.

89+

90+#### `$desk`, filesystem branch

91+

92+```hoon

93++$ desk @tas

94+```

95+

96+This is the name of a branch of the filesystem. The default `desk`s are `%home`

97+and `%kids`. More may be created by simply referencing them. `desk`s have

98+independent histories and states, and they may be

99+[merged](/docs/arvo/clay/using#merging) into each other.

100+

101+### `$dojo`, domestic desk state

102+

103+```hoon

104++$ dojo

105+ $: qyx=cult :: subscribers

106+ dom=dome :: desk state

107+ per=regs :: read perms per path

108+ pew=regs :: write perms per path

109+ ==

110+```

111+

112+This is the all the data that is specific to a particular `desk` on a domestic

113+ship. `qyx` is the set of subscribers to this `desk`, and `dom` is the data in

114+the `desk`. `regs` are `(map path rule)`, and so `per` is a `map` of read

115+permissions by `path` and `pew` is a `map` of write permissions by `path`.

116+

117+#### `$cult`, subscriptions

118+

119+```hoon

120++$ cult (jug wove duct)

121+```

122+

123+`cult`s keep track of subscribers. `wove`s are associated to requests, and each

124+`wove` is mapped to a set of `duct`s associated to subscribers who should be

125+notified when the request is filled/updated.

126+

127+#### `$rave:clay`, general subscription request

128+

129+```hoon

130+ +$ rave :: general request

131+ $% [%sing =mood] :: single request

132+ [%next =mood] :: await next version

133+ [%mult =mool] :: next version of any

134+ [%many track=? =moat] :: track range

135+ == ::

136+```

137+

138+This represents a subscription request for a `desk`.

139+

140+A `%sing` request asks for data at single revision.

141+

142+A `%next` request asks to be notified the next time there’s a change to the

143+specified file.

144+

145+A `%mult` request asks to be notified the next time there's a change to a

146+specified set of files.

147+

148+A `%many` request asks to be notified on every change in a `desk` for a range of changes (including into the future).

149+

150+### `$rove`, stored general subscription request

151+

152+```hoon

153+ +$ rove :: stored request

154+ $% [%sing =mood] :: single request

155+ [%next =mood aeon=(unit aeon) =cach] :: next version of one

156+ $: %mult :: next version of any

157+ =mool :: original request

158+ aeon=(unit aeon) :: checking for change

159+ old-cach=(map [=care =path] cach) :: old version

160+ new-cach=(map [=care =path] cach) :: new version

161+ == ::

162+ [%many track=? =moat lobes=(map path lobe)] :: change range

163+ == ::

164+```

165+

166+Like a `rave` but with provisions to store current versions for `%next` and `%many`.

167+Generally used when we store a request in our state somewhere. This is so that

168+we can determine whether new versions actually affect the path we're subscribed to.

169+

170+

171+#### `$mood:clay`, single subscription request

172+

173+```hoon

174+ +$ mood [=care =case =path] :: request in desk

175+```

176+

177+This represents a request for data related to the state of the `desk` at a

178+particular commit, specfied by `case`. `care` specifies what kind of information

179+is desired, and `path` specifies the path we are requesting.

180+

181+#### `$moat:clay`, range subscription request

182+

183+```hoon

184+ +$ moat [from=case to=case =path] :: change range

185+```

186+

187+This represents a request for all changes between `from` and `to` on `path`. You

188+will be notified when a change is made to the node referenced by the `path` or to

189+any of its children.

190+

191+### `$care:clay`, Clay submode

192+

193+```hoon

194+ +$ care ?(%a %b %c %d %e %f %p %r %s %t %u %v %w %x %y %z) :: clay submode

195+```

196+

197+

198+This specifies what type of information is requested in a subscription

199+or a scry.

200+

201+`%a` build a Hoon file at a `path`.

202+

203+`%b` build a dynamically typed `mark` by name (a `$dais` mark-interface core).

204+

205+`%c` build a dynamically typed `mark` conversion gate (a `$tube`) by "from" and

206+"to" `mark` names.

207+

208+`%d` returns a `(set desk)` of the `desk`s that exist on your ship.

209+

210+`%e` builds a statically typed `mark` by name (a `$nave` mark-interface core).

211+

212+`%f` builds a statically typed mark converstion gate.

213+

214+`%p` produces the permissions for a directory, returned as a `[dict:clay dict:clay]`.

215+

216+`%r` requests the file in the same fashion as `%x`, but wraps the result in a `vase`.

217+

218+`%s` has miscellaneous debug endpoints.

219+

220+`%t` produces a `(list path)` of descendent `path`s for a directory within a `yaki`.

221+

222+`%u` produces a `?` depending on whether or not the specified file exists. It

223+does not check any of its children.

224+

225+`%v` requests the entire `dome` for a specified `desk` at a particular `aeon`.

226+When used on a foreign `desk`, this get us up-to-date to the requested version.

227+

228+`%w` requests the revision number and date of the specified path, returned as a `cass:clay`.

229+

230+`%x` requests the file at a specified path at the specified commit, returned as

231+an `@`. If there is no node at that path or if the node has no contents (that

232+is, if `fil:ankh` is null), then this crashes.

233+

234+`%y` requests an `arch` of the specfied commit at the specified path. It will

235+return the bunt of an `arch` if the file or directory is not found.

236+

237+`%z` requests a recursive hash of a node and all its children, returned as a `@uxI`.

238+

239+#### `$ankh`, filesystem node

240+

241+```hoon

242++$ ankh :: expanded node

243+ $~ [~ ~]

244+ $: fil=(unit [p=lobe q=cage]) :: file

245+ dir=(map @ta ankh) :: folders

246+ == ::

247+```

248+

249+This is a recursive filesystem node type that can describe a whole tree of

250+folders and files, with subtrees organized by path prefix. In Earth filesystems,

251+a node is a file xor a directory. On Mars, we're inclusive, so a node is a file

252+ior a directory.

253+

254+`fil` is the contents of this file, if any. `p.fil` is a hash of the

255+contents while `q.fil` is the data itself.

256+

257+`dir` is the set of children of this node. In the case of a pure file,

258+this is empty. The keys are the names of the children and the values

259+are, recursively, the nodes themselves.

260+

261+

262+### `$arch`, shallow filesystem node

263+

264+```hoon

265++$ arch (axil @uvI)

266+++ axil

267+ |$ [item]

268+ [fil=(unit item) dir=(map @ta ~)]

269+```

270+

271+An `arch` is a lightweight version of an `ankh` that only contains the hash

272+of the associated file and a `map` of child directories, but not the children of

273+those directories.

274+

275+The child directories are given by a `map` to null rather than a `set` so that the

276+ordering of the `map` will be the same as it is for an `axal`, allowing

277+efficient conversion for when the heavier node is needed.

278+```hoon

279+++ axal

280+ |$ [item]

281+ [fil=(unit item) dir=(map @ta $)]

282+```

283+

284+#### `$case`, specifying a commit

285+

286+```hoon

287++$ case

288+ $% :: %da: date

289+ :: %tas: label

290+ :: %ud: sequence

291+ ::

292+ [%da p=@da]

293+ [%tas p=@tas]

294+ [%ud p=@ud]

295+ ==

296+```

297+

298+A commit can be referred to in three ways: `%da` refers to the commit

299+that was at the head on date `p`, `%tas` refers to the commit labeled

300+`p`, and `%ud` refers to the commit numbered `p`. Note that since these

301+all can be reduced down to a `%ud`, only numbered commits may be

302+referenced with a `++case:clay`.

303+

304+#### `$dome`, desk data

305+

306+```hoon

307++$ dome

308+ $: ank=ankh :: state

309+ let=aeon :: top id

310+ hit=(map aeon tako) :: versions by id

311+ lab=(map @tas aeon) :: labels

312+ mim=(map path mime) :: mime cache

313+ fod=ford-cache :: ford cache

314+ fer=(unit reef-cache) :: reef cache

315+ == ::

316+```

317+

318+A `dome` is the state of a `desk` and associated data.

319+

320+`ank` is the current state of the desk. Thus, it is the state of the

321+filesystem at revison `let`. The head of a `desk` is always a numbered

322+commit.

323+

324+`let` is the number of the most recently numbered commit. This is also

325+the total number of numbered commits.

326+

327+`hit` is a map of numerical ids to commit hashes. These hashes are mapped into

328+their associated commits in `hut.rang` in the `raft` of Clay. In general, the

329+keys of this map are exactly the numbers from 1 to `let`, with no gaps. Of

330+course, when there are no numbered commits, `let` is 0, so `hit` is null.

331+Additionally, each of the commits is an ancestor of every commit numbered

332+greater than this one. Thus, each is a descendant of every commit numbered less

333+than this one. Since it is true that the date in each commit (`t:yaki`) is no

334+earlier than that of each of its parents, the numbered commits are totally

335+ordered in the same way by both pedigree and date. Of course, not every commit

336+is numbered. If that sounds too complicated to you, don't worry about it. It

337+basically behaves exactly as you would expect.

338+

339+`lab` is a map of textual labels to numbered commits. Note that labels

340+can only be applied to numbered commits. Labels must be unique across a

341+desk.

342+

343+`mim` is a cache of the content in the directories that are mounted to Unix.

344+

345+`fod` is the Ford cache, which keeps a cache of the results of builds performed

346+at this `desk`'s current revision, including a full transitive closure of

347+dependencies for each completed build.

348+

349+`fer` is the system file cache, which consists of `vase`s for `hoon.hoon`,

350+`arvo.hoon`, `lull.hoon`, and `zuse.hoon`.

351+

352+#### `++rung`, filesystem per neighbor ship

353+

354+```hoon

355++$ rung

356+ $: rus=(map desk rede) :: neighbor desks

357+ ==

358+```

359+

360+This is the filesystem of a neighbor ship. The keys to this `map` are all

361+the `desk`s we know about on their ship.

362+

363+#### `++rede`, generic desk state

364+

365+```hoon

366+ ++ rede :: universal project

367+ $: lim=@da :: complete to

368+ qyx=cult :: subscribers

369+ ref=(unit rind) :: outgoing requests

370+ dom=dome :: revision state

371+ == ::

372++$ rede :: universal project

373+ $: lim=@da :: complete to

374+ ref=(unit rind) :: outgoing requests

375+ qyx=cult :: subscribers

376+ dom=dome :: revision state

377+ per=regs :: read perms per path

378+ pew=regs :: write perms per path

379+ == ::

380+```

381+

382+This is our knowledge of the state of a desk, either foreign or

383+domestic.

384+

385+`lim` is the most recent `@da` for which we're confident we have all the

386+information for. For local `desk`s, this is always `now`. For foriegn `desk`s,

387+this is the last time we got a full update from the foreign ship.

388+

389+`ref` is the request manager for the desk. For domestic `desk`s, this is

390+null since we handle requests ourselves. For foreign `desk`s, this keeps track

391+of all pending foriegn requests plus a cache of the responses to previous requests.

392+

393+`qyx` is the `set` of subscriptions to this desk, with listening `duct`s. These

394+subscriptions exist only until they've been filled. For domestic `desk`s, this

395+is simply `qyx:dojo` - all subscribers to the `desk`. For foreign `desk`s this

396+is all the subscribers from our ship to the foreign `desk`.

397+

398+`dom` is the data in the `desk`.

399+

400+`regs` are `(map path rule)`, and so `per` is a `map` of read permissions by

401+`path` and `pew` is a `map` of write permissions by `path`.

402+

403+

404+#### `$rind`, foreign request manager

405+

406+```hoon

407++$ rind :: request manager

408+ $: nix=@ud :: request index

409+ bom=(map @ud update-state) :: outstanding

410+ fod=(map duct @ud) :: current requests

411+ haw=(map mood (unit cage)) :: simple cache

412+ == ::

413+```

414+

415+This is the request manager for a foreign `desk`. When we send a request to a

416+foreign ship, we keep track of it in here.

417+

418+`nix` is one more than the index of the most recent request. Thus, it is the

419+next available request number.

420+

421+`bom` is the set of outstanding requests. The keys of this `map` are some subset

422+of the numbers between 0 and one less than `nix`. The members of the `map` are

423+exactly those requests that have not yet been fully satisfied.

424+

425+`fod` is the same set as `bom`, but from a different perspective. In particular,

426+the values of `fod` are the same as the keys of `bom`, and the `duct` of the

427+values of `bom` are the same as the keys of `fod`. Thus, we can map `duct`s to

428+their associated request number and `update-state`, and we can map request

429+numbers to their associated `duct`.

430+

431+`haw` is a map from `%sing` requests to their values. This acts as a cache for

432+requests that have already been filled.

433+

434+#### `$update-state`, status of outstanding foreign request

435+

436+```hoon

437++$ update-state

438+ $: =duct

439+ =rave

440+ have=(map lobe blob)

441+ need=(list lobe)

442+ nako=(qeu (unit nako))

443+ busy=_|

444+ ==

445+```

446+

447+An `update-state` is used to represent the status of an outstanding request to a

448+foreign `desk`.

449+

450+`duct` and `rave` are the `duct` along which the request was made and the

451+request itself.

452+

453+`have` is a map of hashes thus far acquired in the request to the data

454+associated with those hashes.

455+

456+`need` is a list of hashes yet to be acquired.

457+

458+`nako` is a queue of data yet to be validated.

459+

460+`busy` tracks whether or not the request is currently being fulfilled.

461+

462+#### `$rang:clay`, data repository

463+

464+```hoon

465+ +$ rang :: repository

466+ $: hut=(map tako yaki) :: changes

467+ lat=(map lobe blob) :: data

468+ == ::

469+```

470+

471+This is a data repository keyed by hash. Thus, this is where the "real" data

472+is stored, but it is only meaningful if we know the hash of what we're

473+looking for.

474+

475+`hut` is a `map` from commit hashes (`tako`s) to commits (`yaki`s). We often get

476+the hashes from `hit:dome`, which keys them by numerical id. Not every commit

477+has an numerical id.

478+

479+`lat` is a `map` from content hashes (`lobe`s) to the actual content (`blob`s).

480+We often get the hashes from a `yaki`, which references this `map` to get the

481+data. There is no `blob` in `yaki:clay`. They are only accessible through

482+`lat`.

483+

484+#### `$tako:clay`, commit reference

485+

486+```hoon

487+ +$ tako @ :: yaki ref

488+```

489+

490+This is a hash of a `yaki:clay`, a commit. These are most notably used as the

491+keys in `hut:rang:clay`, where they are associated with the actual `yaki:clay`,

492+and as the values in `hit:dome:clay`, where sequential numerical ids are

493+associated with these.

494+

495+#### `$yaki:clay`, commit

496+

497+```hoon

498+ +$ yaki :: commit

499+ $: p=(list tako) :: parents

500+ q=(map path lobe) :: namespace

501+ r=tako :: self-reference

502+ t=@da :: date

503+ == ::

504+```

505+

506+This is a single commit.

507+

508+`p` is a `list` of the hashes of the parents of this commit. In most

509+cases, this will be a single commit, but in a merge there may be more

510+parents. In theory, there may be an arbitrary number of parents, but in

511+practice merges have exactly two parents. This may change in the future.

512+For commit 1, there is no parent.

513+

514+`q` is a `map` of the `path`s on a desk to the content hashes at that location.

515+If you understand what a `lobe:clay` and a `blob:clay` is, then the type

516+signature here tells the whole story.

517+

518+`r` is the hash associated with this commit.

519+

520+`t` is the date at which this commit was made.

521+

522+#### `$lobe:clay`, data reference

523+

524+```hoon

525+ +$ lobe @uvI :: blob ref

526+```

527+

528+This is a hash of a `blob:clay`. These are most notably used in `lat:rang:clay`,

529+where they are associated with the actual `blob:clay`, and as the values in

530+`q:yaki:clay`, where `path`s are associated with their content hashes in a commit.

531+

532+#### `$blob:clay`, data

533+

534+```hoon

535+ +$ blob :: fs blob

536+ $% [%delta p=lobe q=[p=mark q=lobe] r=page] :: delta on q

537+ [%direct p=lobe q=page] :: immediate

538+```

539+

540+This is a node of data. In both cases, `p` is the hash of the blob.

541+

542+`%delta` is the case where we define the data by a delta on other data. In

543+practice, the other data is always the previous commit, but nothing depends on

544+this. `p.q` is the `mark` of the parent blob, `q.q` is the hash of the parent

545+blob, and `r` is the delta.

546+

547+`%direct` is the case where we simply have the data directly. `q` is the data.

548+These almost always come from the creation of a file.

549+

550+

551+#### `+urge`, list change

552+

553+```hoon

554+ ++ urge |*(a=mold (list (unce a))) :: list change

555+```

556+

557+This is a parametrized type for list changes. For example, `(urge @t)`

558+is a list change for lines of text.

559+

560+#### `+unce`, change part of a list.

561+

562+```hoon

563+ ++ unce :: change part

564+ |* a=mold ::

565+ $% [%& p=@ud] :: skip[copy]

566+ [%| p=(list a) q=(list a)] :: p -> q[chunk]

567+ == ::

568+```

569+

570+This is a single change in a list of elements of type `a`. For example,

571+`(unce @t)` is a single change in lines of text.

572+

573+`%&` means the next `p` lines are unchanged.

574+

575+`%|` means the lines `p` have changed to `q`.

576+

577+#### `$nori:clay`, repository action

578+

579+```hoon

580+ +$ nori :: repository action

581+ $% [%& p=soba] :: delta

582+ [%| p=@tas] :: label

583+ == ::

584+```

585+

586+This describes a change that we are asking Clay to make to the `desk`.

587+There are two kinds of changes that may be made: we can modify files or

588+we can apply a label to a commit.

589+

590+In the `|` case, we will simply label the current commit with the given

591+label. In the `&` case, we will apply the given changes.

592+

593+#### `$soba:clay`, delta

594+

595+```hoon

596+ +$ soba (list [p=path q=miso]) :: delta

597+```

598+

599+This describes a `list` of changes to make to a `desk`. The `path`s are `path`s

600+to files to be changed, and the corresponding `miso` value is a description of

601+the change itself.

602+

603+#### `$miso:clay`, ankh delta

604+

605+```hoon

606+ +$ miso :: ankh delta

607+ $% [%del ~] :: delete

608+ [%ins p=cage] :: insert

609+ [%dif p=cage] :: mutate from diff

610+ [%mut p=cage] :: mutate from raw

611+ == ::

612+```

613+

614+There are four kinds of changes that may be made to a node in a `desk`.

615+

616+`%del` deletes the node.

617+

618+`%ins` inserts a file given by `p`.

619+

620+`%dif` is currently unimplemented. This may seem strange, so we remark that

621+diffs for individual files are implemented using `+diff` and `+pact` in `mark`s.

622+So for an `ankh`, which may include both files and directories, `%dif` being

623+unimplemented really just means that we do not yet have a formal concept of

624+changes in directory structure.

625+

626+`%mut` mutates the file using raw data given by `p`.

627+

628+#### `$riff:clay`, request/desist

629+

630+```hoon

631+ +$ riff [p=desk q=(unit rave)] :: request+desist

632+```

633+

634+This represents a request for data about a particular `desk`. If `q`

635+contains a `rave`, then this opens a subscription to the `desk` for that

636+data. If `q` is null, then this tells Clay to cancel the subscription

637+along this duct.

638+

639+#### `$riot:clay`, response

640+

641+```hoon

642+ +$ riot (unit rant) :: response+complete

643+```

644+

645+A `riot` is a response to a subscription. If null, the subscription has

646+been completed, and no more responses will be sent. Otherwise, the

647+`rant` is the produced data.

648+

649+#### `$rant:clay`, response data

650+

651+```hoon

652+ +$ rant :: response to request

653+ $: p=[p=care q=case r=desk] :: clade release book

654+ q=path :: spur

655+ r=cage :: data

656+ == ::

657+```

658+

659+This is the data associated to the response to a request. `p.p` specifies

660+the type of data that was requested (and is produced). `q.p` gives the

661+specific version reported (since a range of versions may be requested in

662+a subscription). `r.p` is the `desk`. `q` is the path to the filesystem

663+node. `r` is the data itself (in the format specified by `p.p`).

664+

665+### `$nako`, subscription response data

666+

667+```hoon

668++$ nako :: subscription state

669+ $: gar=(map aeon tako) :: new ids

670+ let=aeon :: next id

671+ lar=(set yaki) :: new commits

672+ bar=(set plop) :: new content

673+ == ::

674+```

675+

676+This is the data that is produced by a request for a range of revisions

677+of a `desk`. This allows us to easily keep track of a remote repository --

678+all the new information we need is contained in the `nako`.

679+

680+`gar` is a map of the revisions in the range to the hash of the commit

681+at that revision. These hashes can be used with `hut:rang:clay` to find the

682+commit itself.

683+

684+`let` is either the last revision number in the range or the most recent

685+revision number, whichever is smaller.

686+

687+`lar` is the set of new commits, and `bar` is the set of new content.

688+

content/docs/arvo/clay/examples.mdnew file+824

This diff is too big to show here.

content/docs/arvo/clay/scry.mdnew file+425

This diff is too big to show here.

content/docs/arvo/clay/tasks.mdnew file+555

This diff is too big to show here.

content/docs/arvo/clay/using.mdnew file+217

This diff is too big to show here.

content/docs/arvo/concepts/_index.mdnew file+13

This diff is too big to show here.

content/docs/arvo/concepts/subscriptions.mdnew file+162

This diff is too big to show here.

content/docs/arvo/dill/_index.mdnew file+7

This diff is too big to show here.

content/docs/arvo/dill/dill-api.mdnew file+366

This diff is too big to show here.

content/docs/arvo/dill/dill.mdnew file+24

This diff is too big to show here.

content/docs/arvo/eyre/_index.mdnew file+16

This diff is too big to show here.

content/docs/arvo/eyre/eyre.mdnew file+721

This diff is too big to show here.

content/docs/arvo/eyre/using-eyre.mdnew file+230

This diff is too big to show here.

content/docs/arvo/ford/_index.mdnew file+7

This diff is too big to show here.

content/docs/arvo/ford/ford.mdnew file+223

This diff is too big to show here.

content/docs/arvo/gall/_index.mdnew file+7

This diff is too big to show here.

content/docs/arvo/gall/overview.mdnew file+11

This diff is too big to show here.

content/docs/arvo/iris/_index.mdnew file+7

This diff is too big to show here.

content/docs/arvo/iris/iris-api.mdnew file+191

This diff is too big to show here.

content/docs/arvo/jael/_index.mdnew file+7

This diff is too big to show here.

content/docs/arvo/jael/jael-api.mdnew file+393

This diff is too big to show here.

content/docs/arvo/overview.mdnew file+577

This diff is too big to show here.

content/docs/arvo/tutorials/_index.mdnew file+9

This diff is too big to show here.

content/docs/arvo/tutorials/move-trace.mdnew file+378

This diff is too big to show here.

content/docs/azimuth/_index.mdnew file+22

This diff is too big to show here.

content/docs/azimuth/advanced-azimuth-tools.mdnew file+68

This diff is too big to show here.

content/docs/azimuth/azimuth.mdnew file+150

This diff is too big to show here.

content/docs/azimuth/life-and-rift.mdnew file+58

This diff is too big to show here.

content/docs/development/_index.mdnew file+33

This diff is too big to show here.

content/docs/development/develop.mdnew file+115

This diff is too big to show here.

content/docs/development/environment.mdnew file+62

This diff is too big to show here.

content/docs/development/grants.mdnew file+84

This diff is too big to show here.

content/docs/development/precepts.mdnew file+336

This diff is too big to show here.

content/docs/development/project-repositories.mdnew file+49

This diff is too big to show here.

content/docs/glossary/_index.mdnew file+10

This diff is too big to show here.

content/docs/glossary/ames.mdnew file+19

This diff is too big to show here.

content/docs/glossary/aqua.mdnew file+16

This diff is too big to show here.

content/docs/glossary/arm.mdnew file+14

This diff is too big to show here.

content/docs/glossary/arvo.mdnew file+40

This diff is too big to show here.

content/docs/glossary/atom.mdnew file+20

This diff is too big to show here.

content/docs/glossary/azimuth.mdnew file+18

This diff is too big to show here.

content/docs/glossary/battery.mdnew file+14

This diff is too big to show here.

content/docs/glossary/behn.mdnew file+14

This diff is too big to show here.

content/docs/glossary/breach.mdnew file+28

This diff is too big to show here.

content/docs/glossary/bridge.mdnew file+32

This diff is too big to show here.

content/docs/glossary/censure.mdnew file+14

This diff is too big to show here.

content/docs/glossary/ceremony.mdnew file+8

This diff is too big to show here.

content/docs/glossary/chat.mdnew file+32

This diff is too big to show here.

content/docs/glossary/claims.mdnew file+21

This diff is too big to show here.

content/docs/glossary/clay.mdnew file+18

This diff is too big to show here.

content/docs/glossary/comet.mdnew file+32

This diff is too big to show here.

content/docs/glossary/core.mdnew file+14

This diff is too big to show here.

content/docs/glossary/delegated-sending.mdnew file+9

This diff is too big to show here.

content/docs/glossary/desk.mdnew file+15

This diff is too big to show here.

content/docs/glossary/dill.mdnew file+22

This diff is too big to show here.

content/docs/glossary/docvote.mdnew file+9

This diff is too big to show here.

content/docs/glossary/dojo.mdnew file+14

This diff is too big to show here.

content/docs/glossary/door.mdnew file+14

This diff is too big to show here.

content/docs/glossary/ecliptic.mdnew file+12

This diff is too big to show here.

content/docs/glossary/eventlog.mdnew file+23

This diff is too big to show here.

content/docs/glossary/eyre.mdnew file+17

This diff is too big to show here.

content/docs/glossary/ford.mdnew file+17

This diff is too big to show here.

content/docs/glossary/galaxy.mdnew file+15

This diff is too big to show here.

content/docs/glossary/gall.mdnew file+17

This diff is too big to show here.

content/docs/glossary/gate.mdnew file+14

This diff is too big to show here.

content/docs/glossary/hdwallet.mdnew file+17

This diff is too big to show here.

content/docs/glossary/hoon.mdnew file+15

This diff is too big to show here.

content/docs/glossary/invite-tree.mdnew file+9

This diff is too big to show here.

content/docs/glossary/iris.mdnew file+11

This diff is too big to show here.

content/docs/glossary/jael.mdnew file+8

This diff is too big to show here.

content/docs/glossary/jaque.mdnew file+15

This diff is too big to show here.

content/docs/glossary/keyfile.mdnew file+15

This diff is too big to show here.

content/docs/glossary/landscape.mdnew file+11

This diff is too big to show here.

content/docs/glossary/mark.mdnew file+17

This diff is too big to show here.

content/docs/glossary/moon.mdnew file+34

This diff is too big to show here.

content/docs/glossary/nock.mdnew file+17

This diff is too big to show here.

content/docs/glossary/noun.mdnew file+15

This diff is too big to show here.

content/docs/glossary/ota-updates.mdnew file+9

This diff is too big to show here.

content/docs/glossary/payload.mdnew file+14

This diff is too big to show here.

content/docs/glossary/ph.mdnew file+9

This diff is too big to show here.

content/docs/glossary/pier.mdnew file+18

This diff is too big to show here.

content/docs/glossary/pill.mdnew file+14

This diff is too big to show here.

content/docs/glossary/planet.mdnew file+15

This diff is too big to show here.

content/docs/glossary/proxies.mdnew file+29

This diff is too big to show here.

content/docs/glossary/replay.mdnew file+13

This diff is too big to show here.

content/docs/glossary/sailudon.mdnew file+13

This diff is too big to show here.

content/docs/glossary/senate.mdnew file+14

This diff is too big to show here.

content/docs/glossary/ship.mdnew file+26

This diff is too big to show here.

content/docs/glossary/shiparvonetwork.mdnew file+9

This diff is too big to show here.

content/docs/glossary/star.mdnew file+17

This diff is too big to show here.

content/docs/glossary/sync.mdnew file+16

This diff is too big to show here.

content/docs/glossary/trap.mdnew file+14

This diff is too big to show here.

content/docs/glossary/upgrade.mdnew file+13

This diff is too big to show here.

content/docs/glossary/vane.mdnew file+24

This diff is too big to show here.

content/docs/glossary/vere.mdnew file+18

This diff is too big to show here.

content/docs/glossary/voting.mdnew file+27

This diff is too big to show here.

content/docs/glossary/wallet-generator.mdnew file+11

This diff is too big to show here.

content/docs/hoon/_index.mdnew file+27

This diff is too big to show here.

content/docs/hoon/guides/_index.mdnew file+13

This diff is too big to show here.

content/docs/hoon/guides/aqua.mdnew file+80

This diff is too big to show here.

content/docs/hoon/guides/cli-tutorial.mdnew file+417

This diff is too big to show here.

content/docs/hoon/guides/parsing.mdnew file+650

This diff is too big to show here.

content/docs/hoon/hoon-school/_index.mdnew file+42

This diff is too big to show here.

content/docs/hoon/hoon-school/ackermann.mdnew file+29

This diff is too big to show here.

content/docs/hoon/hoon-school/arms-and-cores.mdnew file+652

This diff is too big to show here.

content/docs/hoon/hoon-school/atoms-auras-and-simple-cell-types.mdnew file+779

This diff is too big to show here.

content/docs/hoon/hoon-school/bank-account.mdnew file+80

This diff is too big to show here.

content/docs/hoon/hoon-school/behn.mdnew file+110

This diff is too big to show here.

content/docs/hoon/hoon-school/caesar.mdnew file+394

This diff is too big to show here.

content/docs/hoon/hoon-school/conditionals.mdnew file+105

This diff is too big to show here.

content/docs/hoon/hoon-school/doors.mdnew file+516

This diff is too big to show here.

content/docs/hoon/hoon-school/egg-timer.mdnew file+159

This diff is too big to show here.

content/docs/hoon/hoon-school/fibonacci.mdnew file+61

This diff is too big to show here.

content/docs/hoon/hoon-school/gall.mdnew file+129

This diff is too big to show here.

content/docs/hoon/hoon-school/gates.mdnew file+272

This diff is too big to show here.

content/docs/hoon/hoon-school/generators.mdnew file+461

This diff is too big to show here.

content/docs/hoon/hoon-school/hoon-syntax.mdnew file+356

This diff is too big to show here.

content/docs/hoon/hoon-school/iron-polymorphism.mdnew file+88

This diff is too big to show here.

content/docs/hoon/hoon-school/lead-polymorphism.mdnew file+155

This diff is too big to show here.

content/docs/hoon/hoon-school/libraries.mdnew file+191

This diff is too big to show here.

content/docs/hoon/hoon-school/list-of-numbers.mdnew file+132

This diff is too big to show here.

content/docs/hoon/hoon-school/lists.mdnew file+497

This diff is too big to show here.

content/docs/hoon/hoon-school/molds.mdnew file+98

This diff is too big to show here.

content/docs/hoon/hoon-school/nouns.mdnew file+563

This diff is too big to show here.

content/docs/hoon/hoon-school/recursion.mdnew file+195

This diff is too big to show here.

content/docs/hoon/hoon-school/setup.mdnew file+105

This diff is too big to show here.

content/docs/hoon/hoon-school/structures-and-complex-types.mdnew file+356

This diff is too big to show here.

content/docs/hoon/hoon-school/the-subject-and-its-legs.mdnew file+726

This diff is too big to show here.

content/docs/hoon/hoon-school/trees-sets-and-maps.mdnew file+321

This diff is too big to show here.

content/docs/hoon/hoon-school/type-checking-and-type-inference.mdnew file+643

This diff is too big to show here.

content/docs/hoon/hoon-school/type-polymorphism.mdnew file+584

This diff is too big to show here.

content/docs/hoon/overview.mdnew file+276

This diff is too big to show here.

content/docs/hoon/reference/_index.mdnew file+50

This diff is too big to show here.

content/docs/hoon/reference/advanced.mdnew file+206

This diff is too big to show here.

content/docs/hoon/reference/auras.mdnew file+98

This diff is too big to show here.

content/docs/hoon/reference/basic.mdnew file+177

This diff is too big to show here.

content/docs/hoon/reference/cheat-sheet.mdnew file+28

This diff is too big to show here.

content/docs/hoon/reference/hoon-errors.mdnew file+189

This diff is too big to show here.

content/docs/hoon/reference/irregular.mdnew file+257

This diff is too big to show here.

content/docs/hoon/reference/limbs/_index.mdnew file+18

This diff is too big to show here.

content/docs/hoon/reference/limbs/limb.mdnew file+71

This diff is too big to show here.

content/docs/hoon/reference/limbs/wing.mdnew file+44

This diff is too big to show here.

content/docs/hoon/reference/rune/_index.mdnew file+73

This diff is too big to show here.

content/docs/hoon/reference/rune/bar.mdnew file+708

This diff is too big to show here.

content/docs/hoon/reference/rune/buc.mdnew file+606

This diff is too big to show here.

content/docs/hoon/reference/rune/cen.mdnew file+466

This diff is too big to show here.

content/docs/hoon/reference/rune/col.mdnew file+245

This diff is too big to show here.

content/docs/hoon/reference/rune/constants.mdnew file+193

This diff is too big to show here.

content/docs/hoon/reference/rune/dot.mdnew file+223

This diff is too big to show here.

content/docs/hoon/reference/rune/ket.mdnew file+387

This diff is too big to show here.

content/docs/hoon/reference/rune/lus.mdnew file+225

This diff is too big to show here.

content/docs/hoon/reference/rune/mic.mdnew file+462

This diff is too big to show here.

content/docs/hoon/reference/rune/sig.mdnew file+452

This diff is too big to show here.

content/docs/hoon/reference/rune/terminators.mdnew file+78

This diff is too big to show here.

content/docs/hoon/reference/rune/tis.mdnew file+490

This diff is too big to show here.

content/docs/hoon/reference/rune/wut.mdnew file+551

This diff is too big to show here.

content/docs/hoon/reference/rune/zap.mdnew file+239

This diff is too big to show here.

content/docs/hoon/reference/stdlib/1a.mdnew file+680

This diff is too big to show here.

content/docs/hoon/reference/stdlib/1b.mdnew file+273

This diff is too big to show here.

content/docs/hoon/reference/stdlib/1c.mdnew file+459

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2a.mdnew file+449

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2b.mdnew file+1412

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2c.mdnew file+1364

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2d.mdnew file+373

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2e.mdnew file+268

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2f.mdnew file+437

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2g.mdnew file+105

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2h.mdnew file+826

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2i.mdnew file+1133

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2j.mdnew file+269

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2k.mdnew file+400

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2l.mdnew file+108

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2m.mdnew file+308

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2n.mdnew file+427

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2o.mdnew file+187

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2p.mdnew file+242

This diff is too big to show here.

content/docs/hoon/reference/stdlib/2q.mdnew file+375

This diff is too big to show here.

content/docs/hoon/reference/stdlib/3a.mdnew file+859

This diff is too big to show here.

content/docs/hoon/reference/stdlib/3b.mdnew file+5889

This diff is too big to show here.

content/docs/hoon/reference/stdlib/3c.mdnew file+649

This diff is too big to show here.

content/docs/hoon/reference/stdlib/3d.mdnew file+821

This diff is too big to show here.

content/docs/hoon/reference/stdlib/3e.mdnew file+8

This diff is too big to show here.

content/docs/hoon/reference/stdlib/3f.mdnew file+722

This diff is too big to show here.

content/docs/hoon/reference/stdlib/3g.mdnew file+384

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4a.mdnew file+217

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4b.mdnew file+994

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4c.mdnew file+364

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4d.mdnew file+100

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4e.mdnew file+471

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4f.mdnew file+1195

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4g.mdnew file+179

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4h.mdnew file+962

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4i.mdnew file+1054

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4j.mdnew file+1656

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4k.mdnew file+276

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4l.mdnew file+608

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4m.mdnew file+434

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4n.mdnew file+447

This diff is too big to show here.

content/docs/hoon/reference/stdlib/4o.mdnew file+782

This diff is too big to show here.

content/docs/hoon/reference/stdlib/5a.mdnew file+7

This diff is too big to show here.

content/docs/hoon/reference/stdlib/5b.mdnew file+7

This diff is too big to show here.

content/docs/hoon/reference/stdlib/5c.mdnew file+7

This diff is too big to show here.

content/docs/hoon/reference/stdlib/5d.mdnew file+7

This diff is too big to show here.

content/docs/hoon/reference/stdlib/5e.mdnew file+7

This diff is too big to show here.

content/docs/hoon/reference/stdlib/5f.mdnew file+176

This diff is too big to show here.

content/docs/hoon/reference/stdlib/5g.mdnew file+7

This diff is too big to show here.

content/docs/hoon/reference/stdlib/_index.mdnew file+1733

This diff is too big to show here.

content/docs/hoon/reference/stdlib/table-of-contents.mdnew file+1731

This diff is too big to show here.

content/docs/hoon/reference/style.mdnew file+476

This diff is too big to show here.

content/docs/nock/_index.mdnew file+27

This diff is too big to show here.

content/docs/nock/definition.mdnew file+186

This diff is too big to show here.

content/docs/nock/example.mdnew file+362

This diff is too big to show here.

content/docs/nock/explanation.mdnew file+605

This diff is too big to show here.

content/docs/nock/implementations.mdnew file+2322

This diff is too big to show here.

content/docs/system-overview/_index.mdnew file+77

This diff is too big to show here.

content/docs/system-overview/arvo.mdnew file+33

This diff is too big to show here.

content/docs/system-overview/azimuth.mdnew file+34

This diff is too big to show here.

content/docs/system-overview/cryptography.mdnew file+116

This diff is too big to show here.

content/docs/system-overview/hoon.mdnew file+28

This diff is too big to show here.

content/docs/system-overview/nock.mdnew file+34

This diff is too big to show here.

content/docs/system-overview/vere.mdnew file+45

This diff is too big to show here.

content/docs/userspace/_index.mdnew file+30

This diff is too big to show here.

content/docs/userspace/gall/_index.mdnew file+21

This diff is too big to show here.

content/docs/userspace/gall/gall-api.mdnew file+958

This diff is too big to show here.

content/docs/userspace/gall/gall.mdnew file+559

This diff is too big to show here.

content/docs/userspace/gall/tutorial.mdnew file+14

This diff is too big to show here.

content/docs/userspace/graph-store/_index.mdnew file+23

This diff is too big to show here.

content/docs/userspace/graph-store/advanced-info.mdnew file+64

This diff is too big to show here.

content/docs/userspace/graph-store/data-structure-overview.mdnew file+338

This diff is too big to show here.

content/docs/userspace/graph-store/overview.mdnew file+109

This diff is too big to show here.

content/docs/userspace/graph-store/validator-walkthrough.mdnew file+487

This diff is too big to show here.

content/docs/userspace/landscape/_index.mdnew file+18

This diff is too big to show here.

content/docs/userspace/landscape/overview.mdnew file+195

This diff is too big to show here.

content/docs/userspace/landscape/reference/_index.mdnew file+11

This diff is too big to show here.

content/docs/userspace/landscape/reference/graph-store.mdnew file+160

This diff is too big to show here.

content/docs/userspace/overview.mdnew file+19

This diff is too big to show here.

content/docs/userspace/threads/_index.mdnew file+27

This diff is too big to show here.

content/docs/userspace/threads/basics/_index.mdnew file+29

This diff is too big to show here.

content/docs/userspace/threads/basics/bind.mdnew file+97

This diff is too big to show here.

content/docs/userspace/threads/basics/fundamentals.mdnew file+169

This diff is too big to show here.

content/docs/userspace/threads/basics/input.mdnew file+145

This diff is too big to show here.

content/docs/userspace/threads/basics/output.mdnew file+119

This diff is too big to show here.

content/docs/userspace/threads/basics/summary.mdnew file+75

This diff is too big to show here.

content/docs/userspace/threads/examples/_index.mdnew file+33

This diff is too big to show here.

content/docs/userspace/threads/examples/child-thread.mdnew file+237

This diff is too big to show here.

content/docs/userspace/threads/examples/get-json.mdnew file+126

This diff is too big to show here.

content/docs/userspace/threads/examples/main-loop.mdnew file+178

This diff is too big to show here.

content/docs/userspace/threads/examples/poke-agent.mdnew file+60

This diff is too big to show here.

content/docs/userspace/threads/examples/scry.mdnew file+70

This diff is too big to show here.

content/docs/userspace/threads/examples/take-fact.mdnew file+65

This diff is too big to show here.

content/docs/userspace/threads/gall/_index.mdnew file+29

This diff is too big to show here.

content/docs/userspace/threads/gall/poke-thread.mdnew file+116

This diff is too big to show here.

content/docs/userspace/threads/gall/start-thread.mdnew file+145

This diff is too big to show here.

content/docs/userspace/threads/gall/stop-thread.mdnew file+152

This diff is too big to show here.

content/docs/userspace/threads/gall/take-facts.mdnew file+184

This diff is too big to show here.

content/docs/userspace/threads/gall/take-result.mdnew file+132

This diff is too big to show here.

content/docs/userspace/threads/overview.mdnew file+81

This diff is too big to show here.

content/docs/userspace/threads/reference.mdnew file+86

This diff is too big to show here.

content/docs/vere/_index.mdnew file+37

This diff is too big to show here.

content/docs/vere/api.mdnew file+1040

This diff is too big to show here.

content/docs/vere/c.mdnew file+114

This diff is too big to show here.

content/docs/vere/jetting.mdnew file+779

This diff is too big to show here.

content/docs/vere/nouns.mdnew file+477

This diff is too big to show here.

content/docs/vere/runtime.mdnew file+44

This diff is too big to show here.

content/ecosystem/spotlight/2022-august.mddeleted−44

This diff is too big to show here.

content/ecosystem/spotlight/2022-december.mddeleted−40

This diff is too big to show here.

content/ecosystem/spotlight/2022-november.mddeleted−42

This diff is too big to show here.

content/ecosystem/spotlight/2022-october.mddeleted−41

This diff is too big to show here.

content/ecosystem/spotlight/2022-september.mddeleted−45

This diff is too big to show here.

content/ecosystem/spotlight/2023-february.mddeleted−48

This diff is too big to show here.

content/ecosystem/spotlight/2023-june.mddeleted−40

This diff is too big to show here.

content/ecosystem/spotlight/2023-may.mddeleted−50

This diff is too big to show here.

content/events/2017-08-11-after-hours-bootstrapping-urbit-from-the-ethereum-blockchain.md+8−10

This diff is too big to show here.

content/events/2017-09-22-after-hours-fun-with-arvo-the-urbit-os.md+8−9

This diff is too big to show here.

content/events/2017-10-26-after-hours-designing-robust-human-systems.md+10−11

This diff is too big to show here.

content/events/2017-11-16-after-hours-visiting-contributors.md+8−8

This diff is too big to show here.

content/events/2018-01-26-urbit-irl-20181.md+8−9

This diff is too big to show here.

content/events/2018-02-23-urbit-irl-20182.md+8−9

This diff is too big to show here.

content/events/2018-03-11-20183-hoon-school.md+8−9

This diff is too big to show here.

content/events/2018-03-23-urbit-irl-20183.md+8−9

This diff is too big to show here.

content/events/2018-04-08-20184-hoon-school.md+8−9

This diff is too big to show here.

content/events/2018-05-25-urbit-irl-20185.md+8−9

This diff is too big to show here.

content/events/2018-08-03-after-hours-decentralized-web-summit.md+7−8

This diff is too big to show here.

content/events/2018-08-17-urbit-irl-20188.md+8−9

This diff is too big to show here.

content/events/2018-09-21-urbit-irl-20189.md+8−9

This diff is too big to show here.

content/events/2018-10-10-urbit-zcash-blockchain-week.md+8−9

This diff is too big to show here.

content/events/2018-12-20-after-hours-its-just-a-party-man.md+8−9

This diff is too big to show here.

content/events/2019-03-01-after-hours-ask-galen-anything.md+8−9

This diff is too big to show here.

content/events/2019-03-08-urbit-irl-austin-tx.md+8−9

This diff is too big to show here.

content/events/2019-04-19-urbit-irl-20194.md+8−9

This diff is too big to show here.

content/events/2019-05-17-urbit-irl-20195.md+8−9

This diff is too big to show here.

content/events/2019-06-21-urbit-irl-20196.md+8−9

This diff is too big to show here.

content/events/2019-07-19-urbit-irl-20197.md+8−11

This diff is too big to show here.

content/events/2019-08-29-urbit-austin-20198.md+8−11

This diff is too big to show here.

content/events/2019-10-04-urbit-irl-201910.md+8−11

This diff is too big to show here.

content/events/2019-11-15-urbit-irl-201911.md+8−11

This diff is too big to show here.

content/events/2019-12-13-urbit-irl-201912.md+8−11

This diff is too big to show here.

content/events/2020-01-24-urbit-irl-20201.md+7−12

This diff is too big to show here.

content/events/2020-02-28-urbit-irl-20202.md+8−11

This diff is too big to show here.

content/events/2020-04-03-urbit-os1-launch-party.md+12−15

This diff is too big to show here.

content/events/2020-10-09-urbit-hosting-launch-event.md+13−19

This diff is too big to show here.

content/events/2020-11-05-developer-call-graph-store.md+6−12

This diff is too big to show here.

content/events/2020-11-19-developer-call-bittorrent-tracking-on-urbit.md+8−12

This diff is too big to show here.

content/events/2020-12-10-developer-call-injecting-external-services-into-urbit.md+6−12

This diff is too big to show here.

content/events/2021-02-04-developer-call-architectural-idea-maze.md+7−13

This diff is too big to show here.

content/events/2021-03-04-developer-call-scaling-azimuth.md+6−9

This diff is too big to show here.

content/events/2021-03-18-developer-call-pressure-and-protolith.md+5−11

This diff is too big to show here.

content/events/2021-04-01-developer-call-javascript-apps-on-urbit.md+6−11

This diff is too big to show here.

content/events/2021-04-15-developer-call-software-distribution.md+7−16

This diff is too big to show here.

content/events/2021-04-27-bitcoin-launch.md+7−12

This diff is too big to show here.

content/events/2021-04-29-developer-call-real-time-communications-on-urbit.md+6−11

This diff is too big to show here.

content/events/2021-05-13-developer-call-versioned-networking.md+6−11

This diff is too big to show here.

content/events/2021-05-27-town-hall.md+7−16

This diff is too big to show here.

content/events/2021-07-01-developer-call-runtime-future.mddeleted−25

This diff is too big to show here.

content/events/2021-07-15-developer-call-yakshaving.mddeleted−25

This diff is too big to show here.

content/events/2021-09-02-21q3-dc-meetup.mddeleted−22

This diff is too big to show here.

content/events/2021-09-16-developer-call-azimuth-scaled.mddeleted−46

This diff is too big to show here.

content/events/2021-09-24-urbit-outside.mddeleted−23

This diff is too big to show here.

content/events/2021-10-07-developer-call-visor.mddeleted−38

This diff is too big to show here.

content/events/2021-10-15-assembly.mddeleted−26

This diff is too big to show here.

content/events/2021-10-16-assembly-keynote.mddeleted−14

This diff is too big to show here.

content/events/2021-10-16-assembly-sw-dist-qa.mddeleted−14

This diff is too big to show here.

content/events/2021-10-28-developer-call-hosting.mddeleted−33

This diff is too big to show here.

content/events/2021-11-26-meetup-brisbane.mddeleted−30

This diff is too big to show here.

content/events/2022-01-21-meetup-austin.mddeleted−16

This diff is too big to show here.

content/events/2022-02-17-developer-call-building-developers.mddeleted−27

This diff is too big to show here.

content/events/2022-03-24-developer-call-urbit-three-ways-with-quartus.mddeleted−26

This diff is too big to show here.

content/events/2022-04-05-urbit-meetup-stockholm.mddeleted−30

This diff is too big to show here.

content/events/2022-04-21-developer-call-uqbar-and-urbits-first-blockchain.mddeleted−24

This diff is too big to show here.

content/events/2022-04-26-urbit-foundation-meetup-kingsnight-amsterdam.mddeleted−23

This diff is too big to show here.

content/events/2022-05-06-urbit-weekend-kansas.mddeleted−20

This diff is too big to show here.

content/events/2022-06-16-developer-call-urbits-new-terminal-stack-tlon copy.mddeleted−23

This diff is too big to show here.

content/events/2022-06-16-developer-call-urbits-new-terminal-stack-tlon.mddeleted−24

This diff is too big to show here.

content/events/2022-07-07-hackathon-hackfs.mddeleted−18

This diff is too big to show here.

content/events/2022-07-08-urbit-fireside-chat-1.mddeleted−19

This diff is too big to show here.

content/events/2022-07-21-developer-holium-community-os.mddeleted−25

This diff is too big to show here.

content/events/2022-07-21-ethcc-paris-22-meetup.mddeleted−21

This diff is too big to show here.

content/events/2022-07-22-urbit-outside-alta-plaza.mddeleted−22

This diff is too big to show here.

content/events/2022-07-28-urbit-meetup-milano-22.mddeleted−22

This diff is too big to show here.

content/events/2022-08-04-reassembly.mddeleted−31

This diff is too big to show here.

content/events/2022-08-12-urbit-fireside-chat-2.mddeleted−20

This diff is too big to show here.

content/events/2022-08-27-urbit-outside-alta-plaza.mddeleted−17

This diff is too big to show here.

content/events/2022-09-08-developer-call-future-of-khan.mddeleted−25

This diff is too big to show here.

content/events/2022-09-15-developer-call-IoT.mddeleted−27

This diff is too big to show here.

content/events/2022-09-19-rabbit-hole-talk.mddeleted−19

This diff is too big to show here.

content/events/2022-09-22-assembly.mddeleted−14

This diff is too big to show here.

content/events/2022-10-13-devcon-bogotá-urbit-meetup-22.mddeleted−36

This diff is too big to show here.

content/events/2022-11-01-developer-week.mddeleted−75

This diff is too big to show here.

content/events/2022-11-19-urbit-irl.mddeleted−18

This diff is too big to show here.

content/events/2022-19-10-developer-call-herd-dependency.mddeleted−25

This diff is too big to show here.

content/events/2023-01-28-urbit-meetup-christchurch.mddeleted−21

This diff is too big to show here.

content/events/2023-01-31-urbit-meetup-krakow.mddeleted−26

This diff is too big to show here.

content/events/2023-02-23-urbit-meetup-berlin.mddeleted−27

This diff is too big to show here.

content/events/2023-03-05-meetup-el-salvador.mddeleted−24

This diff is too big to show here.

content/events/2023-03-25-urbit-meetup-christchurch.mddeleted−21

This diff is too big to show here.

content/events/2023-04-18-urbit-lisbon.mddeleted−19

This diff is too big to show here.

content/events/2023-04-27-urbit-meetup-berlin.mddeleted−27

This diff is too big to show here.

content/events/2023-04-27_urbit-austin-meetup-consensus.mddeleted−16

This diff is too big to show here.

content/events/2023-05-10_urbit-meetup-berlin.mddeleted−25

This diff is too big to show here.

content/events/2023-05-14_urbit-meetup-london.mddeleted−23

This diff is too big to show here.

content/events/2023-05-18_urbit-denver-meetup.mddeleted−19

This diff is too big to show here.

content/events/2023-05-18_urbit-miami-meetup.mddeleted−20

This diff is too big to show here.

content/events/2023-05-27_urbit-meetup-london.mddeleted−21

This diff is too big to show here.

content/events/2023-05-27_urbit-meetup-mst.mddeleted−20

This diff is too big to show here.

content/events/2023-06-03-urbit-meetup-christchurch.mddeleted−24

This diff is too big to show here.

content/events/2023-06-08_urbit-meetup-berlin.mddeleted−25

This diff is too big to show here.

content/events/2023-06-08_urbit-meetup-prague.mddeleted−39

This diff is too big to show here.

content/events/2023-06-12-developer-week.mddeleted−95

This diff is too big to show here.

content/events/2023-06-15_urbit-denver-meetup.mddeleted−19

This diff is too big to show here.

content/events/2023-06-24-urbit-meetup-christchurch.mddeleted−24

This diff is too big to show here.

content/events/2023-06-29-Urbit-Paris-Meetup-1.mddeleted−30

This diff is too big to show here.

content/events/2023-07-01_urbit-meetup-mst.mddeleted−23

This diff is too big to show here.

content/events/2023-07-20-Urbit-Paris-Meetup-ethcc.mddeleted−53

This diff is too big to show here.

content/events/2023-08-16_reassembly.mddeleted−22

This diff is too big to show here.

content/events/2023-10-28_urbit-assembly-lisboa.mddeleted−24

This diff is too big to show here.

content/faq.md+195−61

This diff is too big to show here.

content/getting-started/_index.md+77−21

This diff is too big to show here.

content/getting-started/cli.md+140−222

This diff is too big to show here.

content/getting-started/cloud-hosting.mddeleted−468

This diff is too big to show here.

content/getting-started/desktop.mddeleted−11

This diff is too big to show here.

content/getting-started/get-id.mddeleted−113

This diff is too big to show here.

content/getting-started/getting-around.mddeleted−55

This diff is too big to show here.

content/getting-started/home-servers.mddeleted−27

This diff is too big to show here.

content/getting-started/hosted.mddeleted−30

This diff is too big to show here.

content/getting-started/hosting-providers.mddeleted−24

This diff is too big to show here.

content/getting-started/installing-applications.mddeleted−39

This diff is too big to show here.

content/getting-started/interfaces.mddeleted−10

This diff is too big to show here.

content/getting-started/joining-groups.mddeleted−54

This diff is too big to show here.

content/getting-started/planet.mdnew file+132

This diff is too big to show here.

content/getting-started/self-host.mddeleted−33

This diff is too big to show here.

content/gifts/sample.mddeleted−6

This diff is too big to show here.

content/grants/2021/smol-future-sustained-knowledge-sharing-and-marketing.md → content/grants/-smol-future-sustained-knowledge-sharing-and-marketing.mdrenamed+5−8

This diff is too big to show here.

content/grants/2021/authenticate-with-urbit.mddeleted−36

This diff is too big to show here.

content/grants/2021/azimuth-cli.mddeleted−164

This diff is too big to show here.

content/grants/2021/bitcoin-wallet-maintenance.mddeleted−65

This diff is too big to show here.

content/grants/2021/bridge-l2-revamp.mddeleted−57

This diff is too big to show here.

content/grants/2021/clojure-urbit-client.mddeleted−113

This diff is too big to show here.

content/grants/2021/contacts.mddeleted−37

This diff is too big to show here.

content/grants/2021/content-producer.mddeleted−40

This diff is too big to show here.

content/grants/2021/cypherscope-bot.mddeleted−80

This diff is too big to show here.

content/grants/2021/feed-aggregator.mddeleted−103

This diff is too big to show here.

content/grants/2021/guide-to-s3.mddeleted−35

This diff is too big to show here.

content/grants/2021/host-two-urbit-meetups-12.mddeleted−58

This diff is too big to show here.

content/grants/2021/host-two-urbit-meetups-13.mddeleted−59

This diff is too big to show here.

content/grants/2021/host-two-urbit-meetups-14.mddeleted−59

This diff is too big to show here.

content/grants/2021/host-two-urbit-meetups-15.mddeleted−59

This diff is too big to show here.

content/grants/2021/host-two-urbit-meetups-16.mddeleted−59

This diff is too big to show here.

content/grants/2021/json-jet.mddeleted−51

This diff is too big to show here.

content/grants/2021/login-with-urbit.mddeleted−84

This diff is too big to show here.

content/grants/2021/machine-learning.mddeleted−122

This diff is too big to show here.

content/grants/2021/market-interface.mddeleted−62

This diff is too big to show here.

content/grants/2021/meetup-bom.mddeleted−118

This diff is too big to show here.

content/grants/2021/native-urbit.mddeleted−30

This diff is too big to show here.

content/grants/2021/nuck-jet.mddeleted−59

This diff is too big to show here.

content/grants/2021/planet-sales.mddeleted−66

This diff is too big to show here.

content/grants/2021/pokur.mddeleted−90

This diff is too big to show here.

content/grants/2021/ra-debugging-tools.mddeleted−26

This diff is too big to show here.

content/grants/2021/ra-page-tracking.mddeleted−34

This diff is too big to show here.

content/grants/2021/ra-segfaults.mddeleted−32

This diff is too big to show here.

content/grants/2021/ra-stack-overflow.mddeleted−32

This diff is too big to show here.

content/grants/2021/send-emails-to-a-mailing-list.mddeleted−78

This diff is too big to show here.

content/grants/2021/speech-recognition.mddeleted−78

This diff is too big to show here.

content/grants/2021/static-site-generation.mddeleted−80

This diff is too big to show here.

content/grants/2021/twitter-uv-extension.mddeleted−67

This diff is too big to show here.

content/grants/2021/urbit-http-api-for-python.mddeleted−46

This diff is too big to show here.

content/grants/2021/urbit-irc-bridge.mddeleted−49

This diff is too big to show here.

content/grants/2021/urbit-notes.mddeleted−102

This diff is too big to show here.

content/grants/2021/uturn.mddeleted−38

This diff is too big to show here.

content/grants/2021/uv-extension-library.mddeleted−44

This diff is too big to show here.

content/grants/2021/~home-urbit.mddeleted−119

This diff is too big to show here.

content/grants/2022/abacus.mddeleted−56

This diff is too big to show here.

content/grants/2022/app-engram.mddeleted−117

This diff is too big to show here.

content/grants/2022/app-openbsd.mddeleted−53

This diff is too big to show here.

content/grants/2022/app-store.mddeleted−159

This diff is too big to show here.

content/grants/2022/app-urvault.mddeleted−41

This diff is too big to show here.

content/grants/2022/app-uv-native-notificatons.mddeleted−42

This diff is too big to show here.

content/grants/2022/apprenticeship-extending-bitcoin.mddeleted−76

This diff is too big to show here.

content/grants/2022/apprenticeship-studio-collections.mddeleted−55

This diff is too big to show here.

content/grants/2022/apprenticeship-studio-email.mddeleted−40

This diff is too big to show here.

content/grants/2022/astrolabe.mddeleted−165

This diff is too big to show here.

content/grants/2022/books-development.mddeleted−44

This diff is too big to show here.

content/grants/2022/books.mddeleted−116

This diff is too big to show here.

content/grants/2022/calendar-holium.mddeleted−53

This diff is too big to show here.

content/grants/2022/chess-bounty.mddeleted−54

This diff is too big to show here.

content/grants/2022/chronicle.mddeleted−63

This diff is too big to show here.

content/grants/2022/communal-computing.mddeleted−130

This diff is too big to show here.

content/grants/2022/cue.mddeleted−60

This diff is too big to show here.

content/grants/2022/desk-import-export.mddeleted−102

This diff is too big to show here.

content/grants/2022/digital-editor-MROB.mddeleted−50

This diff is too big to show here.

content/grants/2022/digital-storefront.mddeleted−73

This diff is too big to show here.

content/grants/2022/dusko-valve.mddeleted−81

This diff is too big to show here.

content/grants/2022/eth-provider.mddeleted−65

This diff is too big to show here.

content/grants/2022/eth-wallet.mddeleted−49

This diff is too big to show here.

content/grants/2022/eyre-scry.mddeleted−72

This diff is too big to show here.

content/grants/2022/faux.mddeleted−58

This diff is too big to show here.

content/grants/2022/filesharer.mddeleted−100

This diff is too big to show here.

content/grants/2022/full-stop.mddeleted−131

This diff is too big to show here.

content/grants/2022/gather.mddeleted−87

This diff is too big to show here.

content/grants/2022/general-web-permissions.mddeleted−36

This diff is too big to show here.

content/grants/2022/gnosis-safe.mddeleted−56

This diff is too big to show here.

content/grants/2022/go-urbit.mddeleted−64

This diff is too big to show here.

content/grants/2022/gora-apprentice.mddeleted−61

This diff is too big to show here.

content/grants/2022/herd.mddeleted−58

This diff is too big to show here.

content/grants/2022/hoon-eval.mddeleted−56

This diff is too big to show here.

content/grants/2022/hoon-markdown-library.mddeleted−52

This diff is too big to show here.

content/grants/2022/http-server-driver.mddeleted−98

This diff is too big to show here.

content/grants/2022/keep.mddeleted−119

This diff is too big to show here.

content/grants/2022/knox.mddeleted−81

This diff is too big to show here.

content/grants/2022/lexicon.mddeleted−69

This diff is too big to show here.

content/grants/2022/lightning-development.mddeleted−201

This diff is too big to show here.

content/grants/2022/loom-pointer-compression.mddeleted−62

This diff is too big to show here.

content/grants/2022/meld-memory.mddeleted−55

This diff is too big to show here.

content/grants/2022/membrane.mddeleted−98

This diff is too big to show here.

content/grants/2022/middleware-apprentice.mddeleted−55

This diff is too big to show here.

content/grants/2022/minesweeper.mddeleted−48

This diff is too big to show here.

content/grants/2022/native-planet-2.mddeleted−90

This diff is too big to show here.

content/grants/2022/nested-goals.mddeleted−162

This diff is too big to show here.

content/grants/2022/notifications-protocol.mddeleted−64

This diff is too big to show here.

content/grants/2022/olif.mddeleted−97

This diff is too big to show here.

content/grants/2022/peat.mddeleted−66

This diff is too big to show here.

content/grants/2022/persistent-memory.mddeleted−157

This diff is too big to show here.

content/grants/2022/plug.mddeleted−165

This diff is too big to show here.

content/grants/2022/pony-bounty.mddeleted−72

This diff is too big to show here.

content/grants/2022/port-maintenance.mddeleted−72

This diff is too big to show here.

content/grants/2022/port-to-hosting.mddeleted−56

This diff is too big to show here.

content/grants/2022/profiling.mddeleted−74

This diff is too big to show here.

content/grants/2022/qr-login.mddeleted−48

This diff is too big to show here.

content/grants/2022/quorum.mddeleted−106

This diff is too big to show here.

content/grants/2022/regex-library.mddeleted−114

This diff is too big to show here.

content/grants/2022/seguro-phase-2.mddeleted−190

This diff is too big to show here.

content/grants/2022/seguro-prototype.mddeleted−66

This diff is too big to show here.

content/grants/2022/serving-the-people.mddeleted−101

This diff is too big to show here.

content/grants/2022/slam.mddeleted−113

This diff is too big to show here.

content/grants/2022/slaw-scot-jets.mddeleted−72

This diff is too big to show here.

content/grants/2022/smart-lightbulb-controller.mddeleted−104

This diff is too big to show here.

content/grants/2022/symmetric-routing.mddeleted−69

This diff is too big to show here.

content/grants/2022/trail.mddeleted−168

This diff is too big to show here.

content/grants/2022/trill-ufa.mddeleted−67

This diff is too big to show here.

content/grants/2022/trove.mddeleted−94

This diff is too big to show here.

content/grants/2022/urbit-forms.mddeleted−250

This diff is too big to show here.

content/grants/2022/urbit-interface-framework.mddeleted−88

This diff is too big to show here.

content/grants/2022/urbitswap.mddeleted−59

This diff is too big to show here.

content/grants/2022/value-articles.mddeleted−54

This diff is too big to show here.

content/grants/2022/volt-ui.mddeleted−54

This diff is too big to show here.

content/grants/2022/whom.mddeleted−70

This diff is too big to show here.

content/grants/2023/aera.mddeleted−50

This diff is too big to show here.

content/grants/2023/app-metrics.mddeleted−74

This diff is too big to show here.

content/grants/2023/blog-updates.mddeleted−64

This diff is too big to show here.

content/grants/2023/bridge-grab-bag.mddeleted−35

This diff is too big to show here.

content/grants/2023/community-meetups.mddeleted−37

This diff is too big to show here.

content/grants/2023/did-rfp.mddeleted−26

This diff is too big to show here.

content/grants/2023/elm.mddeleted−68

This diff is too big to show here.

content/grants/2023/email-stella-fixa-rfp.mddeleted−29

This diff is too big to show here.

content/grants/2023/eyre-noun-channels.mddeleted−42

This diff is too big to show here.

content/grants/2023/generator-doccords.mddeleted−46

This diff is too big to show here.

content/grants/2023/gh-concierge.mddeleted−42

This diff is too big to show here.

content/grants/2023/git-on-clay.mddeleted−42

This diff is too big to show here.

content/grants/2023/goals-2.mddeleted−64

This diff is too big to show here.

content/grants/2023/hoon-linter.mddeleted−30

This diff is too big to show here.

content/grants/2023/hoon-replit.mddeleted−45

This diff is too big to show here.

content/grants/2023/issue-grab-bag.mddeleted−36

This diff is too big to show here.

content/grants/2023/json-parser-suite.mddeleted−170

This diff is too big to show here.

content/grants/2023/kNock-property-testing.mddeleted−71

This diff is too big to show here.

content/grants/2023/lick.mddeleted−82

This diff is too big to show here.

content/grants/2023/mapping-ids.mddeleted−106

This diff is too big to show here.

content/grants/2023/network-weather.mddeleted−24

This diff is too big to show here.

content/grants/2023/oauth2-stella-fixa-rfp.mddeleted−31

This diff is too big to show here.

content/grants/2023/osmosis-client.mddeleted−48

This diff is too big to show here.

content/grants/2023/pastebin-RFP.mddeleted−28

This diff is too big to show here.

content/grants/2023/pastebin-proposal.mddeleted−33

This diff is too big to show here.

content/grants/2023/portal-features-1.mddeleted−82

This diff is too big to show here.

content/grants/2023/privacy-msg.mddeleted−89

This diff is too big to show here.

content/grants/2023/quorum-2.mddeleted−84

This diff is too big to show here.

content/grants/2023/replit.mddeleted−52

This diff is too big to show here.

content/grants/2023/school-support-23q1.mddeleted−43

This diff is too big to show here.

content/grants/2023/splitwise-rfp.mddeleted−26

This diff is too big to show here.

content/grants/2023/splitwise.mddeleted−129

This diff is too big to show here.

content/grants/2023/text-search.mddeleted−24

This diff is too big to show here.

content/grants/2023/tinygrad.mddeleted−24

This diff is too big to show here.

content/grants/2023/treesitter.mddeleted−71

This diff is too big to show here.

content/grants/2023/turf.mddeleted−205

This diff is too big to show here.

content/grants/2023/uc-concierge.mddeleted−42

This diff is too big to show here.

content/grants/2023/update-mass.mddeleted−26

This diff is too big to show here.

content/grants/2023/urbit-ninja-strike-team.mddeleted−38

This diff is too big to show here.

content/grants/2023/urbit-react-docs.mddeleted−124

This diff is too big to show here.

content/grants/2023/vere-eyre-cache.mddeleted−38

This diff is too big to show here.

content/grants/2023/wiki-stella-fixa-rfp.mddeleted−26

This diff is too big to show here.

content/grants/2020/a-book-about-urbit.md → content/grants/a-book-about-urbit.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/a-network-enabled-spatial-database-and-demonstration-app.md → content/grants/a-collaborative-web-mapping-system-for-urbit.mdrenamed+34−38

This diff is too big to show here.

content/grants/2021/analytics-script.md → content/grants/analytics-script.mdrenamed+6−9

This diff is too big to show here.

content/grants/2020/antechamber.md → content/grants/antechamber.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/art-by-urbit.md → content/grants/art-by-urbit.mdrenamed+6−9

This diff is too big to show here.

content/grants/2020/bart-train-tracker-landscape-tile.md → content/grants/bart-train-tracker-landscape-tile.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/bitcoin-full-node-provider-and-wallet.md → content/grants/bitcoin-full-node-provider-and-wallet.mdrenamed+6−9

This diff is too big to show here.

content/grants/2020/bitcoin-key-derivation.md → content/grants/bitcoin-key-derivation.mdrenamed+7−10

This diff is too big to show here.

content/grants/2019/bitcoin-node-json-rpc-api-part-1.md → content/grants/bitcoin-node-json-rpc-api-part-1.mdrenamed+6−9

This diff is too big to show here.

content/grants/2019/bitcoin-node-json-rpc-api-part-2.md → content/grants/bitcoin-node-json-rpc-api-part-2.mdrenamed+6−9

This diff is too big to show here.

content/grants/2019/bitcoin-node-json-rpc-api-part-3.md → content/grants/bitcoin-node-json-rpc-api-part-3.mdrenamed+6−9

This diff is too big to show here.

content/grants/2019/bitcoin-node-json-rpc-api-part-4.md → content/grants/bitcoin-node-json-rpc-api-part-4.mdrenamed+6−9

This diff is too big to show here.

content/grants/2019/bitcoin-wallet-on-bridge.md → content/grants/bitcoin-wallet-on-bridge.mdrenamed+7−10

This diff is too big to show here.

content/grants/2020/boston-t-train-tracker-landscape-tile.md → content/grants/boston-t-train-tracker-landscape-tile.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/calendar-ui.md → content/grants/calendar-ui.mdrenamed+5−8

This diff is too big to show here.

content/grants/2020/calendar.md → content/grants/calendar.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/comprehensive-local-server-and-mum-explanation-video.md → content/grants/comprehensive-local-server-and-mum-explanation-video.mdrenamed+5−8

This diff is too big to show here.

content/grants/2020/content-saver.md → content/grants/content-saver.mdrenamed+6−8

This diff is too big to show here.

content/grants/2021/cross-platform-desktop-urbit-app.md → content/grants/cross-platform-desktop-urbit-app.mdrenamed+6−9

This diff is too big to show here.

content/grants/2020/cta-train-tracker-landscape-tile.md → content/grants/cta-train-tracker-landscape-tile.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/display-eth-data.md → content/grants/display-eth-data.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/docker-image-for-cloud-container-orchestration.md → content/grants/docker-image-for-cloud-container-orchestration.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/educational-guide-todomvc-urbit-edition.md → content/grants/educational-guide-todomvc-urbit-edition.mdrenamed+7−10

This diff is too big to show here.

content/grants/2019/escape.md → content/grants/escape.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/ethereum-abi-parser.md → content/grants/ethereum-abi-parser.mdrenamed+5−8

This diff is too big to show here.

content/grants/2019/gall-api-documentation.md → content/grants/gall-api-documentation.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/go-airlock-library.md → content/grants/go-airlock-library.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/graph-store-documentation-guide.md → content/grants/graph-store-documentation-guide.mdrenamed+6−9

This diff is too big to show here.

content/grants/2020/haskell-airlock-library.md → content/grants/haskell-airlock-library.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/hoon-001-learner-efficiency-and-early-learner-resources.md → content/grants/hoon-001-learner-efficiency-and-early-learner-resources.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/host-three-college-university-urbit-meetups-1.md → content/grants/host-three-college-university-urbit-meetups-1.mdrenamed+7−15

This diff is too big to show here.

content/grants/2020/host-three-college-university-urbit-meetups-2.md → content/grants/host-three-college-university-urbit-meetups-2.mdrenamed+7−15

This diff is too big to show here.

content/grants/2020/host-three-college-university-urbit-meetups-3.md → content/grants/host-three-college-university-urbit-meetups-3.mdrenamed+7−15

This diff is too big to show here.

content/grants/2020/host-three-virtual-urbit-meetups.md → content/grants/host-three-virtual-urbit-meetups.mdrenamed+5−8

This diff is too big to show here.

content/grants/2019/host-two-urbit-meetups-1.md → content/grants/host-two-urbit-meetups-1.mdrenamed+7−15

This diff is too big to show here.

content/grants/2019/host-two-urbit-meetups-10.md → content/grants/host-two-urbit-meetups-10.mdrenamed+7−15

This diff is too big to show here.

content/grants/2021/host-two-urbit-meetups-11.md → content/grants/host-two-urbit-meetups-11.mdrenamed+7−15

This diff is too big to show here.

content/grants/2019/host-two-urbit-meetups-2.md → content/grants/host-two-urbit-meetups-2.mdrenamed+7−15

This diff is too big to show here.

content/grants/2019/host-two-urbit-meetups-3.md → content/grants/host-two-urbit-meetups-3.mdrenamed+7−15

This diff is too big to show here.

content/grants/2019/host-two-urbit-meetups-4.md → content/grants/host-two-urbit-meetups-4.mdrenamed+7−15

This diff is too big to show here.

content/grants/2019/host-two-urbit-meetups-5.md → content/grants/host-two-urbit-meetups-5.mdrenamed+7−15

This diff is too big to show here.

content/grants/2019/host-two-urbit-meetups-6.md → content/grants/host-two-urbit-meetups-6.mdrenamed+7−15

This diff is too big to show here.

content/grants/2019/host-two-urbit-meetups-7.md → content/grants/host-two-urbit-meetups-7.mdrenamed+7−15

This diff is too big to show here.

content/grants/2019/host-two-urbit-meetups-8.md → content/grants/host-two-urbit-meetups-8.mdrenamed+7−15

This diff is too big to show here.

content/grants/2019/host-two-urbit-meetups-9.md → content/grants/host-two-urbit-meetups-9.mdrenamed+7−15

This diff is too big to show here.

content/grants/2020/links-in-urbit-reference-docs.md → content/grants/links-in-urbit-reference-docs.mdrenamed+6−9

This diff is too big to show here.

content/grants/2020/llelogram.md → content/grants/llelogram.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/matrices-in-hoon.md → content/grants/matrices-in-hoon.mdrenamed+6−8

This diff is too big to show here.

content/grants/2020/matrixriotim-bridge-bot.md → content/grants/matrixriotim-bridge-bot.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/minimal-urbit-os.md → content/grants/minimal-urbit-os.mdrenamed+5−8

This diff is too big to show here.

content/grants/2021/network-explorer-data-pipeline-http-api.md → content/grants/network-explorer-data-pipeline-http-api.mdrenamed+6−9

This diff is too big to show here.

content/grants/2020/open-street-maps-data-importation.md → content/grants/open-street-maps-data-importation.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/overhaul-the-urbitorg-website.md → content/grants/overhaul-the-urbitorg-website.mdrenamed+6−9

This diff is too big to show here.

content/grants/2019/ragnarok-online-on-urbit.md → content/grants/ragnarok-online-on-urbit.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/search-in-groups.md → content/grants/search-in-groups.mdrenamed+6−8

This diff is too big to show here.

content/grants/2020/staff-the-urbit-help-desk-1.md → content/grants/staff-the-urbit-help-desk-1.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/staff-the-urbit-help-desk-2.md → content/grants/staff-the-urbit-help-desk-2.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/staff-the-urbit-helpdesk-east.md → content/grants/staff-the-urbit-helpdesk-east.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/staff-the-urbit-helpdesk-west.md → content/grants/staff-the-urbit-helpdesk-west.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/the-complete-guide-to-gall-and-landscape.md → content/grants/the-complete-guide-to-gall-and-landscape.mdrenamed+6−8

This diff is too big to show here.

content/grants/2021/thread-documentation.md → content/grants/thread-documentation.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/tor-nodes-relay-search-tile.md → content/grants/tor-nodes-relay-search-tile.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/translate-key-parts-of-urbitorg-into-german.md → content/grants/translate-key-parts-of-urbitorg-into-german.mdrenamed+5−8

This diff is too big to show here.

content/grants/2021/translate-key-parts-of-urbitorg-into-korean.md → content/grants/translate-key-parts-of-urbitorg-into-korean.mdrenamed+6−9

This diff is too big to show here.

content/grants/2021/translate-key-parts-of-urbitorg-into-norwegian.md → content/grants/translate-key-parts-of-urbitorg-into-norwegian.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/translate-key-parts-of-urbitorg-into-spanish.md → content/grants/translate-key-parts-of-urbitorg-into-spanish.mdrenamed+5−8

This diff is too big to show here.

content/grants/2021/try-urbit-website.md → content/grants/try-urbit-website.mdrenamed+5−8

This diff is too big to show here.

content/grants/2020/typescript-airlock-library.md → content/grants/typescript-airlock-library.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/ua-collaborative-text-editor.md → content/grants/ua-collaborative-text-editor.mdrenamed+9−11

This diff is too big to show here.

content/grants/2021/ua-filesharer.md → content/grants/ua-filesharer.mdrenamed+7−9

This diff is too big to show here.

content/grants/2021/ua-heads-up-poker.md → content/grants/ua-heads-up-poker.mdrenamed+8−10

This diff is too big to show here.

content/grants/2021/ua-invoice-system.md → content/grants/ua-invoice-system.mdrenamed+7−9

This diff is too big to show here.

content/grants/2021/ua-marketplace.md → content/grants/ua-marketplace.mdrenamed+7−11

This diff is too big to show here.

content/grants/2021/ucal-google-and-outlook-integration.md → content/grants/ucal-google-and-outlook-integration.mdrenamed+5−8

This diff is too big to show here.

content/grants/2019/udon-syntax-highlighter.md → content/grants/udon-syntax-highlighter.mdrenamed+5−7

This diff is too big to show here.

content/grants/2019/unit-tests-for-json-parsing.md → content/grants/unit-tests-for-json-parsing.mdrenamed+5−7

This diff is too big to show here.

content/grants/2019/unit-tests-for-pure-algorithms.md → content/grants/unit-tests-for-pure-algorithms.mdrenamed+5−7

This diff is too big to show here.

content/grants/2019/unit-tests-for-sha-functions.md → content/grants/unit-tests-for-sha-functions.mdrenamed+5−7

This diff is too big to show here.

content/grants/2019/unit-tests-for-zuse-cryptographic-functions.md → content/grants/unit-tests-for-zuse-cryptographic-functions.mdrenamed+6−8

This diff is too big to show here.

content/grants/2020/up-to-date-hoon-reference-card.md → content/grants/up-to-date-hoon-reference-card.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/urbian-a-customized-linux-distribution-for-urbit-appliances.md → content/grants/urbian-a-customized-linux-distribution-for-urbit-appliances.mdrenamed+5−8

This diff is too big to show here.

content/grants/2021/urbit-api-for-elixir.md → content/grants/urbit-api-for-elixir.mdrenamed+6−8

This diff is too big to show here.

content/grants/2021/urbit-community-concierge-east-coast-2q2021.md → content/grants/urbit-community-concierge-east-coast-2q2021.mdrenamed+6−9

This diff is too big to show here.

content/grants/2021/urbit-community-concierge-east-coast.md → content/grants/urbit-community-concierge-east-coast.mdrenamed+6−9

This diff is too big to show here.

content/grants/2021/urbit-community-concierge-west-coast-2q2021.md → content/grants/urbit-community-concierge-west-coast-2q2021.mdrenamed+6−9

This diff is too big to show here.

content/grants/2021/urbit-community-concierge-west-coast.md → content/grants/urbit-community-concierge-west-coast.mdrenamed+6−9

This diff is too big to show here.

content/grants/2020/urbit-event-series.md → content/grants/urbit-event-series.mdrenamed+6−9

This diff is too big to show here.

content/grants/2020/urbit-explainer-video.md → content/grants/urbit-explainer-video.mdrenamed+5−8

This diff is too big to show here.

content/grants/2021/urbit-http-api-for-emacs-elisp.md → content/grants/urbit-http-api-for-emacs-elisp.mdrenamed+5−8

This diff is too big to show here.

content/grants/2020/urbit-http-api-for-kotlin.md → content/grants/urbit-http-api-for-kotlin.mdrenamed+5−8

This diff is too big to show here.

content/grants/2020/urbit-http-api-for-rust.md → content/grants/urbit-http-api-for-rust.mdrenamed+6−9

This diff is too big to show here.

content/grants/2020/urbit-http-interface-java-edition.md → content/grants/urbit-http-interface-java-edition.mdrenamed+5−8

This diff is too big to show here.

content/grants/2020/urbit-http-library-for-ruby.md → content/grants/urbit-http-library-for-ruby.mdrenamed+6−11

This diff is too big to show here.

content/grants/2021/urbit-lfs-filehosting.md → content/grants/urbit-lfs-filehosting.mdrenamed+5−8

This diff is too big to show here.

content/grants/2020/urbit-online-meetup.md → content/grants/urbit-online-meetup.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/urbit-react-cookbook.md → content/grants/urbit-react-cookbook.mdrenamed+6−9

This diff is too big to show here.

content/grants/2020/urbit-ship-and-star-hosting-and-troubleshooting-docs.md → content/grants/urbit-ship-and-star-hosting-and-troubleshooting-docs.mdrenamed+5−7

This diff is too big to show here.

content/grants/2020/verifying-urbit-id-on-keybase.md → content/grants/verifying-urbit-id-on-keybase.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/video-content-manager.md → content/grants/video-content-manager.mdrenamed+5−8

This diff is too big to show here.

content/grants/2021/volt-lightning-on-urbit.md → content/grants/volt-lightning-on-urbit.mdrenamed+17−50

This diff is too big to show here.

content/grants/2020/web-scraper.md → content/grants/web-scraper.mdrenamed+5−7

This diff is too big to show here.

content/grants/2021/webrtc-gall-agent-and-external-app.md → content/grants/webrtc-gall-agent-and-external-app.mdrenamed+20−20

This diff is too big to show here.

content/groups/_index.mddeleted−3

This diff is too big to show here.

content/groups/~bitbet-bolbel/urbit-community.mddeleted−14

This diff is too big to show here.

content/groups/~bitdeg/assembly22.mddeleted−10

This diff is too big to show here.

content/groups/~dalten/aera.mddeleted−10

This diff is too big to show here.

content/groups/~dibref-labter/arbit.mddeleted−9

This diff is too big to show here.

content/groups/~dister-dozzod-lapdeg/battery-payload.mddeleted−9

This diff is too big to show here.

content/groups/~fabled-faster/new-york.mddeleted−10

This diff is too big to show here.

content/groups/~fabled-faster/structure.mddeleted−10

This diff is too big to show here.

content/groups/~fabled-faster/wind.mddeleted−10

This diff is too big to show here.

content/groups/~famreb-todmec/the-combine-public.mddeleted−13

This diff is too big to show here.

content/groups/~halbex-palheb/uf-public.mddeleted−10

This diff is too big to show here.

content/groups/~hatryx-lastud/other-life.mddeleted−10

This diff is too big to show here.

content/groups/~hiddev-dannut/new-hooniverse.mddeleted−11

This diff is too big to show here.

content/groups/~hocwyn-tipwex/uqbar-event-horizon-forever.mddeleted−11

This diff is too big to show here.

content/groups/~ladtem-filmyr/urbit-ny-week.mddeleted−193

This diff is too big to show here.

content/groups/~lanlyd/terminal.mddeleted−8

This diff is too big to show here.

content/groups/~lodsum-rilner/emil-graphics.mddeleted−10

This diff is too big to show here.

content/groups/~martyr-sarlev-sarsen/assembly-hackers.mddeleted−10

This diff is too big to show here.

content/groups/~matwet/networked-subject.mddeleted−11

This diff is too big to show here.

content/groups/~middev/the-forge.mddeleted−10

This diff is too big to show here.

content/groups/~mister-hilper-dozzod-dalten/quartus.mddeleted−10

This diff is too big to show here.

content/groups/~napmer-rilnut/wet-brain.mddeleted−10

This diff is too big to show here.

content/groups/~natnex-ronret/door-link.mddeleted−10

This diff is too big to show here.

content/groups/~nibset-napwyn/tlon-public.mddeleted−10

This diff is too big to show here.

content/groups/~poldec-tonteg/the-phantom-tollbooth.mddeleted−12

This diff is too big to show here.

content/groups/~sillus-mallus/toki-pona.mddeleted−12

This diff is too big to show here.

content/groups/~sitbus-dapsup/urstralia.mddeleted−9

This diff is too big to show here.

content/groups/~tirrel/the-marketplace.mddeleted−14

This diff is too big to show here.

content/groups/~todset-partug/urmetica.mddeleted−9

This diff is too big to show here.

content/groups/~wacrep-lossul/encyclosphere.mddeleted−9

This diff is too big to show here.

content/groups/~widbep-faltev/asheville.mddeleted−9

This diff is too big to show here.

content/groups/~winder-dapsym/urchan.mddeleted−29

This diff is too big to show here.

content/groups/~witbep-witbep/embark.mddeleted−11

This diff is too big to show here.

content/highlights/highlight-1.mddeleted−6

This diff is too big to show here.

content/highlights/highlight-2.mddeleted−6

This diff is too big to show here.

content/highlights/highlight-3.mddeleted−6

This diff is too big to show here.

content/ids/ballun-dilsup.mddeleted−7

This diff is too big to show here.

content/ids/battus-datsun.mddeleted−10

This diff is too big to show here.

content/ids/binnus.mddeleted−10

This diff is too big to show here.

content/ids/bintud-bitnev.mddeleted−8

This diff is too big to show here.

content/ids/bitbet-bolbel.mddeleted−4

This diff is too big to show here.

content/ids/botbyn-dolrum.mddeleted−7

This diff is too big to show here.

content/ids/datder-sonnet.mddeleted−13

This diff is too big to show here.

content/ids/datnut-pollen.mddeleted−15

This diff is too big to show here.

content/ids/datryn-ribdun.mddeleted−12

This diff is too big to show here.

content/ids/datsyr-radser.mddeleted−12

This diff is too big to show here.

content/ids/dopbet-larped.mddeleted−7

This diff is too big to show here.

content/ids/fallyn-balfus.mddeleted−8

This diff is too big to show here.

content/ids/finmep-lanteb.mddeleted−29

This diff is too big to show here.

content/ids/forryd-ravtyn.mddeleted−6

This diff is too big to show here.

content/ids/haddef-sigwen.mddeleted−12

This diff is too big to show here.

content/ids/haldul-navsyr.mddeleted−7

This diff is too big to show here.

content/ids/hocmed-lidrev.mddeleted−8

This diff is too big to show here.

content/ids/lagrev-nocfep.mddeleted−8

This diff is too big to show here.

content/ids/lanlyd.mddeleted−8

This diff is too big to show here.

content/ids/mallus-fabres.mddeleted−12

This diff is too big to show here.

content/ids/mastyr-bottec.mddeleted−10

This diff is too big to show here.

content/ids/monnys-riphet.mddeleted−7

This diff is too big to show here.

content/ids/nallux-dozryl.mddeleted−12

This diff is too big to show here.

content/ids/nibtud-bidsyt.mddeleted−17

This diff is too big to show here.

content/ids/panleg-padben.mddeleted−6

This diff is too big to show here.

content/ids/pinsyt-nossub.mddeleted−18

This diff is too big to show here.

content/ids/poldec-tonteg.mddeleted−14

This diff is too big to show here.

content/ids/rabsef-bicrym.mddeleted−14

This diff is too big to show here.

content/ids/ravmel-ropdyl.mddeleted−8

This diff is too big to show here.

content/ids/rilfun-lidlen.mddeleted−8

This diff is too big to show here.

content/ids/sarlev-sarsen.mddeleted−8

This diff is too big to show here.

content/ids/sicdev-pilnup.mddeleted−8

This diff is too big to show here.

content/ids/sitful-hatred.mddeleted−8

This diff is too big to show here.

content/ids/sogrum-savluc.mddeleted−11

This diff is too big to show here.

content/ids/tagdyl-ponwyn.mddeleted−10

This diff is too big to show here.

content/ids/tambes-palped.mddeleted−10

This diff is too big to show here.

content/ids/tiplec-lacnyx.mddeleted−6

This diff is too big to show here.

content/ids/tobrun-tomnet.mddeleted−8

This diff is too big to show here.

content/ids/topfet-parmed.mddeleted−6

This diff is too big to show here.

content/ids/wicrum-wicrun.mddeleted−8

This diff is too big to show here.

content/ids/wolref-podlex.mddeleted−8

This diff is too big to show here.

content/marketplaces/azimuth-shop.mddeleted−11

This diff is too big to show here.

content/marketplaces/lanlyd.mddeleted−19

This diff is too big to show here.

content/marketplaces/mocbel-house.mddeleted−19

This diff is too big to show here.

content/marketplaces/networked-subject.mddeleted−14

This diff is too big to show here.

content/marketplaces/opensea.mddeleted−18

This diff is too big to show here.

content/marketplaces/planet-market.mddeleted−26

This diff is too big to show here.

content/marketplaces/urbit-live.mddeleted−13

This diff is too big to show here.

content/marketplaces/urbitex.mddeleted−11

This diff is too big to show here.

content/marketplaces/urbitme.mddeleted−11

This diff is too big to show here.

content/marketplaces/wexpert-systems.mddeleted−13

This diff is too big to show here.

content/media/blockchannel-episode-19-virtual-land-in-the-clouds-with-urbit.mdnew file+12

This diff is too big to show here.

content/media/blueprint-2017-galen-wolfe-pauly-on-the-distributed-web.mdnew file+12

This diff is too big to show here.

content/media/epicenter-episode-205-urbit-a-digital-republic-reinventing-the-internet.mdnew file+12

This diff is too big to show here.

content/media/governing-the-future-e09-urbit-a-user-owned-internet-on-top-of-the-internet.mdnew file+12

This diff is too big to show here.

content/media/lambdaconf-2016-curtis-yarvin-urbit-a-clean-slate-functional-operating-stack.mdnew file+12

This diff is too big to show here.

content/media/lambdaconf-2018-ted-blackman-ford-urbits-build-system.mdnew file+12

This diff is too big to show here.

content/media/on-the-brink-castle-island.mdnew file+14

This diff is too big to show here.

content/media/the-ether-review-46-curtis-yarvin-and-galen-wolfe-pauly-on-urbit.mdnew file+12

This diff is too big to show here.

content/media/urbit-and-the-not-so-dark-future-of-the-internet.mdnew file+10

This diff is too big to show here.

content/media/what-is-urbit.mdnew file+9

This diff is too big to show here.

content/organizations/assemblycapital.mddeleted−10

This diff is too big to show here.

content/organizations/dalten.mddeleted−10

This diff is too big to show here.

content/organizations/holium.mddeleted−10

This diff is too big to show here.

content/organizations/labyrinthdao.mddeleted−10

This diff is too big to show here.

content/organizations/mars-review-of-books.mddeleted−19

This diff is too big to show here.

content/organizations/nativeplanet.mddeleted−10

This diff is too big to show here.

content/organizations/quartus.mddeleted−22

This diff is too big to show here.

content/organizations/reciprocal.mddeleted−13

This diff is too big to show here.

content/organizations/sortug.mddeleted−10

This diff is too big to show here.

content/organizations/third-earth.mddeleted−10

This diff is too big to show here.

content/organizations/tirrel.mddeleted−12

This diff is too big to show here.

content/organizations/tlon.mddeleted−12

This diff is too big to show here.

content/organizations/uqbar.mddeleted−10

This diff is too big to show here.

content/organizations/urbit-foundation.mddeleted−12

This diff is too big to show here.

content/organizations/zorp.mddeleted−10

This diff is too big to show here.

content/overview/interface.mddeleted−42

This diff is too big to show here.

content/overview/people-history.mddeleted−73

This diff is too big to show here.

content/podcasts/2018-11-18_a-digital-republic.mddeleted−19

This diff is too big to show here.

content/podcasts/2019-11-11_urbit.mddeleted−9

This diff is too big to show here.

content/podcasts/2020-03-23_a-new-computing-platform.mddeleted−17

This diff is too big to show here.

content/podcasts/2020-03-23_technology-and-freedom.mddeleted−18

This diff is too big to show here.

content/podcasts/2020-03-23_under-the-hood.mddeleted−15

This diff is too big to show here.

content/podcasts/2020-03-24_urbit-id-and-the-network.mddeleted−13

This diff is too big to show here.

content/podcasts/2020-03-26_built-to-last.mddeleted−21

This diff is too big to show here.

content/podcasts/2020-03-26_urbit-and-bitcoin.mddeleted−15

This diff is too big to show here.

content/podcasts/2020-04-05_tlon-operations.mddeleted−15

This diff is too big to show here.

content/podcasts/2020-11-24_humane-computing.mddeleted−11

This diff is too big to show here.

content/podcasts/2021-02-08_urbit.mddeleted−27

This diff is too big to show here.

content/podcasts/2022-01-21_the-most-beautiful-computer.mddeleted−17

This diff is too big to show here.

content/podcasts/2022-01-26_the-only-dignified-computer.mddeleted−17

This diff is too big to show here.

content/podcasts/2022-02-01_100-year-computer.mddeleted−15

This diff is too big to show here.

content/podcasts/2022-02-15_building-web3-products.mddeleted−20

This diff is too big to show here.

content/podcasts/2022-02-21_most-correct-computer.mddeleted−17

This diff is too big to show here.

content/podcasts/2022-02-27_the-combine.mddeleted−13

This diff is too big to show here.

content/podcasts/2022-03-02_theory-of-the-egirl.mddeleted−17

This diff is too big to show here.

content/podcasts/2022-03-04_nockin.mddeleted−18

This diff is too big to show here.

content/podcasts/2022-03-08_urbit-blockchains.mddeleted−16

This diff is too big to show here.

content/podcasts/2022-03-11_mars-review.mddeleted−12

This diff is too big to show here.

content/podcasts/2022-03-13_alien-invasions.mddeleted−16

This diff is too big to show here.

content/podcasts/2022-03-18_politics-of-urbit-governance.mddeleted−15

This diff is too big to show here.

content/podcasts/2022-03-23_quantum-computing.mddeleted−15

This diff is too big to show here.

content/podcasts/2022-04-07_in-lehmans-terms.mddeleted−12

This diff is too big to show here.

content/podcasts/2022-04-19_robot-opera.mddeleted−11

This diff is too big to show here.

content/podcasts/2022-05-21_diary-of-sam-frank.mddeleted−10

This diff is too big to show here.

content/podcasts/2022-05-22_cincinnati-chili.mddeleted−10

This diff is too big to show here.

content/podcasts/2022-06-04_market-bedshite.mddeleted−10

This diff is too big to show here.

content/podcasts/2022-06-22_software-as-soulcraft.mddeleted−20

This diff is too big to show here.

content/podcasts/2022-06-29_josh-lehman.mddeleted−30

This diff is too big to show here.

content/podcasts/2022-07-04_enable-people-to-run-their-own-servers.mddeleted−116

This diff is too big to show here.

content/podcasts/2022-08-04_middling.mddeleted−10

This diff is too big to show here.

content/podcasts/2022-08-11_probing-questions.mddeleted−14

This diff is too big to show here.

content/podcasts/2022-08-19_the-blind.mddeleted−9

This diff is too big to show here.

content/podcasts/2022-08-26_the-harvard-finance-bro.mddeleted−12

This diff is too big to show here.

content/podcasts/2022-09-14_insanely-bullish-on-urbit.mddeleted−13

This diff is too big to show here.

content/podcasts/2022-09-21_the-worlds-best-crypto-investor.mddeleted−12

This diff is too big to show here.

content/podcasts/2022-09-30-neal-davis-urbit-sentience-daos.mddeleted−33

This diff is too big to show here.

content/podcasts/2022-10-04-reality-maximalism-josh-lehman.mddeleted−9

This diff is too big to show here.

content/podcasts/2022-10-06_urbit-maxi-episode copy.mddeleted−9

This diff is too big to show here.

content/podcasts/2022-12-22_epicenter-ted-blackman-gary-lieberman.mddeleted−11

This diff is too big to show here.

content/podcasts/2023-01-05_lets-get-personal.mddeleted−9

This diff is too big to show here.

content/podcasts/2023-01-19_crypto-metaphysics.mddeleted−9

This diff is too big to show here.

content/podcasts/2023-01-24_reject-triviality.mddeleted−13

This diff is too big to show here.

content/podcasts/2023-01-26_building-future-states-with-nation3.mddeleted−9

This diff is too big to show here.

content/podcasts/2023-01-29_urbit-for-idiots.mddeleted−11

This diff is too big to show here.

content/podcasts/2023-02-09_crypto-narratives-new-and-old.mddeleted−9

This diff is too big to show here.

content/podcasts/2023-02-13_distributed-networked-computing.mddeleted−17

This diff is too big to show here.

content/podcasts/2023-02-23_the-urbit-episode.mddeleted−9

This diff is too big to show here.

content/podcasts/2023-03-09_reclaiming-web-1.mddeleted−9

This diff is too big to show here.

content/podcasts/2023-03-23_how-to-invest-in-web3-like-a-cool-kid.mddeleted−9

This diff is too big to show here.

content/podcasts/2023-03-28_pupusas-volcanoes-and-databases.mddeleted−9

This diff is too big to show here.

content/podcasts/2023-04-03_legacy-internet-new-internet.mddeleted−15

This diff is too big to show here.

content/podcasts/2023-04-06_the-ai-episode.mddeleted−9

This diff is too big to show here.

content/podcasts/2023-04-11_its-urbits-all-the-way-down-with-dachus-tiprel.mddeleted−9

This diff is too big to show here.

content/podcasts/2023-04-14_epicenter-tim-galebach.mddeleted−11

This diff is too big to show here.

content/podcasts/2023-04-20_artificial-qintelligence.mddeleted−9

This diff is too big to show here.

content/podcasts/2023-04-27_hoon-only-legal-ui-with-hastuc-dibtux.mddeleted−11

This diff is too big to show here.

content/podcasts/2023-05-11_full-metal-urbit-with-mopfel-winrux.mddeleted−15

This diff is too big to show here.

content/podcasts/2023-05-18_crypto-takes-flight.mddeleted−11

This diff is too big to show here.

content/privacy.md+24−25

This diff is too big to show here.

content/proposals.mddeleted−93

This diff is too big to show here.

content/reset.mdnew file+109

This diff is too big to show here.

content/rfps.mddeleted−40

This diff is too big to show here.

content/terms-of-service.md → content/terms-of-use.mdrenamed+25−24

This diff is too big to show here.

content/overview/_index.md → content/understanding-urbit/_index.mdrenamed+24−20

This diff is too big to show here.

content/understanding-urbit/interface.mdnew file+71

This diff is too big to show here.

content/understanding-urbit/people-history.mdnew file+104

This diff is too big to show here.

content/understanding-urbit/roadmap.mdnew file+98

This diff is too big to show here.

content/overview/urbit-id.md → content/understanding-urbit/urbit-id.mdrenamed+21−16

This diff is too big to show here.

content/overview/urbit-os.md → content/understanding-urbit/urbit-os.mdrenamed+30−17

This diff is too big to show here.

content/updates/2016-10-6-update.md+72−73

This diff is too big to show here.

content/updates/2016-5-16-roadmap.md+62−63

This diff is too big to show here.

content/updates/2016-7-20-update.md+33−34

This diff is too big to show here.

content/updates/2016-8-30-update.md+47−48

This diff is too big to show here.

content/updates/2017-1-30-update.md+123−124

This diff is too big to show here.

content/updates/2017-10-7-update.md+2−3

This diff is too big to show here.

content/updates/2017-11-14-update.md+34−33

This diff is too big to show here.

content/updates/2017-12-16-update.md+9−11

This diff is too big to show here.

content/updates/2017-12-2-update.md+16−17

This diff is too big to show here.

content/updates/2017-12-22-update.md+12−13

This diff is too big to show here.

content/updates/2017-3-1-update.md+40−41

This diff is too big to show here.

content/updates/2017-4-17-update.md+36−37

This diff is too big to show here.

content/updates/2017-5-11-roadmap.md+70−71

This diff is too big to show here.

content/updates/2017-8-11-update.md+31−30

This diff is too big to show here.

content/updates/2017-9-23-update.md+2−3

This diff is too big to show here.

content/updates/2017-9-29-update.md+2−3

This diff is too big to show here.

content/updates/2018-1-13-update.md+2−3

This diff is too big to show here.

content/updates/2018-1-6-update.md+10−11

This diff is too big to show here.

content/updates/2018-10-12-update.md+12−13

This diff is too big to show here.

content/updates/2018-10-24-update.md+7−8

This diff is too big to show here.

content/updates/2018-11-20-update.md+11−12

This diff is too big to show here.

content/updates/2018-11-6-update.md+7−8

This diff is too big to show here.

content/updates/2018-12-18-update.md+8−9

This diff is too big to show here.

content/updates/2018-2-17-update.md+4−6

This diff is too big to show here.

content/updates/2018-2-24-update.md+9−10

This diff is too big to show here.

content/updates/2018-2-5-update.md+10−10

This diff is too big to show here.

content/updates/2018-2-9-update.md+8−9

This diff is too big to show here.

content/updates/2018-3-24-update.md+11−12

This diff is too big to show here.

content/updates/2018-3-5-update.md+7−8

This diff is too big to show here.

content/updates/2018-4-14-update.md+15−16

This diff is too big to show here.

content/updates/2018-4-7-update.md+8−9

This diff is too big to show here.

content/updates/2018-5-16-update.md+13−13

This diff is too big to show here.

content/updates/2018-5-23-update.md+11−11

This diff is too big to show here.

content/updates/2018-5-29-update.md+2−3

This diff is too big to show here.

content/updates/2018-5-30-update.md+10−11

This diff is too big to show here.

content/updates/2018-6-14-update.md+12−13

This diff is too big to show here.

content/updates/2018-6-21-update.md+12−12

This diff is too big to show here.

content/updates/2018-6-6-update.md+12−13

This diff is too big to show here.

content/updates/2018-7-13-update.md+11−12

This diff is too big to show here.

content/updates/2018-7-20-update.md+20−20

This diff is too big to show here.

content/updates/2018-7-3-update.md+13−13

This diff is too big to show here.

content/updates/2018-7-30-update.md+18−18

This diff is too big to show here.

content/updates/2018-8-23-update.md+15−16

This diff is too big to show here.

content/updates/2018-8-30-update.md+10−11

This diff is too big to show here.

content/updates/2018-8-8-update.md+17−18

This diff is too big to show here.

content/updates/2018-9-11-update.md+16−17

This diff is too big to show here.

content/updates/2019-11-06-update.md+5−7

This diff is too big to show here.

content/updates/2019-12-06-update.md+9−8

This diff is too big to show here.

content/updates/2019-2-11-update.md+6−8

This diff is too big to show here.

content/updates/2019-2-25-update.md+5−7

This diff is too big to show here.

content/updates/2019-2-26-network-update.md+2−4

This diff is too big to show here.

content/updates/2019-2-4-update.md+7−9

This diff is too big to show here.

content/updates/2019-3-11-update.md+6−8

This diff is too big to show here.

content/updates/2019-3-27-update.md+4−6

This diff is too big to show here.

content/updates/2019-3-4-update.md+5−7

This diff is too big to show here.

content/updates/2019-4-11-update.md+5−7

This diff is too big to show here.

content/updates/2019-5-10-update.md+3−4

This diff is too big to show here.

content/updates/2019-5-17-update.md+3−4

This diff is too big to show here.

content/updates/2019-5-31-update.md+6−7

This diff is too big to show here.

content/updates/2019-6-14-update.md+7−10

This diff is too big to show here.

content/updates/2019-7-25-update.md+5−9

This diff is too big to show here.

content/updates/2020-02-06-update.md+12−17

This diff is too big to show here.

content/updates/2020-04-04-update.md+7−7

This diff is too big to show here.

content/updates/2020-06-15-update.md+25−19

This diff is too big to show here.

content/updates/2020-07-27-update.md+7−5

This diff is too big to show here.

content/updates/2020-09-30-update.md+2−2

This diff is too big to show here.

content/updates/2020-10-29-update.md+2−2

This diff is too big to show here.

content/updates/2020-12-01-update.md+2−2

This diff is too big to show here.

content/updates/2021-01-15-update.md+2−2

This diff is too big to show here.

content/updates/2021-02-19-update.md+2−2

This diff is too big to show here.

content/updates/2021-04-01-update.md+2−2

This diff is too big to show here.

content/updates/2021-05-05-update.md+2−2

This diff is too big to show here.

content/updates/2021-06-16-update.md+2−6

This diff is too big to show here.

content/updates/_index.mdnew file+6

This diff is too big to show here.

content/using/_index.mdnew file+33

This diff is too big to show here.

content/using/id/_index.mdnew file+33

This diff is too big to show here.

content/using/id/bridge-troubleshooting.mdnew file+37

This diff is too big to show here.

content/using/id/creating-an-invite-pool.mdnew file+106

This diff is too big to show here.

content/using/id/guide-to-breaches.mdnew file+84

This diff is too big to show here.

content/using/id/overview.mdnew file+71

This diff is too big to show here.

content/using/id/using-bridge.mdnew file+113

This diff is too big to show here.

content/using/os/_index.mdnew file+36

This diff is too big to show here.

content/using/os/filesystem.mdnew file+397

This diff is too big to show here.

content/using/os/getting-started.mdnew file+337

This diff is too big to show here.

content/using/os/messaging.mdnew file+254

This diff is too big to show here.

content/using/os/s3.mdnew file+34

This diff is too big to show here.

content/using/os/shell.mdnew file+413

This diff is too big to show here.

content/using/os/ship-troubleshooting.mdnew file+213

This diff is too big to show here.

content/using/os/stars-and-galaxies.mdnew file+46

This diff is too big to show here.

content/using/running/_index.mdnew file+16

This diff is too big to show here.

content/using/running/hosting.mdnew file+187

This diff is too big to show here.

content/voting-instructions.md+1−1

This diff is too big to show here.

gnosis-safe.mddeleted−48

This diff is too big to show here.

lib/buildGlossary.jsdeleted−59

This diff is too big to show here.

lib/buildPageTree.jsdeleted−111

This diff is too big to show here.

lib/cache.js+8−25

This diff is too big to show here.

lib/constants.js+7−128

This diff is too big to show here.

lib/glossary.jsnew file+6396

This diff is too big to show here.

lib/hooks.js+1−60

This diff is too big to show here.

lib/lib.js+284−187

This diff is too big to show here.

lib/rss.jsdeleted−95

This diff is too big to show here.

next.config.js+10−10

This diff is too big to show here.

package-lock.json+5895−4309

This diff is too big to show here.

package.json+26−40

This diff is too big to show here.

pages/404.js+4−13

This diff is too big to show here.

pages/[slug].jsdeleted−48

This diff is too big to show here.

pages/_app.js+6−20

This diff is too big to show here.

pages/api/dev-search.jsdeleted−8

This diff is too big to show here.

pages/api/ops-search.jsdeleted−8

This diff is too big to show here.

pages/api/roadmap-search.jsdeleted−8

This diff is too big to show here.

pages/api/search.js+4−39

This diff is too big to show here.

pages/api/sigil.jsdeleted−60

This diff is too big to show here.

pages/api/urbit-org-search.jsdeleted−45

This diff is too big to show here.

pages/applications/[[...application]].jsdeleted−206

This diff is too big to show here.

pages/applications/submit.jsdeleted−143

This diff is too big to show here.

pages/articles/[slug].jsdeleted−84

This diff is too big to show here.

pages/bitcoin.jsdeleted−98

This diff is too big to show here.

pages/blog.js+49−92

This diff is too big to show here.

pages/blog/[slug].js+83−41

This diff is too big to show here.

pages/bounties.jsnew file+17

This diff is too big to show here.

pages/campus/[[...slug]].jsdeleted−312

This diff is too big to show here.

pages/communities/[slug].jsdeleted−87

This diff is too big to show here.

pages/community/[[...slug]].jsnew file+126

This diff is too big to show here.

pages/decentralized-discord.jsdeleted−291

This diff is too big to show here.

pages/docs/[[...slug]].jsnew file+160

This diff is too big to show here.

pages/ecosystem/index.jsdeleted−416

This diff is too big to show here.

pages/ecosystem/spotlight/[slug].jsdeleted−69

This diff is too big to show here.

pages/events.js+82−149

This diff is too big to show here.

pages/events/[slug].js+117−116

This diff is too big to show here.

pages/getinvolved.jsdeleted−58

This diff is too big to show here.

pages/getting-started/[[...slug]].js+65−249

This diff is too big to show here.

pages/grants.js+206−331

This diff is too big to show here.

pages/grants/[slug].js+55−207

This diff is too big to show here.

pages/grants/apprenticeships.jsdeleted−29

This diff is too big to show here.

pages/grants/bounties.jsdeleted−28

This diff is too big to show here.

pages/grants/proposals.jsdeleted−29

This diff is too big to show here.

pages/grants/rfps.jsdeleted−29

This diff is too big to show here.

pages/groups/[[...group]].jsdeleted−136

This diff is too big to show here.

pages/groups/submit.jsdeleted−152

This diff is too big to show here.

pages/ids/[id].jsdeleted−241

This diff is too big to show here.

pages/ids/submit.jsdeleted−170

This diff is too big to show here.

pages/index.js+242−348

This diff is too big to show here.

pages/marketplaces/[slug].jsdeleted−84

This diff is too big to show here.

pages/media.jsnew file+47

This diff is too big to show here.

pages/media/[slug].jsnew file+141

This diff is too big to show here.

pages/organizations/[slug].jsdeleted−179

This diff is too big to show here.

pages/overview/[[...slug]].jsdeleted−147

This diff is too big to show here.

pages/podcasts/[slug].jsdeleted−84

This diff is too big to show here.

pages/privacy.jsnew file+17

This diff is too big to show here.

pages/terms-of-service.jsnew file+21

This diff is too big to show here.

pages/trial-over.jsdeleted−35

This diff is too big to show here.

pages/trial.jsdeleted−129

This diff is too big to show here.

pages/understanding-urbit/[[...slug]].jsnew file+135

This diff is too big to show here.

pages/updates.jsdeleted−87

This diff is too big to show here.

pages/updates/[slug].jsdeleted−126

This diff is too big to show here.

pages/using/[[...slug]].jsnew file+157

This diff is too big to show here.

pages/voting-instructions.jsnew file+21

This diff is too big to show here.

patches/prismjs+1.24.1.patchnew file+42

This diff is too big to show here.

public/images/android-chrome-192x192.pngdeleted

Binary file not shown.

public/images/android-chrome-512x512.pngdeleted

Binary file not shown.

public/images/apple-touch-icon.pngdeleted

Binary file not shown.

public/images/favicon-16x16.pngdeleted

Binary file not shown.

public/images/favicon-32x32.pngdeleted

Binary file not shown.

public/images/favicon.icodeleted

Binary file not shown.

public/images/planet-l2-claim.gifdeleted

Binary file not shown.

public/images/planet-l2-migration.gifdeleted

Binary file not shown.

public/images/planet-l2-transactions.pngdeleted

Binary file not shown.

public/images/sound.svgdeleted−5

This diff is too big to show here.

scripts/date_to_string_upgrade.jsdeleted−43

This diff is too big to show here.

scripts/event_date_upgrade.jsdeleted−51

This diff is too big to show here.

styles/globals.cssnew file+191

This diff is too big to show here.

styles/markdown.module.cssnew file+92

This diff is too big to show here.

styles/prism.cssnew file+170

This diff is too big to show here.

tailwind.config.js+47−14

This diff is too big to show here.

vercel.json+668−112

This diff is too big to show here.

yarn.locknew file+1865

This diff is too big to show here.