Sequel to TAJ Mahalo: Logical S3 via Translated Access JWTs (A RAJ Musical)

“The Simple Dictionary Apparatus for Unbelievably Scrumptious Lickables”

Explain how SDA is like being able to “eat the menu;” as a Roald Dahl story.

ChatGPT Prompt (condensed)

Dramatis Personae

• Zooko Wilcox — The hungry boy who simply uses what is in front of him. Represents the instinctive understanding that names should be enough.
• Mark S. Miller — Zooko’s loving, overworked father and inventor of the rule that names carry authority. Built the system, but must learn what it was for.
• Tim Berners-Lee — Designer of menus that never describe kitchens. Believes identifiers must not leak location.
• Roy Fielding — The explainer of the uniform method of interaction. Knows how things should be used, but must watch someone actually use them.
• Sage Weil — Builder of the endless pantry. Ensures there is always enough, no matter how much is consumed.
• Matt Klein — The quiet arranger who makes sure things arrive in exactly the right place. Obsessed with correct delivery, not with where things come from.
• Norm Hardy — Architect of sensible cupboards that no one should ever need to open. Defender of the abstraction boundary.

---

ACT I — THE SPAGHETTI

A worktable covered in sketches, diagrams, half-drawn menus.
A bright pop-up book sits among them like it doesn’t belong.

MARK is pacing, muttering to himself, adjusting drawings.
ZOOKO sits at the table, chin in hands, watching his father work.

ZOOKO: Are we eating soon?

MARK (absently): In a moment.

(He draws a careful line through a picture of a cupboard.)

No cupboards.

ZOOKO: You said that yesterday.

MARK: Yesterday we still had cupboards.

(He crosses something else out.)

This is better.

ZOOKO (poking the pop-up book): What’s this?

MARK: Prototype.

ZOOKO: For food?

MARK: For names.

(Beat.)

Which is almost the same thing.

Zooko opens the book.
A splendid paper spaghetti springs upward.
He stares at it.

ZOOKO: That looks real.

MARK (still drawing): It’s a demonstration.

ZOOKO: Of spaghetti?

MARK: Of naming.

Zooko leans forward.
He licks the spaghetti.
POOF.
A real, hot, dripping plate of spaghetti appears in his hands.

(Silence.)

Mark slowly turns.
Looks at the plate.
Looks at the book.
Looks at Zooko.

MARK: Don’t move.

ZOOKO (already eating): I wasn’t.

Mark approaches cautiously, like one approaches a sleeping animal.

MARK: Did you… ask for that?

ZOOKO: No.

MARK: Did you… press anything?

ZOOKO: I licked it.

Mark kneels beside the book.
Peers at the page.
Touches nothing.

MARK: Hm.

Zooko turns the page.
A lasagna rises.
He licks.
POOF.
Lasagna.
He eats.

Mark stands.
Calls toward the doorway without looking away from the book.

MARK: Matt.

(Beat.)

Matt!

MATT enters, carrying a ruler.

MATT: If this is about the table alignment, I’ve—

(Sees Zooko with lasagna.)

Where did that land?

ZOOKO: Here.

MATT (pleased): Good.

Zooko turns another page.
Pancakes.
Lick.
POOF.

MATT: Consistent placement.

MARK (quietly): He hasn’t asked where it comes from.

MATT: Why would he?

Zooko flips back to the first page.
Spaghetti again.
Lick.
POOF.
Another plate.

Mark and Matt stare.

MATT: That’s the same one.

MARK: Yes.

(Long pause.)

He’s using it again.

Zooko eats happily, surrounded now by plates.

ZOOKO: This is the best book you’ve ever made.

Mark watches his son eat.
He says nothing.

---

ACT II — THE FLOOD

Same table. Same room.
Very much more food.

Plates are everywhere. Pancakes sliding. Lasagna leaning. Spaghetti attempting escape.

ZOOKO sits happily in the middle of it, turning pages and licking with methodical enthusiasm.

MARK and MATT stand nearby, no longer quite certain what is happening.

