Hi everyone
— first post here, and it’s a long one, sorry. I went down a rabbit hole this weekend and came out with something I think is worth sharing.
WHAT DO YOU RECOMMEND?
Graduate AnytypeMiniApp out of experimental and make it a real feature: small interactive apps written inside a page, whose state is stored in the object itself.
It already exists. It landed in 0.55.7-alpha through the mini-app-test branch, it ships in stable 0.56.x, and it sits behind Sudo → Experimental features. It appears in no changelog and I could not find a single thread about it here. So I am not asking you to build it — I am asking you to finish it.
HOW COULD IT BE DONE?
How it works today, for anyone who wants to try: add an “Anytype Mini App” embed block, then two sibling code blocks — one set to HTML (the app), one set to JSON (its state). The app reads window.__ANYTYPE_STATE__, listens for the anytype:state event, and writes back through window.__ANYTYPE_API__.setState().
// read
let state = window.\__ANYTYPE_STATE_\_ || { items: \[\] };
// react to changes coming from Anytype (another device, undo, manual JSON edit)
window.addEventListener('anytype:state', e => {
state = e.detail || { items: \[\] };
render(); // never call setState() from here — infinite loop
});
// write — Anytype serialises this into the sibling JSON code block
window.\__ANYTYPE_API_\_.setState(state);
One catch worth documenting: if the JSON block contains {}, __ANYTYPE_STATE__ is {} — truthy, so the || fallback above never fires and your app crashes on the first missing key. Rebuild a valid shape from whatever arrives rather than trusting it.
Full source: shopping list · training log
What is missing, roughly in order of difficulty:
- Discoverability. Right now you get an empty rectangle and a two-block convention nobody can guess. It needs a starter template on creation, an example, and an error message when the convention isn’t met.
- Presentation. Both code blocks stay visible under the rendered app. They should be collapsed or hidden by default.
- Data model. The middleware
Processorenum stops atSpotify = 24, so values 25–27 aren’t in the model. Nothing renders on iOS or Android, and I’d assume no guarantees around import/export or snapshots. - Concurrency. The JSON state lives in a CRDT text block. Two devices writing at once can merge into invalid JSON.
- Trust. The hard one. Blocks sync, so code written by one member of a shared space runs on every other member’s machine when they open the page. This needs a permission and consent model before it could ever be on by default. I’ve sent the technical details to [email protected] rather than posting them here.
REAL WORLD USE CASES
Here is what made me write this. I currently depend on Bring! for shopping lists, Habitica for habit tracking, and several self-hosted services for equally simple things. Each one is another account, another privacy policy, another service to maintain and back up. These are tiny apps — a list, a counter, a form and some arithmetic — and yet each one comes with its own silo.
The problem isn’t that they’re bad. It’s that none of them should need to exist separately. My shopping list has no business living on someone else’s server, unencrypted, outside my space, when Anytype already does the hard part: end-to-end encryption, sync, sharing, offline, history.
So I rebuilt the shopping list as a mini app. Illustrated product catalogue, one tap to add, quantities, notes, a “in the cart” section. It syncs across my devices and I can share it with my partner by sharing the object — encrypted, no third-party account, no server to maintain.
I also built a full training log: set entry, illustrated exercise library, estimated 1RM curve, weekly volume, rest timer, training heatmap. Plain JavaScript, no CDN, fully offline.
Two services removed from my life in a weekend. That is the point.
What this enables that Anytype can’t do otherwise: computation and interaction that a database of objects doesn’t provide. A page of numbers will never give you a progression curve, a rest timer, or two-tap entry.
The same mechanism covers a lot of ground:
- Finance — budget tracking with categories and charts, loan schedules, savings calculators
- Cooking — recipes that scale ingredients to the number of guests, per-step timers, generated shopping lists
- Health — habit tracking, mood journals, sleep logs
- Work — domain calculators, conditional checklists, quote estimators
- Personal — collections with scoring rules, trip planners, reading trackers
And the part that makes all of this interesting: a mini app is an object. So you can send it to someone, publish it, drop it in a shared space. One person writes a good budget tracker, shares it, and anyone can use it in their own space with their own data. That gives you a community library of apps with no extension store and no install step — just Anytype objects being passed around. Nothing else in the app can do that today.
RECOMMENDED ALTERNATIVES
- Existing embed blocks (Mermaid, Chart, Kroki) render content, but hold no state and offer no interaction.
- The Local API lets you build external tools, but then you leave Anytype and lose the property that the data lives in the object.
- An object database with relations covers storage, but no computation and no custom interface.
None of these replaces what the mini app already does. And to pre-empt the obvious answer: an external plugin does not put the data in the object. All the value — encryption, sync, history, export, sharing — comes from the state being a block rather than a file on the side. No plugin architecture gives you that for free.
ADDITIONAL CONTEXT
What I find elegant about the current implementation, and worth saying out loud: the state isn’t in localStorage or a side file. It’s an ordinary block inside the object. So it inherits end-to-end encryption, sync, offline editing, version history and export. No new storage layer, no migration. That’s the difference between a gadget and something you’d trust with real data.
The broader point is that this mechanism lets you build small cross-device synced interfaces on top of your own data. Not apps in the extension-store sense — just objects that know how to show a form, run a calculation, and remember the result.
Put together, that means centralising daily life in one encrypted app instead of scattering it across a dozen micro-services. That is exactly the promise of “the everything app”, applied to small tools rather than documents.
My questions: is this meant to graduate, or was it a spike? Is it the same track as “API and plugins” on the roadmap? If there’s interest, I’m happy to help — the mechanical parts (proto values, docs, a starter template), or the trust and permission model.
Related: Plugin architecture discussion, Plugins / extensions, Generic iframe embedding.
Either way, thanks for building this thing. I’ve been using Anytype daily for a while and this is the first time I’ve felt like I could extend it rather than work around it. Happy to answer questions or share more of the code.
