thepoet

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.

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.

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.