MATT (measuring a stack of pancakes): They’re still arriving in his hands.

MARK: Yes.

MATT: That’s reassuring.

(Beat.)

Is it reassuring?

Zooko flips to a random page.
Licks.
POOF. Soup.
He drinks.

MARK (calling toward the hallway): Tim!

(No response.)

Tim!

TIM enters with a paintbrush.

TIM: If this is about the fork illustration, I’ve removed it.

(Stops.)

Why is there soup?

ZOOKO: Book.

Tim peers at the pop-up.

TIM: That plate shouldn’t be there.

MARK: It isn’t.

TIM: I can see it.

MARK: That’s the problem.

Zooko turns two pages at once.
Lick.
POOF. POOF.
Two desserts land in his lap.

TIM: He’s not even looking carefully!

MARK: He doesn’t seem to need to.

Zooko flips back.
Spaghetti again.
Lick.
POOF.

TIM: That’s the same page!

MATT: Same placement.

MARK: Same result.

(Beat.)

He trusts it.

TIM: We should explain how it works.

MARK: Why?

TIM: So he understands what he’s doing.

MARK: He appears to understand what he’s doing.

Zooko flips forward, backward, sideways.
Lick. Lick. Lick.
Food is now spreading off the table.
A pancake slides to the floor.

MARK: Sage!

SAGE enters, already chewing something.

SAGE: I smelled pudding.

(Looks around.)

Ah.

I’ll extend the back.

(He reaches into the book and pulls. The pages lengthen like a scroll.)

Zooko does not look up.
He keeps licking.

TIM (distressed): He’s not following any order!

MATT: The order appears irrelevant.

MARK (watching Zooko): He isn’t searching.

TIM: For what?

MARK: Anything.

Zooko pauses, breathing a little harder now.
He turns back to spaghetti again.
Lick.
POOF.

Everyone watches.

SAGE: Still works.

MATT: Still lands.

TIM: Still no cupboards.

Zooko smiles through a mouthful of noodles.

ZOOKO: You don’t have to think with this book.

(They all go quiet.)

---

ACT III — THE BITE

The room is now a landscape of food.
Plates. Bowls. Puddings. A small river of soup.

ZOOKO sits in the middle of it, slower now. Still hungry.

MARK, TIM, MATT, and SAGE watch him with the uneasy attention of people who have stopped pretending they understand what is happening.

The pop-up book lies open in Zooko’s lap.

Zooko turns a page.
Stares at a magnificent roast chicken made of folded paper.
He does not lick it.
He looks tired.
Hungry still.

He grips the page with both hands.
And tears it out.

TIM: Don’t—!

Zooko stuffs the entire pop-up into his mouth.
Paper. Ink. Everything.

The adults freeze.

This is not careful.
This is not correct.
This is not how it was meant to be used.

POOF.

A full, hot roast chicken appears in Zooko’s hands.
Grease runs down his fingers.
He begins to eat.

No one speaks.

MATT (quietly): Placement… still correct.

SAGE: Supply… unaffected.

TIM: He didn’t even— he didn’t even look at it first.

MARK sits down slowly across from Zooko.
He watches his son eat.
Really watches him.
For the first time in the play, he is not looking at the book.

MARK: He was hungry.

No one replies.

Zooko turns back to the book.
There is a jagged hole where the chicken page used to be.
He smiles.
Turns to the next one.

MARK (softly, almost to himself): We built a restaurant.

(He looks at the book. Then at Zooko.)

He just wanted a meal.

---

END OF PLAY

---

Appendix I — Software-Defined Addressing for Universal Storage Locators

1. This appendix states plainly what the play demonstrates.

A Uniform Storage Locator (USL) is a logical, stable identifier for data.

Software-Defined Addressing (SDA) is the system that gives that identifier meaning without exposing storage topology.

TAJ/RAJ is a concrete mechanism that implements SDA for object stores.

2. The Problem USLs Solve

Modern object storage forces clients to encode infrastructure into addresses:

