thepoet

More than ambitious, I can now build things I had no time for but had the idea and architecture in place since long. A cool side project for me recently has been to allow reading more than books on my Kobo reader. I built an SDK and apps that allows e-ink apps with sandboxing and permissions model, auto-updates, shared capabilities etc. to be built for Kobo https://github.com/BandarLabs/Cobalt

I suspect also to do with internal Slack etc. where employees vote on launch posts (a lot of them on HN since long). Not a scam or accusing anyone but this probably propels a lot.

Yes absolutely, the current Kobo one uses the Mac's mic. I work near a window on my Mac so this is handy without any hardware setup.

If you have a Kobo (~ US$ 120 or even less used) you can run this using Cobalt https://github.com/BandarLabs/Cobalt/tree/beta/apps/birds

Perfect! BW should work the best as it is the one I test on. We have merged the Libra branch to main, it will still show grayscale but should work. I am working with contributors on adding Color support to the UI components.

Yes, issues is where we are talking currently, though we have started a sub on Reddit too for those who are not on GitHub and want to share suggestions, bugs, app requests /r/CobaltForKobo

Current priority is a stable SDK, support for oauth and token for adding apps like Dropbox, read later ones etc. and a larger app ecosystem eventually.

Hey, we have merged support for the Color devices, actual colorful displays still testing. Let me know if you would like to test it. Happy to get any feedback on this.

Thanks! Can you please create two separate issues in the project for both Elipsa Gen1 support and the other for the stockfish and tailscale client implementation support. Would love to discuss and collaborate with you on both. I would need your help to test on the actual Gen1 device.

There are current issues and PRs for Clara HD and Color devices support so we can take it up by common generations.

I can help to port it for your device if you can help by testing it on your Color.

This project has an OPDS client implemented as an app example here, tested on Gutenberg's OPDS and standard eBooks. https://github.com/BandarLabs/Cobalt/tree/main/examples/gute...

Thank you for the kind words. I will add a page to the project explaining the differentiation.

NickelMenu is a mature project and perfect at what it does, we just have different goals. NickelMenu is designed to extend Kobo's stock interface. Cobalt is designed to be an app platform like Android has for example. I wanted app creators to just write their app logic and not build things like a UI toolkit for their apps, app lifecycle and rendering support (framebuffer drawing, partial eInk refreshes, touch input handling etc.), bluetooth handling, sensor and more. Anything launched through NickelMenu like KOReader or Plato have to implement these on their own.

AFAIK NickelMenu command actions spawn arbitrary shell cmds that inherit root from Nickel, we avoid it by running apps as separate unprivileged processes with declared capabilities like network, storage, audio, fronlight etc.

I also wanted to provide ability to quickly build apps with the SDK and our simulator to test apps on before putting it on the real device, an app store to get new apps over the WiFi after the initial USB install.

This was more oriented on making my life easier, say I have an app idea that I want on my Kobo tomorrow and how quickly can I bring it live on the device. The 'you can run apps' I wrote was meant to signify anyone can now create apps using the SDK without bothering about the device specific bits and publish them and install it via Cobalt's app store. I hope this clarifies things.

Hey, author here. NickelMenu is terrific and Cobalt uses it to show the menu item in the default Kobo menu. It's just that Cobalt and NickelMenu are not the same in terms of project goals.

I created this as I could not find anything existing that gives the capabilities I wanted. I read several things downloaded over web apart from books on my Mac and phone, which I would prefer to do on an eInk display. Search papers on arxiv and read them offline later, Substack, even spending a lot of time on chess puzzles, monitor my Claude/Codex remotely, generate explainer audiobooks and listen to them on my bluetooth speaker etc.

The longer battery and the display makes some use cases really shine and I wanted to create apps for my own Kobo and potentially helpful for others as well.

Thank you for this! This is perfect and what I was looking for while building the UI components for an SDK for Kobo e-ink apps https://github.com/BandarLabs/Cobalt

I have high myopia that is progressively getting worse so started working on building an app development platform for my Kobo eReader so that I can live without my mac and phone. https://github.com/BandarLabs/Cobalt

