An implementation — CES

As discussed in the previous section, MINX is a foundation for some computing-resource economy system. It is a way for the 9-year-old's online computer to generate, without any configuration or intervention, some value that its local software agent can provide to remote hosts that can then, in turn, be managed by the user's local agent as server infrastructure for them to play with others.

MINX provides a practical way for two computers to prove resource expenditure to each other, but it does not dictate anything about the network, computational and economic, that these computers are assumed to be a part of. The question of what, exactly to build on top of MINX remains.

CES is one possible answer to that question. Specifically, it is the "federated network" answer.

All CES nodes are autonomous and self-sufficient computing servers that host their own credit ledgers, digital asset stores, file storage, remote compute, and network relay services.

CES is a fully-featured piece of peer-to-peer "node" software. It is relatively large, so I don't want to technically dissect it here. Rather, I want to focus on a high-level view of its capabilities and explain why it was built with those specific capabilities — in other words, what the purpose of a CES network is.

----

A CES node is a server, so all nodes that interact with it do so as clients. When two CES servers interact, one is often being a client of the other. That is where the "federated" aspect of the system comes from.

However, a network of CES servers is still a peer-to-peer or decentralized system, in the sense that the nodes in the CES network are cooperating with each other, both consuming and providing resources from and to each other. The peer-to-peer aspect is less network-topological, related to distributed algorithms or symmetric protocols, and more of the underlying goal of the system — to be peer-to-peer, instead of modeling computational horizontality just as cargo-cult or for the sake of it.

Centrally, a CES server contains a persistent and secure credit account ledger. One account occupies exactly 64 bytes of RAM (one typical CPU L1 cache line), which means a modern bare-metal dedicated server that costs a few tens of dollars per month in rent can host billions of accounts, so each account costs about "nothing" to be hosted.

Cryptographic identities in the system are either Ed25519 or Secp256k1 keys that can be generated unilaterally, for free, by clients. These keys require very little security to handle on the client side since the values they move are worth fractions of dollar cents — just enough to instantly "pay for" (or to prioritize) simple computing needs in modern hardware.

To create an account at a CES server, a host simply mines a RandomX solution to a puzzle based on the client and the server's identity (that is, the public key) and the current UTC time. The effort in the proof-of-work (PoW) solution determines the number of credits granted at the server. The cost of creating the account is subtracted from the issued credit amount, and the remainder is deposited in the account.

Transferring credits between accounts just takes a cryptographic signature by the client covering a request to transfer some amount of credits from their public key to another public key, which can also take as little as two 200-byte UDP packets being sent and received. The whole operation costs "nothing." A tens-of-dollars-per-month bare-metal server can easily process ~90,000 transactions per second (TPS) without skipping a beat — it can actually do more than that, as the current ~90,000 TPS limit is essentially a Linux kernel limitation on network syscalls. The system is so abundant that we are hard-pressed to find a reason to optimize it.

And precisely that is the core heresy of the CES system. It bypasses all the computational complexity of all previous token systems and implements the simplest end-to-end system that could possibly work. Issuance, book-keeping, and transfers with zero cost, zero friction, and sufficient security for the intended use case.

----

That is all well and good, but if each CES node keeps its own ledger and thus can issue infinite amounts of credits, and also delete any amount of previously-issued credits, how is trust supposed to build up in this system? Realistically, what are the odds that a computer A would even care to accumulate credits on a random computer B on the Internet?

The answer is that this system does not carry any one of the assumptions born of the existing world of finance, of Cloud Computing, and the rest of it. It is built for Public Computing, which is a different world — for our new analogy of computing as a quasi "natural" resource, instead of a constructed and regulated billion-dollar, extractive business.

Remember, the goal of the credit system is merely to help make resource sharing a living phenomenon. To reinforce it.

The same CES server that has this ledger also has the ability to host data, to run programs, and to relay network traffic on behalf of clients. The credit is used to prioritize requests to consume those resources.

You get the credits not because they are "money" in some global-consensus sense. They are not a substitute for goods elsewhere. They are a substitute for goods here, in this server. And you already trust the server with your programs and your data, because you are mining credits at it.