• Buckets
• Regions
• Accounts
• Vendors
• IAM assumptions
• Signing mechanics

These are kitchens leaking into the menu.

As a result, object identifiers today are:

• Not location independent
• Not referentially transparent
• Hard to migrate
• Hard to cache
• Operationally coupled to infrastructure layout

This violates the spirit of REST as described by Roy Fielding: resource identifiers should not expose server topology.

3. Uniform Storage Locators (USLs)

A USL is:

A topology-independent, stable, logical identifier for stored data.

Example form:usl://customer-logs/2026/01/23.json

A USL does not reveal:

• Where the data lives
• How it is stored
• Who owns the bucket
• Which region serves it
• Which vendor provides it

It is a name, not a location.

This mirrors what a URL did for the web.

4. Software-Defined Addressing (SDA)

SDA is the architectural pattern where:

The mapping from logical identifiers to physical resources is performed by software, not encoded in the identifier and not resolved by infrastructure lookups at request time.

In SDA:

• Address meaning is defined in a control step
• Resolution requires no directory or policy lookup during use
• The address can be interpreted anywhere that understands the scheme

SDA turns addresses into capabilities.

This aligns with the object-capability model described by Mark S. Miller and Norm Hardy.

5. TAJ/RAJ as an SDA Mechanism

In the TAJ system:

• A client requests access to a USL.
• A control component (RAJA) evaluates policy once.
• RAJA fetches the Quilt manifest for the package/version.
• RAJA issues a Translated Access JWT (TAJ) containing an encrypted RAJ with:
  • The manifest hash (the routing table)
  • The logical scope within that manifest
  • The authority to use that scope

The RAJ does not contain physical S3 locations.

A data-plane proxy (RAJEE, an Envoy filter) uses the TAJ to:

• Decrypt and validate the RAJ
• Fetch the pinned manifest by hash
• Look up the logical key in that manifest
• Obtain the extended S3 URI with versionId
• Rewrite and sign the S3 request
• Forward it without further policy checks

No bucket knowledge.
No IAM calls.
No directory lookups.

The token does not carry the mapping.
The token carries authority over the routing table.

6. Referential Transparency

A USL is referentially transparent:

It always refers to the same logical object, regardless of where or how the data is stored.

Data can be:

• Moved to a new bucket
• Replicated to a new region
• Migrated to a new vendor
• Re-sharded internally

The USL does not change. Clients do not break.

7. Cacheability

Because USLs are stable and TAJs embed authority:

• Proxies can cache safely
• Clients can cache safely
• No re-authorization is needed for each access
• Infrastructure changes do not invalidate caches

This restores the natural cacheability that URLs enabled for the web.

8. Relationship to REST

S3 today provides a RESTful API over storage.

USL + SDA + TAJ restores the deeper REST constraint:

Resource identifiers must not expose server topology.

This is REST applied to storage identity, not just transport.

9. Layered View

• USL — the logical identifier clients use
• SDA — the system that interprets the identifier
• TAJ — the compiled mapping and authority
• Proxy — the runtime translator
• Object store — the physical data plane

Each layer is cleanly separated.

10. Summary Definition

Uniform Storage Locators are logical identifiers for data.

Software-Defined Addressing is the system that gives those identifiers meaning without exposing infrastructure.

TAJ is one practical way to implement this for object storage.

---

Appendix II — Why These Researchers

1. The characters in the play are not decorative.

Each represents a line of thought that independently argued for a piece of what USL + SDA + TAJ quietly assembles.

This appendix makes those connections explicit.

2. Zooko Wilcox — Names Should Be Enough

Zooko’s work on Tahoe-LAFS and secure distributed storage revolved around a simple idea:

A reference to data can be self-authenticating and sufficient to retrieve it.

Capability URLs in Tahoe already behaved like primitive USLs:

• The name carried authority
• No directory lookup was required
• Location did not matter

Zooko’s character in the play reflects the instinctive use of such names without caring how they work.

3. Mark S. Miller — Authority in References

