HN Debrief

Kobo can run apps now

  • Hardware
  • Open Source
  • Developer Tools
  • AI
  • Consumer Tech

The post introduced Cobalt, an open source environment for Kobo e-readers that aims to make them app-capable without asking each app author to reinvent low-level e-ink plumbing. The author framed it less as a tweak to Kobo’s stock reader and more as a platform with an SDK, simulator, app lifecycle, UI support, partial refresh handling, touch input, Bluetooth, declared capabilities, and an app store that works over Wi‑Fi after the first USB install. Right now that ambition is much bigger than the compatibility list. Commenters noted it is tested on a single Clara BW configuration and refuses unsupported models rather than trying to muddle through.

If you care about owning and extending your hardware, Kobo remains one of the friendlier e-reader ecosystems, but today the mature tools are still NickelMenu, KOReader, Plato, and in some cases postmarketOS. If you might depend on Cobalt, treat it as an early platform experiment until it supports more devices and proves it can be maintained reliably.

Discussion mood

Interested but cautious. People liked the idea of a more structured Kobo app platform and praised Kobo’s openness, but the mood was tempered by concern that most users do not want app-store complexity on an e-reader, by practical device limitations, and by strong distrust of the project’s obvious LLM-generated code and copy.

Key insights

  1. 01

    Cobalt is a runtime, not just a launcher

    It fills a gap between simple menu extensions and full standalone apps by giving developers the boring but hard parts in one place. That changes the value proposition from "you can launch hacks" to "you can build Kobo-native software quickly". The security model also matters. Apps run as separate unprivileged processes with declared capabilities instead of inheriting root through stock Kobo processes, which is a cleaner foundation if this grows beyond hobby use.

    If you are evaluating this as a platform, compare it to an SDK and runtime, not to NickelMenu alone. If you already have a Kobo app idea, the key question is whether Cobalt’s abstractions are stable enough to save you from writing device-specific e-ink glue yourself.

      Attribution:
    • thepoet #1 #2
    • the-grump #1
    • podgietaru #1
  2. 02

    Best modding hardware and best reading hardware diverge

    The comments make clear that Kobo buyers are stuck between performance and display quality. Color models bring faster internals on some devices, which helps with Wi‑Fi, Bluetooth, and heavier software, but many readers still prefer black-and-white screens because the issue is contrast more than raw sharpness. That means a device that is pleasant for long-form reading can still be a mediocre target for ambitious apps.

    Choose hardware based on your primary job. If you want a reader first, optimize for screen contrast. If you want an e-ink Linux gadget, prioritize CPU and memory even if the screen is a compromise.

      Attribution:
    • the-grump #1
    • charles_f #1
    • ololobus #1
    • pepperoni_pizza #1
    • mkozlows #1
    • II2II #1
    • ironqcold #1
  3. 03

    PostmarketOS already covers the full Linux route

    For people who want a Kobo as a general-purpose e-ink computer, postmarketOS is the more direct answer. One commenter pointed to a Clara setup running Firefox, Syncthing, and KOReader, which highlights that Cobalt is not trying to be a full replacement operating system. It is a narrower path that keeps closer to the stock device while still enabling apps.

    Decide early whether you want an app platform on top of Kobo firmware or a full Linux conversion. That choice determines your risk, compatibility work, and how much stock Kobo functionality you keep.

      Attribution:
    • yoavm #1
    • erelong #1
    • nosioptar #1
  4. 04

    The demand is for focused reading-adjacent apps

    The app ideas that kept coming up were not games or generic computing. People wanted an OPDS client, Libby access, Zotero sync, Obsidian or markdown viewing, Anki support, better highlight review, and lightweight note workflows. That is a strong signal that the promising niche is software that extends reading and studying, not turning the device into a slow tablet.

    If you build for this ecosystem, ship narrow tools tied to reading, notes, library sync, and study workflows. Those fit e-ink well and avoid the "worse phone" objection that hurt enthusiasm.

      Attribution:
    • mawise #1
    • bragr #1
    • GlenTheMachine #1
    • locusofself #1
    • inatreecrown2 #1
    • quasarj #1
  5. 05

    Kobo wins on control more than features

    Kindle owners were not just jealous of novelty. They were frustrated by Amazon’s locked-down appliance model, weak file handling, ads, awkward sideloading, and UI decisions that push curation over ownership. Even commenters who preferred a single-purpose reader still liked that Kobo users can choose to keep it simple or replace large pieces of the stack with KOReader, plugins, and now possibly Cobalt.

    If device ownership and custom workflows matter, Kobo has strategic advantage over Kindle even before Cobalt matures. That makes Kobo a better base for startups or hobby projects that need user-controlled reading hardware.

      Attribution:
    • kioleanu #1
    • SpecialistK #1
    • cs3f16 #1
    • adezxc #1
    • RattlesnakeJake #1
    • pmkary #1
    • utopiah #1
    • toomuchtodo #1

