From Blocklet Server to ARC: Why Owning Software Is Harder Than Generating It

Direction of architecture, not a claim that every layer is finished.

AI has changed what it means to make software. In the past, if someone wanted a blog of their own, a shop, or a small tool for their daily life, the first questions were rarely about features. They were about whether to hire a developer, how to buy a server, and who would maintain it later. Now more and more needs can be described directly to an Agent. By Agent, I mean an AI assistant that can understand a request and help generate, run, or maintain software. Software suddenly feels much less distant.

But software that can be generated is not necessarily software that you own.

It is easy to be excited when an application works in a demo. Once it begins to hold your data, relationships, history, and daily work, the real questions begin. Where does the data live? Who can access it? What happens when you switch devices? Can it be recovered when a service fails? When you share it with a friend, are you sharing a link, or binding yourself to another platform all over again? For a long time, the difficult parts have been hidden behind words like deployment, operations, and account systems. Put plainly, they mean putting software somewhere it can be reached over time, keeping it running, and managing who can sign in and use it.

That is why we are building ARC. ARC means Agentic Realm Computer. It is not another traditional computer for an Agent to manage on the user's behalf, patching Linux and watching logs. We want to build a different computing foundation: one where people can use Agents to get the software they need without handing their identity, data, and long-term control to a single platform.

Software that can be generated is not necessarily software that you own

ArcBlock grew out of blockchain, decentralized identity, and application infrastructure. We have been trying to solve a very practical problem: building and deploying decentralized applications is too hard. Blocklet Server and early Blocklets did more than deploy applications onto a machine. They handled the common parts first, including identity, user management, domains, and application deployment, so developers could stay focused on their own work.

The DID system, access to and use of different blockchains, payment support, and components such as PageKit and DiscussKit were all important parts of that platform. They allowed users and developers to handle identity and to install and compose site, discussion, and payment-related capabilities through a web interface, rather than rebuilding a complete service from scratch every time.

ARC has corresponding foundations for these capabilities, but they will not appear with the same maturity or in the same model. Identity, existing ledger capabilities, and payment-layer capabilities can carry forward. Blockchain-side AFS integration, on-chain settlement, and the unified way they are carried by ARC are still under construction. We should not present this as if the older capabilities had been wiped away and replaced by a purely future-facing idea. They remain the baseline of whether ARC can be useful at all.

The earlier judgment was not wrong. We saw ourselves clearly as a developer platform: if enough developers made enough applications and components, ordinary users could install, compose, and use them. Blocklet Store and a range of Kits emerged from that view. Many developers still need tools like these today.

Later, we had to admit something practical: even when the components already exist, installation, configuration, and maintenance still keep most ordinary people out. A software package does not automatically become an application that someone can own over time. This is also why SaaS became popular. It hides as much of that trouble as it can.

The change is that AI has greatly expanded who can make software. A person no longer needs to become a professional developer before they can say, “I want a site of my own,” “I want to collect and organize this material,” or “I want a small application just for my family.” But even if an Agent helps create the application, it is still more like a polished demo than software of one's own if its data, deployment, and continued operation remain a tangle only professionals can understand.

One could reasonably say that hosted online services, or SaaS, are enough. Platforms run and maintain applications for you. They provide immediate availability, shared operations, and everyday convenience for many people, and they will remain suitable in many cases. ARC is not an attempt to make everyone learn system administration again. Nor is it a demand that every service move back into the home. When people buy a phone, they do not first ask whether it is “self-hosted.” They simply regard it as theirs. What we want to change is something else: when an application truly becomes part of your life, owning it should not become impossible because of a technical barrier.

ARC does not want to give Agents another traditional computer

Traditional servers, virtual machines, and isolated runtime environments can all let Agents do work. But they carry the burden of traditional computing: version updates, access rights, operational failures, and a long list of separate management interfaces. Asking an Agent to operate them is certainly better than asking ordinary users to do it themselves. Still, the complexity has only been transferred to someone else. It has not disappeared.

ARC starts with AFS. AFS means Agentic File System. It is not a new name for a traditional file system. It uses the file system as a unifying abstraction through which people and Agents can understand and operate on data, available services, and current context. Think of it as a shared work surface: only after a user has explicitly authorized something, and the relevant data or service has been connected, can an application find the material, understand the permissions, and use the allowed service. Ordinary users do not need to see this layer, but it determines whether the system can bring things from different environments onto one understandable surface.

Above AFS is AOS, the Agentic Operating System. Together they form the ARC runtime, the underlying environment in which applications actually run. ARC has already validated Blocklet operation and data integration in local and cloud runtime environments, and it will continue to extend to more environments. Those environments are where ARC runs underneath. They are not a set of machines users should have to manage one by one. What matters is not how many platforms ARC supports, but that the system an Agent faces is no longer a collection of unfamiliar boxes.

Put plainly, we do not want “helping users own software” to mean “managing a server for them.” What users care about is whether their things are still there, whether they still work, and whether they can be recovered when something goes wrong. Machines themselves should become more like replaceable tools, not things users must personally tend.

Important things should not be bound to a single run

