1

Hi folks,

I was replying to that big comment thread about SwiftUI for other platforms, and thought that what i've answered there would be a great thing to describe in its own post and get a little feedback from the community, giving i'm about to launch this.

Im about to launch a platform for application development, that is multi-process and multi-os based on a heavily modified Chrome engine.

The primary application SDK is for Swift, that will have direct access to the web layer and even the compositor layers that are gpu accelerated (the ones that the web layer actually uses).

I bet it will be a perfect match for a SwiftUI kind of layer as it can directly draw to the accelerated compositor layers through the Canvas API for instance. (This comment was targeted at the SwiftUI post)

You wont have to worry in binding to many graphics apis because the platform will have this covered for you.

I was trying to keep this to myself until the launch phase (a couple of months from now), but giving i think this will be a perfect target to this and giving i'm almost there, seeing people anxious about stuff that the platform im describing can help, i couldn't hold it.

This platform will be a mix of a browser and a application platform like the ones you see in phones, with the difference that for each app there's an application process running as a service and handler of a RPC service(you can think of it as a application server process) distributed with the application and a application UI process for each UI launched (much like the renderer process in Chrome).

The applications distributions is P2P and the storage is also distributed through P2P, later when the applications are installed on the "nodes" (the host OS) they can serve through RPC over TCP or only IPC if they want to serve it privately only to the local machine.

The storage layer can also be synchronized over the p2p network in a distributed fashion.. so users can have their persisted resources and share them with others or clone to themselves in other machines.

Giving its multi-process, its a good target for multi-platform application sandboxing as important things all go through IPC and can use a permission system that is controlled by the machine/host owner.

The applications will have to be good citizens and define a API that will be used by the RPC service handled by the application logic.. So it will be easy to have a inter-application interface or network between apps in the platform.

I wonder whats the interest of the Swift community in this kind of project, as it would help a lot all of us in developing applications in Swift that could easily run in other platforms with a rich SDK as in smart-phone platforms.

EDIT: Just a detail, that the application will feel as its running on its own (think Visual Studio Code).. the user wont need to know about all of those details, and the developer will have a lot of cool stuff being automatically managed for them.

The application for instance can have a native binary that will launch it, that is actually just a shim calling the RPC method on the host machine that actually launch the application.

As the "application server" process(singleton) runs all the time, the application can manage background tasks and later when the users needs it just show in the UI what it have processed before.

2

Are you targeting platforms like macOS, or are considering mobile environments? In mobile environments, no process ever runs "forever", unless you jailbreak it, and install something at the root level (at least for iOS, really can't speak for Android). So, you'll have to figure out to kill/restart your "forever" process cleanly.

How are you going handle security? How will you mediate between "good" peers and "bad" peers? If you are going to punt that to the application, that's the wrong answer. You are putting together an infrastructure close to the operating system, and all security research has shown that those type of services have to security considered at the root. Application security is just too high level and can be compromised quickly.

3

Sounds like CORBA to me (Common Object Request Broker Architecture). Been down this road before. Not a bad architecture, but, it's not revolutionary.

4

About Security

One of the good things about using the chrome code infra-structure is to be able to reuse the multi-process and IPC communication layer, so you can basically sandbox the application process with few syscalls giving the applications access the resources through IPC by asking to the host process.

This host process works as a "userspace kernel" controlling access to the host resources and can be the only process to have a better access to the OS resources.

This is the same architecture used by the chrome browser by the way that can even launch "untrusted code" in a very insecure fashion (as in out of the control of the user)

In this platform, the applications can be considered "trusted", because the user will install the apps he wants that will be digitally signed and only accessible via the public key over the DHT that routes the app manifest. The app manifest then is used to distribute the application in p2p fashion, as in torrent. Later you can decide if you help to serve the application or not.

And even when they can be considered trusted (contrary to the browser), their process will have almost non-existent access to the host system and they will have to route all the resource calls over IPC throught the main host process.

About peers.. in the beggining it will only be used to distribute applications and contents (access to blobs/files and structured data over a key-value store), but later i intend to use the same peers sharing content to be used as peers (if they authorize of course) to serve the RPC api in distributed fashion.

Only the "host process" have real access to the peers, but eventually IO events could be routed to the applications process from the peers so the daemon application process can act upon it (can be grouped only by peers that share the same RPC api for instance). For instance it can add to a pool of peers and route method calls working in a distributed fashion and working as alternative to a centralized service on the cloud.

About Corba:

Yes, its RPC like Corba was, implemented over gRPC (which is basically RPC-over-HTTP2) with bidirectional streaming support.

Because its gRPC, there a lot of drivers for almost every language out there, so this gives a way to call the methods of an application from Python or Go, etc.

Its not that the novelty of the project im making lies in any component im using, im even trying to use kind of boring technology.. but i think that once they are put together in one piece, that combination can make really cool things.

Just by running the not-yet-finished version i have here, there are a lot of cool things i can make here that i didnt see anywhere else. I think the advantage here lies in do this in the cathedral fashion, where you can combine things and make them work together smoothly to make it easy on developers and users.

About the targets:
iOS will the the only target out of this for now, because of the restrictive environment Apple impose on iOS applications. Even Android will be able to run this as the multi-process version of Chrome can with no problems.

But even iOS could eventually be added as a target, by running the multi-process architecture in one process, as Chrome already does in iOS.

To be true, i'm very interested in the aspect of applications running as in a network that can rely on others applications api to communicate and share...

As in, i'm most interested in how this runs more like a web browser (or a application browser as i like to think) does now, than just a UI application platform like Electron, Dart or Xamarin. I think it can be really competitive here too, but i'm trying to aim at a broader category, something that i've always dreamed to have, but never saw anything into that direction, that would fill that void.

But unlike the browser, i want this platform to "get out of the way" and let the application shine without the user even being aware the the applications is managed in a multi-process architecture.

The cool thing also is that you can create some sort of browser-like window to present the application process rendered framebuffers, instead of each app having its own window.

Also there's a cool factor about being able to own your digital life/property, being independent of the cloud, and only eventually(when its the best option) getting things from there.

The cool thing about going through a well-defined RPC api as a middleware, is letting the application decides if it wants to use and synchronize local resources or if it wants to talk to a mothership somewhere in the cloud..

By having a well defined api in Protobuf will also with time help into automation.. like sending a message into this chat app to someone from a python command line tool.. or getting text from blog entries from that blog app.

Imagine a search application being able to index the content of your social network messages only if you allow them to? And once you dont want that app anymore, that content it created remains with you as long as you want. Not having to loose all of your friends contacts, because its your digital property, and give access to it, only to the apps you want to?

How many social networks could not compete with Facebook just because facebook monopolizes the list of friends and you can get it out of there and export to the other social networks..

Also, you dont depend of any centralized app store to distribute your applications, you just pass over a address that is the public key of your digital signature where only you can change the manifest when you want to update to what application resource it needs to point (a new version for instance)

Or you can just use it to share your mail inbox with yourself so you can synchronize to the same application that uses it into the machine on your job desk.

Oh.. this text is pretty big now, but i need to add the fact that applications will export entry points as in pages, so you can access that resource directly.. eg: "/login", "/inbox"
and things are url addressable.
The intention is to help the user (or any tool) and if he/she wants, he/she can launch the "app X" at "page Y" because we have a central point that can manage this sort of things.