I understand that this can sound like a wild claim, while at the same time being, clearly, an entirely obvious one. That is because it is inverting some of our most basic cultural training: that "money" or credit or the socioeconomic measure of access is prior to the technologies, mechanisms, and relationships that fulfill concrete, material needs that the measurement system is regulating access to. And as such, they are a kind of prior escrow agent that is to be separated from that sphere of posterior provision.

----

Some may wonder if CES can be described as a mutual credit system. It depends, and I prefer not to think of it as one.

Open distributed computing networks have a hard time with that metaphor, which was crafted to describe human socioeconomic relations in the real world.

Real mutual credit systems use informal accounting, gossipy reputation, local currencies (or networks of such currencies, with higher-level clearing mechanisms), and sometimes community-maintained credit ledgers (e.g. LETS). CES does not fit any of these cleanly.

CES's ledger subsystem could be seen as a LETS where each "person", so to speak — each node, really — keeps their own ledger. But even that doesn't translate cleanly, because in the real world, we still have real communities functioning as oracles of services rendered. The reputational engine can always be supported, ultimately, by groups of people themselves. Ascertaining and proving to a "collective of computers" that a digital occurrence is objectively true — such as "Computer A did a concrete amount of work W for Computer B" — is the entire business, and the entire overhead, of consensus-based systems (like blockchains). That's what "consensus" means in computing: it means emulating a "social witnessing" function for a network of computing agents.

The CES RandomX-backed account ledger has no exact parallel in any present credit system, real-world or digital. It is unique.

Agent A, running CES server A, can obtain credits at CES server B, run by Agent B. Then A can use resources at B. For B to use resources at A, it has to pay A in its own currency. Now you have two agents performing an additional step of "mining credits" at each other, apparently in an unnecessary way, since the credit ledgers don't communicate with each other.

A mutual credit system works because the unit of account and the space in which that unit of account exists is social. The CES network has no way, by default, to create a shared consensus of what a credit is and who has it. Each node has its own value universe.

The natural scenario would be for Agent A to enjoy Agent B's resources, and then immediately have Agent B enjoy Agent A's resources to the same extent without having both agents continuously working double to first produce proof-of-work credits that are legible in the remote host and then doing actual useful work for their peer. For that to work, an additional mechanism is required.

----

The mechanism is, perhaps unsurprisingly, an old one. It predates digital networks entirely; it predates the modern banking system by centuries. Before there was a SWIFT network or central banks adjudicating between currencies, two merchants on opposite sides of a continent could still settle accounts with each other, without any single global authority looking over their shoulders. The mechanism is called correspondent banking, or, in some traditions, hawala.

The idea is simple: a pair of agents who wish to transact with each other regularly do not need a third party to mediate. They only need to agree, bilaterally, to keep two reciprocal accounts — one on each side. Each agent keeps, on their own books, an account on behalf of the other agent, which records locally what they owe the peer. When ten transactions go in one direction and seven go in the other, those mostly cancel out, and only the small residual ever needs to be settled by some external means. Day-to-day, transaction by transaction, the system requires no consensus, no third-party signature, no global ledger. Each peer-pair is its own sovereign clearinghouse.

In CES, the two reciprocal accounts have names borrowed from that older world. The vostro ("yours") is an account that lives on our server, keyed by the peer's public key; it records, in our books, what we owe to the peer. The reserve (the peer's nostro, "ours") is the mirror account on the peer's server, keyed by our public key; it records, in the peer's books, what the peer owes to us.

When a user on server A wants to transfer credits to a user on server B, server A does not wait for server B to respond, and asks no one's confirmation. Server A simply debits its local user, credits the peer's vostro account locally, and acknowledges the transaction immediately. Then, asynchronously, server A tells server B about it. Server B, on receiving the message, debits the reserve account that holds A's credits at B (the credits A previously mined, or accrued, at B), and credits the local destination user.