Mark Miller’s object-capability model formalized:

A reference can be both designation and authority.

TAJ is exactly this idea applied to cloud storage:

• The token is the reference
• The reference grants the authority
• No ambient permission checks are needed

Mark’s character built the rules. Zooko simply uses them.

4. Norm Hardy — Abstraction Boundaries

Hardy spent decades arguing:

Users should never need to open the cupboard.

S3 today forces users into cupboards: buckets, regions, IAM.

USLs restore the abstraction boundary Hardy insisted on:

• Names should not reveal mechanism
• Mechanism should not leak into usage

5. Tim Berners-Lee — Identifiers Must Not Leak Location

URLs succeeded because they hid:

• Server layout
• File systems
• Network topology

A URL is not an IP address.

USLs apply the same discipline to storage:

• Not bucket names
• Not regions
• Not accounts

Tim’s menus never describe kitchens.

6. Roy Fielding — REST and Resource Identity

Fielding’s REST constraint most people forget:

Resource identifiers must be opaque and location-independent.

S3 URLs violate this.

USLs restore it.

This is REST applied to object identity, not just HTTP verbs.

7. Sage Weil — Storage Without Limits

Ceph and SDS solved:

How to make storage infinite, reliable, and self-healing.

But SDS does not solve naming.

Sage ensures the pantry is endless.
USLs ensure no one needs to know where the pantry is.

8. Matt Klein — Correctness in the Data Plane

Envoy and modern service meshes focus on:

• Correct routing
• Identity in the request path
• Separation of control and data planes

RAJEE (the Envoy role in TAJ) is exactly this:

Interpret the token and deliver correctly, without caring about origins.

Matt ensures the plate lands in the right hands.

9. The Convergence

It makes a storage address behave like a capability URL, a REST resource, and an abstraction-safe identifier — all at once.

That is why the play resonates with their ideas without naming them.

---

Appendix III — The Grace S3 Lacked

S3 was built under a good law:

Remove indirection from the data path.

This law made S3:

• Simple
• Fast
• Scalable
• Operationally elegant

But something was missing.

Not another mechanism.
Not another layer.
A grace.

---

The Law S3 Kept

S3 eliminated:

• Filesystems
• Mount tables
• Storage appliances
• Directory services
• Metadata lookups in the hot path

You go straight to the bytes.

This is correct for storage.

---

What Was Lost With It

In removing indirection from storage, S3 also removed:

The indirection between a name and where the thing lives.

That indirection is what makes naming work in:

• File systems
• The web
• Networks
• Capability systems

Without it, the name becomes the location.

---

The Consequence

S3 keys and bucket names became:

• Infrastructure diagrams
• Embedded in application code
• Part of security policy
• Part of deployment topology
• Part of business logic

Meaning leaked into addresses.

---

Why This Could Not Be Fixed Before

If you tried to reintroduce logical naming, you had to add:

• A lookup service
• A metadata system
• A policy engine
• A proxy hop

Which violated the law by putting indirection back into the data path.

So the industry chose the law and lived without the grace.

---

What Quilt and RAJ Make Possible

Quilt provides:

• Immutable, versioned mappings from logical keys to physical objects
• A place for meaning to live outside the data path

RAJ/TAJ provides:

• A way to carry authority over a specific manifest as a token
• So resolution requires no lookup and no policy check

Indirection is restored for naming.

Directness is preserved for data.

---

The Grace

The grace S3 lacked was:

The ability to keep indirection for identity without reintroducing indirection for access.

USL + SDA + Quilt + RAJ supply that grace.

---

The Result

• The data path remains as simple as S3 intended
• Names no longer describe infrastructure
• Meaning no longer leaks into code
• Storage can move without breaking clients

---

The One-Line Truth

S3 kept the law of direct access.
USLs restore the grace that makes names independent of where data lives.

---

Appendix IV — Quilt Packages As Routing Tables

1. This appendix restates the argument in the language of the Quilt mental model, showing how Quilt package semantics map naturally to Software-Defined Addressing (SDA) for Uniform Storage Locators (USLs).

