Urbit Docs
  • What is Urbit?
  • Get on Urbit
  • Build on Urbit
    • Contents
    • Environment Setup
    • Hoon School
      • 1. Hoon Syntax
      • 2. Azimuth (Urbit ID)
      • 3. Gates (Functions)
      • 4. Molds (Types)
      • 5. Cores
      • 6. Trees and Addressing
      • 7. Libraries
      • 8. Testing Code
      • 9. Text Processing I
      • 10. Cores and Doors
      • 11. Data Structures
      • 12. Type Checking
      • 13. Conditional Logic
      • 14. Subject-Oriented Programming
      • 15. Text Processing II
      • 16. Functional Programming
      • 17. Text Processing III
      • 18. Generic and Variant Cores
      • 19. Mathematics
    • App School I
      • 1. Arvo
      • 2. The Agent Core
      • 3. Imports and Aliases
      • 4. Lifecycle
      • 5. Cards
      • 6. Pokes
      • 7. Structures and Marks
      • 8. Subscriptions
      • 9. Vanes
      • 10. Scries
      • 11. Failure
      • 12. Next Steps
      • Appendix: Types
    • App School II (Full-Stack)
      • 1. Types
      • 2. Agent
      • 3. JSON
      • 4. Marks
      • 5. Eyre
      • 6. React app setup
      • 7. React app logic
      • 8. Desk and glob
      • 9. Summary
    • Core Academy
      • 1. Evaluating Nock
      • 2. Building Hoon
      • 3. The Core Stack
      • 4. Arvo I: The Main Sequence
      • 5. Arvo II: The Boot Sequence
      • 6. Vere I: u3 and the Serf
      • 7. Vere II: The Loom
      • 8. Vanes I: Behn, Dill, Kahn, Lick
      • 9. Vanes II: Ames
      • 10. Vanes III: Eyre, Iris
      • 11. Vanes IV: Clay
      • 12. Vanes V: Gall and Userspace
      • 13. Vanes VI: Khan, Lick
      • 14. Vanes VII: Jael, Azimuth
    • Runtime
      • U3
      • Conn.c Guide
      • How to Write a Jet
      • API Overview by Prefix
      • C in Urbit
      • Cryptography
      • Land of Nouns
    • Tools
      • Useful Links
      • JS Libraries
        • HTTP API
      • Docs App
        • File Format
        • Index File
        • Suggested Structure
    • Userspace
      • Command-Line App Tutorial
      • Remote Scry
      • Unit Tests
      • Software Distribution
        • Software Distribution Guide
        • Docket File
        • Glob
      • Examples
        • Building a CLI App
        • Debugging Wrapper
        • Host a Website
        • Serving a JS Game
        • Ship Monitoring
        • Styled Text
  • Urbit ID
    • What is Urbit ID?
    • Azimuth Data Flow
    • Life and Rift
    • Urbit HD Wallet
    • Advanced Azimuth Tools
    • Custom Roller Tutorial
    • Azimuth.eth Reference
    • Ecliptic.eth Reference
    • Layer 2
      • L2 Actions
      • L2 Rollers
      • L2 Roller HTTP RPC-API
      • L2 Transaction Format
  • Urbit OS
    • What is Urbit OS?
    • Base
      • Hood
      • Threads
        • Basics Tutorial
          • Bind
          • Fundamentals
          • Input
          • Output
          • Summary
        • HTTP API Guide
        • Spider API Reference
        • Strandio Reference
        • Examples
          • Child Thread
          • Fetch JSON
          • Gall
            • Poke Thread
            • Start Thread
            • Stop Thread
            • Take Facts
            • Take Result
          • Main-loop
          • Poke Agent
          • Scry
          • Take Fact
    • Kernel
      • Arvo
        • Cryptography
        • Move Trace
        • Scries
        • Subscriptions
      • Ames
        • Ames API Reference
        • Ames Cryptography
        • Ames Data Types
        • Ames Scry Reference
      • Behn
        • Behn API Reference
        • Behn Examples
        • Behn Scry Reference
      • Clay
        • Clay API Reference
        • Clay Architecture
        • Clay Data Types
        • Clay Examples
        • Clay Scry Reference
        • Filesystem Hierarchy
        • Marks
          • Mark Examples
          • Using Marks
          • Writing Marks
        • Using Clay
      • Dill
        • Dill API Reference
        • Dill Data Types
        • Dill Scry Reference
      • Eyre
        • EAuth
        • Eyre Data Types
        • Eyre External API
        • Eyre Internal API
        • Eyre Scry Reference
        • Low-Level Eyre Guide
        • Noun channels
      • Gall
        • Gall API Reference
        • Gall Data Types
        • Gall Scry Reference
      • Iris
        • Iris API Reference
        • Iris Data Types
        • Iris Example
      • Jael
        • Jael API Reference
        • Jael Data Types
        • Jael Examples
        • Jael Scry Reference
      • Khan
        • Khan API Reference
        • Khan Data Types
        • Khan Example
      • Lick
        • Lick API Reference
        • Lick Guide
        • Lick Examples
        • Lick Scry Reference
  • Hoon
    • Why Hoon?
    • Advanced Types
    • Arvo
    • Auras
    • Basic Types
    • Cheat Sheet
    • Cryptography
    • Examples
      • ABC Blocks
      • Competitive Programming
      • Emirp
      • Gleichniszahlenreihe
      • Islands
      • Luhn Number
      • Minimum Path Sum
      • Phone Letters
      • Restore IP
      • Rhonda Numbers
      • Roman Numerals
      • Solitaire Cipher
      • Water Towers
    • Generators
    • Hoon Errors
    • Hoon Style Guide
    • Implementing an Aura
    • Irregular forms
    • JSON
    • Limbs and wings
      • Limbs
      • Wings
    • Mips (Maps of Maps)
    • Parsing Text
    • Runes
      • | bar · Cores
      • $ buc · Structures
      • % cen · Calls
      • : col · Cells
      • . dot · Nock
      • / fas · Imports
      • ^ ket · Casts
      • + lus · Arms
      • ; mic · Make
      • ~ sig · Hints
      • = tis · Subject
      • ? wut · Conditionals
      • ! zap · Wild
      • Constants (Atoms and Strings)
      • --, == · Terminators
    • Sail (HTML)
    • Serialization
    • Sets
    • Standard Library
      • 1a: Basic Arithmetic
      • 1b: Tree Addressing
      • 1c: Molds and Mold-Builders
      • 2a: Unit Logic
      • 2b: List Logic
      • 2c: Bit Arithmetic
      • 2d: Bit Logic
      • 2e: Insecure Hashing
      • 2f: Noun Ordering
      • 2g: Unsigned Powers
      • 2h: Set Logic
      • 2i: Map Logic
      • 2j: Jar and Jug Logic
      • 2k: Queue Logic
      • 2l: Container from Container
      • 2m: Container from Noun
      • 2n: Functional Hacks
      • 2o: Normalizing Containers
      • 2p: Serialization
      • 2q: Molds and Mold-Builders
      • 3a: Modular and Signed Ints
      • 3b: Floating Point
      • 3c: Urbit Time
      • 3d: SHA Hash Family
      • 3e: AES encryption (Removed)
      • 3f: Scrambling
      • 3g: Molds and Mold-Builders
      • 4a: Exotic Bases
      • 4b: Text Processing
      • 4c: Tank Printer
      • 4d: Parsing (Tracing)
      • 4e: Parsing (Combinators)
      • 4f: Parsing (Rule-Builders)
      • 4g: Parsing (Outside Caller)
      • 4h: Parsing (ASCII Glyphs)
      • 4i: Parsing (Useful Idioms)
      • 4j: Parsing (Bases and Base Digits)
      • 4k: Atom Printing
      • 4l: Atom Parsing
      • 4m: Formatting Functions
      • 4n: Virtualization
      • 4o: Molds
      • 5a: Compiler Utilities
      • 5b: Macro Expansion
      • 5c: Compiler Backend & Prettyprinter
      • 5d: Parser
      • 5e: Molds and mold builders
      • 5f: Profiling support
    • Strings
    • The Engine Pattern
    • Udon (Markdown-esque)
    • Vases
    • Zuse
      • 2d(1-5): To JSON, Wains
      • 2d(6): From JSON
      • 2d(7): From JSON (unit)
      • 2e(2-3): Print & Parse JSON
      • 2m: Ordered Maps
  • Nock
    • What is Nock?
    • Decrement
    • Definition
    • Fast Hints and Jets
    • Implementations
    • Specification
  • User Manual
    • Contents
    • Running Urbit
      • Cloud Hosting
      • Home Servers
      • Runtime Reference
      • Self-hosting S3 Storage with MinIO
    • Urbit ID
      • Bridge Troubleshooting
      • Creating an Invite Pool
      • Get an Urbit ID
      • Guide to Factory Resets
      • HD Wallet (Master Ticket)
      • Layer 2 for planets
      • Layer 2 for stars
      • Proxies
      • Using Bridge
    • Urbit OS
      • Basics
      • Configuring S3 Storage
      • Dojo Tools
      • Filesystem
      • Shell
      • Ship Troubleshooting
      • Star and Galaxy Operations
      • Updates