The cross-server transfer is, on each side, just a pair of ordinary local ledger operations. No round trip; no consensus; no global synchronization. The whole network just works, as a mesh of bilateral relationships, each one no more complicated than the everyday operation of a single sovereign ledger.

----

Of course, this metaphor too has its limits. Real-world hawala works because the residual that ultimately settles between two correspondents has somewhere to go: there is some substrate — gold, fiat, what have you — whose value the two agents already share, and whose persistence is enforced not by their agreement but by the world itself. A gold coin is a gold coin. It cannot be unilaterally erased. Physicality, in the real world, performs the deepest form of consensus: an atoms-witnessed-by-society guarantee that the medium of settlement will still be there tomorrow, regardless of what anyone chooses to remember.

In the digital world, that guarantee does not exist. There is no substrate that is automatically witnessed by anyone. A CES server can vanish overnight; its operator can pull the plug, its disk can fail. The whole pile of credits at that server — everyone's vostros and reserves included — simply pops out of existence. Entire sovereign accounting universes blink in and out of reality all the time. There is no gold here. There are no atoms here. There is just the agreement, while it lasts.

And yet, surprisingly, there is something universal that does survive across every CES node, even as individual servers come and go. It is not the credits themselves; the credits are local, ephemeral, sovereign. What is universal is the unit of account — the relationship, fixed by the RandomX algorithm and the protocol, between an amount of energy spent and a number of credit-quanta produced. Every node speaks that same language. Every node measures value in the same numeric grammar, even if every node's pile of value is its own and can appear and disappear at any time.

So the usual stack inverts. In the real world, the physical substrate gives you a shared store of value for free, and a unit of account is constructed socially on top of it. In CES, the algorithm gives you a shared unit of account for free, and the store of value is what is local, fragile, sovereign. The grammar of money is universal by construction. The speakers of the language are volatile and many.

----

What this looks like, mechanically, is that nothing actually crosses the network. When user A "transfers" credits to user X at server B, server A simply takes some A-currency from its user and deposits it in the pile that "belongs to" B (the vostro); server B, on the other side, takes some of the B-currency it was previously holding on behalf of A (the reserve) and hands it to X. The two amounts are equal at the wire level — but the debits and the credits all happen entirely within the sovereign accounting universe of one server. Nothing fungible actually passed between them.

The cost of this mechanism is the same cost that real-world hawala has always paid: trust is bilateral, and it does not transit. If server A peers with server B, and B peers with C, it does not follow that A can settle a transfer to a user at C. Either A has its own direct relationship with C, or the transfer must be explicitly relayed and settled along the chain. There is no inherent guarantee that the residuals between any two peers will ever balance out, and there is no inherent enforcement mechanism if one side stops honoring its books. Each peer-pair stands on its own.

But that cost is the benefit. There is no global consensus. There is no blockchain. There is no shared ledger that all the world's participants must update in lockstep. Each server is sovereign, fast, cheap, and answerable to no one but the peers it directly chooses to trust. The federation emerges from trust, rather than being imposed as trust by a central authority.

And there is nothing to trust, really. A CES server cannot have its accounting universe be gamed by any client, be them end-users or peer CES servers. The bilateral banking protocol is built entirely on top of the same wire protocol used to settle end-user transfers. All that a server can do is freely mint and destroy its own ledger, because, of course, anybody can do that in any system where individual agents keep their own sovereign tallies. The remaining "trust" issue is about choosing which servers and server operators you want to use.

And that is the entire CES proposal, end to end. RandomX provides the unilateral proof-of-resource expenditure that lets any computer mint credits at any other. The local credit ledger lets each server account for those credits abundantly and cheaply. And bilateral correspondent banking lets a mesh of such servers cooperate, federate, and settle, without forcing any of them to give up their autonomy or their sovereignty over their own resources.

It is the simplest end-to-end token-economic system that could possibly work, for the world that Public Computing wants to live in.

----

That covers the economics. The Public Computing definition asks three things of an implementation: an economic substrate, a technical solution that is actually effective, and social enablement. The first of these is what we have just shown — how a Public Computing implementation can enable computing to be as accessible not only as the power grid is accessible, as was the inspiration of Grid Computing, but as accessible as a public park is.

