Abstract
Kloppy asks a practical question: can a desktop assistant be fun enough to spread, useful enough to keep, and private enough to trust? The project uses an approachable character to explore serious issues in LLM distribution, desktop automation, local memory, user controlled data, and the future of personal artificial intelligence.
Kloppy v0.1.0 is intentionally small. It ships notes, reminders, tray presence, opt-in folder commentary, local storage, and chat through a user-chosen local llamafile. These are a foundation for testing how users respond to an assistant that behaves like software they own rather than a remote service they rent.
Purpose
Many assistant products begin with impressive model capability and then search for durable user behavior. Kloppy begins from the other direction. It studies attachment, routine, desktop presence, humor, and small daily utilities as a path toward a trusted assistant surface.
The parody exterior is useful because it lowers the emotional temperature around AI. A funny paperclip can ask for permission, fail visibly, explain what it remembers, and make constraints feel understandable. That creates space to test serious privacy and ownership patterns without presenting the assistant as magic.
Research Questions
- Can a lightweight desktop assistant create daily utility while keeping model-powered features local and optional?
- Can users understand and value local memory when it is represented through simple files and clear interface language?
- Can LLM capability be distributed in layers, with local utility available before a user chooses a local model?
- Can humor increase transparency rather than obscure it?
- Can an assistant be designed as user owned infrastructure instead of a service that captures user behavior?
Architecture
The current desktop app is built with Electron, plain HTML, CSS, and JavaScript. The main process owns file access, lifecycle behavior, tray state, and validation. The renderer presents the interface and talks to the main process through a narrow preload bridge.
The architecture is intentionally boring in v0.1.0. That is the point. Trust starts with inspectable boundaries, explicit model setup, and a local-only chat listener.
Privacy Model
Kloppy treats local storage as the default. Notes, reminders, settings, watched-folder metadata, and memories are stored in the operating system app data folder. v0.1.0 does not require an account, telemetry, or cloud sync.
Current boundary
- The renderer cannot directly read or write arbitrary files.
- The main process validates note and reminder input before writing to disk.
- Folder watching is opt-in, observes top-level names and events, and does not read file contents.
- The only external app request is the optional model download a user explicitly starts; its checksum is verified.
- After setup, chat runs through a local llamafile bound to
127.0.0.1.
LLM Distribution
Kloppy operates as a useful local app without model access, then adds chat through explicit user choice. v0.1.0 supports a local llamafile only. Remote or hybrid model support remains a research direction, not a shipped claim.
Layered capability model
- Layer one: local utility, notes, reminders, tray presence, settings, and visible storage.
- Layer two: local chat through a user-chosen llamafile, with notes, reminders, and app context exposed through validated operations.
- Layer three: possible remote model calls for tasks that exceed local capability, only with clear consent and clear data boundaries.
- Layer four: user controlled portability, including export, import, model provider choice, and transparent history.
Assistant Design
Kloppy uses character as an interface primitive. The character gives the assistant a memorable shape, but the design rule is that personality must never hide agency boundaries. When Kloppy knows something, the user should know why. When Kloppy stores something, the user should know where. When Kloppy cannot do something, the failure should be visible.
The assistant should be ambient without being invasive. It can live in the tray, remind the user, hold small bits of memory, and provide commentary, but the user must be able to inspect, pause, delete, and quit.
User Owned AI
User owned AI means the assistant should be accountable to the person running it. That includes data portability, local first defaults, provider choice, understandable memory, and a path to use the assistant without surrendering routine personal data to a central account.
Kloppy does not solve all of this in v0.1.0. The release proves that a small assistant can behave like owned software while providing local model choice, local memory tools, and explicit setup controls. Portability and broader provider choice remain future work.
Technical Roadmap
Risks And Mitigations
- Novelty risk: The character could be loved briefly and then ignored. The mitigation is to ship useful routines before model spectacle.
- Trust risk: Assistant products can feel invasive. The mitigation is local first storage, visible memory, and clear consent for model calls.
- Scope risk: User owned AI is broad. The mitigation is a small MVP with explicit layers and a roadmap that grows from utility to intelligence.
- Distribution risk: v0.1.0 is packaged but unsigned. The mitigation is exact warning instructions, published checksums, and future signing and notarization.