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
  • Messaging Tasks
  • %hear
  • %heed
  • %jilt
  • %plea
  • System Tasks
  • %born
  • %init
  • %sift
  • %snub
  • %spew
  • %stir
  • %vega
  • Remote scry tasks
  • %keen
  • %chum
  • %yawn
  • %wham
Edit on GitHub
  1. Urbit OS
  2. Kernel
  3. Ames

Ames API Reference

In this document we describe the public interface for Ames. Namely, we describe each task that Ames can be %passed, and which gift(s) Ames can %give in return.

Some tasks appear to have more than one arm associated to them, e.g. there are four +on-hear arms. We denote this where it occurs, but always refer to the +on-hear:event-core arm.

Ames tasks can be naturally divided into three categories: messaging tasks, system/lifecycle tasks, and remote scry tasks.

Messaging Tasks

%hear

[%hear =lane =blob]

%hear handles raw packet receipt.

This task only ever originates from Unix. It does the initial processing of a packet, namely by passing the raw packet information to +decode-packet which deserializes the packet and giving that data and the origin of the packet to +on-hear-packet, which begins the transformation of the packet into a new event in the form of a +event-core.

There are multiple +on-hear arms in ames.hoon. Here we refer to +on-hear:event-core, as that is the one called by a %hear task. The other ones are used primarily for ack and nack processing, or receiving message fragments.

%hear takes in a $blob, which is essentially a large atom (around 1kB or less) that is the raw data of the message, and a $lane, which is the origin of the message (typically an IP address).

Returns

%hear can trigger a number of possible returns. It can trigger the release of zero or more additional packets via %send gifts. It may also trigger a %boon or %plea gift (collectively referred to as a %memo within Ames) to a local vane in the case of a completed message.


%heed

[%heed =ship]

A vane can pass Ames a %heed task to request Ames track a peer's responsiveness. If our %boons to it start backing up locally, Ames will give a %clog back to the requesting vane containing the unresponsive peer's Urbit address.

Stop tracking a peer by sending Ames a %jilt task.

The ship field specifies the peer to be tracked.

Returns

If the ship is indeed being unresponsive, as measured by backed up %boons, Ames will give a %clog gift to the requesting vane containing the unresponsive peer's urbit address.


%jilt

[%jilt =ship]

%jilt stops tracking a potentially unresponsive peer that was previously being tracked as a result of the %heed task.

There are two +on-jilt arms, this task utilizes +on-hear:event-core.

The ship field specifies the peer we want to stop tracking.

Returns

This task returns no gifts.


%plea

[%plea =ship =plea:ames]

%plea is the task used to instruct Ames to send a message. It extends the %pass/%give semantics across the network. As such, it is the most fundamental task in Ames and the primary reason for its existence.

Ames also passes a %plea note to another vane when it receives a message on a "forward flow" from a peer, originally passed from one of the peer's vanes to the peer's Ames.

Ultimately %plea causes %send gift(s) to be sent to Unix, which tells Unix to send packets. In terms of %pass/%give semantics, this is in response to the %born task, which came along the Unix duct, rather than a response to the %plea.

A %plea task takes in the ship the plea is addressed to, and a $plea.

Returns

This task returns no gifts.


System Tasks

%born

[%born ~]

Each time you start your Urbit, the Arvo kernel calls the %born task for Ames.

Returns

In response to a %born task, Ames %gives Jael a %turf gift.

The duct along which %born comes is Ames' only duct to Unix, so %send gifts (which are instructions for Unix to send a packet) are also returned in response to %born.


%init

[%init ~]

%init is called a single time during the very first boot process, immediately after the larval stage is completed. This initializes the vane. Jael is initialized first, followed by other vanes such as Ames.

In response to receiving the %init task, Ames subscribes to the information contained by Jael.

Returns

=~  (emit duct %pass /turf %j %turf ~)
    (emit duct %pass /private-keys %j %private-keys ~)

%init sends two moves that subscribe to %turf and %private-keys in Jael.


%sift