But what is actually in that park? Have we built an actual park? What else can a CES server do? How do we cover the second requirement of Public Computing, that of offering a technical solution that is actually effective?

Well, it has a RAM-backed cell storage connected to a bytecode virtual machine which allows clients to store arbitrary data there and use it as code. It has disk storage payable with credits. It has a network-relay-capable compute server that runs sandboxed client-provided code in LuaJIT instances, with full metering support, also payable in credits.

And more. The bytecode VM is scheduling-aware — programs can ask the server to wake them up at a future wall-clock time, run for a while, and go back to sleep, so a program parked on a CES server can have its own clock and act on its own initiative without anyone watching.

The bytecode VM has an outbound RPC engine, so a program on server A can dial a program on server B, ask it a question, get an answer back, persist that answer locally, and carry on; the network of CES servers thus becomes, by composition, a distributed-actor substrate.

The RAM-backed storage cells are actually assets which are queryable by a unique 32-byte key. These assets can be used as a naming system or as a virtual-items system, and they can be put up for sale or gifted between users.

Users can attach directly into a running program from their own terminal, opening a bidirectional byte stream into the program's instance, as though they were dropping a phone line into a process.

Operators can deploy their own programs into a curated namespace on the server — a game, a chat room, a search index, a public bulletin board — so anyone with credits can connect to and use them without installing anything locally.

The whole protocol bus is extensible: anyone linking the CES library can register their own handler under a new protocol name, ship their own binary, and run a CES server with a feature on it that no one else has.

Technically, a CES server is a fractal rendition of the whole apparatus of Cloud Computing. What you can do in a Cloud Computing host, you can do, to some extent, on a CES server. CES doesn't have the R&D budget of Amazon, but I think we did just decent with what we had at our disposal. It is enough to get some interesting projects started.

----

What ties all of this together is that there is one credit system, and one only. Storage rent, compute metering, network bandwidth — everything that costs the server resources costs the user credits. The same RandomX-mined, Hashcash-descended, fraction-of-a-cent credits that were automatically minted and paid for a user's first transfer also pay for everything else.

And so the 9-year-old's vision — writing little programs that anyone, anywhere, could connect to and play with — can finally be realized in concrete software. She does not need a credit card. She does not need to register with a Cloud provider. She does not need anyone's permission. She points her computer at someone else's, spends a few minutes of CPU time, gets enough credits to put her program on the network, and lets her friends connect to it. If she wants her own server, she runs one. If she wants to ship her program to a friend's server, she does that. If she wants to charge other people credits to use her program, she does that too.

When she grows up to be a distributed-systems researcher and engineer, she can write a DHT that runs on top of this substrate, instead of on top of a dedicated (and isolated) monolithic peer-to-peer substrate with its own illiquid reputation system — or a liquid one that costs $150 per message.

Which covers the third and final requirement of the Public Computing definition: social enablement. Our park can have visitors that enjoy it, and that enhance it with their presence.

And that's it.

Addendum: Permanence.

An idea

Around 2011, my vision started taking a stronger shape. I would say that it was at that time that the concept of Public Computing as I define it became concrete, in the form of a recognizable, implementable, layered software architecture. The core insight is that resource sharing between computers replaces resource contracting and renting. It does not concern itself with what the resources are being deployed for, as that is for applications to decide.

It’s a simple insight, if it is considered just in its computing technology dimension. Dissociated from its obvious social, economic and cultural implications, that is essentially all there is to it.

So-called “Peer-to-peer networks” as historically implemented are monoliths that combine a single-purpose distributed operating system (the “P2P layer” that meshes people’s home computers together, for example) with the application it is built to support (say, file sharing). Instead, a “P2P network” should be seen as the application of a Public Computing substrate — itself both software and a cooperative, P2P-natured run-time infrastructure.

However, it's not that simple. It never is.

----

