My visions on new Distributed Systems
So I realized I haven’t really written about my ideas, my larger visions for systems, for “apps,” for things we could build on top of the Internet. And that includes also a new vision for what our actual global information network is — it is not the Internet, as the so-called “Internet,” the IP network is, conceptually, just a part of it.
I don’t really know how to put all that stuff in order. Right now, I sit in a temporary Airbnb-rented apartment, while I wait to be able to move to my next fixed location. It’s 11 PM, I’m all alone, and I have nothing else to do. So I’ll just take the time I have and just type stuff in whatever order until I pass out.
In 2009 I finished my thesis. It described a decentralized (“peer-to-peer”), secure and scalable networking engine model (a schematic) for Massively Multiplayer Online Games (MMOGs). The idea was that someone, anyone, could design and build an independent MMO and, for the cost of, essentially, web-hosting, they could host it for hundreds of thousands people to play it simultaneously by harnessing the computing power of volunteer Internet “peers” — home computers with consumer broadband — which would probably be assembled from the bandwidth and computing power of the players themselves. (Using only regular, wasteful “unicast” communication, since the hierarchical IP network and its private “ISP” paradigm would never give multicast for the “consumers” which are supposed to be only receiving content and never broadcasting it.)
I have always been fascinated with “file-sharing” and “peer-to-peer computing” since its inception, and also of anonymous file hosting, being a huge fan of the Freenet project. What always fascinated me was the possibility of people getting together with their home computers and their home broadband and, in droves, assembling what is now known as “The Cloud.” That would be the true “cloud,” where corporate data centers, which are named “The Cloud” today, would be mere members of — though powerful members, still just members and not owners of the concept.
I am a huge fan of software (and hardware) that just works. I am saddened by how most “peer-to-peer,” or “decentralized” software is really hard to use, especially anything related to “privacy,” including secure communication and secure, personal file hosting. “Personal Computing” brought in this notion that users want to be System Administrators, which is best contemplated by the complete joke that is the expectation that regular users should spend their lives babysitting a desktop computer (a “PC”) with some flavor of Windows installed on it. Most installation and maintenance tasks are completely mysterious for users, and if you observe even the users that manage through these, the experience is stressful and not only feels like a lot of work, but you can see them twitching with anticipation for the moment where a screen that doesn’t make any sense will pop up and talk down to them in system-babysitting terms they were never meant to waste their lives trying to understand.
Though the MMO systems I designed would probably never be absolutely zero-configuration for its users, at least I could count on gamers being natural power-users and not the average clueless family member that we have to sysadmin for. Games, including online games, are the most advanced and most user-friendly pieces of software you will ever encounter. A games programmer can work on any other kind of system, as almost anything he picks up will be a downgrade in complexity to what he has to deal with as a games programmer. Game developers will usually have a sense for all components and areas of a system, from UI to graphics to networking to databases etc. Gaming is a world populated by the best developers and the best users in terms of technical competence.
However, “file-sharing” systems, such as Gnutella, Kazaaa(?), Morpheus and eMule were always very easy to use, right up to when these networks were hit with massive poisoning attacks by Copyright monopolists (and legal persecution/crusades in the US) circa early/mid 2000's, after which they became unusable, and have since been replaced by BitTorrent and torrent tracker sites such as Piratebay. They were so easy to use that any regular user could just fire them up, type up some stuff and find the files to download. It was truly decentralized. It was powerful. It did not ask users stupid sysadmin questions, did not force them into a whole new world of app-specific concepts, did not ask them for usernames, passwords or public/private keypairs, or IP addresses of peer-friends they somehow were supposed to trust. It just worked — until they didn’t, because they were vulnerable to some of the myriad attacks possible to decentralized systems and protocols designed naively, without knowing the corporations and the state want to eat their “users,” their “citizens” for the cattle they are.
There is another such “peer-to-peer” system that just works, and that not only works beautifully, but that is completely immune to Sybil attacks, poisoning attacks, and a whole host of other kinds of attacks. It is called Bitcoin. And not only it is beautifully run-and-use, as transparent and as user-friendly as the original “file-sharing” programs, but it — the “block-chain” which includes also the Ethereum network, my favorite — is probably the most secure decentralized information network ever built. The Bitcoin project is the best example of a deployed peer-to-peer network that has solved, in practice, most of the theoretical attacks that can be mounted against such networks. Granted, it is simply a globally-replicated database of token transfers, which is the simplest MMO that could have even been designed, but still, it is a magnificent feat of design and engineering of an usable, secure, scalable and decentralized application network of whatever.
Around 2013 I was really enthusiastic about the Sneer Project and Sovereign Computing. Bitcoin is essentially a standalone SovComp application running on its own network, as is any other application-specific peer-to-peer network such as “file-sharing” networks. Around that time, I had a bunch of visions about what the Internet was, and what was it that “we” were really trying to build. Something that was (a) truly easy-to-use and empowering, something that feels like lightning emanating from the user’s fingers and (b) symbolically powerful, retelling the relationship of the user to the network.
The Internet as “The Network” — a technical and psychological trap
At the core of my feverish dreams was the realization that the Internet was not something innocent. Usually, we see the Internet as this “liberating technology,” as this liberating network of wires that we can get access to by calling a local ISP, paying a few bucks a month, and then having the freedom to access. Perhaps as an user it is more difficult to see how the Internet — the IP network — is oversold as Teh Freedom, but it is a little less difficult to see it if you are a developer.
The Internet is a hierarchical information network of the State. It originated in the US military, and was since built by the global network of States, and is now operated by large corporations which are essentially both the controllers of these States and supported (funded) by them by holding huge monopolist positions in the now non-existent, non-competitive “market” for broadband access.
To be able to reach other users, you have to plug yourself in at the bottom of an hierarchy, the IP addressing hierarchy. If an ISP wants to monitor or to throttle your connection, you have no choice, as you have to pass through one. The ISP is, in fact, an adversary (as is every “for-profit” corporation really — exercise for the reader), either in volunteer service of the State or forced to be so: a malicious entity, an eavesdropper and censor by definition. The ISP will assign you an “IP address,” which is essentially a meaningless random number that not only can identify you and your network activity, but is useless as an identifier for other people to know who you are and to reach you later. As the IP address of a home computer changes every time their ISP feels like it, if you want to develop software for regular “home users” of the Internet to host content, you need to create additional “overlay” (“logical”) addressing on top of the meaningless IP addressing scheme. The Home User cannot ask the network for neighbors; to communicate with the network the user has to manually inform, “bootstrap” the logical (application) connectivity manually, and it will probably end up doing so by connecting to a “centralized” service offered by some corporation. He will have an username and a password at, say, Google or Facebook, or other “Cloud” sites where he will make his back-ups and host his private content. The IP network considers the “home user” to be a dependent, powerless node. The real work and power of routing is done by special “routing” hardware and networks with their own protocols.
So, when you develop an application while having IP addressing and routing, and the IP network in mind as the concept of “The Network,” the software you write will reflect these assumptions. You will attempt to develop a non-trivial “peer-to-peer” application, one that is not completely anonymous and disregarding of what individual user identities exist such as Bitcoin or the earlier “file-sharing” systems (in doing these trivial, user-location-free systems, the dis-empowering nature of IP addressing is masked). And in attempting to do so, you will write an unusable mess that asks users to bootstrap and fill in, for a specific application and its specific network, a bunch of information, such as who your “trusted friends are.” It will try to bootstrap a non-hierarchical application network on top of a hierarchical one. As you code in IP paradigm, you are faced with all the problems of secure and scalable decentralized application networks, from DDoS, Sybil, Poisoning attacks, to secure key exchange problems, address bootstrapping and then routing of search requests, and then of locating peers as their addresses change.
It is no accident that the only “peer-to-peer applications” that in practice got deployed are ones that are not based on Trust Networks, or in having users weave a logical network by coordinating with other users. Such peer-to-peer application networks fail because they project the Personal/Desktop Computing fiasco back into the realm of distributed, “online” systems: they assume users are sysadmins, and even when they don’t, when they purport “user friendliness,” they operate from a complete blindness to the fact that users have simply desensitized to the senseless violence that Personal/Desktop Computing is. Users will not complain of the unusable garbage you will develop. They will just not use it, and turn to centralized providers instead. That is the real reason most users migrate to “Mobile” (centralized, curated operating system and app platforms), and the real reason why companies use “The (corporate) Cloud” instead of Grid Computing, and the real reason why “peer-to-peer” networks can’t compete with Google, Facebook, Twitter, Dropbox or the centralized web-hosting web of HTML pages. It’s the usability. And the usability fails at the core because you can’t see what the stacks you’re using, including the IP stack and the user/permissions “desktop security mindset” are making you do to users.
Users are not sysadmins. They want appliances. They want robots in their home that they shout “MAKE IT SO” to them, and they fucking do what they are asking them to do. They don’t want their robots to ask them stuff, they don’t want to babysit a piece of technology. And that’s what they are going to be forced to do every time you try to build an “app of liberation” on top of a twisted, wrong mindset. If you really want to use the existing software and the existing network stacks and the existing hierarchical, corporate-state physical network, you need a conceptual correction layer first and foremost.
Every time a Windows dialog box pops up with a piano chord and an exclamation point, with two lines of sysadmin technobabble that the user has to read and choose between two buttons, the user has a small heart attack and physically loses about an hour off of their lives, and a fraction of their sanity. Windows is the Desktop. Windows is Personal Computing. Windows is the computing version of Cthulhu.
The IP network as a carrier medium of the actual global network
There was a guy, one of the early technical founders or pioneer technicians of the Internet (probably an IETF guy), a guy that was, if I recall correctly, the guy who technically prevented a congestion-related meltdown of the Internet in the 80’s, that has a talk on the future of the Internet on YouTube. I can’t for the life of me find the video right now, but his talk, in essence, was about the following.
He was saying the first wave of networking was circuit-switched networking. It was connection-oriented. That’s how the telephony network used to function. When you made a call, a dedicated circuit was allocated to you out of several dedicated segments (wires) between each pair of stations, and that circuit, that path, stayed constant through the connection.
The second wave of networking is the current one, which is packet-switched networking, or how the IP network operates. You send a packet, say a 1,000-byte UDP packet, like a mail packet, with a destination address on it. The packet travels to some machine owned by your ISP, and from there it travels to some other machine, and keeps going for many such “hops” until it finds the destination address. When you’re using any “online” application in your PC, it is constantly sending out packets to the same destination address, but the packets can each be routed through completely independent, different paths. There’s no dedicated circuit allocated for you, and packets can even fail to deliver, in which case you have to guess they died and resend them.
The third wave of networking, he argued, was content-oriented. He didn’t have a clear vision of what it would be, but he referenced content hashes. A “content hash” is a mathematical function (an one-way hash function such as the SHA) you apply to any “file,” any sequence of bytes, any data, and it gives out a, say, mathematically unique 256-bit number. It is virtually impossible to generate duplicates of that number for two different sets of data. So, if you have a network wherein you’re interested in some content, you can ask it to find a given content hash. That is, these unique identifiers, these content numbers become your “addresses.” You are not trying to find a specific “node address” on the network. You are trying to find somebody. Some content. It doesn’t matter where — which machine, which network interface — you’re going, as long as you find what you’re looking for when you get there.
It doesn’t matter who you’re talking to. It only matters whether they can provide what you want. And if what you want is a specific person, a “friend” to connect to and chat to, you can ask for that “thing” as well, and the network will route you to the place where you can find them. You certainly are not required to know “what is the IP address (or URL) where I can find them.”
But of course, the guy was almost right. He was not really describing content hashes for the most part. He was really describing Public Keys. The “public” part of Public-Private Keypairs, of Public-Key Cryptography. Your friend does not identify himself with a content hash, as he is not a file. He identifies himself as his public key — or one of his public keys, for which he has not yet lost the private key. And you’re not going to type in a bunch of public keys into your “peer-to-peer Facebook” or “peer-to-peer Dropbox” while you install it, to babysit it into connecting to the network so it can start to do something, into manually weaving its “overlay network.” Instead, you’re going to enter these public keys as a procedure to magically find and connect to your friends as peer users of an application. These public keys of users, along with content hashes and other things that can be used to “find things,” to “route” to them, will be passed along to the decentralized networking platforms, the “decentralized, virtual operating systems” on top of which these new, non-trivial and yet usable peer-to-peer applications will be developed.
The new, generic engines of decentralization that provide a conceptual correction of the IP network and that empower the very developers of “peer-to-peer applications.” Imagine developing a “peer-to-peer”, “decentralized” application without having to worry about all that bullshit that you see before you when you try to start over from the IP layer! If you think that was bullshit, you are right. Developing on top of IP is complete bullshit. Hell. There should be a framework, an engine that did most of that work for you. And that’s what I am trying to develop. To get there though, we need some insight into what is that “conceptual correction” that it is supposed to provide.
And at its root, that correction is very simple. The network is, essentially, the user nodes. Your computer, in your home, is the center, not your ISP, the undersea cables of the Internet, or the myriad “routers” that, unlike your feeble IP-endpoint node, have to do “actual work” and have actual routing power. And by home computer I do not mean your Personal/Desktop Computer, that planned-obsolescence piece of garbage that you have to entirely re-format every eight months or throw away and buy a new one. That computer is the computer you use as a terminal, to operate the system from somewhere in your home, to present a temporary interface to you. The user node, the Center of the network, is a special, dedicated computer in your home that is really an appliance, very much like a FreedomBox appliance in shape, look-and-feel, form. It looks more like your wireless router in your home, though it is not a piece of shit like most wireless routers and Seagate/WesternDigital home storage solutions crap. A server for which you have to do zero babysitting and near-zero configuration. It asks you only about things that make sense to you, that make sense to ask to an user. For the rest, it does its own thing, and in case it breaks, you lose nothing. You can try to fix it, wipe it clean, or even throw it away and replace it. All that you ever need is external storage, such as pieces of paper even, for your cryptographic keys — the same due-diligence, the exact same sort of backups you already know how to do when using a Bitcoin “wallet.”
The network is, primarily, these user nodes, these smart robots that serve people in their homes, that make people feel powerful when dealing with them. And “The Internet” — what is it? Well, the state-corporate Internet, the IP network, is your Bitch. It is just, as some US politician said once, just a series of tubes. Tubes operating under a corporate-state hierarchical paradigm. You will interface with the corporate-state, with the old world, do some work to get access to the tubes, and then you’re going to encrypt every single fucking thing that comes out of your home, and it’s going to exit through a Center you have in your home, travel through whatever carrier medium and whatever bullshit the carrier medium operates with, and it is going to reach the destination Center directly, or it is going to reach another intermediary Center which is going to keep routing it through other Centers until the destination Center is reached. Whether the various Centers communicate using “Internet” (IP networking and addressing) and/or smoke signals and/or Ad-Hoc Peer-to-Peer Wireless Signals and/or TCP Over Amateur Radio and/or Pigeons and/or Floppy Disks is mostly irrelevant.
The master addressing scheme is the address of Centers, and the application-level “address” of Centers is any one of their public keys. IP addresses, for example, become what MAC addresses are to IP addresses. The IP address becomes a network interface address. When you write an application to this “home centers” paradigm, this language, this framework, the “addresses” you use, for the most part, at the user/application level, is the Center address, which are Public Keys mostly. You pass these in and out of the networking engine you’re using, and you don’t ever have to deal with meaningless IP addresses anywhere in your code ever again, unless you’re going “physical layer” and doing lower-level stuff.
The power relation is inverted in the minds of the programmer and also of the home operator of decentralized systems. The application is the center, and “The Internet” is, conceptually, a mere provider of tubes among potentially many, though in practice nothing but the conceptual inversion is really necessary, as the abstractions of IP are isolated by an engine, a set of “IP Drivers” that solve all the theoretical attacks that can be mounted against any decentralized application that uses the API of that engine. The application developer, the person trying to solve problems of decentralized applications, does not have to reinvent the wheel of dealing with a network intended for consumer-company, state-corporate asymmetric power relations, whose assumptions are encoded in the hostility of the IP networking paradigm towards their creations, and all the theoretical attacks possible that can be mounted against “naive” decentralized networks built on top of a network such as the IP network, where nothing but the most centralized applications can be made secure by application development and deployment without incurring an absurd technical cost.
Decentralized does not mean center-less. It means you are the center of power of your life, together with other people who are also the center of power of their lives. If you are not left more alive, powerful with it, then your “decentralization” is simply extinguishing whatever “centering” was left after the “centralized” power systems took their 95%+ cut of people’s souls.
What do Centers do with each other: Trust vs. Trade Networks
On the Internet, ISPs don’t grant users the power to “multicast.” If a home user wants to same the exact same packet of data to 1,000 people, the user has to send 1,000 copies of the same fucking packet down their connection to their ISP. This is incredibly moronic and is really just done because the enforcement of “unicast,” or “one-packet, one-destination” is really the only way the IP world has to throttle spam. If you don’t ever know whether your users are spamming until someone denounces them, you cannot allow multicast, or “one-packet, multiple-destinations.” The only entities that can multicast are large, dedicated networking deployments that can deal directly with carriers at a business or state level. Say large corporations and state institutions, universities and research centers, military institutions, etc.
At the core, is the “anonymity” or, better put, the lack of insight by the IP protocol on who the parties are and whether they can be trusted. Trust Networks are supposed to address that. If you can score nodes of a network (“physical” or “logical”), then any “routing” through that network can use these trust metrics to limit spam: if you are overloaded as a router, then you take more routing commands, you forward more traffic from peers you trust than from peers you do not trust. That is necessary because all routing is “free.” There is no “compensation,” no “trade” going on. All e.g. network routing service you do is “for free,” in a spirit of hopeful reciprocation or, in the case of hierarchical corporate-state IP routing, users have paid for routing proportional to what they can get through unicast, and corporations and the top-tier routing hierarchy running BGP usually can monitor each other and see their traffic exchanges mostly cancel out — when they don’t, people with jobs talk to other people with jobs and problems get solved.
The paradigm of Trust Networking is gaining traction. The idea is that the “peer-to-peer Cloud” that will at last free users and connect them directly, bypassing the tyranny of Facebooks, Googles, Twitters, Dropboxes and Apples will be shoe-stringed by people identifying other people, their “friends,” and connecting them directly. Perhaps even using their Personal/Desktop Computers, or their Mobiles, but not much more will be required. There are academic projects researching that kind of stuff, and also techno-activists with or without Tech Industry ties, trying to build their own peer-to-peer networks of liberation using that paradigm of Trust between Users being the source of the central abstractions in the code, in the basic anti-spam, attack-resistant routing logic and in the user-interface operation of such systems. For one thing, the interminable quest for secure and scalable Distributed Hash Tables (DHTs) in CompSci literature has finally headed towards that alley, and has actually attained some results.
I hope these do work. There’s a lot of people down that path. I however am headed in another direction, just in case.
First, a quick recap. As I mentioned before, perhaps not so clearly, I do not believe every developer of a decentralized, distributed, “peer-to-peer” application has to develop his own fucking network from scratch. In no circumstance should that developer be coding his application on top of IP Sockets. The best analogy here, though a bit flawed, is with games. If you want to develop a 3D online shooter, you should just develop a Quake mod (or a mod of whatever the kids play these days), or at least use the Quake engine as the basis of your own modified game-engine code. You do not want to open Visual Studio and start from base libraries and IP networking. The engine has already solved a bunch of problems, so you can focus on how much blood you want to be spilled when a bullet hits a head.
Okay, so we want to develop an engine, an operating system, a network, this big thing that is really a correction of the Internet itself, of the OSI layers model. It inverts that fucker and puts the peer-to-peer application developer and the users he wants to serve at the fore, at the position of power. Ideally, we would develop one such network, one such engine, and just plug applications on top of that network, in such a way that different applications could talk to each other using the same logical network. I can develop an “app” to this peer-to-peer network that e.g. sells disk space, and a person can develop an “app” that is a decentralized hosting solution, and another an “app” that is one of a myriad of crypto-currency wallets, and these apps all talk to each other through the same routing substrate to have a computer pay another computer to keep one copy of an encrypted file for one user. I am not really creative in that regard tonight, but you can come up with even more interesting, complex scenarios when your “app” is no longer the sole app in its own logical network, contemplating the virtual impossibility of that app communicating in any non-trivial fashion with other apps that all operate under their own logical networks and whose only commonality is really the IP protocol and its complete fucking uselessness as a inter-operator between different “peer-to-peer” application projects.
The point is, as an app developer of decentralized thingies, you now have an engine of decentralization, of distribution, of “peer-to-peer” that really works for you and that really gives the abstractions you need to work and to think in when you’re trying to build a global network of sovereign, powerful, emancipated, self-governing users. You’re no longer isolated, fighting alone against the depressing psychological rape that is IP Networking, Desktop Computing and not to mention the entire body of corporate-mindset software that you’re trying to use to liberate people from that very mindset.
And finally, Trust vs. Trade. My route is that of Trade. But first, let’s remember Hashcash.
A solution to spam: the Hashcash system
The Hashcash system was a way to solve e-mail spam. With Hashcash, you force the sender to solve a self-selected puzzle to be able to send a single message. No server is needed: the sender can choose the puzzle. But the puzzle is mathematically bound to the message he wants to send, as well as the recipient’s address, the time of sending and a bunch of other things. So, if a spammer wants to send a billion messages, he has to pay the computational cost of solving the puzzle a billion times: once for each message. Hashcash is a “Proof of Work:” it proves the sender has “paid his dues,” has “suffered” to be able to send that message.
Incidentally, Hashcash was the core inspiration, the precursor to Bitcoin’s “coin mining”: its secure, 100% decentralized time-stamping and event-ordering algorithm. To attach a block of transactions to the chain, and to earn “coins” for that, you need to solve a difficult puzzle that takes, on average, 10 minutes to be solved by the network of puzzle-crackers as a whole.
E-mail spam is essentially the same problem of multicast in IP networking: one sender, multiple destinations. I believe that our conceptual network of Centers, regardless of how we are going to codify it into a peer-to-peer engine or virtual operating system that takes various “apps” on top of it, is going to charge something like Hashcash as a substitute for trust, when the “customer,” the computer of an user requiring something from another computer of another user, such as basic routing services even, cannot prove that they are to be trusted (the other computer is not a “friend”) or when they possibly are a “friend” but, anyway, the “friend” still wants “cash” because at the software layer the decision has to be made there’s no access to the concept of users and their friends, or so he can reciprocate later with someone who is not one of his friends — if the Hashcash being paid is not regular Hashcash, but Transferable Hashcash — essentially, a “crypto-currency,” a form of digital money.
When computer nodes, when peer Centers are asking each other favors, and when the number of favors requested of a Center exceed its capacity, that Center has to know which ones to prioritize. That can be done if requests can be white-listed as, for example, belonging to a Center that is a computer agent of a “trusted human friend” of the human owner of that Center. That can also be done in a loose tit-for-tat, running-credit system where the first five favors are free, but the sixth one is given only if a returning favor is returned first, and so forth. And that can also be done if one Center just pays the other some generic, globally-valid digital money.
In either case, I model the world of computers serving us as a world of Trade. But not in the exact image of the current, abhorrent human world of Trade, but rather in the image of the original Hashcash anti-spam e-mail system. Trade not as an access of the few, as a manufacturer of poverty and competition, but simply as an anti-spam measure. To have a minimum proof, a minimum “cost” imposed on the anonymous requester of a favor. A world where “money” is something anyone can generate, at any time. Anyone could generate a Hashcash stamp to be able to send an e-mail, and that’s how digital money for this Trade Economy between Centers should operate.
That’s why I created Infinitum: a fork of Bitcoin where you get as many “coins” as the hash-rate you put in. That is, the first for of Bitcoin that is non-scarce in the same sense the original Hashcash system for sending spam-free email worked. The Infinitum “block-chain,” and the second-tier, real-time, light-weight “banking system” that is yet to be built on top of it, is intended to allow these home Centers to Trade very frequently and very cheaply, to regulate the very routing algorithms of the “peer-to-peer” overlay network! Centers run tabs on each other, and they top up their credits regularly on each other. When Centers need “money,” they just activate the local “mining” hardware to generate more or, if users don’t want to mine themselves, they can spend $10 to buy some of that computer-talk lube and inject it into their Centers. If his Center is going to reciprocate, $10 will give them just enough tit-for-tat buffer to operate the system for a lifetime. Or if you want other Centers to do a lot of work for you, without reciprocation, then you buy or generate enough Hashcash/Infinitum to pay for it, the same way you would pay for Google or Apple to host your shit. But now you’re paying much less, and you’re paying this not to a centralized information monopoly that’s going to be abused by the corporate-state, but to other people like you (mostly, hopefully).
So that’s my vision. The human operator of a Center is only going to Add and Remove mostly isolated, sand-boxed, virtualized “apps,” just like they do today with their Mobile phones — compare that to the hassle (far too often fatal to the system) of installing/uninstalling things on Personal/Desktop Computers. The Centers have their own distributed operating system or network that ties all of them up, and that knows how to hold Hashcash and how much they have to spend autonomously and on what, as budgeted by their owner-operator user. The user expresses their wishes, the things they are interested in, by the installation of “apps” which are searched for, found, downloaded, paid for (the transfer service of the actual bytes, that is) and installed by secure content-hash verification. The user operates the “apps,” mostly by pasting public keys of users and things they want to interact with, or content hashes of files or other static resources they want to get or find. Or, if the “app” really creates other metaphors, other objects of interest, the addresses or names of these things that they introduce on top of the core abstractions, the core locators of the operating system, network or engine of Centers.
Eventually, the “apps,” or the peer-to-peer engine itself, or its drivers, will insert other forms of “trust” as alternative “payment” avenues. These are more complicated to visualize. The generic glue is, to me, Hashcash. It is easier to deal with, and easier to use as a boot-strapper of the rest. If the peer-nodes can just pay each other, we can abstract away trust and just deal with prices as we solve all the other problems, and try to visualize how the network of Centers and its component apps is really going to work, focusing on the actually important problems. Later we can refine it and introduce additional source of trust. For now, I think, electricity eternalized in the form of symbolic information should do the trick.
The basis of all decentralized (in the computer science, computer-technical sense, as well as in the social sense) computer systems for self-governance, for “anarchist”or “libertarian” creation of a “Star Trek future” or “Venus Project future” of peace and abundance, passes through identifying we are immersed in a corporate-state, structurally genocidal and ecocidal paradigm, and that paradigm trickles down to the pieces of technology, hardware, software and networking infrastructure, that are available to the creators of alternatives to that structure.
A networking engine, conceptual framework, set of libraries and APIs is needed to make the development of “peer-to-peer networks (applications)” something that is not a complete technical and conceptual nightmare. All e.g. Sovereign Computing projects will have to deal with that problem in one way or another.
One way to do that in the medium term is to push capitalism to the computer realm, tell the computers to convert electricity into Hashcash, and just let them pay each other. By doing so, we can develop autonomous, self-organizing, self-healing, self-assembling decentralized software ecosystems that are usable, because they ask the least possible out of users. They don’t have to know who your “friends” are to assemble the network. All you have to do is plug that black box into wall power and DSL/Cable, and three months later the box has money in it. Because you didn’t tell that 10-TB disk box what to do for you, so it just started serving other people, and charging the default rate for it. Now you can install a “dropbox” app and drop a few GBs of photos nowhere in particular, in the “cloud,” and leave them there for the next fifty years if nothing else changes. And if you later install a “chat app,” or a “Twitter like app,” then the app is going to ask you who your friends are. You can paste in the public key of every such “friend,” or, in the “2.0” version of these “apps,” you just type in one public key — of the decentralized, multi-party audited, reputable trusted name-to-keys directory that everyone uses, and just “search” there for an unique, intelligible symbolic name that your friends paid a little bit to insert there.
Total freedom from the Twitters and Facebooks and Googles is very possible. It will be harder to get rid of the physical Internet, the IP network, and replace it with something else. Perhaps we never will; perhaps even as we replace the corporate-state with bottom-up, life-affirming, truly human, global self-governance, we will keep that old bugger working, as its specific architecture will no longer bother us. We won’t have needed multicast at the “home” after all, and its abstractions only assault the minds of the few people who still have to deal with the lower-level stuff. Or, who knows, the network of Centers actually informs and controls the next iterations of the IP protocol, injecting its bottom-up knowledge of “trust” into it, and we even get multicast to work for everyone without out-of-band negotiation.
3:20 AM. I’m feeling a bit dizzy, and I hope any of this stuff makes sense. Hit publish. Sleep.