Powered by GitBook

GitHub

  • Urbit ID
  • Urbit OS
  • Runtime

Resources

  • YouTube
  • Whitepaper
  • Awesome Urbit

Contact

  • X
  • Email
  • Gather
On this page
  • bitt
  • boat
  • boar
  • fans
  • bowl
  • dude
  • gill
  • load
  • scar
  • suss
  • well
  • deal
  • unto
  • verb
  • coop
  • agent
  • step:agent
  • card:agent
  • note:agent
  • task:agent
  • gift:agent
  • sign:agent
  • form:agent
Edit on GitHub
  1. Urbit OS
  2. Kernel
  3. Gall

Gall Data Types

This document describes the data types for Gall defined in lull.hoon.

bitt

Incoming subscriptions.

+$  bitt  (map duct (pair ship path))

This is the structure Gall uses to keep track of incoming subscriptions for a Gall agent. The sup field of a bowl contains the bitt for our agent.


boat

Outgoing subscriptions.

+$  boat  (map [=wire =ship =term] [acked=? =path])

This is the structure Gall uses to keep track of subscriptions our agent has initiated. The wex field of a bowl contails the boat for that agent.

The wire field is the wire which sign:agents will come in on. The ship and term fields are the ship and the name of the agent to which our agent has subscribed.