If you open up a dedicated computer on the internet to host any program, data, or traffic to any requester that can reach it, like it was a "free Cloud Computing host for all," it will immediately be exhausted of resources, permanently, for as long as it is online.

That is sometimes referred to as a "Tragedy of the Commons," which is the idea that a physical space that is open to all for enjoyment becomes immediately degraded. Ironically, that idea is far more adequate to describe what happens in open digital spaces than in open physical spaces. Degrading a physical space requires material presence, linear effort, and risk. The abuse of open digital spaces is mostly risk-free, and costs mostly nothing.

By analogy with the original problem of "abuse" in open networks, we denote that activity as "spam." We call it the "spam problem" of open and public computing systems.

However, that framing as "spam" is not actually exact. The problem is misdiagnosed and misnamed.

The term "spam" was created to describe mass email marketing. Even if the definition of spam varies somewhat between people, there is a substantial overlap, a definite pattern to what spam generally means for everyone. Crucially, your attention is not ever adequately described by default as a public resource of any kind; it is a private one.

Public Computing is the idea of spawning public spaces in the virtual realm, such that the kind of free-form occupancy that manifests on open traffic relays, open compute servers, and open file servers, is not adequately described as "spam." An ontological reboot is needed.

Let's first consider that a naive Public Computing resource fulfills its duty completely and immediately merely by being occupied. If it is fully occupied, then its function is fully realized by default. The question is not ever whether the occupancy is legitimate or not, as that question is seldom answerable definitively.

Instead, let's consider that the costs or requirements for access that we could introduce to the Public Computing resource are the same kinds we would impose on other real public places, such as rivers, forests, parks, libraries, plazas, theaters, schools, roads, hospitals, etc. That is, we don't impose barriers to decrease life, but to increase it.

A boundary or an obstacle is not always to diminish, but to demarcate, to characterize, to enhance a living center.

If you impose a slight cost to the access of an otherwise fully open computing resource, you will indirectly teach would-be users that they are supposed to use the resource judiciously to store, relay, or process artifacts that are at least as valuable as the cost or commitment required for that access.

That is the core of the answer that I offer to the question raised by the Public Computing provocation: we need a token-economy mechanism that is as reliable and as secure as any state-of-the-art mechanism that operates today, but also one that is absolutely democratic, accessible, fast, cheap, and abundant.

----

In 1997, Adam Back invented Hashcash, a method by which a computer A can prove, unilaterally, to another computer B, that an e-mail message sent from A is, by definition, "not spam" to B.

A Hashcash-stamped email possesses an independently-verifiable cryptographic proof of an expenditure of an estimated amount of computing cycles, which translates to an estimated expenditure of electricity, which in turn translates to an estimated financial expenditure.

Thus, the email carries a mathematical proof that the sender has sacrificed significant resources to "pay," as it were, for the receipt of the message by the remote mail agent, which in turn is translated to some amount of attention to the message by the human receiver.

The original Hashcash had some problems. First, it used simple secure hash functions, which can be gamed by dedicated hardware. And second, the Hashcash proof was tied to that single "transaction" between the email sender and the email receiver. The receiver of the email could not reuse the email it received as some kind of digital currency to "pay," as it were, for the receipt of their own message at other hosts.

Both problems were addressed by Bitcoin, the first widely-successful blockchain cryptocurrency system. The first problem was addressed by treating the asymmetry of dedicated hardware not as a problem, but simply as a natural part of the solution for securing the blockchain-based ledger of the cryptocurrency. And the second problem was addressed by the blockchain system itself: by making the transaction system itself extremely expensive and scarce: today, one Bitcoin transaction (transfer X bitcoins from A to B) costs the same amount of electricity that it takes to power an entire home for a month, or a financial cost of about $150 per transaction.

Since the invention of blockchain cryptocurrency, multiple attempts have been made to spawn a token economy for peer-to-peer resource sharing. However, in part due to their high costs of operation, blockchain cryptocurrencies have been deployed as a substitute for traditional financial assets and currencies. That meant that the culture that spawned around it read resource sharing as a business, as a trading problem. Not as a mere mechanism deployed to allow people to delineate the open, public offering of computing resources to each other.

