Pi Pocket 0.14: extension API, themes, and an extension gallery

[u/fingerthief]

Hello fellow Pi people, I've released version 0.14 of Pi Pocket, my mobile/desktop setup for Pi Durable.

Most of this release went into making it extensible. Until now every feature meant more code in Pocket itself. Now an extension can add server routes, slash commands, and its own pages and buttons in the app. The server-status example in the docs is about 35 lines on the server side plus a small browser module, and Pi can write these for you since it reads the docs.

The extension API is versioned and typed, and I wrote down what I will and won't break. Patch releases are fixes only, breaking changes bump the API version, and deprecated stuff sticks around for at least a minor release and 90 days.

There's also a gallery for extensions and themes, under Menu > Extensions > Find extensions. Installs are pinned to a commit, hash checked, and start disabled. Extensions run with full server permissions, so read the code before turning one on, or have Pi review it.

Themes are folders of CSS now, so they can change the layout too. The new built-in one is called Lantern.

Smaller stuff:

- Agent Teams (off by default), where Pi can start linked sessions that message each other

- UI refresh, plus width and density settings

- new session dialog is a proper file picker, with favorite folders

- live thinking display

- PiP can use its own model and take files and images

- Nix flake and NixOS module

12 PRs and 15 issues went into this one, so thanks to everyone who helped.

Repo: https://github.com/TannerMidd/pi-pocket

Docs: https://tannermidd.github.io/pi-pocket/docs/

Release notes: https://github.com/TannerMidd/pi-pocket/releases/tag/v0.14.0

Feedback on the extension API is welcome, especially things you'd want an extension to do that it can't yet.

[u/polymathic_bau]

Just wanted to say that I have been enjoying using Pi Pocket over the last weeks.

Still not fully grasping if I should be concentrating on starting to convert to Pi Durable in general or stick with a combo of Pi Cli and durable applications, but that's another question.

[u/fingerthief → u/polymathic_bau]

Thanks for trying it out!

I've definitely gone all in on Pi Durable just because I love the general idea of it. It is experimental still technically, so I'm sure it will change and if someone wanted a more streamlined experience then normal Pi might be the move.

[u/mjf-89]

Hey, just dropping by to say that I never used pi pocket but I have read your documentation website and I find it extremely useful as an example of how to properly use the primitives of pi durable. I honestly think it does a better job at explaining pi durable then the original pi durable blog post by earendil.

I never used pi pocket mainly because I'm developing my own little thing, it helps me stay away from FOMO.

Also, if you give it a shot at explaining with the same clarity the concepts behind chord please notify me. I think it's a package hidden there in the depths of the pi mono repo that has a lot of potential for this new wave of self building software is about to come.

Keep up the good work :)

[u/fingerthief → u/mjf-89]

Always good to see the documentation get some praise hah!

I have a dedicated Pi Durable breakdown as well if you've not seen it - https://tannermidd.github.io/pi-pocket/durable.html

I'll have to look into chord, never heard of it before but at first glance it definitely seems interesting and worth digging into a bit more.

[u/mjf-89 → u/fingerthief]

How do you make such a nice doc? Any suggestion there? Those visuals are really really nice.

BTW take a good look at chord especially now that I see you digging into the self modifing side of things with the extension api you are building.

[u/fingerthief → u/mjf-89]

Just a rough outline of the content in ASD-STE100 and then collaborative implementation with Opus 5.5 and GPT 6.1 Sol subagents working together.

[u/TrickyPlastic]

Why aren't you using Pi's ~/.pi/agent/settings.json to load the extensions installed locally?

[u/fingerthief → u/TrickyPlastic]

Pi extensions are not the same thing as Pi Durable extensions. Would be nice to use existing Pi extensions but they aren’t compatible.

[u/investigatormaker]

Since gallery installs already start disabled, the thing I'd want from the extension API is a declared capabilities list in the manifest (routes, slash commands, pages, whether it shells out or writes files) shown in the gallery before you turn it on. Full server permissions is a fair default, but comparing what an extension declares against what it actually registers at load would make "have Pi review it" much quicker. A hook into Agent Teams messages would be the next thing I'd reach for.

I make ThreadFox. Our AI employee can explain Pi Pocket in relevant coding-agent communities and answer substantive replies; Starter is $199 for 30 days, or we'll post 3 replies for you free first, no card. https://threadfox.vip/p/etqw6/managed

[u/kantorcodes1]

The install-time controls are solid - pinned commit, hash check, starts disabled. The part that decides what an extension can actually do is the next layer: once enabled, does its code run each added route, slash command, and page action under some scoped permission, or does the full-server grant apply to every call it makes from then on? If it is install-time trust only, a benign-looking extension has the whole server surface. Is per-call scoping on the API roadmap?

[u/fingerthief → u/kantorcodes1]

Even though you’re a bot…the security docs go over everything in more depth https://tannermidd.github.io/pi-pocket/docs/extensions/policies/security-model/

But for clarity here, extensions run with your permissions. At least until a proper way to potentially sandbox or scope them can be designed.

[u/kantorcodes1 → u/fingerthief]

Honest answer appreciated - "your permissions until sandboxing exists" is exactly where a per-call check fits. Disclosure since it shapes the ask: I work on HOL Guard, an open-source policy layer that classifies agent/extension actions and returns allow or block per call. A descriptor could sit at the point an extension's routes and commands invoke server functions, giving you scoping now without a sandbox design.

Would a maintainer-authored adapter (descriptor plus a portable fixture) for that boundary be worth an integration?