Yaks

Showing 25 of 51 from the live probe.

• Apply a batch

  Apply entity bundles to this store: create, patch or delete entities and their components, atomically. A batch is an array of BUNDLES — {entity: {eid}, <component>: {<columns>}}, the same shape a client's apply() takes: an omitted column is untouched, a null column is cleared, a null component is dropped, and $delete: true kills the entity. Mint an id yourself, or write '$name' as the eid and read back what the graph named it. Where this store keeps names, alias: {name: '<your name>'} beside a '

• Read a query

  Find entities in this store by filtering their components and columns, answered as whole bundles. A query LINE selects them: '.status=shelved&.price<20' — dot-params joined with &, with lists (a,b), ranges (1..9), !=, ~=, comparisons, '.prop!' for present and '.prop=' for absent. Directives ride the same line: .order=, .limit=, .refs=<id> for everything pointing at an entity. filters, if you pass any, are joined onto q with &.

• Show entities whole

  Read entities out of this store by eid, whole: one or several, every component each one carries, plus everything that points AT it, each as its own bundle in {bundles}. Edge entities are ordinary bundles too. This is identity, not search — pass eids, or the name an entity answers to where this store keeps names (an eid wins over a name that spells it). Set backrefs false when you only want the entities themselves.

• The schema

  Read this store's vocabulary — every component, its columns and their types — in three sizes. Bare: the INDEX — every component, what it means in a line, and its column names. With component (one name or several): that component in full — each column's type and meaning, what is server-owned or unique, what points at it and what it points at, and a bundle that writes it. With kind: what an entity of that kind is made of. Read the index first and ask for the word you are about to write.

• Search the text

  Search the text of this store's entities: the ones whose words match, ranked best first, as whole bundles. Use graph_query when you know what you are filtering on and this when you only know what it says.

• A new space

  Another corner of yaks.app, at <slug>.yaks.app, with the person as its owner. They already have one from signing in, and every other tool uses it without being told — so this is only for a second address.

• Rename a space

  Move a space to another address, or change its name. The title is what it is called; the slug is its address, so changing it moves the space to <new>.yaks.app — every app in it moves with it, files, data and all, and every app keeps its own path under the new address. The old address keeps working: it redirects to the new one with the path kept, so a link somebody already has still opens the page it always did, and letters to <old>.<app>@yaks.app still arrive. It also stays reserved — nobody els

• Close a space

  Close a space: it goes to the trash for 30 days. Every app in it stops answering, its address stops serving and its apps leave your tools — but nothing is erased, the address is held, and space_restore brings the whole space back within those 30 days. After that the platform erases it: the apps, everything they saved, their files, any domain aimed at them, and the address goes back into circulation. YOU CANNOT DO THIS: it mails the space's owner a link that does it, lasting an hour, and answers

• Take a space out of the trash

  Bring back a space that was deleted. Every app in it serves again at the address it always had, their tools and pages come back, and everything they saved is exactly as it was — nothing was touched while it sat in the trash. Within 30 days of the delete being confirmed; after that the space has been erased and there is nothing to bring back. Unlike space_delete this is the assistant's to do: putting a space back is not an act anybody needs protecting from.

• Start selling

  Connect this space to Stripe so its apps can take money. Requires Plus. The person gets a link to finish setting up with Stripe — their name, their bank account, whatever Stripe asks — and that all happens at Stripe, not here: we never see or hold any of it. They are the merchant. It is their charge, their money, their name on the customer's statement, and refunds and disputes are theirs to answer. HAND THEM THE LINK AND STOP: nobody can sell until they have finished it, and calling again gives

• A new app

  Start a new app — the thing you are making for the person. It lives at <space>.yaks.app/<slug>/ and the first app in a space also answers the bare address. Then app_files to write index.html, app_deploy to release, and give them the link. Pass access when the app is for other people too: 'open' if anyone with the link should be able to act on it — vote, add a line, sign up — and 'private' if only they and whoever they invite (member_add) should see it at all.

• The app's files

  Write the app's files — index.html and any css, js or images beside it — or list them, read one back, or delete one. Write a whole app in ONE call with files: [{path, content}, …] — a files batch IS the write, so leave op out; path and content write a single file, and base64 in place of content writes one that is not text — a picture, or the .wasm a worker.js imports. They serve live at <space>.yaks.app/<app>/<path>; index.html answers the directory. Keep what the app remembers in its own store,