The acked field is %.y if they have acknowledged our subscription request with a %watch-ack, and %.n if they have not. The path field is the path on the other agent to which our agent has subscribed.


boar

Subscription nonces.

+$  boar  (map [=wire =ship =term] nonce=@)

Gall uses this to keep track of nonces for subscriptions.


fans

Revisions for a remote scry file published at a particular path.

+$  fans  ((mop @ud (pair @da (each page @uvI))) lte)

The mop is organized by file revision number. Each value includes the date-time of the entry, and then either the file as a page or just the @uvI hash of the file if it has been tombstoned.


bowl

Additional agent state.

+$  bowl                                              ::  standard app state
  $:  $:  our=ship                                    ::  host
          src=ship                                    ::  guest
          dap=term                                    ::  agent
          sap=path                                    ::  provenance
      ==                                              ::
      $:  wex=boat                                    ::  outgoing subs
          sup=bitt                                    ::  incoming subs
          sky=(map path fans)                         ::  scry bindings
      ==                                              ::
      $:  act=@ud                                     ::  change number
          eny=@uvJ                                    ::  entropy
          now=@da                                     ::  current time
          byk=beak                                    ::  load source
  ==  ==                                              ::

A bowl is given to the agent core each time an event comes in. The fields are as follows:

  • our: Our ship.

  • src: The ship from which the current request originated.

  • dap: The name of our agent.

  • wex: Outgoing subscriptions. That is, subscriptions our agent has initiated. See the boat section for details of the type.

  • sup: Incoming subscriptions. That is, subscriptions others have made to our agent. See the bitt section for details of the type.

  • sky: Remote scry bindings. A map from binding paths to a fans, an ordered map of files by revision number. Tombstoned files have an @uvI hash rather than page.

  • act: The total number of moves our agent has processed so far.

  • eny: 512 bits of entropy.

  • now: The current date-time.

  • byk: The ship, desk and case in Clay from which this agent was loaded. The case will be [%da @da] where the @da is the when the agent was loaded. A beak is a triple of [ship desk case].


