About CosmicOS

It's a familiar problem. You've finally managed to contact that alien civilization. Things are going great. You feel like your world will never be the same, that whole new realms of possibilities are opening up before your eyes. Then, inevitably, a hint of strain starts to creep into your relationship. You find that you don't really have all that much in common. Heck, sometimes it feels like you're not even in the same galaxy. It's as if there is this vast gulf between you, making communication almost impossible. You're not even sure you'd understand each other no matter how physically close you become. What do you do?

You design a language for cosmic intercourse. Hans Freudenthal made a start at one in his book, Lincos, published in 1960. I think it's time for version II, the all-new action-packed sequel guaranteed to have you on the edge of your seat, which is a specific structure with a flat surface perpendicular to the pull of gravity, which is a thing that, oh never mind.

Goals of CosmicOS

• To create a complete message which, if noticed by a non-human intelligence, stands some chance of being understood. The message should introduce the intelligence to a significant portion of the human world view.

• To develop this message in a form that is easy to edit and extend, so that anyone interested can simply take it and make it better without having to track down out-of-print books.

• To avoid making too many assumptions about the perceptual abilities of the non-human intelligence; for example that they make sense of 2D images in the same way we do. While some arguments can be made for this, as a machine vision researcher I am very skeptical that we really understand the variability possible here.

• To send Scheme into deep space.

• To send the GPL into deep space.

The "intelligence" reading the message could be extra-terrestrial, or artificial. It is this second possibility that motivates me -- I want this message as a challenge for AI -- but the ET possibility is also fun.

Current status

The current goal of development work on CosmicOS is to communicate enough structure to simulate a simple MUD (multi-user dungeon) and to use the interactions between locations, objects, and characters as an alternative to the clever "morality plays" in Lincos.

The message has a strong backbone of actual executable code. The results of executing code is fundamentally what gets talked about in most of the message so far. This has the advantage that it can be understood on two levels: working out what the code does by looking at its details, or just treating it as a black box and learning from examples what it does. It also gives the listener the ability to do experiments using the code that are not talked about in the message. At the level of the MUD, this means the listener is free to play around with the simulated world and understand its logic through experimentation.

A difficulty with using code is that it assumes the listener has a computer to run the code on, or is computer-like enough themselves to work through the code with excruciating patience. I'm okay with this assumption for now, since it is hard to imagine the message being detected in the first place without some good hardware.

Roadmap

There isn't quite a roadmap for CosmicOS yet, but development work can be decomposed into the following activities:

• Medium: Finding the most productive ways to encode the message in physical processes, for transmission or long-term storage.
• Kernel: Communicating a core set of logical and mathematical ideas, a simple programming language, and the overall structure of the message.
• Library: Contructing a broad collection of derived concepts from the kernel, enriching the shared language.
• Bridging: Making it possible to include code written in a conventional programming language in the message. This is important to simplify development, and to insulate as much of the message as possible from changes to the kernel.
• Alternative primers: Integrating entirely different kernels/primers into the message, to give alternate starting points to a reader.
• Simulations: A key advantage of the algorithmic approach to communication is that it is possible to include simulations and games, to communicate about physical and social properties by demonstrating behavior.

Medium

This issue has been studied extensively by others, so it is dealt with only superficially in this project. A toy auditory form of the message has been developed, and a few toy visualizations. Given that the message can be compiled to a sequence of 4 symbols, and has a very regular structure, encoding it physically should not be difficult.

Kernel

A basic kernel has been developed, reminiscent of scheme or lisp (but much simpified). The major limitation currently is that there is no treatment of real numbers yet, just integers.

Library

Again, a very basic library is in place. The issue of efficiency needs to be addressed -- some of the constructs used are very inefficient. It seems better to go for the simplest possible constructs, but this trade-off could be re-evaluated.

Bridging

The approach adopted here has been to support a subset of Java. Java byte-code is translated into code that can be inserted into the message, and evaluated in terms of the kernel+library. The Java support is being added step by step, and is far from complete (and again, uses inefficient constructs to maximize simplicity).

Alternative primers

Work on this has just begun. Based on discussions with Brian McConnell, logic circuits have been chosen as an alternate starting point. 2D images of circuits have been introduced into the message, and related to the kernel. But a lot more needs to be done to make this a true alternate starting point for the message.

Simulations

Pending the introduction of real numbers, there are no physical simulations. There is the beginning of a simulated adventure game with rooms and doors and characters moving around, but it is very rudimentary and wouldn't be very understandable yet.