Hacker News Reader

Comment by fiatjaf | Hacker News Reader

What's the difference between this and Sandstorm?

It's an alternative to Sandstorm. We've made some different choices, like using full KVM VMs instead of Linux containers for apps. Portal also doesn't require that apps know much about Portal itself to be run as apps. They can use their own authentication or the single sign on system.

An unmodified Ubuntu cloud image is a valid (though basic) Portal app and can boot using CloudInit. Real world apps store data on the separate "user data" drive that is attached to all app VMs, which makes them upgradeable. And they almost always have a web interface for the user to interact with.

They can also use the Portal metadata service to interact with the system. But for the most part apps just receive raw TCP/IP traffic or proxied HTTP traffic and work normally.

We began working on Portal before Sandstorm was public, but I can tell you this is the first time I've been happy to see other people working on the same idea as myself. Decentralizing the internet is more of a mission than a competition.

Also, we expect to be able to run Sandstorm as a Portal app, so you could run many Sandstorm apps inside one VM, assuming they're okay with that.

> Also, we expect to be able to run Sandstorm as a Portal app, so you could run many Sandstorm apps inside one VM, assuming they're okay with that.

I'm definitely OK with that. :)

Awesome to hear that. You guys seem to have the same motivations, so I'm sure we can make everything play nicely together.

I love your LAN house, btw. We're also insanely hardcore PC gamers who think LAN parties are the most fun thing in the world :-)

What I like about the VM-centric design you've adopted is that 'apps' are long-running by default. Sandstorm in its current form is not great for hosting internet-facing sites.

Sandstorm tries to encourage web publishing apps to work in a way that significantly reduces resource usage and improves security. The platform will let an app publish a static web site which does not require starting up the app to serve. The platform also lets an app expose an API which starts up the app on-demand. So the app can publish a bunch of static content which includes Javascript that invokes the API when needed (e.g. when a comment is posted), which then wakes up the app to update the static content.

But, yeah, for a fully-dynamic web site served to a large number of users, Sandstorm currently isn't well-suited. It'll get there eventually, but given that other platforms (like Portal) already cover this use case pretty well, we wanted to focus on the interesting things we can do with fine-grained containers.

What is that?

This runs VMs, Sandstorm runs OS containers. Apps for Sandstorm might need a little work to integrate with Sandstorm's model for users and permissions, but apps in Portal won't have a built-in mechanism for sharing documents/data and will each have individual authentication, I assume.

Portal will have a method for sharing data between apps, but it's not there yet. For authentication, apps can run an HTTP server on a special port, which will be proxied to the user pre-authenticated. That might change before launch, but it's fairly simple.

In the case of apps that publish public URLs (like WordPress) they can choose to use Portal's single sign on or not.

Cool, thanks for the clarification. Glad you're building a single sign on feature!

Reply on news.ycombinator.com