2. Why This Is Happening Now

The problem being solved is immediate and concrete:

Fine-grained sharing of massive objects across organizational boundaries.

Organizations need to:

• Share specific datasets from large collections
• Grant time-limited access without bucket permissions
• Track what was shared and with whom
• Revoke access without moving data
• Do this at scale (terabytes, petabytes)

Traditional approaches fail:

• Bucket policies — too coarse-grained, grants bucket-level access
• Presigned URLs — individual objects only, no collection semantics
• IAM roles — requires AWS account coordination
• API gateways — adds latency and cost to data path

This is not a theoretical problem. It is blocking data sharing today.

3. Why This Is Happening Here (At Quilt)

Only Quilt combines the necessary properties:

Versioning at two levels:

• Package manifests are versioned (immutable collections)
• Individual objects are versioned (immutable content)

Immutability as culture:

• Quilt packages are never mutated, only republished
• Physical S3 objects use versioning
• Hashes are recorded for integrity

Actual discipline around object identity:

• Logical keys are stable across package versions
• Physical keys include full version coordinates
• The manifest is the authoritative mapping

No other system in the S3 ecosystem has this combination.

4. Physical Keys Are Extended S3 URIs

A Quilt physical key is not just s3://bucket/key.

It is:s3://bucket/prefix/hash/filename?versionId=XYZ123

This extended URI includes:

• The bucket (physical location)
• The content-addressed prefix (for deduplication)
• The object key (the actual filename)
• The S3 versionId (immutability guarantee)

The versionId parameter is critical. It ensures:

• The manifest points to a specific immutable object
• Even if someone overwrites the key, the manifest still resolves correctly
• Referential integrity is preserved

5. Manifests Are Immutable Routing Tables

A Quilt package manifest is:

A versioned, immutable mapping from logical keys to extended physical S3 URIs.

Example manifest entry:{ "logical_key": "data/customers.csv", "physical_keys": [ "s3://prod-bucket/a4f2e9/customers.csv?versionId=abc123" ], "hash": {"type": "SHA256", "value": "d4f8..."}, "size": 1048576 }

This is a routing rule:

• Destination: logical key
• Next hop: physical S3 URI with versionId
• Integrity check: hash
• Metadata: size, type, etc.

Just as a network routing table maps IP prefixes to next hops, a Quilt manifest maps logical keys to physical objects.

6. Double Versioning Enables Clean SDA

Because Quilt versions both the manifest and the objects:

The manifest hash pins the routing table

• A specific manifest revision = a specific set of routing rules
• No floating semantics
• No temporal ambiguity

The versionId pins the object

• A specific physical key = a specific immutable object
• No race conditions
• No consistency problems

This double versioning is what makes Software-Defined Addressing safe:

• RAJA mints a RAJ pinned to a manifest hash
• RAJEE uses that exact manifest to resolve logical → physical
• The physical URI includes versionId, so the object is immutable
• The RAJ contains no physical mappings — only the manifest identity and logical scope
• Authority, routing, and content are all precisely defined

7. Logical Keys Are Location-Independent

A Quilt address of the form:registry/pkg_prefix/pkg_suffix/logical_key

behaves like a Uniform Storage Locator:

• registry — control plane authority (e.g., quiltdata.com)
• pkg_prefix/pkg_suffix — stable package namespace and version
• logical_key — the conceptual datum (e.g., data/customers.csv)

This identifier does not expose:

• Which bucket
• Which region
• Which account
• Which versionId

The manifest provides that information only to authorized resolvers (RAJA/RAJEE).

8. Buckets Are Deployment Details

In Quilt’s model, S3 buckets are:

• Lifecycle or environment branches
• Storage backends
• Operational concerns

They are not part of the logical address space seen by clients.

A package can be:

• Pushed to dev-bucket for testing
• Pushed to prod-bucket for production
• Replicated to eu-bucket for compliance

The logical keys remain identical. The manifest updates to reflect new physical locations.

