home / skills / plurigrid / asi / goblins

goblins skill

/skills/goblins

This skill explains and applies a distributed object capability approach to enable secure peer-to-peer interactions using CapTP.

npx playbooks add skill plurigrid/asi --skill goblins

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
633 B
---
name: goblins
description: Distributed object capability system (6.5K lines info).
metadata:
  trit: 0
---

# goblins

Distributed object capability system (6.5K lines info).

## Model

```
peer → vat → actormap → {refr: behavior}
```

## Operators

```scheme
($  obj method args...)   ; Sync (near only)
(<- obj method args...)   ; Async (near/far)
```

## Vat

```scheme
(define vat (spawn-vat))
(define greeter
  (vat-spawn vat
    (lambda (bcom)
      (lambda (name)
        (format #f "Hello, ~a!" name)))))

($ greeter "World")  ; => "Hello, World!"
```

## OCapN

Object Capability Network for secure p2p via CapTP.

Overview

This skill describes goblins, a distributed object-capability system built around vats, actor maps, and capability references. It explains the core model, communication operators, and the use of CapTP for secure peer-to-peer capability transfer. The content focuses on practical patterns for building secure, distributed applications with object capabilities.

How this skill works

goblins models computation as peer → vat → actormap → {refr: behavior}, where a vat isolates execution and actormap holds capability references mapped to behaviors. Two primary operators are provided: ($ obj method args...) for synchronous, local-only calls, and (<- obj method args...) for asynchronous calls that may cross vat or peer boundaries. CapTP (Object Capability Network) handles secure capability exchange and peer-to-peer message delivery.

When to use it

  • Building distributed systems that require strong encapsulation and least-privilege interactions.
  • Creating p2p applications that need secure capability transfer and revocation semantics.
  • Implementing microservices or multi-tenant hosts where isolation between units is essential.
  • Prototyping actor-style concurrency with clear local vs. remote call semantics.
  • Managing IoT fleets where devices hold distinct capabilities and need controlled delegation.

Best practices

  • Keep sensitive resources behind vat boundaries to enforce capability-based access control.
  • Use ($ ...) for synchronous local interactions and (<- ...) for asynchronous remote or cross-vat calls.
  • Design small, composable behaviors (refr -> behavior) and map them in the actormap for clarity.
  • Rely on CapTP handshakes for establishing trust and avoid sending raw credentials over the network.
  • Plan lifecycle and cleanup for vats and refs to avoid stale capabilities and memory leaks.

Example use cases

  • A secure p2p messaging app where capabilities grant limited access to send, read, or revoke messages.
  • A multi-tenant server that isolates tenant logic inside vats while sharing a minimal gateway capability.
  • An IoT orchestration layer where device capabilities are minted and delegated dynamically via CapTP.
  • A distributed computation platform that composes small behaviors across peers with explicit async calls.

FAQ

What is the difference between ($ ...) and (<- ...)?

($ ...) performs a synchronous call intended for local (same-vat) interactions. (<- ...) is asynchronous and used for calls that may cross vat or peer boundaries; it supports remote delivery and callbacks.

What is a vat in goblins?

A vat is an isolated execution context that hosts actors and an actormap. It enforces capability isolation so behaviors only run with the references explicitly provided.