NODUVI SYSTEMA computer
that runs on skills.
Plug in a skill. Get work done.
A local-first work computer built around modular capabilities, understandable permissions, and deliverables people can review.
01 / Vision
NODUVI brings tasks, tools and results into a personal computer-like workspace. A user chooses a work cartridge, defines a task, grants the required access, and receives a file or report they can inspect.
The unit of value is a completed piece of work: a project brief with source links, a draft grounded in supplied facts, or a website report with observed responses. The workspace keeps the task and its evidence together.
The design follows the physical computer in the NODUVI identity: a cream enclosure, a readable screen and a replaceable green cartridge. Modularity is intended to be visible in the interface and in the execution boundaries.
02 / Work cartridges
A cartridge bundles a purpose, an execution method, declared access and a deliverable format. The initial release includes three built-in cartridges.
| CARTRIDGE | CURRENT EXECUTION | DELIVERABLE |
|---|---|---|
| Project Radar | Read up to five public HTTPS pages; compare page-text hashes with saved successful snapshots. | Dated Markdown brief with source URLs, page excerpts and change status. |
| Content Studio | Format user-supplied facts into a release draft, short excerpt and review checklist. | A Markdown content draft. Default generation is rules-based. |
| Site Watch | Read source pages and check up to three same-origin links per source. | HTTP status and sampled link inspection report. |
Optional AI assistance can refine collected evidence or supplied notes when a model is configured on the server and the user authorizes a paid request. No language model is required for local execution.
Planned: third-party cartridge packaging, signed releases, compatibility requirements and a unified install-to-execution interface. The current work cartridges are built in; the legacy component marketplace remains a separate reference interface.
03 / The work lifecycle
- Choose: select a cartridge by the output required.
- Define: enter a task title, source URLs or verified source notes.
- Authorize: approve storage, public web access where required, and optional model data sharing.
- Execute: run the task and inspect progress logs. Tasks can be cancelled.
- Review: read the report, warnings and supporting evidence.
- Keep or remove: download Markdown, reuse task inputs or delete the task and its deliverable.
Execution states include queued, running, completed, failed, cancelled and interrupted. A server restart marks unfinished work as interrupted. When all source retrievals fail, the task fails instead of presenting a successful research report.
04 / Architecture
Workspace
The browser provides cartridge selection, task inputs, history, logs and report review. Content Studio also supports browser-only execution and browser-local history when the Node service is unavailable.
Local execution service
A dependency-free Node service serves the interface, validates tasks, runs public-page tools and persists server history and Radar baselines in .noduvi/data.json. It binds to the local computer, supports up to two active tasks, and provides task and report endpoints.
Evidence and delivery
Radar records the hash and an excerpt of successfully retrieved page text. A changed hash indicates text changed; it does not establish the importance or truth of a change. Watch inspects returned HTML and bounded link samples. Reports contain observations and source references, and require human review.
Existing component runtime
The repository retains component integrity checks, capability declarations, licensing code and the Solana reference program. Existing protocol identifiers remain unchanged for compatibility. The built-in task runner does not claim that arbitrary third-party cartridges execute within an audited isolation boundary.
05 / Permissions and budgets
Network cartridges require explicit public-web permission. Requests accept public HTTPS pages, reject private and reserved addresses, validate redirects and pin validated DNS addresses for the request. Each page has a response size limit and timeouts. The tools do not access logged-in browser sessions.
Default execution uses zero-cost local tools. Optional AI requires a server-side API key, a model identifier, configured token rates and explicit consent to share task notes and excerpts with the provider. Keys stay out of the browser and repository.
Before a paid generation request, the adapter counts tokens, reserves input headroom and limits output tokens within the configured request budget estimate. Provider billing is authoritative: token estimates and configured prices can differ from final billing, and cancelling a request may still incur charges. There is no automatic paid retry.
The system never publishes content or sends a wallet transaction as part of a work task. Deleting a task removes its saved notes and report; Radar comparison baselines remain until local data is reset.
06 / Ownership and settlement
The longer-term direction extends the original project's component ownership model: developers publish verifiable software artifacts with permissions and license terms; users can inspect what they acquire and retain portable rights where the protocol permits them.
The repository contains a Solana program and client code for component records, listings, payments and time-limited licenses. Real chain purchases require a compatible deployed program and published listings. The workbench does not establish that a production deployment, audit or tradable cartridge economy exists.
Planned: integration between cartridge distribution, task execution and verifiable licensing. A third-party cartridge marketplace and creator settlement are roadmap items. This release makes no token issuance, yield or price promise.
07 / Current implementation
The shipped local release includes the three built-in workflows, task creation, permission checks, progress logs, cancellation, history, reuse, report preview, Markdown download and deletion. The optional model adapter is implemented but requires the operator's own credentials.
Automated tests cover core execution, failures, private-address rejection, budget preflight, provider responses and the HTTP persistence/download flow. Browser checks have exercised Studio task creation and report review on desktop and mobile layouts.
External-page success paths were not verified in the current development environment because DNS returned private addresses and the fetch policy rejected them. Paid model calls have not been verified with a live key. These are verification limits, not claims of production readiness.
08 / Roadmap
- Refine the workspace: improve reading hierarchy, cartridge navigation and desktop interaction while preserving the existing workflows.
- Harden execution: expand integration tests, recovery, snapshot controls and report-quality evaluation.
- Define a cartridge standard: specify manifests, signatures, version compatibility, permissions and isolation boundaries.
- Extend deployment: design authentication, user isolation, durable job queues and scheduling before offering hosted execution.
- Connect distribution and settlement: validate the licensing program, test on devnet and review the security model before real-value use.
Roadmap items are proposed work, without guaranteed dates. Product claims should track observable behavior and reviewed releases.
Appendix / Original architecture note
I am building a new kind of computer system on top of Solana—one where applications, agents, storage, compute, licenses, and other parts of the system can be owned, exchanged, and recombined by the people who use them.
WHY I STARTED
Computers are called personal, but most of their important relationships are no longer personal. Our applications depend on company accounts. Our purchases can become inaccessible. Our files are pushed into services we do not control. A useful tool can disappear because a platform changes its rules, shuts down, or decides that our device is too old.
I do not think every company is malicious, and I do not believe blockchain automatically fixes these problems. I simply think we should be able to build another option: a computer where ownership is visible, permissions are understandable, and software can continue to exist beyond the company that first published it.
This idea began with a simple question. If a computer is made from many replaceable parts, why are the parts inside its software so difficult to own, exchange and recombine?
THE SIMPLE VERSION
Shellwork is a computer environment with its own internal market. It is not a shop for laptops or graphics cards. What people exchange inside it are digital parts of the system itself.
Those parts might be an application, an AI agent, a visual desktop, a month of encrypted storage, access to specialized computing power, a professional tool, an automation workflow, or a license that allows a component to run on your machine.
You could buy a component, rent it for a project, subscribe to its updates, resell a transferable license, or support the developer directly. The system would verify what you own and load the component without forcing you to depend on a single app store.
A local-first computer system with an economy built into its architecture.
The project has three connected layers. The first is a familiar computer interface where people open files, use tools and manage their work. The second is a secure runtime that isolates components and controls what each one is allowed to access. The third is Solana, which records ownership, licenses, payments and the history of published components.
The computer does not run “inside” the blockchain. Code execution, private files and everyday interaction stay on the user's device whenever possible. Solana sits underneath the experience as the shared ownership and settlement layer.
WHY SOLANA
Solana programs store component records, listings and time-limited licenses in program-derived accounts. Purchases settle in SOL while the local runtime keeps code and private files on the user device.
Shellwork uses Solana for shared ownership and settlement. The browser connects to a Solana wallet, and the runtime checks account state and the component code hash before loading software.
HOW A COMPONENT ENTERS THE SYSTEM
- A developer publishes a component and a cryptographic fingerprint of its code.
- The developer defines its price, license rules, update policy and required permissions.
- A user buys, rents or receives the right to use that component.
- The local system verifies the license and code fingerprint through Solana.
- The runtime loads the component inside a restricted environment.
- Payment and royalties are settled automatically according to the published rules.
WHAT CAN BE EXCHANGED
Applications, plugins, AI agents, interface modules, storage plans, compute credits, datasets with clear usage rights, automation recipes, game content and transferable software licenses could all become system objects.
WHAT MUST NEVER BECOME A MARKET
Ownership must have limits. A person's identity, private keys, personal files, recovery rights and fundamental access to their own machine should never be commodities. No purchased module should be able to silently sell private information or take control of another component. The economy exists to serve the computer's owner—not to turn the owner into the product.
DESIGN PRINCIPLES
- User sovereignty. Core identity and personal data cannot be revoked by a vendor.
- Explicit capability boundaries. Every module declares what it can read, change and transmit.
- Local-first execution. Owning a component does not force private work onto a public chain.
- Developer continuity. Creators can publish, version and earn without locking users into one storefront.
- Replaceable parts. No system module should become an irreplaceable gatekeeper.
WHAT THE FUTURE COULD LOOK LIKE
Imagine opening a new computer and signing in with an identity you control. Your workspace reconstructs itself from a private manifest. The tools you own appear, your preferred interface loads, and every component clearly shows who built it, what it can access and whether its license can be transferred.
A designer could rent an expensive rendering module for one afternoon. A small developer could publish a useful system tool and receive payment each time a license changes hands. A community could maintain an abandoned application without losing its users. An AI agent could purchase a limited amount of compute through a session permission without receiving control of the owner's wallet.
Eventually, Shellwork could become a shared protocol rather than one company's operating system: many interfaces, many runtimes and many marketplaces using the same open component standard. Users could leave one implementation and carry their legitimate software rights into another.
WHERE THE PROJECT IS TODAY
This is an early architecture project. The repository currently demonstrates the core model: a capability-based kernel, a component registry, a license market and a local runtime. It is not yet a finished operating system, and the Solana program has not been presented as production-ready financial infrastructure.
The next serious work is to define the component standard, threat model, permission language and recovery model; deploy and test the Shellwork program on Solana devnet; and build a small local runtime that can install and safely launch one real component from beginning to end.
THE QUESTIONS I AM NOT HIDING
How should licenses survive forks? Which rights should never be transferable? How can account recovery work without rebuilding centralized custody? How do we stop speculation from overwhelming usefulness? What is the simplest permission language a non-technical user can genuinely understand?
I do not have final answers yet. Those questions are not weaknesses to cover with branding—they are the actual work of building the project responsibly.
WHY THIS IS PUBLIC
I am showing the work early because the project should be understandable before it becomes impressive. The code on the right is a concrete description of the direction, not proof that every problem has been solved. I want criticism from developers, designers and ordinary computer users while the foundations can still change.
If this succeeds, the blockchain will not be the first thing people notice. They will notice that their tools are portable, their permissions make sense, developers are paid fairly, and their computer continues to belong to them.
— Shellwork, development note 001