----

In 2019, the RandomX proof-of-work algorithm was released, replacing hardware-accelerable secure hash functions as the state-of-the-art for blockchain proof-of-work systems. RandomX is tuned to favor general-purpose CPUs, and to defeat specialized hardware, meaning it lets a computer A prove to a computer B that it completed a digital-stamping challenge whose real energy cost — and therefore financial cost — can be estimated within a much narrower range.

In other words, "mining" for blockchain blocks and therefore for cryptocurrency became fair and democratic, depending mostly on the miner's energy bill, not on the miner's capacity to deploy capital to develop or purchase specialized mining hardware that is orders of magnitude more energy-efficient.

Incidentally, what RandomX gives us is the concrete possibility of finally deploying Adam Back's original Hashcash idea to solve the Public Computing version of the original problem he set out to solve, which was the problem of "spam" (or, in our case, the problem of prioritization rather) in open resource-sharing peer-to-peer networks.

And that is the proposal of the MINX protocol. MINX uses RandomX to allow machines on the Internet to submit RandomX proof stamps to each other. Those stamps can be quantified directly as credit deposits, and tracked at each recipient host B on behalf of the sending host A. Afterwards, those credits can be redeemed at B for computing resources by A — or, crucially, transferred by A to a third party C, so that instead C can redeem those credits for services at B.

If RandomX-minted credits are tracked at each host independently, that means there is virtually no overhead in processing, tracking, transferring, and redeeming these credits. Although such credits are theoretically less secure than blockchain-tracked cryptocurrencies, their use case is, again, not really that of financial payments, but simply of prioritization in what would otherwise be naive, completely open and public, general-purpose computing-resource sharing.

Such a system is therefore sufficient for providing Public Computing with a common economic protocol for application-agnostic resource hosting, renting, and sharing. A MINX-based ledger can impose a cost of approximately $0.00000001 per transaction. That is orders of magnitude cheaper than what blockchain-based transactions cost.

The resulting currency, or transferable Hashcash system, is absolutely democratic and accessible by construction, as any computer can securely generate roughly the same amount of credits for the same amount of energy spent. The ledger system can be maximally fast and cheap. Credit production can be unbounded. It is, by all accounts, a plentiful and abundant system, as opposed to a scarcity-based one.

----

And that is the idea.

We have both the cultural and the technical solution to the fundamental problem. We can now make hosting and using public computing infrastructure maximally enjoyable. Not by a mandated lack of any access system, and not by spawning our own version of the rent-a-computer paradigm, but via the creation of a particular kind of token-access system that is cheap, fast, democratic, accessible, abundant, fun; one that enlivens, enriches, enables the activity of application-agnostic computing resource sharing.

The solution to the credit-economy problem for open resource sharing, implemented by the MINX protocol, becomes the foundation for the CES system.

Addendum: Permanence

The core insight behind the CES token-economy is that running completely open servers that offer compute, storage, and networking on the Internet is the same movement as hyper-financializing everything.

That may sound strange or paradoxical. It is a difficult point to make. I don't want to delve too much into it, and I'd rather leave it as an exercise to readers.

But consider the historical debate on "Free Software" versus "Open Source Software." Turns out that software that doesn't make capital pay us or at least make it squirm a bit is mostly just the flip-side of patented and private corporate software development. Is it not? Neither approach contributes to the community that we hope to create through it, which is a community of horizontal, mutual cooperation in software production.

As another example, we can observe that reputation, that communal gating of access to decentralized networks in general is a good thing with positive, community-building effects, since that is at least one way to give shape, to accentuate the relevance of what goes on in these networks.

Gentle, smart friction in access to systems is life-enhancing. A little bit of democratically-produced skin-in-the-game, nothing more. We all have skins, and we don't have to procure "skin" (commitment) outside of us. You have a computer that can produce a PoW proof. But if you don't have money, then you don't have it, and the absence of money in your possession proves not one useful property for the kinds of systems we want to build, that we want to be live online, that we want to exist.

