Systems Design and IPC General

[4c3e]

I wanted to open up a discussion page focused on using Reticulum for inter-process communication on some sort of future computer systems.
@markqvist gave a nice description of what is possible here:

All of our computing systems live squarely within the terminology of a 1920's filing cabinet. That's literally the mental construction around what a computer is. A mechanistic animation of a filing cabinet, you know, one of those old metal hunks with plenty of drawers filled with "folders" and "files". Yes, that's what our computers are. Except that they're not. Since all computers today are universal turing machines (at least up to their memory limits), they can be made to represent or model any abstract or concrete concept (from the real world, or from the imagination, or a combination). The UNIX philosophy of "everything is a file" is incredibly powerful, but only up to the limits of the conceptual domain it exists within. There's a lot of other things in the world than "files", and our computers have a hard time dealing with them. This is severely limiting our creative capabilities and defining how we think way too much.

I want a computing system that does not draw the "filing cabinet" conceptual domain around itself. The kind of operating environment I would like to have could be termed something like "metamorphic computing". There is no operating system. There is no single-channel stdio. There is a hyper-efficient kernel providing the hardware abstration layer, and basic system-independent functionality for an operating environment. There is no files. Everything is abstract objects that can contain any sort of data structures and/or code. Any object can interact with, inspect, modify or communicate with any other object (according to rules, of course) on the system itself, or on other systems. Objects decide what kind of structures to materialise, from simple text to geometries, code, audio or anything else. Any object can erect internal representational domains to place its outputs into.

All abstract objects communicate with each other and the operating environment layers via Reticulum, making it possible to interact with objects on any system, or even render a hybrid environment that runs across thousands of devices (each one doing their share of the processing). This also makes it easy to control what and who can interact with what parts of your own systems. You can think of it as a sort hyper-connected, possibly distributed (when needed), always efficient, easily reconfigurable abstract simulation of any sort of abstract system you can imagine. This is the computer I want.

The human interaction with all of this is completely abstracted. You can run your entire "computer" on a very simple device, that simulates the metamorphic environment you want to operate in, and run the interaction interface on a powerful GPU-equipped system, rendering everything in 3D. Or interact directly with the operating environment running on the low-powered device over a console describing all the environments and states as textual representations.

This conecptual construction is insanely powerful and interesting. And it probably makes no sense until I give some more concrete examples of how such systems would look, how they would work, and what you could do with them.

Some useful resources for those interested:
Plan 9 from Bell Labs - http://doc.cat-v.org/plan_9/4th_edition/papers/9
The Organization of Networks in Plan 9 - http://doc.cat-v.org/plan_9/4th_edition/papers/net/
Minix - https://www.youtube.com/watch?v=bx3KuE7UjGA & https://wiki.minix3.org/doku.php?id=www:documentation:start
Project Oberon - https://people.inf.ethz.ch/wirth/ProjectOberon1992.pdf

[4c3e]

Obviously writing an entire OS focused on Reticulum networking is way out of scope right now, but I think one interesting idea Reticulum application developers could focus on right now is to represent processes as objects that can be fully utilized through an interface of Reticulum destinations.
An example given in a later discussion:

you could write a basic windowing system that exposed data about its windows, and events like mouse clicks and keyboard inputs as RNS destinations, and then you could have other software that reads and writes to these destinations, so each individual running window could be anywhere in the RNS mesh.
Kind of expanding on the Unix idea where “everything is a file”, I’ve just been having a bit of fun thinking about computing systems where “everything is a RNS destination”

[avon61002]

A distributed smalltalk, or some sort of E lang inspired actor system is a really good way of approaching this problem imo.

Modern options:

• https://newspeaklanguage.org/
• https://spritely.institute/goblins/
• https://syndicate-lang.org/

this project also looks interesting: https://applied-langua.ge/~gnuxie/posts/utena-introduction.html

I'm working now on building a "proxy actor" system in python on top of syndicate-py . The idea here is that for passing local messages, syndicate's message passing infrastructure will be used, and then remote objects can be messaged by resolving their reticulum destination into a "proxy" local capability address and then sending normal-looking messages to these proxy address. If the underlying reticulum channel fails for whatever reason, the proxy actor will be destroyed, allowing syndicate's built in error handling systems to be used.

In a similar vein, implementing reticulum as an OCapN netlayer will go a long way towards realizing this vision.