This is where ARC connects with what ArcBlock has built over time.

The identity layer is DID, or Decentralized Identifier. It can be understood as an identity marker that can be carried forward and independently verified. ArcBlock has long treated identity as a foundation of the system, rather than an account issued temporarily by a particular platform. People, devices, and other entities that need to be recognized can each have their own DID. ARC is carrying this foundation forward. Our goal is that existing users should not need to recreate their identity because the architecture has changed. That continuity matters. If a new system makes you start over on the question of who you are, it is hard to call that an upgrade.

The data layer is DID Spaces. It is not a cloud drive that users must maintain themselves. It is where personal data belongs. Our design goal is for the ARC runtime to be reconstructible and applications to be replaceable, while the data, history, and authorization relationships that matter over time retain an independent continuity. After replacing an application or device, notes, authorizations, and history should not disappear with a particular installation. This does not mean data can never be lost, or that users will never need backups. It means the system should separate persistent data from a particular run, so synchronization, backup, and recovery have clear objects.

Blockchain has not been abandoned either. It is simply no longer used as a slogan. It remains an important continuity for verifiable records, asset-related contexts, and future payment capabilities in the ARC architecture. For users, the important point is not to hear the word “blockchain” first. It is that in situations that require verification, our goal is to reduce dependence on the logs of a single platform. Which actions are verifiable must be determined by the identity and ledger capabilities that have actually been connected. Blockchain-side AFS integration and on-chain settlement are still under construction. A clear direction is not a reason to pretend they have already been delivered.

Together, these layers are what we mean by ownership. What users own is not a particular machine or deployment. It is their identity, data, authorization relationships, and the possibility of recovery and migration when a runtime fails. This is not a marketing slogan that says “your data belongs to you.” It is an architectural division of responsibility: a replaceable runtime is the goal of the architecture; identity should remain continuous, data should have a home, and important actions should leave verifiable records. How each part takes shape in different products still has to be demonstrated through real products.

Blocklet must be tested in real products

Blocklet is a name ArcBlock coined early on. The original Blocklet was more like a software package installed together with its complete runtime environment. Its value was always clear: turn applications into components that can be installed, reused, and composed.

That idea has not been lost in ARC, but its implementation model is changing. ARC-era Blocklets are evolving toward a declarative application model: applications state what capabilities they need, while ARC provides common foundations for runtime, identity, data, and interaction. The DID, blockchain, payment, site, and discussion capabilities that were often packaged inside Blocklet Server or a Kit still need to be carried forward in ARC, but they will not necessarily appear through the old installation model. We often use “Blocklet 2.0” to refer to this generation of the model, although its final public name will follow the product.

This is an intentional trade-off, and it has real costs. Under the older model, complex applications could bring their complete runtime environment with them. In the direction of this new model, an application description does not carry arbitrary executable programs. Common capabilities are provided consistently by ARC. Unusual requirements need to be implemented separately through the relevant Provider and explicitly mounted. Technical readers can understand this boundary through AFS Providers. In other words, we give up some of the freedom to put anything into a single software package in exchange for clearer security boundaries and less runtime burden on each application.

The interface follows the same idea. AUP, or the Agentic UI Protocol, lets the meaning of an interface and its important actions be described instead of being hidden entirely inside a particular frontend implementation. It is not a promise that Agents can already operate any interface. It is a step toward a clearer common language for people, applications, and Agents.

Technical readers can see this as a redrawing of abstraction boundaries. Ordinary users do not need to remember these terms. What we hope they ultimately feel is that when data, authorization, and application capabilities can move, changing a device or runtime environment does not suddenly turn an application into something unfamiliar.

If users must first take a course on ARC before they can use an application, then we have probably done this backwards.

This architecture must ultimately be tested in real applications. It does not need a roster of product names announced in advance to be valid. Users will only care whether they can create a site, organize a discussion, manage identity, handle payments, or safely keep their own material. ARC should carry the complexity of identity, data, runtime, and collaboration with Agents in the background, rather than becoming a brand burden every user has to understand.

Precisely because the earlier platform had already addressed these concrete capabilities, ARC cannot replace them with a beautiful architecture diagram. The new model should let these things happen in a way that better fits collaboration between Agents and users. It should not make users confront installation, configuration, and operations all over again.

This is why we do not want to draw only a more complicated architecture diagram. We used to explain those components through developer-oriented diagrams, and they still have value. But the future of ArcBlock should not make ordinary people feel shut out by the names of its components. ARC is the new main line. Blocklet, DID, and Blockchain are the foundations we have not left behind. The real test is not on the diagram. It is whether people can naturally own the software they need.

This is not finished. ARC will not become real simply because of one article. We still need to prove this architecture layer by layer through products, content, and an open building process. But we want to state the direction clearly first: after AI makes software easier to bring into existence, the next step should not be merely to generate more software. It should be to let more people truly own it.

Appendix: A quick guide to the terms in this article

This is not ArcBlock's complete glossary. It is only a reading map for this article. The formal strategy and product boundaries will continue to evolve, so “under construction” in the table is not an evasion. It deliberately distinguishes foundations that are already available from things that still need to be validated.