Open Xqua opened 8 years ago
Hi @Xqua,
Have you tried the "collections" app?
https://apps.sandstorm.io/app/s3u2xgmqwznz2n3apf30sm3gw1d85y029enw5pymx734cnk5n78h
This app lets you organize a variety of grains into a single collection.
One way to manage a group project on Sandstorm is to create a collection for the project and then any time you want to share a grain to the whole project, add it to the collection. Then everyone gets access at once.
Does this meet your needs?
Yes it does, but I would like to automate the creation of this grain. Aka, I have a page, with different open project people can work on. When someone creates a project, it should create a collection automatically on that person's sandstorm account. Moreover, when someone joins a team, they should be added to the collection grain automatically.
Is that possible ?
I can see a hack for the joining part where I ask the person creating the project to create a collection, then to click share and add the share link to the project page. When anyone joins, they are asked to click that link. (or I could even trigger that link automatically on join.)
But for the creation and generation of the link for the collection I can't figure out something automatic.
Hi @Xqua,
It sounds like you're requesting an API for grain creation and sharing. This is a very reasonable request. Unfortunately we don't have an API currently and it may be a while before we are able to work on this.
Hmm, @Xqua, you might be able to accomplish what you want unofficially by taking advantage of the DDP API which the Sandstorm client (running in your browser) uses to talk to the Sandstorm server. If you look at the network inspector when you open Sandstorm, you'll see it opens a WebSocket to the server over which all dynamic communications happen. The protocol used is Meteor's DDP protocol. Possibly, you could create a WebSocket directly and speak DDP in order to call the appropriate Sandstorm server methods to do the things you want. This could work like an API.
However, note that we don't make any guarantee that these methods won't change over time, so whatever you do here might break in a future update.
@kentonv Thanks ! That's a great info ! I'll look into this as soon as I can ! :D
hopefully this won't break. Hopefully there will be such a control API in the future, this would allow for many potential uses of sandstorm as a backend ! While I like the interface, there are thousands of potential use of your grain/app/container philosophy that could be made if there was such control by another front end over those. (something like the docker API for example)
Was thinking about wanting an api for creating/managing grains recently. Here's a stab at a starting point:
@0xfeb2f5d432a6e068;
using Util = import "util.capnp";
using Package = import "package.capnp";
interface Session @0xb96851380c1e4df7 {
getAppById @0 (id :Text) -> (app :InstalledApp);
# Get a capability to an installed app by it's ID.
uploadApp @1 () -> (app :InstalledApp, spk :Util.ByteStream);
# Upload an app. The caller should write the package file to the `spk`
# return value. The `app` return value will typically be a promise,
# which will not be fulfilled until done() is called on `spk`.
}
interface InstalledApp @0xebda34630b50b39c {
# Represents an app installed on a sandstorm instance.
getPackageDef @0 () -> (def :Package.PackageDef);
# Get the package definition for this app
makeGrain @1 () -> (grain: Grain);
# Make a new grain. TODO: add parameters for apps that can create
# different kinds of grains, and/or a powerbox offer.
}
interface Grain @0x9f40875c51698a97 {
# Represents a grain. The methods correspond roughly to the options in
# the sandstorm ui menu, with "Share access" split into the two methods
# sendInvite and getShareLink. Unless otherwise specified, the arguments
# correspond to the options/fields by the same name in the UI.
setName @0 (name :Text);
# Set the name of the grain.
sendInvite @1 (guest :Text, permissions :List(Text), message :Text);
# Send an invitation. TODO: there might be a better thing to do re:
# permissions than just treating them as text; maybe something from the
# app's package definition? Also, we may want to have different kinds
# of "guests," e.g. existing users vs. arbitrary email addresses.
getShareLink @2 (label :Text, permissions :List(Text)) -> (url :Text);
moveToTrash @3 ();
readLog @4 (out :Util.ByteStream) -> (cancel :Util.Handle);
# Stream the log into `out`. The returned handle tells the server
# to stop streaming.
backup @5 (out :Util.ByteStream) -> (cancel :Util.Handle);
# Write a backup of the grain into `out`. The returned handle can be
# used to stop the transfer.
restart @6 ();
# restart the grain
getWebkey @7 (label :Text, permissions :List(Text)) -> (key :Text);
# Get a web key. Args are the same as for getShareLink.
}
Re: bootstrappig, maybe put something akin to an offer iframe somewhere in the user's settings or such, with a websocket url that they can connect to to get a capnp rpc session, with the Session
type as the server's bootstrap interface.
Thoughts?
Hi,
we are working on a project to create an integrative tool to perform open science. Our vision is very similar to sandstorm's vision of having an app market (such as ipython, data managemnt, wiki, etc) for users. From our experience organizing open science, one of the biggest issue is that teams get disorganized by using 30 apps hosted who knows where, and it demotivates a lot of less tech users.
We are thinking of using sandstorm as a base layer, but for this we would need some features, such as if you are part of a project A, you gain access to all the grains of that project. if you then also join project B, you are added to the shared list automatically.
As of now, sharing is based on someone actively clicking and adding members.
Could it be possible to handle teams automatically ?
Probably using LDAP as a based auth layer, with a parameter being boolean for a team.
Ideally, on the creation of a team, a collection grain would be created with default apps, such as rocket chat, gitlab repo, and such. So that the team can get started right away. If the team then wants more grains etc then users can create and manage using the classic sandstorm approach.
Is that feasible ?