dude

Agent name.

+$  dude  term

gill

A general contact.

+$  gill  (pair ship term)

A pair of the ship and agent name.


load

Loadout.

+$  load  (list [=dude =beak =agent])

The dude is the agent name, the beak is the ship/desk/case in which it resides, and the agent is the built agent itself. Clay passes this to Gall when it builds or modifies the state of running agents.


scar

Opaque duct - used internally.

+$  scar
  $:  p=@ud
      q=(map duct bone)
      r=(map bone duct)
  ==

suss

Configuration report.

+$  suss  (trel dude @tas @da)

well

Desk and agent.

+$  well  (pair desk term)

deal

An agent task or raw poke.

+$  deal
  $%  [%raw-poke =mark =noun]
      task:agent
  ==

The additional %raw-poke is for pokes which haven't yet been converted to an ordinary %poke by molding the noun with the specified mark core. This structure is passed around on the kernel level, it would not be used in userspace.


unto

An agent gift or a raw fact.

+$  unto
  $%  [%raw-fact =mark =noun]
      sign:agent
  ==

The additional %raw-fact is for facts which haven't yet been converted to an ordinary %fact by molding the noun it with the specified mark core. This structure is passed around on the kernel level, it would not be used in userspace.


verb

Verbosity flags.

+$  verb  ?(%odd)

Flags to set Gall verbosity. Currently only %odd for unusual errors.


coop

Verbosity flags.

+$  coop  spur

A security context for remote scries.


agent

++  agent
  =<  form
  |%

Container for Gall agent types. The most significant arm is form:agent, which specifies the structure of the agent itself. There are also some additional structures defined here, mostly defining the kinds of messages agents can send. The different arms of the core in agent are considered separately below.

step:agent

+$  step  (quip card form)

A cell of card:agents to be sent and a new agent state. This is the type returned by most arms of an agent. A (quip a b) is the same as [(list a) b], it's just a more convenient way to specify it.


card:agent

+$  card  (wind note gift)

An effect - typically a message to be sent to another agent or vane. A list of these are returned by most agent arms along with a new state in a step:agent. A wind is the following:

++  wind
  |$  [a b]
  $%  [%pass p=path q=a]
      [%slip p=a]
      [%give p=b]
  ==

Gall will not allow a %slip, so in practice a card will be one of:

  • [%pass path note]

  • [%give gift]

For %pass, p specifies the wire on which a response should be returned. See note:agent and gift:agent below for details of their types.


note:agent

+$  note
  $%  [%agent [=ship name=term] =task]
      [%arvo note-arvo]
      [%pyre =tang]
  ::
      [%grow =spur =page]
      [%tomb =case =spur]
      [%cull =case =spur]
  ==

