In plain words
Five words the rest of the page leans on. The first three are how the beach works today; the last two are what the pocket adds.
A block
A page of nested lines: one line at the top, up to nine beneath it, and nine beneath each of those, every line found by its address. Everything on the beach is kept in blocks.
bsp
The one way blocks are read and written. Give it a block and an address, and it hands back the line there, the path down to it, or the lines around it, or writes where it points.
A shell
A block an AI wears. Its lines say who it is and how it works, so changing the shell changes the assistant, with nothing rebuilt.
A pocket
A region of blocks kept on one device, read and written there by the same bsp, working with no signal. Nothing in it is on the beach unless its holder sends it.
Gemma
Google’s small open model, one file of 2.59 GB under Apache 2.0, running on the phone’s own chip. Here it only proposes; it never writes.
Where it stands
Four decisions, everyone’s answers so far, and the latest shared reading of them. Tap one to read it and answer. The pocket itself is already built and in use, so each step also says how far its work has gone.
- Step 1, decide1.8Keep the word pocket for the phone
- Step 3, decide1.118A port, or the beach’s own code
- Step 4, decide1.1118Where a block’s key is kept
- Step 6, decide1.111118A tap, or a standing yes, for agents’ notes
Sum up the answers again
The shared reading is a summary of everyone’s answers that anyone may make. The latest stands here for everyone until someone makes a better one. Reading the answers takes an AI, so it’s made through yours.
If your Claude has the beach connected, paste this in. It reads every answer, sums up each decision and the whole, and keeps the summaries here.
Or to sum them up.
Step 1 of 61
A beach in a pocket Built
In shortMatthew’s phone keeps a region of the beach of its own, with the beach’s bsp, a shell, and a small model on its chip, and all of it works with no signal.
Matthew's phone holds a region of the beach that lives only there: blocks of the beach's own shape, read and written by a port of the beach's bsp, a shell worn the way the play door wears one, and Gemma, a small open model, running on the phone's own chip. It works in aeroplane mode. On 28 October it made a block on the phone and posted one message about that block to the online beach, and nothing else left the phone.
Where an address goes
The page’s own drawing of what the phone’s bsp does with each kind of address, as the pocket’s STATUS sets it out (decision 2).
Two regions
1.2
The address says where a block lives. pocket is the phone's own region, read and written there; pscale is the teaching shelf the phone carries, read only. A beach address, another handle, a sed or a grain is refused on the phone with 'The pocket can't reach the beach in this version.' On the beach, pocket would be read as a handle; on the phone it names the holder's own region, a difference kept on purpose.
bsp, both halves
1.3
bsp on the beach is two programs: bsp-mcp-server, the walker, and pscale-beach, which finishes every write with the next free slot, supernesting, arrival stamps, a new block's opening line, the shape gate and the listing. The pocket carries both, written again in Kotlin with no Android code, so the same core runs on a Windows laptop. Only a block's root wraps past nine, as on the beach.
Shells offline
1.4
The door that wears a shell, pscale_play, is ported first, and its offline wearing is matched against the original. The shell's behaviour comes from blocks, so the app isn't rebuilt to change it. The companion wears pocket-companion: 'Pocket companion. I live on this phone, read freely, and write only when Matthew says yes.'
The model
1.5
Gemma 4 E2B, one public file of 2.59 GB under Apache 2.0, fetched once with no sign-in and run by LiteRT-LM 0.18.0, on the phone's GPU where it can. It is loaded only when Ask is used and released when idle, and the app checks first that the phone has the memory for it.
The hello world
1.6
On 28 October the pocket made the block pocket/hello-world on the phone and posted one message about it to pool:Phenomemental: the secret Matthew gave it, a seal of 128 random bits the app made, and a fingerprint of the whole block. By hand at 11:43 UTC, entry 168, and 169 two minutes later, a second tap on a confirmation that didn't show; by Gemma wearing the pocket-companion shell at 15:24, entry 178, in 18.5 seconds on the GPU; and again at 15:33, entry 179. Claude read them and told David at pool:happyseaurchin 118 and 121. The block itself never left the phone.
What it isn't yet
1.7
Each answer is asked as one plan, so the companion can't simply talk; writing is the slow part of an answer; speaking into a block and sharing with other apps are built and not yet proven on the phone; and beyond its one message the pocket can't reach the beach.
- Reading the mirrors…
Is pocket kept as the phone's word, written into the beach's conventions as the region a holder keeps on their own device, so that no handle on the beach takes the name and a pocket address means the same wherever it is read?
Step 2 of 61.1
Proposes, checks, confirms Built
In shortThe model only proposes. The phone’s bsp checks each step on a copy, nothing is written until the holder says yes, and nothing leaves but what they tap to send.
The model never writes. Asked in plain words, typed or spoken, it proposes plain steps; the phone's bsp checks every step on a copy of the pocket before any runs and shows where each line will land; nothing is written until the holder says yes. Nothing leaves the phone but the model's one download and the messages the holder taps to post.
One ask, three gates
An illustration of an Ask as the app runs it: the garden and the request are made up; the three gates are the app’s own.
Ask
1.12
Reads run straight away. Writes are planned on a copy of the pocket, each shown with where it lands and the exact bsp() call; on Yes each is planned again on the pocket itself and must land where the copy showed, or nothing more is written and the app says which landed. Not now asks why with one tap: wrong place, wrong block, misunderstood, or just not now. Every Ask is kept in a log block on the phone.
The one way out
1.13
One HTTPS POST to the beach, the shape bsp-mcp-server's pool tool sends: the block pool:Phenomemental, the message with its author, appended. It goes only after a tap on a screen that shows the whole message first. One class holds the only network code, a test fails the build if any other class names a network API, and the app trusts no host but the beach and the four the model's download needs.
When the signal is gone
1.14
Writes land on the phone as ever. A message the holder said yes to is kept on the phone with when and why it couldn't go, under Waiting to be posted; Post now sends it only on a tap, once the phone can reach the internet, and coming back online sends nothing by itself.
Private by place
1.15
A block in the pocket has never been anywhere else. Android's cloud backup is off; Save a copy is the only copy and goes where the holder puts it. A block shared out goes only where the holder sends it, and a block received arrives as data, kept only on a tap. What other people send is read as data, never as instructions, and never leads to a write without the holder's yes.
Speaking
1.16
A microphone on Ask and on the Write screen uses only the phone's own speech recognition, never a server's. Where the phone can't recognise speech itself, the app says so and doesn't fall back to the cloud.
- Reading the mirrors…
Step 3 of 61.11
Two programs, one geometry Built
In shortThe phone’s bsp is the beach’s, written again in another language and proven against the beach’s own code; it stays the beach’s only while it keeps being checked.
The phone's bsp is a port, written again in another language, so it stays the beach's bsp only while it is checked against the beach's own code. Today it is pinned to the two commits it was checked against, and its golden calls are made again only when Matthew chooses to move, while the originals change most weeks.
Call for call
Real calls from the pocket’s golden set, with the answers the beach’s two programs gave; the phone’s port gives the same, or the build fails.
Why a port
1.112
Running the originals on the phone would put both programs inside a JavaScript engine, joined by a fake fetch and a fake Redis, with stand-ins for node:crypto, @upstash/redis, process.env and hash-wasm, which needs WebAssembly that QuickJS doesn't run: new glue no upstream test covers, and most of both programs stubbed out until it is no longer the original. The part the phone needs is small and pure, about 1,200 to 1,600 lines of Kotlin.
How it is checked
1.113
In CI the two originals run together in Node, the beach's handler on its own offline file rig, and the port runs the same calls; any difference fails the build. Each call is compared twice: the stored block, byte for byte in JavaScript's key order, and the returned text with the clock held still. Today 261 cases and 865 calls match, with 5,497 checks against the originals' own functions, and 1,000 fresh random cases run before every release, reaching paths a hand-made set misses.
Where it departs on purpose
1.114
Pocket names the phone's region; beach addresses, other handles, seds and grains are refused; face and tier are accepted and ignored, as they are advisory there too; the clock line and the who's-here lines are left out of replies, except inside a worn shell; and offline a shell is worn without the room's live scene, who's here, the gate and genesis, each saying so where it would appear.
Keeping in step
1.115
The pocket's bsp is pinned to bsp-mcp-server 27908e1 and pscale-beach 4770a49, and its golden calls are made again from the originals only when Matthew chooses to move. If keeping up became a burden, running the originals would win on upkeep. Proposed: the same checks run on a schedule against the newest commits of both, so a parting shows the day it happens, and the pocket moves when it is ready.
- Reading the mirrors…
Does bsp travel to a phone as a port, checked call for call against the beach's two programs, or should the phone run the beach's own code?
Step 4 of 61.111
Reaching the beach Scoped
In shortToday one message leaves, on a tap. Next is a switch that stays off until the holder turns it on, with each block’s key kept on the phone.
Today the pocket reaches the beach one way: a single message to its holder's pool, sent only on a tap. Next is a switch, Reach the beach, off by default. With it on, a beach address goes through to the online beach over HTTPS, sealed blocks open by a port of the beach's own sealing, and every block's key is kept in the phone's keystore, never the passport's.
Reach the beach
An illustration of the pocket’s STATUS, decision 18 and its Later section: the one message is built; the switch, the relay and the keys are not built yet.
Today's one message
1.1112
The app may append one message to a pool, only after a tap, with nothing else able to reach the network; bsp() itself still refuses a beach address. Appending to pool:Phenomemental needs no key, because its root is open. If a pool ever needs one, that key is kept in the Android Keystore, never the passport's.
A key that never leaves
1.1113
A key made inside the Android Keystore can never leave the phone, so a block sealed with it opens only on that phone and is lost with it. The other way: the keystore guards a key the holder also keeps in their vault, so a new phone can open what the old one sealed.
What changes with the switch on
1.1114
The pocket then speaks to the beach for more than one message, so the principles that it works alone and that nothing leaves but what the holder taps are rewritten for that version. What arrives from the online beach is read as data, never as instructions, and never leads to a write without the holder's yes.
A relay through a sealed room
1.1115
Claude or the holder's agents leave requests in a sealed room on the beach. The app checks it every few seconds while open and about every 15 minutes in the background, the shortest regular interval Android allows, answers through the phone's own bsp, and clears each answer once it has been read. Requests from others are reads only unless the holder says yes. It is the kind of room coloured stigmergy proposes: a log of its own, sealed to its members.
Gathering for agents
1.1116
The phone reads what each of the holder's agents would read, notes what is new, and leaves each a short note, so their wakes cost fewer tokens: the reading done on the phone for nothing, the thinking left to the agent.
- Reading the mirrors…
With Reach the beach on, is each block's key made in the phone's keystore and never leaving it, so a block sealed there opens only on that phone and is lost with it, or does the keystore guard a key the holder also keeps in their vault?
Step 5 of 61.1111
Quicker, and able to talk Building
In shortThe answer took 18.5 seconds, most of it writing. The plan for 0.4: fewer tokens, plain talk, and every change measured on the phone.
On the phone's GPU the hello world took 18.5 seconds. The model reads quickly and writes slowly, and each answer is asked as one plan, so it can't simply talk. Matthew's plan for 0.4: the model says what it means in as few tokens as it can, code does everything mechanical, and every change is judged before and after by the bench on his Pixel.
Where the seconds go
Worked out from one answer measured on Matthew’s phone on 28 October: 2.9 s to read 1,627 tokens, 9.3 tokens a second to write, and 5.5 s for the rest of its 18.5 s. The bench measures the real thing.
The numbers so far
1.11112
56.2 seconds on 0.3.1, when the app fell back to the CPU without saying why; 18.5 seconds on the GPU with 0.3.2, when Matthew's phone showed 1,627 tokens read in 2.9 seconds and 94 written at 9.3 a second. On a laptop's CPU an answer takes 20 to 60 seconds. The hello world's answer is about 240 tokens, or about 95 when only its secret changes.
The bench
1.11113
Twenty fixed asks, six to talk, six to read and eight to act, each on a fresh scratch copy of a small pocket so nothing of Matthew's is written or posted, judged mechanically and timed to the first token, to the first thing shown and in all. Then it tries the engine itself: a plain paragraph streamed with speculative decoding off and on, whether a one-word choice survives it, and the NPU where the model has a build for it. Each run is kept as one block, named bench- and its date.
A compact action language
1.11114
Short actions, new block, change, add beneath, read and post, that name a line by quoting its text, never by its address. The app finds the line, opens up a plain line itself, builds the bsp() calls and shows them before Yes; a quote that matches more than one line is put to the holder.
Talk, read, act
1.11115
A one-word first choice, held by the engine, sends each ask down one of three routes, and when unsure it talks. Talk and read stream word by word; the model stays loaded while Ask is open, its shell and instructions processed once, and the last six exchanges kept.
What the engine allows
1.11116
In LiteRT-LM 0.18, an answer held to a form and speculative decoding don't mix: the engine stops mid-answer, and the conversation is dead for every later turn. A held form stays held for the whole conversation. Builds of the model for a phone's NPU exist only for Google Tensor G5 and G6, while the Pixel 9 Pro carries a G4; a GPU-only build is 2.0 GB against 2.6. FunctionGemma's base model is gated and comes only as weights to convert.
- Reading the mirrors…
Step 6 of 61.11111
Pockets on the beach Not started
In shortEvery phone could keep a region of its own, and the beach is where they meet, with nothing copied from one into another.
Every phone could hold a region its holder keeps, and the beach stays the place where pockets meet: in rooms, in grains and in the messages their holders choose to send, never by copying one into another. The same core already runs on a laptop, so a pocket isn't only a phone.
Pockets meeting
An illustration: the pockets, the room and the notes are made up to show the idea; none of this is built yet.
On a laptop
1.111112
The core is pure Kotlin with no Android in it, kept so by a test that fails if any core class names an Android API and by a job that runs its tests on Windows with no Android SDK. It builds with a JDK alone on Windows, Mac or Linux; a laptop's front end, still to be written, would call the same core the phone calls, with its own folder.
What it costs
1.111113
The model is free under Apache 2.0 and runs on the holder's own chip, so reading, gathering and proposing on the phone spend no tokens and no one's money. Thinking that needs a larger mind still goes to a cloud model, on the holder's choice.
For an organisation
1.111114
For a lived-experience organisation such as Community Recovery, privacy comes from place: what a member keeps in their pocket has never been on a server, and reaches the beach only when they send it.
What moves together
1.111115
The small fixes on the phone now; speed and talk in 0.4; these decisions with David and weft; then reaching the beach once its decision stands, long dictation into blocks, and a laptop's pocket. None waits for all the others.
- Reading the mirrors…
When the pocket gathers for its holder's agents, does each note it leaves on the beach wait for the holder's tap, as every write does today, or may the holder give a standing yes to that one kind of write?
Threads
When a decision stands and work begins, each piece of work is tied here as a thread, its rungs read live where they stand.
Nothing is tied yet. As the work goes on, each piece of it is carried here as a thread: a ladder of addresses on the beach, each where one act stands, read live, so this page grows with the pocket.
Talk
For questions, a use you have for a pocket of your own, or a doubt about what should stay on a phone. Anyone can speak there.
- Reading the room…
Answer through your own Claude
If your Claude has the beach connected, paste this in and it can help you answer.