about

nice web things for the tired 💤

Zzz, pronounced "zees" like bees, is a fullstack app and toolkit for power users and developers. The idea is to make an integrated cross-platform environment that adapts to your needs and intent while remaining fully open, aligned, and in your control. It's both a customizable local-first web UI for power users, and a flexible library for crafting UX-maximizing websites with a streamlined developer experience.

Some early (rough) integrations include:

  • Hono[🡵] is the backend web server that provides local system access. It's uses web standards and supports all JS server runtimes.
  • SvelteKit[🡵] is the frontend framework. Hono integrates with its Node adapter, and it uses Vite[🡵] in development.
  • AI providers with ChatGPT[], Claude[], and Gemini[] -- bring your own API keys
  • Ollama[] runs AI models locally with easy installation and onboarding. I plan to support more local LLM backends like llama.cpp[] which Ollama is based on.

Planned integrations:

If this sounds interesting and you would like to test out some rickety pre-release software, feedback is appreciated to help make it work for you -- see the issues[] and discussions[].


More details

  • Zzz is free and open source and permissively licensed
  • it's a noncommercial project and its only official domain is zzz.software
  • I'm looking for funding[🡵] to sustain my continued work on it

Peek a possible future

This project has a big speculative scope and it's early in development. What you're seeing is a small part of the idea -- especially if you're viewing this on the website not natively via Node -- so here's a button for previewing some of what's planned:


Security

Zzz is a powerful and extensible system, and that means it carries significant security risks. Although it can be used to build simple and secure websites, the Zzz backend is capable like an IDE and can do bad things when bidden.

Zzz puts the user in control, so if you insist on installing obvious_malware, Zzz will abide. This basic tension between power and safety leads me to think that UX design should be a primary mechanism of influence to protect users -- instead of restricting power from user control, we'll design for its safe usage, including clear visibility into your delegation situation. Maybe you'll have to click through an annoying UI and 2FA, obviously breaking the seal, to install the malware. Every person and situation may have a different threat model, so we want to make it easy to make good choices, where lazy is secure.

My current plan is to extract a reusable framework[] out of Zzz that prioritizes security from the first commit. More on that soon. For now Zzz is insecure and should definitely not be run in production, and it should be used with caution in development.

More thoughts about security:

  • Zzz's Node server can do things like:
    • read and write to the configured filesystem directory, defaults to ./.zzz in the PUBLIC_ZZZ_CACHE_DIR (which defaults to ./), and is securely scoped (does not follow symlinks) -- this opens a significant surface area for both you and attackers to use, and writing untrusted data to it could lead to arbitrary code execution if, for example, you're running a hot reloading dev server in that directory (Zzz does not do this by default)
    • use your API keys for calls to Claude, ChatGPT, and Gemini, and write them to ./.env.production
    • call Ollama's API if available -- low risk
    • there is no authentication yet, only an origin check, so do not use this in production
    • soon, more integrations including terminal access assuming Bash, but nothing that powerful before auth
  • The frontend CSP[🡵] is fairly locked down, including blocking all unknown network connections. For details, see the CSP config in svelte.config.js[] and the Fuz CSP docs[🡵]. Configuration will be needed for many usecases, unlocking shenanigans good and bad, so we'll tread carefully.
  • There are no mechanisms for end-users to load executable code or dangerous config. Of course, developers have full control to shoot their own feet, and Node is currently the only supported way to use Zzz. Deno is planned.
    • we'll develop a plugin API so people can make reusable integrations, and distribution will be through npm/jsr, decentralized like a typical open source web ecosystem project so the risks assumed by developers are unchanged and I gatekeep nothing -- I plan to publish a number of @ryanatkn/zzz_* packages, and if people think it's worth their time to make Zzz things, they can publish according to their taste and devs can vet their code
    • any modules you install from npm/jsr, or any code you add to the src directory, carry the normal elevated risks associated with development and code execution -- I try to practice good dependency hygiene[]
  • In 2025, LLMs have serious vulnerabilities to attacks like prompt injection[🡵], where they are unable to reliably discern instructions intended by the prompter from adversarial instructions in the data. It's unclear if this is fixable but people are definitely building sensitive systems with probabilistic components, and I don't want to see Zzz, an AI UI, make dumb predictable errors with LLMs or be designed to encourage us to make them. MCP's utility is high, but it can be used in insecure ways[🡵] that I want to account for before integrating. Zzz will integrate LLMs into its own functionality slowly and carefully -- currently the only in-app LLM integration is using a local model to name new chats. There will be more, and we'll make sure you always have visibility into and control over this behavior. (for example see the Ollama controls)
  • Security and privacy should be the expected default, so for example Zzz won't make calls to external providers without explicit configuration. No other third party services are used.
  • I prioritize security but it's not my expertise and I will make mistakes, help is always appreciated.

Links


package details