9. Resolution Flow (Quilt → SDA → TAJ)

Step 1: Client requests accessPOST /taj/issue { "package": "registry/user/dataset@v1.2.3", "path": "data/customers.csv", "actions": ["read"] }

Step 2: RAJA evaluates policy

• Checks: Is this user allowed to read this package?
• Fetches: The manifest for user/dataset@v1.2.3
• Compiles: A RAJ containing the manifest hash and logical scope

Step 3: RAJA issues TAJ{ "taj": "eyJhbGc...", // Contains encrypted RAJ "manifest": "sha256:a4f2e9...", "scope": "data/customers.csv" }

Step 4: Client uses TAJGET /registry/user/dataset@v1.2.3/data/customers.csv Authorization: Bearer eyJhbGc...

Step 5: RAJEE processes request

• Decrypts and validates the RAJ
• Fetches manifest sha256:a4f2e9...
• Looks up data/customers.csv in the manifest
• Gets: s3://prod-bucket/a4f2e9/customers.csv?versionId=abc123
• Rewrites the request to physical coordinates
• Signs with AWS credentials
• Forwards to S3

Step 6: S3 returns the versioned object

Client receives customers.csv without ever knowing the bucket name or versionId.

10. Why Only Quilt Can Do This

Other systems lack essential properties:

Git LFS — No S3 versionId, objects are mutable via pointer files

DVC — No immutable manifests, tracking files can be edited

Delta Lake / Iceberg — Table formats, not general-purpose package semantics

Plain S3 — No logical/physical separation, no versioned collections

Quilt uniquely provides:

• Immutable packages (versioned manifests)
• Content-addressed + versioned objects (extended URIs with versionId)
• Logical key stability across package revisions
• Hash-based integrity for both manifests and objects
• A registry that publishes and resolves package versions

This combination is what makes Quilt packages work as routing tables for Software-Defined Addressing.

11. The Key Insight

Quilt did not set out to build Software-Defined Addressing.

But by treating data packages as immutable, versioned collections with stable logical keys and extended physical URIs, Quilt packages already function as routing tables for a system where:

• Identity lives in logical keys
• Authority lives in RAJs
• Resolution happens via manifests
• Access goes directly to immutable versioned objects

12. The One-Line Statement

A Quilt package is an immutable routing table that tells a Software-Defined Addressing system how Uniform Storage Locators resolve into versioned physical S3 objects.

---

Appendix III — Quilt Packages As Routing Tables

1. This appendix restates the argument in the language of the Quilt mental model, showing how Quilt package semantics map naturally to Software-Defined Addressing (SDA) for Uniform Storage Locators (USLs).

2. Manifest = Logical → Physical Mapping

Quilt package manifests separate logical keys from physical keys:

• A logical key is a stable, human name like data/customers.csv that code references.
• A physical key is an actual object such as s3://bucket/hash/customers.csv?versionId=....
• The manifest maps logical keys to one or more physical keys and records hashes and version identity.

This is exactly what an SDA control plane defines: how names resolve to storage.

3. USLs in Quilt Terms

A Quilt address of the form:registry/pkg_prefix/pkg_suffix/logical_key

behaves like a Uniform Storage Locator:

• registry acts as the control plane authority.
• pkg_prefix/pkg_suffix defines a stable package namespace and version.
• logical_key names the conceptual datum independent of storage layout.

This identifier does not expose buckets, regions, accounts, or vendors.

4. Packages as Route Tables

A Quilt package is not merely a collection of files.

It is a declaration of routing rules:

• Each logical key is associated with of these researchers were working on “logical S3.”

Yet each argued for:

• Capability references
• Opaque identifiers
• Abstraction boundaries
• Location independence
• Clean data-plane enforcement
• Infinite storage substrate

USL + SDA + TAJ is where all of those lines meet.

10. Why They Would Recognize Themselves

Because the system does something rare:

It makes a storage address behave like a capability URL, a REST resource, and an abstraction-safe identifier — all at once.

That is why the play resonates with their ideas without naming them.