Have built the SDK and some apps like an HN Client, ChatGPT client, Claude Code permissions sidekick, RSS Reader, some games etc. (all in the same above repo)

It has 8x less powerful hardware than a modern raspberry pi but runs Linux with an eink display, wifi bluetooth and a good battery life for $100 or something.

NickelMenu is fantastic for adding custom buttons and some extra. We use it to display the Cobalt entry button on the stock Kobo interface.

This SDK provides more of an android/iOS type framework to use underlying hardware like bluetooth, wifi, battery and a bunch of UI components for creating complex apps with eink rendering, notifications, managed windows, OTA updates, a simulator, a sidekick mode for your apps and more.

I have a Kobo that was kept unused in a similar state for a few years until I decide to build an SDK platform to develop and deploy apps on it. My Kobo does not support apps on its Linux platform.

I have been using it to read HN, as an RSS reader over my news and blog sources, generate audiobooks on topics I want to understand with ElevenLabs, Exa and OpenAI and listen via connecting its bluetooth to my speakers and even as a remote Claude Code & Codex approval sidekick.

It is amazing that a $100 device with a single core and 512mb RAM can do so much and run for so long.

Here is the open-sourced platform https://github.com/BandarLabs/Cobalt

I have tried to do this, but most newer Kobo cannot due to CPU architecture support limitations. https://wiki.postmarketos.org/wiki/Kobo_Clara_BW

The older ones which do are severely restricted in features, and often end up with several issues. Have you tried it personally?

A bit idealistic for the crowd here but has some good points.

The other day I wanted to build personal apps for my Kobo device. It has a single ~800Mhz core and 512 MB of RAM, probably eight times less than a rasbperry pi, but runs a Linux.

I wanted to break free from watching my laptop screen for long Claude sessions partially due to degrading eyesight and have a sidekick for approvals streamed to the Kobo. Apart from the Claude and Codex permissions sidekick done via hooks, I ended up building an entire SDK, an HN client, an RSS discovery & reader and an audiobook generator using deep research and ElevenLabs API all running on it.

Anyone using an LLM can now personalize it for their own Kobo device, which might have some nuances over my Clara BW. Significantly less work I hope than doing it all from scratch even with a coding agent.

https://github.com/BandarLabs/Cobalt

An earlier larger discussion 22 days ago on this https://news.ycombinator.com/item?id=48834924

We will be soon including this in Tarit, a firecracker alternative https://github.com/instavm/tarit

Currently we have to supply a kernel to run the OCI as a microVM with a warm pool.

  TARIT_KERNEL=/path/vmlinux

  taritd image build --oci ubuntu:24.04 --name ubuntu
  taritd vm create --image ubuntu

Yes, we have been using this internally too. If you use it and encounter any bugs or have ideas for improvement, please file it. I will have a look.

Interestingly we did a version of a shared communication bus over MCP here https://github.com/instavm/murmur

The idea being mostly to use all of the coding agent subscriptions which are much cheaper than API access in order to delegate tasks, break down into chunks and distribute or even the standard coder/reviewer pattern.

Hey, this is exactly what we do at https://instavm.io Agents get persistent storage that outlive the sandbox and when the agent spins up again you get access to the computer with same files.

The images or rather portable artifacts rehydration on any platform plus the packaging is neat. I have been working on https://instavm.io for some time around VM based sandboxes and related infra for agents and this is refreshing to see.

Hi Ben, one of the founders of InstaVM here. Congrats on the launch!

Here is a feature tour of InstaVM https://instavm.io/blog/meet-instavm-infra-for-your-agents We would be publishing on the tech soon.

Would love to give you a demo of InstaVM and trade notes. Let me know [email protected]

One of the things that makes Clawdbot great is the allow all permissions to do anything. Not sure how those external actions with damaging consequences get sandboxed with this.

Apple containers have been great especially that each of them maps 1:1 to a dedicated lightweight VM. Except for a bug or two that appeared in the early releases, things seem to be working out well. I believe not a lot of projects are leveraging it.

A general code execution sandbox for AI code or otherwise that used Apple containers is https://github.com/instavm/coderunner It can be hooked to Claude code and others.