This is Part III of a series on the Cartesia project. Part II can be found here.
Interface
As mentioned earlier, the primary interface to Cartesia is text-based. It is a simple "conversational" interface that can be displayed on virtually any terminal or console.
(interface example)
The interface has essentially two "modes", one for conversation and another for everything else. These two modes are selected by specifying a "prompt" character, a double-quote for conversation and an asterix for the rest.
The interface is primarily designed for direct use by a person but is also implemented as an HSNI to reserve(?) the potential for consumption by other types of interface. The primary objective is to make Cartesia more accessible via unanticipated interfaces but this also opens the door for other types of interface as well (graphical, immersive, etc.). The key requirement is that the interface never compromise it's usability as directly human-usable interface regardless of what other types of interfaces consume it.
Protocol*
Cartesia Worlds provide a standard protocol for interacting with their Rooms that is used to make connections between Worlds. For example, if you are logged-on to the Interface of World 1 and enter a Room on World 2, the protocol is used to get information about the room and the people and objects it contains from the hardware running World 2. Like the Interface, the protocol is also an HSNI so it is possible to interact with it directly, but it is a more streamlined experience... hmm...
VM
Most of Cartesia is implemented in a purpose-built virtual machine. The language of this virtual machine is the same language used to add programatic behaviors to objects. This means most of Cartesia is written in the same programming language as the objects inside Cartesia, and learning how to program objects is a stepping-stone to learning how to maintain and modify Cartesia itself.
The VM not only provides some safety in the form of isolation between the programs Objects run, but also makes Cartesia as portable as possible. This allows Cartesia to run on a wide-range of hardware but also provides protection from hardware obsolescence.
In addition to the above the VM tracks resource utilization and provides capacity information about the underlying hardware. When the VM is initialized it establishes how much of each resource it has been allocated and conveys the utilization of these capacities in the form of budgets that can be allocated to Rooms, Objects and People. As the World grows these budgets shrink and this information is conveyed to the People inside the World in a transparent way, allowing them to take appropriate actions. If the budgets are exausted, the VM prevents any further expansion to preserve the stability of the World until resources are freed-up or reallocated.
Examples
Rooms
Room 0.0.0 is often a "lobby" as this is the first place most people will experience in a given world. It is likely to have a set of rules for the World that must be accepted and a detailed description about the types of Rooms and Objects that exist in this World as well as information about the People who regularly inhabit it. It might even include a directory of the World, Objects that might be useful there, etc.
Another likely room is a library. This contains Objects that function like books, with attributes like "Author", "Table of Contents" and "Chapters" containing the text of the book. A library could contain other types of media as well, although it might require special Interfaces to access them.
Objects
Simple objects that serve as decoration for rooms is expected. These consist of little more than a name and perhaps a description.
As described in the Rooms section, a book object could be created by adding attributes such as "Author" and chapters containing the text.
A "concierge" that uses the programmatic features of Objects to produce a menu of services which can be selected providing details, or other forms of simple, interactive conversations.
A "pet" that purrs and increases a person's "calm" stat (if they have one).
An instrument that can be played by consuming conversation keystrokes like buttons pressed on a keyboard, etc.
Footnotes
* I'm not sure if there's a need for this, could we just "bridge" the HSNI of the regular Interface instead?
Jason J. Gullickson, 2026