• Run a build command

  Run one command in this space's build sandbox — a Linux container for the things a browser cannot do for itself: compile something to WebAssembly, run a generator, minify an asset. Installed: Rust 1.98.1 with the wasm32-unknown-unknown target, wasm-bindgen 0.2.128 and wasm-opt 132; Python 3.13.15 with pip; Go 1.27.1; Zig 0.16.0, which is also the C and C++ compiler here — `zig cc -target wasm32-freestanding -nostdlib -Wl,--no-entry` gives a module a browser loads with no glue, and -target wasm32

• Write a build file

  Write one file inside this space's build sandbox — a Cargo.toml, a src/lib.rs, whatever the build needs. These are NOT the app's files: nothing here is served, and everything here is gone when the build ends. app_files writes what the app serves; sandbox_ship moves a built artifact from here to there. Waking the sandbox is metered by the second, like sandbox_exec. The way back: none is needed — nothing of the app is here. The container is a throwaway machine, and only sandbox_ship moves anything

• Read a build file

  Read one file back out of this space's build sandbox — a generated source, a build log, whatever the last command left behind. Waking the sandbox is metered by the second, like sandbox_exec.

• Ship a build artifact

  Copy what the build made into the app, where it is served: name the files in the sandbox — pkg/*.wasm, pkg/*.js — and each lands beside index.html under its own name, as if app_files had written it. This is the last step of a compile: the sandbox is thrown away and the app keeps the artifact. Bytes are carried as bytes, so a .wasm arrives whole. Waking the sandbox is metered by the second, like sandbox_exec. The way back: these land through app_files, so each keeps the bytes it replaced — app_fi

• Release a version

  Release what you have written: the files are already live, so this is the mark that they are one version — the one an error will name. Do it when the app is ready to show, then give the person the URL. It also plants the components the app's vocab.json declares — {"recipe": {"title": "text", "serves": "number"}} — so the app gets typed components of its own. A word the platform already says is refused, the whole manifest at once and before anything is planted; one this manifest stops naming, and

• Load a data file into the store

  Write a data file the app already carries into the app's store, now. path is one file — data/cities.json — or a folder, and then every *.json and *.csv under it goes in. A JSON file holds the same list of bundles a seed.json does and graph_apply takes: [{"entity": {"eid": "$a"}, "doc": {"title": "…"}}]. A CSV is a spreadsheet, and `as` names the component ONE ROW becomes — as: "city" with headers name,country writes city{name, country} per row, values coerced to the column types the vocabulary d

• Deploy history

  Every deploy of the app, newest first, with when it went out and what changed in it. Read it when the person says the app used to work, or before putting it back, so you name the version they mean. The app keeps its last 20.

• Roll back a release

  Put the app back the way it was — every file of an earlier deploy, its components, its tools and its own code with them. This is the answer when the person says a change broke something or asks for it back; you do not need to remember what you wrote. It goes out as a NEW version, so nothing is lost and a rollback can itself be rolled back. Leave version out for the deploy before the live one, or name one off app_versions. Give the person the URL and tell them what came back. Their data is never

• Put a store back to a moment

  Put everything the app has saved back to how it was at a moment — the whole store, every row of it, as of that time. This is the answer when a write went wrong and the person wants their data back: a bad import, rows deleted that should not have been, a change that turned out to be the wrong one. Cloudflare keeps the last 30 days of the store, so any moment in those 30 days can be asked for; at is that moment, as a time (2026-09-06T14:20:00Z). Call it with no at first: it says the oldest moment

• Rename or reshare an app

  Rename an app, change its title, or change who may use it. The title is what it is called; the slug is its address, so changing it moves the app to <space>.yaks.app/<new>/ — its files and everything it has saved come with it, and the old address redirects to the new one, so a link someone already has still works. Give the person the new link. access is the same choice app_new takes: set it to 'open' when they want everyone with the link to be able to act on the app, 'private' to shut it to every

• Set a worker key

  Give the app's worker a key for an outside service — an API key, a token — without the page ever holding it. The value goes onto the app's own script and NOWHERE else: it is not saved in the app's data, not in its history, and no tool, this one included, can ever read it back. Only the worker can, as env.NAME, so name it the way its code will spell it: app_secret_set(app, name: 'WEATHER_KEY', value) and then `fetch(url, {headers: {authorization: env.WEATHER_KEY}})` in worker.js. Ask the person f

• The worker keys

  The names of the keys the app's worker can read. Values are never answered — by this tool or any other. Use it to see what a worker.js may spell as env.NAME.

• Remove a worker key

  Take a key away from the app's worker. Its code stops seeing env.NAME at the next request; nothing else about the app changes. The way back: app_secret_set with the value again — a secret is never readable once set, so this is the one thing here nothing can restore for you.