eXastum WebOS on SAFE?

Has anyone seen eXastum?
It appears to be a browser based OS that I can’t help but think would be pretty cool on the network.

Having the login/file system be tweaked for the SAFE API would be interesting…

10 Likes

There was another one with the same idea a couple years ago but I forgot the name… It was in beta but it seemed pretty cool. Maybe you know what I’m thinking of?

Just an update, I contacted the dev and let him know about Maidsafe and the possibility of switching to SAFE for storage, he had some good info…promising stuff! -

"eXastum currently uses HTML5 local storage to store settings and such via a little function I wrote called lStore which can be found in my Macgril JS library, it’s listed as mg_lStore. It is just a very simple abstraction to the local storage API to allow, adding, updating and deleting localstorage data through a single function.

As for the database storage I am using indexedDB however this part of the system is not yet developed further than setting up the database which is just some JS code directly in the setup script eX_setup.js. The actual indexedDB code will be in eX_storage, that file doesn’t exist yet but hopefully will soon. eXastum 5 is pretty new and is a full rewrite from scratch so thats why many features are not complete and there are no official releases of this version yet, although 5.0.3-alpha should be out in the next few days.

Just as a note, the mg_lStore function that abstracts the local storage API would actually make it very easy for anyone to switch to another kind of web storage in eXastum. Since the localstorage API is never called directly anywhere but in this function you could just change that one function and switch the entire system from using localstorage to using something else entirely."

10 Likes

I would guess it was probably Carbyn :slight_smile:

That might be it but the name doesn’t sound familiar, unless they changed it. I just looked at a list of other web OSes and didn’t see it there either. Maybe he gave up on it?

This is cool stuff. I’ve thought for along time that a browser based GUI to the OS was going to be the future. I hope that we will still have access to the lower level of the OS through browser i.e. the browser replacing the window manager. I will be looking into this project!

2 Likes

Hi everyone, developer of eXastum here. Carbyn has pretty much gone away because a company bought them out for 1.1mil if I remember right, I saw some websites belonging to the company that bought them out that had absorbed some of the features found in Carbyn but Carbyn itself basically disappeared. Another called OS.js is impressive in terms of core tech, it has a filesystem and you can even run GTK+ apps in the thing and use its desktop as a client for X11. Projects like Emscripten have completely changed the game, people are doing crazy things like attempting to port UNIX clones into the browser and such, that wasn’t really a thing when I started eXastum, HTML5 was only really coming on the scene, its part of why eXastum became so popular it was because I was using features that people didn’t know existed and everyone was amazed but by know everyone is well aware of what HTML5 can do. While I love people supporting my project and being interested in it I honestly have to advise you guys look into OS.js or eyeOS, they are both leaps and bounds beyond eXastum for what you want to do with it, just my two cents.

15 Likes

Welcome to this forum. It is good to have you here.

6 Likes

Thanks :slight_smile:

3 Likes

@brianmillar with your skill and experience I can easily see you making one of the more popular apps for SAFEnet. Please feel more than welcome to stick around and help us bring about a communications revolution. The current internet paradigm is about to shift. Take your position and get ready to make that money. :wink:

5 Likes

I looked at both. Pretty neat. eyeOS - http://www.eyeos.com seems closed source, but os.js - https://os.js.org/ is open source and the demo is showing promise. https://osjsv2.0o.no/

I could easily see authenticating into my SAFEdesktop, putting it in full screen mode to remove distractions (the demo allows this) and having all my SAFEfiles and SAFEapps (SAFEchat, SAFEbrowser, SAFEmail, SAFEwriter, etc.) accessible in a my customized environment… from anywhere. But I would think you need to be sure the host browser your using, on the host system, are both secure too. Wonder if it would be able to control or communicate with local devices like a web camera or nearby printer, or remote devices like my printer back home.

When polished, for everyday users who do not care about how things work… I could see no need for interaction with the hostOS anymore. Turn on your device and it boots up (Linux, BSD, or some other free secure OS with very low overhead), and all it does is auto launches an HTML5 browser (a secure, opensource, free browser) in fullscreen mode and it goes straight to a SAFEdesktop authentication screen.