[%sift ships=(list ship)]

This task filters debug output by ship. This task is used internally when the |ames/sift hood generator is run from the dojo.

The ships field specifies the ships for which debug output is desired.

Returns

This task returns no gifts.


%snub

[%snub form=?(%allow %deny) ships=(list ship)]

This task blacklists/whitelists ships in Ames.

The form field specifies whether the given ships should be blacklisted or whitelisted. The ships field are the ships to blacklist/whitelist.

The Ames snub settings can only have one form at a time: an %allow list or %deny list. If an %allow form is set, packets from all ships not on the list will be blocked. If a %deny form is set, packets from any ship on the list will be blocked, and all others allowed.

Note: a %snub task overrides the existing snub list and form entirely, it does not merely add/remove ships from the existing list.

If you just want to add/remove a ship from an existing blacklist/whitelist, you'll need to first scry out the existing snub settings, make your changes, and send the whole modified list and form in a new %snub task.

Returns

This task returns no gifts.


%spew

[%spew veb=(list verb)]

Sets verbosity toggles on debug output. This task is used internally when the |ames/verb hood generator is run from the dojo.

%spew takes in a list of $verb, which are verbosity flags for Ames.

%spew flips each toggle given in veb.

Returns

This task returns no gifts.


%stir

[%stir arg=@t]

A %stir task starts timers for any flows that lack them.

The arg field is unused.

Returns

This task returns no gifts.


%vega

[%vega ~]

%vega is called whenever the kernel is updated. Ames currently does not do anything in response to this.

Returns

This task returns no gifts.


Remote scry tasks

%keen

Perform an unencrypted or multi-party encrypted remote scry.

[%keen sec=(unit [idx=@ key=@]) spar]

A %keen task asks Ames to perform a remote scry, retrieving the value of path on the given ship in the spar. The sec field provides optional encryption details for multi-party encrypted scries.

The path has the general format of /[vane-letter]/[care]/[revision]/[rest-of-path]. For a regular read into Gall, it's /g/x/[revision]/[agent]//[rest-of-path]. Note the empty element in between the agent and the rest of the path.

Note that you would not use this task directly from userspace. For unencrypted or multi-party encrypted scries you'd use a Gall %keen note and for two-party encrypted scries you'd use a %chum task.

Returns

A %tune gift. A %tune gift looks like:

[%tune spar roar=(unit roar)]

It represents a result. The roar field is null if Ames doesn't have a response, but may have one in the future. The $roar contains a signature and the data. The data in the $roar will be null if there is no value at the path in question and will never be. These two cases are equivalent to ~ and [~ ~] of a local scry.


%chum

Perform a two-party encrypted remote scry.

[%chum spar]

A spar is a pair of ship and remote scry path like /c/x/4/base/sys/hoon/hoon.

The path has the general format of /[vane-letter]/[care]/[revision]/[rest-of-path]. For a regular read into Gall, it's /g/x/[revision]/[agent]//[rest-of-path]. Note the empty element in between the agent and the rest of the path.

Note this is for two-party encrypted remote scries only. For unencrypted or multi-party encrypted scries you'd use a Gall %keen note.

Returns

A %tune gift. A %tune gift looks like:

[%tune spar roar=(unit roar)]

It represents a result. The roar field is null if Ames doesn't have a response, but may have one in the future. The $roar contains a signature and the data. The data in the $roar will be null if there is no value at the path in question and will never be. These two cases are equivalent to ~ and [~ ~] of a local scry.


%yawn

Cancel a remote scry request.

[%keen =ship =path]

A %yawn task asks Ames to cancel an existing remote scry request to the given path on the given ship.

Returns

This task returns no gifts.


%wham

[%wham =ship =path]

A %wham task asks Ames to cancel all existing remote scry requests from all vanes on all ducts for the given path on the given ship.

Returns

A %tune gift with a null data is given to all listeners. See the %keen entry for more details of the %tune gift.


PreviousAmesNextAmes Cryptography

Last updated 1 day ago