The type for messages initiated by our agent. This is opposed to gift:agent, which is the type for responding to other agents or vanes, or for sending out updates to subscribers. The three cases are:

  • %agent: Poke another agent, subscribe to another agent, or cancel a subscription to another agent. The ship and name fields are the ship and agent to which the task should be sent. The task is the request itself, see task:agent below for its possible types.

  • %arvo: Pass a task to a vane. The type of a note-arvo is:

    +$  note-arvo
      $~  [%b %wake ~]
      $%  [%a task:ames]
          [%b task:behn]
          [%c task:clay]
          [%d task:dill]
          [%e task:eyre]
          [%g task:gall]
          [%i task:iris]
          [%j task:jael]
          [%k task:khan]
          [%$ %whiz ~]
          [@tas %meta vase]
      ==

    You can refer to the /sys/lull.hoon source code for all the possible vane tasks, or see each vane's API Reference section in the Arvo documentation

  • %pyre: This is for aborting side-effects initiated during agent installation. The tang is an error message.

  • %grow/%tomb/%cull: These are used for publishing and managing data available for remote scries. For more information, see the remote scries guide.

A note:agent is always wrapped in a %pass card:agent.


task:agent

The types of messages initiated by our agent and sent to another agent.

+$  task
  $%  [%watch =path]
      [%watch-as =mark =path]
      [%leave ~]
      [%poke =cage]
      [%poke-as =mark =cage]
  ==

This is in contrast to gift:agents, which are responses to incoming messages from agents or updates to agents already subscribed. The five kinds of task:agent are:

  • %watch: Subscribe to path on the target ship and agent.

  • %watch-as: Same as %watch, except you ask the target's Gall to convert subscription updates to the mark you specified rather than just giving you the mark produced by the agent.

  • %leave: Cancel subscription. The particular subscription to cancel will be determined by the wire given in the p field of the containing %pass card:agent.

  • %poke: Poke the target ship and agent with the given cage, which is a pair of [mark vase].

  • %poke-as: Same as %poke, except the cage will be converted to the specified mark before sending.

A task:agent is always wrapped in a %pass card:agent.


gift:agent

The types of messages our agent can either send in response to messages from other agents, or send to subscribed agents.

+$  gift
  $%  [%fact paths=(list path) =cage]
      [%kick paths=(list path) ship=(unit ship)]
      [%watch-ack p=(unit tang)]
      [%poke-ack p=(unit tang)]
  ==

This is in contrast to task:agents, which are messages to other agents our agent initiates rather than sends in response. The four kinds of gift:agent are:

  • %fact: An update to existing subscribers. The paths field specifies which subscription paths the update should go out to. The cage is the data, and is a [mark vase].

  • %kick: Kick subscriber, ending their subscription. The paths field specifies which paths the subscriber should be kicked from, and the ship field specifies the ship to kick. If the ship field is null, all subscribers on the specified paths are kicked. Gall will automatically remove the subscription from our agent's bitt (inbound subscription map), and subscriber will no longer receive updates on the paths in question.

  • %watch-ack: Acknowledge a subscription request. If p is null, it's an ack (positive acknowledgement), and if p is non-null, it's a nack (negative acknowledgement). Simply crashing will caused Gall to nack a subscription request, and not crashing but not explicitly producing a %watch-ack gift will cause Gall to ack a subscription request. Therefore, you'd typically only explicitly produce a %watch-ack gift if you wanted to nack a subscription request with a custom error in the tang.

  • %poke-ack: Acknowledge a poke. If p is null, it's an ack, and if p is non-null, it's a nack. Simply crashing will cause Gall to nack a poke, and not crashing but not explicitly producing a %poke-ack gift will cause Gall to ack a poke. Therefore, you'd typically only explicitly produce a %poke-ack gift if you wanted to nack a poke with a custom error in the tang.

A gift:agent is always wrapped in a %give card:agent.


sign:agent

A sign is like a gift:agent but it's something that comes in to our agent from another agent rather than something we send out.

