Port Rocket.Chat to sandstorm.io

[Sing-Li]

Sandstorm.io is a platform of choice for running private apps securely over the Internet, and Rocket.Chat can become essential for users on the emerging private Internet.

Both Rocket.Chat and Sandstorm.io are built on Meteor. The porting (initial port - anyways) should be straightforward.

[Sing-Li]

Sandstorm's capabilities based security and apps inter-ops model supports a superset of #346

[jmatsushita]

Hmm... Sandstorm is awesome, but #346 is about deep integration rather than side by side apps (which are not interoperable - can't embed an ethercalc sheet in an etherpad doc right :) ? ).

[engelgabriel]

Like sdelements/lets-chat#419 ?

[engelgabriel]

https://docs.sandstorm.io/en/latest/developing/raw-packaging-guide/

[engelgabriel]

https://github.com/sandstorm-io/meteor-spk

[Sing-Li]

The port is basically working now.

The real cool thing is that you can save the state of your entire 'private chat server' (5.77MB on top toolbar) and migrate between sandstorm.io operators at any time - in seconds - with zero lock in 😃

Now the real work begins. Need to strip out our auth and just delegate to Sandstorm's. Sandstorm's accounts schema do not have the additional fields that we depend on - so we either maintain two sets or doctor Sandstorm's and forever-track-upstream-progress-and-redoctor 😦 @rodrigok - any preference?

[Sing-Li]

@jmatsushita - great observation 😄

Today's sandstorm.io is still a work-in-progress, and the 'apps' that exist indeed interop only in a side-by-side manner. Sandstorm is not part of their original design; and only an 'afterthought'. But it is my understanding that nothing in sandstorm's architecture prevents the 'deep integration' that you refer to.

In fact, the fine granularity security model, the upcoming powerbox UI, and the 'sandstorm native' app dev guidelines -- all point to a future where such integration can become common place. I'm no expert on the future of sandstorm. Perhaps @kentonv can enlighten us.

[jmatsushita]

@Sing-Li Thanks for explaining. That's cool. I guess that each type of application interop will be quite different, especially if it's about having an integrated user experience. #346 and #293 have some thoughts on a specific type of integration which is "chat stream centric" apps that might be of interest.

[engelgabriel]

Cool! That was quick! Feels nice to be surrounded by ninja devs.

I'll dedicate this song to @Sing-Li
https://www.youtube.com/watch?v=PSYxT9GM0fQ

[rodrigok]

@Sing-Li I really don't know :(

I don't know anything about sandstorm yet

[Sing-Li]

Thanks guys 😊 Love the 'low budget', 'high impact' style of that video 😉

[engelgabriel]

It's a classic! I love that song!

[kentonv]

You may be interested in this email I wrote about "composing" apps in sandstorm -- e.g. embedding one app in another:

https://groups.google.com/d/msg/sandstorm-app-committee/s0wxG3s_l-8/FHv6PUenwlsJ

More generally, the Powerbox is a UI which will allow users to easily and securely connect apps to each other through capability-based security. Details here:

https://docs.sandstorm.io/en/latest/developing/security-practices/#capability-based-usable-security

The powerbox and embedding are not done yet. The powerbox works in a very basic form involving copy/pasting secret keys, but we still need to build the picker UI on top of that. Embedding will be straightforward to support once the powerbox is in-place. (The main delay is that we have had a lot of more basic things that needed to get done in Sandstorm before we could think about the powerbox, but we're getting close.)

[jmatsushita]

@kentonv Thanks for the links. Super ambitious and fascinating. Capabilities for the win. But it seems that to handle more granular composition (when bits of documents are in other bits of documents - like a task connected to a commit or a spreadsheet range embedded into a document) is another order of difficulty and you might need to let apps figure that sauce out themselves (behind Sandstorm's back)?

[engelgabriel]

Hi @kentonv

I am flattered to see you around :) and thanks for the info. We are looking forward to see the Powerbox working. We will follow closely to make sure we are the first web chat app to get in there :)

[kentonv]

@jmatsushita Our model actually supports arbitrarily fine-grained capability sharing. A single grain (app instance) can export any number of capabilities representing sub-objects. Of course, Sandstorm can only enforce isolation and access control at the unit of a grain, so we encourage grains to be as fine-grained as possible for better security. But, for example, a git repository should probably be a single grain, but could export capabilities representing each commit. Each capability can have an arbitrary API (defined in Cap'n Proto), and can also define an arbitrary embeddable user interface (by implementing the sandstorm.UiView Cap'n Proto interface).

[jmatsushita]

@kentonv Thanks a lot for the explanation. Looking forward to see a sandstorm app implementing the UiView interface. Any particular one working on it?

[kentonv]

@jmatsushita Every Sandstorm app currently implements it for the main interface (usually using sandstorm-http-bridge pointed at a traditional HTTP server). We don't yet quite support "non-main" UiViews; the infrastructure is there but we need some plumbing in the front-end.

