This idea is entirely separate from MaidSafe as a company. If I work on this, it’ll purely be in my free time, entirely separate from my actual job.
Well, the keynote address first thing this morning from @dirvine sparked a few ideas in me. The mention of the commoditisation of hardware set a few gears in motion in that thinker of mine, so this is a thread to get everything out and on paper into the community.
I see from searching the forum that this has already been thought about, but I’m now documenting less so much the idea, and more the execution.
SafeOS Stage 1
For the first stage of this project, I envision making a replacement to existing software. SafeOS will be a Linux distribution, and will work like one.
Ultimately, this boils down to the login manager. By replacing this with a version of the Authenticator which then logs into SAFE Network, one can authenticate on every computer running SafeOS, simply by having a SAFE account.
The login manager should also give people the option to sign up to the SAFE Network as well, for those just starting out. If this ends up pervading the world (hey, engineers dream too you know), it’s not really a sensible supposition to believe a user will already have an account.
Taking this idea a step further. We already know that vaults can be used via NFS. This allows then the syncing of data everywhere - have the authenticator not only log in to the operating system itself, but also setting up the user /home to use the users vaults.
Additionally, the next step would then be to sync to another user vault, storing the users “installed” software and configurations. This would then be placed onto the system path, via manipulation of environment variables, symlinking, or some other how. The specifics of that don’t really matter at this stage.
I’d like to be able to demo stage 1 at SAFE DevCon 2019. I can’t guarantee that, but I’m gonna work my socks off to damn well try, and if I don’t manage it, I’ll still be talking about it.
SafeOS Stage 2
Stage 2 will build upon this. Application distribution will start to become more and more integrated with SAFE Network as time goes on.
One thing I can easily see, for example, is stock versions of existing software going live on the network, in an unencrypted, immutable store. This would work for both system software, and for user software. Either can be pinned, or left free to update, and a mutable store would exist, globally readable again, to contain a list of every version of the software, in order, with a link to the respective immutable store.
Assuming the version of a particular package is not pinned, the upgrade algorithm would work like this: for the operating system packages, the OS would detect an upgrade from the mutable store, download and install it, and in the case of the kernel, use hotswapping to update itself.
In the case of user software, I’d start to replace that central vault with a vault containing only configuration data, and a store somewhere detailing what packages, and what versions. These are then each independently mapped via NFS, as before. This reduces duplication on the network, and makes things a bit simpler.
SafeOS Stage 3
This one is relatively easy. Tighter integration of the SAFE browser into the OS, and greater usage of the desktop applications using SAFE.
Additionally, the OS shall now start to move away from the standard POSIX tools. There was talk today about starting to replace some of the GNU CoreUtils with equivalents that work with the SAFE Network. It’s worth raising here that they’d also need to work with ordinary files, in the event of things like external disks etc.
By integrating these tools, and potentially some new tools in line with the CoreUtils ethos, one can then begin to compose scripts to automate various jobs on the SAFE Network.
SafeOS Stage 4
At this point, I’d firstly like to start seriously paring down the size of the OS. Ideally, it should fit easily on a thumb drive as a bootable image, with plenty of space left over.
Additionally, we’d need to set up an installer at this point. The installer will connect to SAFE Network, and provide a way by which users may create an account on the network - fairly important for initial setup. This is, of course, optional, if users already have an account.
The installer should also install the necessary software for the machine to actually act as a node on the SAFE Network. This should not be done when in portable boot mode, however on a static install, it should, under the account of the machine owner. It would perhaps be best if this were provided as an option, as opposed to being required.
Possible future ideas
I can easily see this expanded further. An idea was floated today, by whom I forget and sincerely apologise, that the OS file system layer could be extended to offer various views into the data, as opposed to just a tree structure. For instance, “Give me all the photos taken in Spain in 2017”, would return a folder containing said photos. Windows Vista attempted something similar, to somewhat limited success.
@anon41664782 raised the idea of basing this on Redox as opposed to Linux. I personally think Linux makes more sense initially, due to the stability and maturity compared to Redox, but Redox makes for a good candidate as an alternate version. This will almost certainly be kernel independent, so SafeOS Redox would be a good second candidate, similar to Debian Hurd in nature.
@povilasb and @pierrechevalier83 both raised the possibility of basing the project on NixOS. Doing some light reading on NixOS and how it fits together, it seems to have a rather elegant concept of packages and configurations done through single files, which the package manager, Nix, then handles in terms of installation. I can easily see a case for this - users each have a configuration stored in an MD they own, and the login manager then installs this config upon login, removing it upon logout. This seems rather a lot more elegant than storing binaries and associated configurations somewhere.
@piluso floated the idea of basing SafeOS on Genode. Genode is an operating system framework based on components, which actually have SAFE in their roadmap, meaning this could get potentially submitted upstream, saving us (possibly only me 
) from the cost of administration, while the modular architecture and framework nature of the project meaning a separate SafeOS based on Genode wouldn’t fragment the community. Genode can run multiple kernels via L4, including Linux and FreeBSD, meaning compatibility with existing software is high. The nature of Genode makes it good for security, which is nicely in line with the goals of SAFE itself.
Disclaimer
Not all of the above ideas are mine. Some are, some partly are, and others were proposed by various people I spoke to today. Thank you to everyone who I spoke to who inspired more ideas, more collaboration, and more development on this. I forget who mentioned what, and I’m really sorry for that, I spoke to a lot of people today.
If anyone else has any ideas for how this could be extended further, what should be integrated in, etc, or just wants to work with me, please please please reply. I’m really excited to work on this, and would absolutely love to work with the community, both with ideas, and with building it.