[LinuxinaBit]

I've been conceptualizing Java 'objects' as folders containing files that hold data ('variables') and execute code ('methods').
That is all contained in a sort of virtual filesystem in memory during execution, separate from the filesystem containing the code you actually wrote.
'Everything is an object' is just 'everything is a file' but with a different name.

Personally I nominate that we call virtual desktops 'groupings' and windows 'instances'.
Might be hard to explain to normal people though 🤔

[LinuxinaBit]

It's fine to reinvent the wheel, but please, please don't try to reinvent the circle.
https://en.wikipedia.org/wiki/Not_invented_here/

Edit: and especially please don't try to reinvent the computing equivalent of math itself like the people behind urbit: https://wejn.org/2021/02/urbit-good-bad-insane/

[avon61002]

The main issue of building on top of Unix-like systems is that they are all built upon a role-based authentication model. When I run a solitaire game in my Linux userspace, that solitaire executable has all the same privileges as me, including reading and modifying my files, accessing the network etc. Sure we could throw the solitaire game in a sandbox, but what if we wanted to compose this solitaire game with other processes? For example what if we now wanted to control the solitaire game remotely from a phone? Now we need to properly sandbox the solitaire game on the host device, while "letting out" only the precise network connections we deem appropriate, then create a secondary control application on the mobile device, which will have it's own sandbox etc. The whole system quickly gets complicated, as sandboxing does not compose well.

Now let's imagine that the solitaire game ran on a "reticulum os". When we ran the program, we would give it two destinations, one destination representing the window it will draw to, and the other representing a file it can read and write high scores to. Under this model solitaire is given the least amount of capabilities it needs to run, and nothing more. When it needs to draw to the screen, it sends messages over a link to the window destination (which, because of reticulum, can now be on any arbitrary device on the network!), when it needs to write a new high score it sends packets to the "file" destination. Because reticulum allows us to easily create new destinations, we can freely create and destroy destinations as we please, for example, if we want to revoke the game's access to the high score file, we can wipe the existing destination we have mapped to the file, so any new packets sent to the old destination won't be routed anywhere. Also, it is now impossible for solitaire to access any random personal files on your device, as it does not know the reticulum address to message them. This way of reasoning about systems is called "capability-based security" and there are a number of great resources for learning about these systems:

• http://www.erights.org/talks/thesis/markm-thesis.pdf (chapter 3)
• https://files.spritely.institute/papers/spritely-core.html#caps-as-programming

You're right that it is not useful to reinvent the wheel, but these systems already exist! If you replace "reticulum os" with "smalltalk" or "scheme" these systems have been around since the 1970's! The graphical user interface you're currently using, along with the traditional computer mouse, and many other personal computing ideas, came out of the Xerox PARC lab in the 70's which primarily used smalltalk as the "os". You could even (facetiously) say our modern linux personal computers are badly reinventing the smalltalk wheel ;)

For practical purposes I do think that linux is by far the best current option as an "hardware abstraction layer" for hosting a virtual machine or a message-passing daemon like the syndicate-server. It also is possible to build a capability-based userspace on top of the linux kernel, this is one aspect of the Genode project. But building an enormous tower of abstractions is usually detrimental to performance, privacy, and security. It also means a single user of such a system could never reasonably understand the entire system as it is far too complex. The STEPS project showed that it is not totally out of the question to implement a personal computing environment using many orders of magnitude less lines of code than the status quo: https://tinlizzie.org/VPRIPapers/tr2012001_steps.pdf. My hope is some day a from-scratch capability-based OS will come along with good hardware support, and become a much better host environment for an efficient message-passing substrate.

Some other related links:

• Design Principles Behind Smalltalk
• CLOSOS: Specification of a Lisp operating system

[LinuxinaBit]

This may or may not be related: https://xkcd.com/2044/

[LinuxinaBit]

I will say that that is a good direction to move in, but I don't think Reticulum is necessarily the right thing to start with, and I doubt the need for a complete re-invention of the modern operating system.

[LinuxinaBit]

Under this model solitaire is given the least amount of capabilities it needs to run, and nothing more

More practically; who assigns these capabilities?

If you can't trust the user to not run something stupid on their system, it's reasonable to assume you're not going to trust the capabilities they assign.
If you can't trust program developers to not be malicious, there is no way you're going to trust the capabilities they assign either.

So who do you trust, and how do you assign that trust?