[paulproteus]

Hi @Sing-Li ,

It seems in this issue there's lots of theoretical discussion of the future of Sandstorm and inter-app embedding, which @kentonv has been addressing, and also one very practical question from you:

Need to strip out our auth and just delegate to Sandstorm's. Sandstorm's accounts schema do not have the additional fields that we depend on - so we either maintain two sets or doctor Sandstorm's and forever-track-upstream-progress-and-redoctor

My opinion is that you should modify this code:

https://github.com/RocketChat/Rocket.Chat/blob/master/server/lib/accounts.coffee#L29

to look for user.services.sandstorm and do whatever special thing you need.

I'm not sure which two fields you need, though. Let me know; I'd love to see RocketChat in the app list as soon as possible! I know lots of people who would love to use something like this.

[Sing-Li]

@paulproteus - thank you!

I'm not sure which two fields you need, though. Let me know; I'd love to see RocketChat in the app list > as soon as possible! I know lots of people who would love to use something like this.

Me too! I was stuck on a bug. Will get back on it and be in touch very shortly.

[paulproteus]

Very exciting!

[Sing-Li]

@paulproteus - iframe'd login working now 😄

One question : might be unique to chat styled app in the context of sandstorm.

If I create users on sandstorm, and then share the grain's URL - everything is fine. User must logon to access the grain.

But if I click that share button on the toolbar, and share that link. Any user with the link will be able to enter the chat with no login - this is a problem. Can I disable that share button on the toolbar (should I)? Or is there some alternate 'operating mode' for sandstorm that I am missing out on?

[paulproteus]

Hi @Sing-Li ! Thanks for asking about this.

For now, there's no way to remove the "Share" button in the Sandstorm interface. One thing we're hoping to add soon is the ability to add a user to the (e.g.) chat instance from the "Share" interface. So in that sense, we want to keep the "Share" button around, since we want the interface for adding users to a chat system to be the same as adding users to a access a (e.g.) text document on Etherpad.

We wrote more about the Sandstorm access control model here https://blog.sandstorm.io/news/2015-05-05-delegation-is-the-cornerstone-of-civilization.html.

We're working on making the "grant a user access to a grain" (or "Sharing" in Sandstorm terminology) interface follow a clean predictable UI, but we know we're not fully there yet. But we hope that as we revise it, every Sandstorm app can benefit from that.

But the summary is, basically, There is no way to turn off the "Share" button.

Hope that helps; let me know if you have more questions.

[Sing-Li]

@paulproteus Thanks for the reply, I've dealt with the 'hole' for now by blocking the UI if the main screen is accessed via a shared URL without login.

[Sing-Li]

initial port now on branch sandstorm-port-001 ; spk in app store within the week.

[paulproteus]

Yay!​ Let me know if there's any other help I can provide.

[kentonv]

@Sing-Li FWIW, the Sandstorm version of Let's Chat also simply blocks people who haven't logged in, so that at least has precedent.

A possible future direction would be to generate random names for people who haven't logged in yet (like gdocs: "anonymous rabbit", "anonymous aardvark", ...), or let them view the chat but don't let them speak.

In the future we'd like to extend the sharing implementation such that when you create a sharing link to send to someone, you can assign them a name which they'll get automatically if they don't sign in. This way you can invite your friends Alice and Bob to a chat and have them get correct names securely without them ever having to bother with login... as long as they don't leak the links, of course.

[Sing-Li]

Thanks, @kentonv for the clear explanation. The port actually has been ready for a while, I'd expect it to be submitted to the brand new Oasis very soon (now that the slash dot effect has finally subsided ;-).

In the next version, the running app will need to access external URLs from inside Sandstorm. Is Meteor.Http a safe way to accomplish this? Or must one work with a hack session? TA

[kentonv]

You'll need to use HackSession, specifically getUiViewForEndpoint() (see the comments for explanation). The idea is that, in the future, when you call this method, the user may be asked to approve.

Where exactly do these URLs come from? Is it, for example, something the user just typed in? If so, then what we really want to do in the future is structure it as a powerbox request -- the user would not type the URL into your app, but rather your app would issue a powerbox request for a URL, and then the user would type the URL into the powerbox (or maybe they'd be able to choose from among their apps, etc.), and then you'd receive the capability for that.

[Sing-Li]

@kentonv - Actually, it sounds strange, but the URL are ones that are embedded within the chat messages.

The server 'probes' these URLs to determine accessibility and what type they may be (image, audio, and so on) and then presents it to the user via the proper renderer.

[kentonv]

@Sing-Li Then it should be the person sending the message who grants the capability to probe it. The easiest thing would be to have them click something to "attach a link" and then paste into the powerbox, though admittedly that is perhaps not the nicest UX. Maybe we can think of something better.