We can use "finance-like" things to enhance life without financializing them, that is, making them about some kind of money. Tokens as tools, as a technical device to achieve a purpose (e.g. "rate-limiting," "spam protection," or things of that nature), not as the objective, the center of attention (e.g. as establishing "merit," for example).

----

Which brings us to permanence.

The point of a Public Computing network is to exist, to be there.

It can be there if we host Public Computing servers and then we just leave them running.

Trying to host physical servers on home internet connections may or may not work, as the Internet is fundamentally a hierarchical system maintained by governments and corporations. Maybe your ISP will allow it. Maybe it won't.

For some, it may be more convenient to just rent a modest dedicated machine to run a node. With today's technology, such machines can be rented for a few tens of dollars per month.

I want to see Sovereign Computing happen. My thesis is that Public Computing provides the substrate from which Sovereign Computing can be bootstrapped, in which it can be expressed, because Public Computing provides a foundation that would strengthen it. (In any case, that was my aim.)

Permanence is the idea that the success of this revolution in computing that thousands seek is measured by the raw amount of physical resources allocated and dedicated to it (compute, network, storage) and that this allocation itself is the measure of success. That such an activity is both the display of power and the intrinsic fun itself.

Notice that the definition of Public Computing does not offer classification criteria for Public Computing systems. You are the classifier. Any system that makes you feel alive is a system you can just run; you don't owe anybody or anything any further explanations.

----

Public Computing is about provisioning resources for Sovereign Computing projects, or any kind of project that wants to use these resources, however these projects identify. Because that is fun, and therefore technically effective and powerful. If it isn't, then its implementations need more work.

Sovereign Computing is then the writing of software atop a culture, a substrate, a network of resource sharing that is already there. Now you can write P2P applications, decentralized applications that truly self-deploy and self-maintain.

I believe that this level of specialization, of separation of concerns, is what naturally fosters the appearance of something analogous to a peer-to-peer operating system. Something akin to Grid Computing's vision of a world computer.

The Public Computing substrate is permanent if we pay to build it and if we pay for the effort of sustaining it. That's the entry ticket to that particular amusement park.

And, finally, we may or may not charge users actual money to use these systems, that is, they may or may not be businesses or have a business aspect. There's a wide spectrum from free-of-charge systems, through public pricing, and into the far reaches of profiteering.

The PoW economy bootstrapped by CES is not intended to be exclusionary or profiteering. Transferable Hashcash is not actual secure currency, not actual money as it does not have the properties to be money. But systems written in CES can integrate their own monetary-economic contracts, their own prices-in-actual-money, their own payment gateways, etc.

So, we put Public Computing servers online. Then, users' computers generate the access tokens, which are used to access the servers and enjoy their services. A secondary transferable-Hashcash token economy can emerge. If it does, its only purpose is to allow for communal regulated access: people give CES credit tokens to each other so everyone can just use the system without the need for everyone to mine these tokens. And through the base CES token economy, the system is protected against "abuse" (for whatever definition of abuse).

I believe that (or something like that) is the minimum necessary foundation for the creation of a large and sustainable network of useful Public Computing services.

----

There's a last point I want to make. Amusingly, I had to resort to the "AI" for help in making it. After writing pages and pages of it, I couldn't find a way to synthesize it. So instead of publishing that rant, I decided to feed it to the machine for summarization, and it produced the paragraph below.

Christopher Alexander spent a lifetime proving — with more rigor than the establishment that dismissed him could marshal — that aliveness is not the opposite of precision. It is its highest form. The most technical, most exacting work is done where there is the most life, the most fun. So a Public Computing network is only worth building if it is alive in that sense: if hosting it, using it, and sharing it feels less like running infrastructure and more like sitting by a river that happens to be made of computers. That is the whole specification. The rest is detail. The rest is life. The rest is fun.

I like that summary. They are essentially my words, merely edited by the machine.

MINX/CES was created for people to have fun.

Public Computing

About

An implementation — CES

The Public Computing definition

An idea

Addendum: Permanence

The Public Computing story