An ARGON cluster is a bunch of nodes in the "real world", and a bunch of entities in the "virtual world".

Each physical server or workstation is known as a node in ARGON terminology; a group of nodes under common administrative control is connected as a cluster, enabling a certain level of trust between the computers comprising the cluster to reduce communications overheads, cooperate on common goals, and to ease administration. Generally, the cluster will usually be administered as a whole, rather than as individual nodes; unless initial installations or hardware upgrades are involved, operations like upgrading software will be performed on the whole cluster.

The cluster cooperates to create the illusion of having one giant shared persistent mass storage full of entities. It's like a distributed file system.

Entities are the applications, services, and files in the ARGON worldview. They are things you can see as icons represented in folder entities and double click on to open up. Their state is replicated across the cluster automatically, and defines their behaviour.

Entities publish information, making it accessible to other entities that ask for it (potentially subject to access controls). This includes information about themselves and information about other entities; entities publishing named links to other entities creates the browsable global "world" of entities, somewhat akin to a combination of the DNS and the World Wide Web.

Entities also provide interfaces (usually several of them), so other entities can submit requests to them that cause code to run "within" the entity.

Entity IDs

Each entity has an ID, which is an opaque block of data containing all the information required to contact an entity over the network, and to cryptographically authenticate it.

Entity IDs are messy things, often quite large (with a list of the IP addresses of all public nodes willing to service requests for the entity, for example) and full of numeric data such as cryptographic keys and hashes.

As such, people don't have to deal with them. Instead, entities are generally referred to by a name, which is a path within the "navigational tree" made up from information published by entities. A name can be looked up to find the entity ID by examining the published information for each entity in the path.

Examples

Here are a few examples of how a few common 'things' can be represented as entities.

A document

Be it written text like HTML or a Word document, or something like a spreadsheet, a 3D model or a picture, the concept of a document is that it's a blob of information. Software is needed to view or interact with that information, but the same bit of software can handle any document of the type it's designed for.

Currently, there are a number of formats for documents of each 'type'; HTML, XML+CSS, XML+XSLT, PDF, and Word all compete for roughly the same application domain. And there are a number of applications, each of which can edit one or more different formats.

Well, we'd like to think that there's no need for such a proliferation of formats, if one format could be designed that's extensible enough to be compatible with varying applications. Maybe ARGON will be lucky to be spared this mess, maybe not.

An entity that contains a document in some agreed format will export the document data as its published knowledge, and will provide an interface to allow API-level access to updating the document itself. For instance, a spreadsheet protocol might offer endpoints to set the contents of a cell, insert rows, etc. There may well one day be several competing spreadsheet protocols; one would hope not, but it's not a showstopper if this happens.

The spreadsheet entity wouldn't contain any actual source code for these operations - it would just refer to a software module that provides the spreadsheet interface. When the nodes hosting that entity receive network requests that require "server-side" code to be executed, they will execute that code within the entity's "context", enabling the code to access the entity's internal state.

A separate software module provides "client-side" code to provide a user interface, by interpreting the published document data from the entity to display it and submitting requests to the "server-side" code over the network to modify it. A reference to this user interface (the name of the module providing it) is embedded in the published state of the spreadsheet entity, so that human-interface software can find an appropriate user interface for the data, which is otherwise opaque to them (unless they have inbuilt support for viewing and editing spreadsheets).

However, ARGON user interfaces may be configured to react to the presence of the 'spreadsheet' protocol by providing the option of accessing with a different user interface, so the user can still (in effect) choose which spreadsheet application to edit their spreadsheet file with.

Notice that all document editing, however, is handled by communicating changes back to the document entity as you do them; there is no concept of opening a document editor application, loading a document into it, editing it, then saving it. It's all entity oriented.

Document entities are highly likely to also provide a standard protocol for version control. Extra metadata in their published state points to the presence of a version history that can be requested, and previous versions of the document can be accessed (using entity IDs with persona fields containing a version reference); the entity will also publish name links to those persona-based version EIDs to name previous versions of itself. A version control API provides operations to push new commits, make branches, and so on.

I've made some mention of software being published in modules with names; those names are entity names in the global namespace discussed previously, and they refer to an entity that publishes source code for a module, ideally also using the version control protocol so that specific versions can be referenced by name.

A service

One might write an entity that provides a service, such as a notary public signature service. This would be done by providing a "notary public" API with two operations; one that accepts an arbitrary object and returns a signature object, and another that checks a signature by being passed the original object plus the signature, and returning either the date and time it was signed, or an error if the signature is invalid.

Such an entity need not have any internal state beyond some cryptographic secrets and references to the software modules providing the service.

An online shop

An online shop wouldn't be a single entity, although there would probably be a front-end entity offering navigational and user interfacing facilities. Each product would be an entity itself, and an ordering service entity would accept payment information as well as a list of IDs of product entities along with appropriate quantity/style/size information, as appropriate, to place your order.

Ideally, purchasing could be handled by a standard protocol across all or most shops, to enable snazzy tools to scan a number of shops for the best prices, but that may be too much to hope for!

Either way, the ordering service entity should provide a nice user interface for browsing products and adding them to a basket, and making your purchase.

A human being

Even users are entities in ARGON. Humans are represented by "User Agent" entities. When a user performs an action upon an entity, it is their agent that uses the interface; so to grant a user a capability, put their agent entity's ID in an access control list.

As well as acting for the user in the virtual world of entities, the user's agent also publishes information about the user, and provides interfaces to interact with them. Think of it as being like your email address, blog, or social networking profile; perhaps something like a "Google Account" that provides email, calendaring, and other services all wrapped up together.

Programs and Applications

As is probably already evident, ARGON's model of entities is more like the Web than like a desktop environment or mobile device with installed applications.

However, there is something that works a bit like a desktop environment; your user agent. When you "log in" to an ARGON human-interface device, your user agent is given access to the device's capabilities to present you with a user interface. What that user interface is entirely depends on your user agent - you get to choose it. Its responsibility is to let you browse the information published by entities, which includes navigating the navigational structure they provide, and to interact with user interfaces provided by entities.

However, your user agent can let you use your own user interfaces instead. If you install a spreadsheet "app" into your user agent, then it will override the default one provided by spreadsheets you encounter.

Also, your user agent can manage data for you inside itself. For a start, it manages information about you that is published to others, and you will also be able to install apps into it that manage that for you. Secondly, it provides APIs to let other people contact you through it, such as sending you things, requesting to book a meeting with you, requesting real-time chat, and so on. Those are all provided by apps you install into your user agent.

Finally, a user agent might contain a load of entirely private information, never published or made accessible via an API, managed entirely by an internal app, such as your phone book.

These apps, of course, are just shared source code modules published somewhere, plus some wrapper information declaring them as installable user-agent apps; your user agent contains a list of them by reference to their published code modules, which it loads into itself and allows them to hook into and extend its behaviours and capabilities.