People “test it out” from their Windows or Mac, and can slowly migrate everything to getting to where all they uses is the SAFEdesktop and when that Windows or Mac gets old in the future they just buy a SAFEappliance for home use and carry on right where they left off, in their secure SAFEdesktop…

I see lots of promise in this type of system with SAFEnetwork underpinnings… both are in alpha… perfect time for someone to take control of this and merge them into a new system.

4 Likes

I think this is possible because I have a web app working with SAFEnetwork that accesses the webcam using WebRTC - the browser asks the user permission when the app asks to access the Webcam. I don’t know much about WebRTC but if it can access the webcam it seems very likely it provides ways to access printers and so on too.

I think eXastum and OS.js are both very promising and hope @brianmillar will stick around. BTW Brian, do you know there’s a programme for MaidSafe and the community to jointly fund projects that are deemed very important to the core offering? We just funded the SAFE Beaker Browser, and I think a SAFE Web OS would be an interesting candidate project :slight_smile:

5 Likes

@happybeing
Webcam and Mic access is certainly possible with user permission. As for printers I don’t think thats possible however its not necessary either, pretty much all browsers have a print function built in, all the web desktop needs to do is format the page correctly for the for built in print function, you can have custom CSS sheets just for print setup which makes it easier. I haven’t looked much into WebRTC yet myself but I probably should, it may solve some issues. Currently eXastum has a fatal design flaw that prevents it from being a useful web desktop. Its application system works by jumping into the DOM of an application through its iFrame and manipulating its DOM and call functions etc. Vice versa also works so the app can reach up into the system and call functions etc. This is a security problem and it causes cross-domain apps to not be able to use eXastum APIs or communicate at all. Its just the way it works right now. Browsers will block iframe <-> parent window communication if they are not on the same domain, same port etc. Chrome is stricter about it than Firefox and breaks when running local files without a localhost server, so eXastum 5 works fine in Firefox as is whereas with Chrome it must be run on localhost or the communication is blocked. And that’s just for local and built in apps, remote apps have no hope of working with this setup. Replacing my DOM hackery, and is really is hackery, with cross-domain messaging might be the correct way to handle this. I’ve found this: spec.whatwg.org/multipage/comms.html#web-messaging and it sounds my issue is exactly what this API was designed to solve and has given me great hope for resolving the problem. It could be a good idea to have messages posted to a system bus like how DBUS works in Linux distros. Thanks for the info about the community and such, I’m still figuring out what all this is about as I hadn’t heard of SAFE until I was emailed by @mvanzyl. Its all new territory but there are endless possibilities for what could potentially be done.

5 Likes

Thanks for the kind words :smiley:

1 Like

This all sounds positive to me.

I suspect that on SAFEnetwork those cross origin issues can be solved - not least by the SAFE Browser itself, or WebRTC, or…who knows. I’m no expert, just learning what I need in order to tinker and help out where I can, but I think these pieces look like fitting together and it’s very exciting.

I’m glad you’ve picked up that SAFEnetwork is worth looking into. I’m sure you will not be disappointed :slight_smile:

4 Likes

Yes, the cross domain issue is a sticky one. Maybe a plug in for Firefox, Chrome, etc would allow that to be bypassed so people could test out and start to use the system, if the plug-in was only for safe:// based items being able to cross domain communicate. A SAFEappliance could have any HTML5 browser we wanted, with whatever changes to the policy we wanted, but for people to test it in their favorite browser on their typical OS, a plug in might be the answer, if a plug in will allow that level of security bypass. People might download a new browser for mac or windows to try it, but a plug in would let the user feel most comfortable with the least change.

Your link to web-messaging is not there anymore. Looks like they redid their site. But if you have the code or can find it again…

1 Like

Sorry I copy and pasted the link wrong, here it is https://html.spec.whatwg.org/multipage/comms.html#web-messaging. This API seems to be designed to solve this exact problem. It opens with a very promising introduction that directly addresses this issue:
"Web browsers, for security and privacy reasons, prevent documents in different domains from
affecting each other; that is, cross-site scripting is disallowed.

While this is an important security feature, it prevents pages from different domains from
communicating even when those pages are not hostile. This section introduces a messaging system
that allows documents to communicate with each other regardless of their source domain, in a way
designed to not enable cross-site scripting attacks."

3 Likes