Against the grain

  1. 01

    An app store breaks the e-reader contract

    For a lot of readers, the whole point of the device is that it stops at books. They do not just ignore extra features. They actively value the absence of options, because that is what makes an e-reader feel different from a phone, tablet, or laptop. From that perspective, adding apps and internet workflows does not enhance the product. It turns it into a worse version of devices they already own.

    If you build on e-readers, keep the product story disciplined. Features that smell like general-purpose computing will lose people unless they clearly preserve the low-distraction reading experience.

      Attribution:
    • brailsafe #1
    • mattcasmith #1
    • VariousPrograms #1
    • nocchedure #1
    • luciana1u #1
  2. 02

    LLM-heavy projects face a trust discount

    The strongest negative reaction was that obvious AI-generated copy and a vibe-coded development style make the project feel disposable. People were not objecting to AI on principle so much as using it as a proxy for weak testing, shallow documentation, and low commitment to maintenance. On a project that touches device internals and asks users to install a new platform, that credibility hit is material.

    If you are launching developer infrastructure, polish the human-facing parts first. Tight docs, clear compatibility claims, and visible testing work are not cosmetic. They are how you earn trust before anyone inspects the code.

      Attribution:
    • KennyBlanken #1
    • bigstrat2003 #1
    • hexasquid #1
    • code-blooded #1 #2
    • QwenGlazer9000 #1
    • mawise #1
    • facepalmz #1
    • ricardobeat #1
    • wbxp99 #1
    • mortenjorck #1

In plain english

Anki
A spaced-repetition flashcard system used for memorization and study.
Bluetooth
A short-range wireless standard used to connect devices like speakers, keyboards, and remotes.
Claude
A family of large language models and AI assistants made by Anthropic.
e-ink
A reflective display technology used in e-readers that looks paper-like and uses very little power when showing static content.
framebuffer
A low-level memory area that software draws into in order to display graphics on a screen.
KOReader
An open source document and e-book reader used on e-readers and other devices as a replacement for stock reading software.
Libby
A library lending app and service for borrowing e-books and audiobooks from public libraries.
LLM
Large Language Model, a machine learning model trained to generate and analyze human-like text.
Markdown
A lightweight plain-text formatting syntax commonly used for notes, documentation, and README files.
Nickel
Kobo’s stock reading software and user interface on the device.
NickelHook
A Kobo modding project that adds hooks into the stock Nickel software so developers can intercept or extend its behavior.
NickelMenu
A long-running Kobo customization tool that adds menu entries and can launch commands or other software from the stock Kobo interface.
Obsidian
A Markdown-based note-taking application that stores notes as local files and supports plugins and custom metadata conventions.
OPDS
Open Publication Distribution System, a catalog format used to browse and download e-books from online libraries and servers.
partial refresh
An e-ink screen update technique that redraws only part of the display to reduce flashing and improve responsiveness.
Plato
An alternative open source reading application for e-readers, often used on Kobo devices.
postmarketOS
A Linux distribution for phones and other mobile devices that aims to keep hardware usable for a long time.
root
Administrator-level control over a device's operating system, which allows deeper access and modification than normal apps or users have.
SDK
Software Development Kit, a bundle of tools and code libraries developers use to build apps.
Syncthing
An open source tool for syncing files directly between devices.
thin client
A device that does little processing itself and mainly serves as a simple interface to remote services or computers.
vibe-coded
Slang for software built heavily through AI prompting with limited visible rigor in testing, review, or engineering discipline.
Wi‑Fi
A wireless networking standard used to connect devices to local networks and the internet.
Zotero
A reference manager used to collect, organize, and cite research papers and other sources.

Reference links

Alternative Kobo and e-reader software

Device references and comparisons

Kindle and ownership context

  • KindleForge video
    Given as an example that jailbroken Kindles can also gain app-like functionality.
  • Fulu
    Linked in a comment about ownership, choice, and resisting locked-down appliance behavior.
  • HN search for enshittification
    Used rhetorically in the Kindle control and platform lock-in discussion.