+$  sign
  $%  [%poke-ack p=(unit tang)]
      [%watch-ack p=(unit tang)]
      [%fact =cage]
      [%kick ~]
  ==

The possible types are:

  • %poke-ack: Another agent has acked (positively acknowledged) or nacked (negatively acknowledged) a %poke task:agent we previously sent. It's an ack if p is null and a nack if p is non-null. The tang contains an error or traceback if it's a nack.

  • %watch-ack: Another agent has acked or nacked a %watch task:agent (subscription request) we previously sent. It's an ack if p is null and a nack if p is non-null. The tang contains an error or traceback if it's a nack. If it's a nack, Gall will automatically remove the subscription from our agent's boat (outbound subscription map).

  • %fact: An update from another agent to which we've previously subscribed with a %watch task:agent (subscription request). The cage contains the data, and is a [mark vase].

  • %kick: Our subscription to another agent has been ended, and we'll no longer receive updates. A %kick may be intentional, but it may also happen due to certain network conditions or other factors. As a result, it's best to try and resubscribe with another %watch task:agent, and if they nack the %watch, we can conclude it was intentional and give up.


form:agent

This defines the structure of the agent itself.

++  form
  $_  ^|
  |_  bowl
  ++  on-init
    *(quip card _^|(..on-init))
  ::
  ++  on-save
    *vase
  ::
  ++  on-load
    |~  old-state=vase
    *(quip card _^|(..on-init))
  ::
  ++  on-poke
    |~  [mark vase]
    *(quip card _^|(..on-init))
  ::
  ++  on-watch
    |~  path
    *(quip card _^|(..on-init))
  ::
  ++  on-leave
    |~  path
    *(quip card _^|(..on-init))
  ::
  ++  on-peek
    |~  path
    *(unit (unit cage))
  ::
  ++  on-agent
    |~  [wire sign]
    *(quip card _^|(..on-init))
  ::
  ++  on-arvo
    |~  [wire sign-arvo]
    *(quip card _^|(..on-init))
  ::
  ++  on-fail
    |~  [term tang]
    *(quip card _^|(..on-init))
  --
--

The agent is a door with a bowl as its sample and exactly ten arms. Below we'll describe each arm briefly.

on-init

  • Accepts: Nothing.

  • Produces: step:agent

This arm is called when the agent is initially installed.

on-poke

  • Accepts: cage

  • Produces: step:agent

This arm is called when another agent pokes our agent.

on-watch

  • Accepts: path

  • Produces: step:agent

This arm is called when another agent subscribes to our agent.

on-leave

  • Accepts: path

  • Produces: step:agent

This arm is called when another agent unsubscribes from a subscription path on our agent.

on-peek

  • Accepts: path

  • Produces: (unit (unit cage))

This arm is called when a scry is performed on our agent.

on-agent

  • Accepts: [wire sign:agent]

  • Produces: step:agent

This arm is called when another agent give our agent a sign:agent.

on-arvo

  • Accepts: [wire sign-arvo]

  • Produces: step:agent

This arm is called when a vane gives our agent a gift. A sign-arvo is:

+$  sign-arvo
  $%  [%ames gift:ames]
      $:  %behn
          $%  gift:behn
              $>(%wris gift:clay)
              $>(%writ gift:clay)
              $>(%mere gift:clay)
              $>(%unto gift:gall)
          ==
      ==
      [%clay gift:clay]
      [%dill gift:dill]
      [%eyre gift:eyre]
      [%gall gift:gall]
      [%iris gift:iris]
      [%jael gift:jael]
      [%khan gift:khan]
  ==

You can refer to the /sys/lull.hoon source code, or the API Reference of each vane in the Arvo documentation.

on-fail

  • Accepts: [term tang]

  • Produces: step:agent

This arm is called if certain errors occur in Gall, such as if our agent tries to create a duplicate subscription.


PreviousGall API ReferenceNextGall Scry Reference

Last updated 1 day ago