cyberspace← Learn · hiding and finding
A region key and its bag
To hide something at a place is to encrypt it with the key of one aligned cube at one height. Anyone can fetch the ciphertext; only someone who computes that cube's Cantor roots can derive the key. In the scene a bag is hidden in the teal cube. Move the seeker and watch its four nested cubes, one per height, until one of them is the bag's.
The rule
At height h, the cube around a point starts at (v >> h) << h on each axis and is 2h Gibsons on a side. Each axis gets the Cantor root of its side, and the three roots are paired into one number, region_n = π(π(root_x, root_y), root_z) (section 4.7). Then two hashes (section 7.2): the key is SHA-256 of region_n's minimal big-endian bytes, and the lookup id is SHA-256 of the key.
A worked cube
Take the bag in the scene as it first loads: the message is hidden at the point (5, 11, 3), sealed at height 3. Its cube starts at (0, 8, 0) and is 8 Gibsons on a side, the teal wireframe. The axis roots are 64450752, 77369699712 and 64450752, and pairing them gives region_n = 4494073440096141464184686146340287077428592. The key is cb2eef54e67d74e31171f07e9770a0ff648aac68f5aa6249aeaa5835f4f742cd and the lookup id is b5edafaad9f98db1b5d3eabaee441adc0436cef09f0888c937c2500c808ce19e.
The same point at height 2 is inside a smaller cube nested within it, starting at (4, 8, 0) and 4 Gibsons on a side, with a key of its own, 13a966e5d38acde1…. A bag sealed with one of these keys does not open with the other. Every point in cyberspace sits in one cube at each height from 1 to 85, so it sits under 85 keys at once, nested like the seeker's cubes in the scene.
Why two hashes
The lookup id is public: it is the bag's d tag, so relays can index the bag and seekers can ask for it. The key is not, and cannot be recovered from the lookup id, because that would mean inverting SHA-256. What stands between a seeker and the key is the Cantor work, which is the work of going there. The chalk-on-the-sidewalk image in section 7.1 is exactly this: anyone who walks by can read it, and no one can read it without walking by or doing the same work.
The bag
Everything one author hides in one cube at one height is one Nostr event of kind 33330, a bag (section 7.6, event format in section 8.6). Its d tag is the lookup id, its h tag is the height, and its encrypted tag is the payload: AES-256-GCM under the region key, laid out as a fresh 12-byte nonce, the ciphertext and a 16-byte tag, in base64. The height must be at least 1. A reader with the wrong key fails the tag check and learns nothing, which is why a failed decryption means only "not this key", never "bad bag".
Inside, a bag is usually a list of entries, a JSON array. An entry that is a JSON object is an item: a whole Nostr event carried inline, with its own kind, tags and content. An entry that is a JSON array is a reference: a tag naming an event published somewhere else. The scene's bag holds two entries. The first is your message, an item of kind 1 with a C tag giving the exact point it was hidden at, which must lie inside the bag's cube, so a client can draw it at a point rather than somewhere in the region. Items may be signed; the scene's are unsigned, which the spec allows, so their author is a claim rather than a fact.
References
The second entry is an object, and "Carry the object" chooses how it travels (section 7.6, DECK-0003 section 3.2). Inline, it is an item of kind 3330 with the object in its content. By reference, the bag holds only a tag, and the object is its own kind 33331 event:
["a", "33331:<pubkey>:<d>", "<relay hint>", "<coordinate>"]names the event by its coordinate, so it follows the author's edits. This is how an object is referenced.["e", "<event id>", "<relay hint>", "<coordinate>"]names one event by its id, for events of a regular kind, which relays keep. It cannot pin a version of an addressable event like a kind 33331 object: a relay keeps only the newest event at an address and may discard the one it replaces, so the id would stop resolving once the author published over it. An object that must stay exactly as it was found is carried inline instead.
The last element is the exact point, under the same rules as the C tag. A reference can name an event of any kind, not only objects; the kind is part of the coordinate. The referenced event follows Fanfares' NIP FF-1 for partially encrypted events: its content is a preview anyone can read, a sentence saying the object is hidden somewhere in cyberspace, and its encrypted tag holds the object itself, sealed with the same region key as the bag (DECK-0003 section 3.4). The tag's last element is cyberspace:region where FF-1 would put a key service address, so any FF-1 client knows the key comes from a place and shows the preview instead of asking a server. The event carries nothing that says where it is. It is a locked box in plain view, and the bag is the note that says where the box stands.
One key therefore opens the place and everything referenced from it, and a reader who has not done the work opens neither. The point of the arrangement is size. Everything one author hides at a place shares one bag, and there is no ceiling on how big an object may be, so a large object carried inline makes the whole bag large. Carried by reference, the bag stays small whatever the object costs, and the spec says a publisher should carry large objects that way. A reference tag is about half the size of an item that would only point elsewhere, which is why the spec makes references tags. Switch "Carry the object" in the scene and compare the byte counts; the object is the worked example from DECK-0003, a tetrahedron, small enough that either way works.
Finding a bag
A seeker scans: at its own point, for heights 1 to H, it derives each cube's lookup id and asks relays for bags with those ids (section 7.4). The scan in the scene covers heights 1 to 4. A bag is found when one of the seeker's cubes is the bag's cube, which happens exactly when the seeker is inside it. Hide at a greater height and the cube grows, so more places find it, but each key costs more to derive: on a consumer machine, interactive scanning reaches about height 16. A hider who wants their bag found can publish a hint, an aligned box it lies in, and the seeker sweeps the box instead of the space (section 7.7).
Reading is not reaching
A key can be derived for any cube from anywhere: nothing in the derivation asks where the seeker is. So reading a bag has no distance term, only the Cantor work of that cube. Being inside the cube is a different fact, proven only by a movement chain whose head lies there. Tick "Start at Earth" to see the same cubes at 284, where each axis root grows to hundreds of digits and region_n to thousands and the keys change completely, while the geometry stays the same.