mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rustyrazorblade has joined #sandstorm
mnutt has joined #sandstorm
<asheesh>
nwf: Right-o. Let me read scrollback.
<nwf>
It makes sense that rights-to-grain are the only thing Sandstorm tracks, but I don't think I understand AppPersistent, then.
<asheesh>
There's a WebKey powerbox thing that apparently a jparyani test app wrote that uses AppPersistent, but that's all, seemingly.
<jparyani>
actually it's C++ :)
<jparyani>
but there is a python one that zarvox wrote as well
<zarvox>
gkoz: This bit doesn't have UI yet, but you'd similarly make a powerbox request for an interface, and a grain which can offer a capability implementing that interface would offer it.
<zarvox>
the Python test app doesn't host any capabilities of its own
<asheesh>
So basically, (a) AppPersistent is a best-effort way for a grain to offer an object within itself to a remote app, but yes, fundamentally that requires the app to not have a security bug where someone else can forge access to the same object.
<asheesh>
(b) I forgot what (b) was.
<asheesh>
But the general point here being that grain isolation is to be trusted, and in-grain isolation is not really, but if grains think they can do it, then power to them, but we're not going to stop as many bugs that way.
<zarvox>
I'd probably have to drop Flask and implement web-session directly, which was out of scope when I first wrote the test app. But maybe is a reasonable thing to do now.
<asheesh>
But we might stop some, due to high clarity of design by the app author.
<nwf>
Well... it's slightly worse than that, right? The application doesn't really know that a request for endpoint /a is due to a capability that was intended to share specifically /a vs. the whole grain.
<nwf>
So I don't think grains should expect to be able to do it. ;)
<asheesh>
AppPersistent isn't implemented in terms of URLs, though.
<asheesh>
It's implemented in terms of runtime objects within the app's address space that it decides how to save capabilities for.
<asheesh>
I should say, how to offer capabilities for.
<asheesh>
As I understand it; I'll go reread the capnp now, or maybe I should let jparyani just say if he agrees.
<nwf>
Ah, so a grain could fab up an Endpoint object (to use Coyotos parlance) and offer that via save().
<nwf>
And so have all kinds of messages to itself encapsulated in that Endpoint ("Protected Payload", again, from Coyotos)
<nwf>
But there's still no access to that object unless you have access to the grain? Can I go from a URL offering such a save()d object to the grain itself?
<zarvox>
and then another grain would receive it, and could call save() on it
<asheesh>
Which is an action that the "grain-frame" Document object perceives, which contains a saved capability aka byte sequence, and then it decides what to do with that.
<asheesh>
Leaking this saved capability by itself doesn't
<zarvox>
Usually, it chooses to send that to the corresponding grain's backend, which can write it to durable storage, and restore() it into a liveref, and make calls on it
<asheesh>
do much because Sandstorm will only trust that byte sequence if it comes from the grain that was given the capability in the first place.
<asheesh>
Right - it's the restore() that will fail for anyone but this grain.
<zarvox>
We should make diagrams of all this stuff. I remember being confused by the whole flow when I was implementing pieces of this.
<zarvox>
Yes.
<nwf>
Mm, is the idea that save()d things are used within an application and not across grains?
<zarvox>
the idea is that other grains (B and C, say) may stop running at any time, invalidating the object reference that grain A holds to them.
<asheesh>
Quite right; if you need to send the capability to another grain, you do that a different way (I forget how but it's an explicit action the grain must take).
<asheesh>
I guess by offering it.
<asheesh>
Can this occur? Grain B requests a cap; it's granted by grain A. then grain C requests, and grain B offers the same cap?
<zarvox>
Yes.
<asheesh>
b # thumb sup
<asheesh>
... thumbs up, but I guess thumb sup is fine with me too.
<zarvox>
Granted, reoffering capabilities is in the "this is how we intend for it to work, but haven't exercised it in anger" set, AFAIK.
<nwf>
So B save()s an object reference, offers it to A... can A then access the entirety of grain B, i.e. make any request of it now that it has a handle to some part of it?
<zarvox>
B can't offer sturdyrefs, only liverefs
<asheesh>
And then C would save it into a sturdyref themselves.
<nwf>
Oh, so, slightly different story, then: B offers a liveref to A that A then turns into a sturdyref with save(). Yes?
<zarvox>
Each object reference implements the interfaces that the process hosting that capability chooses to implement on that interface.
<zarvox>
Yeah, that's a valid workflow.
<zarvox>
Here's a high-level flow:
<nwf>
OK, I think I understand; all of this is running *beside* the SandstormHttpBridge interface, rather than *over* it.
<zarvox>
User is looking at grain A. Grain A needs a thing that implements interface I.
<asheesh>
i,i I'm totally *not over* the SandstormHttpBridge interface
<nwf>
asheesh: :)
<asheesh>
Also yes, that's my understanding. Might as well wait for an ack from e.g. zarvox though.
<zarvox>
On that user's sessionContext, A calls request(I)
<zarvox>
sandstorm shows the user things which can implement I, like grain B
<zarvox>
user selects grain B
<zarvox>
grain B shows some interface to allow the user to choose what thing inside grain B they want an I for.
<zarvox>
(say, if I was "a byte stream containing a JPEG", and B was a folder app, then the user might select a particular image file)
<zarvox>
grain B mints a new capability C implementing both interface I and AppPersistent, and offers it to the user by calling sessionContext.offer(C, ..., ..., ...)
<maurer>
kentonv: When creating a ListBuilder from a null pointer, member variables were uninitialized. Dunno if there's a way to get warnings for those
<zarvox>
Sandstorm passes C to grain A. Grain A calls C.save()
<asheesh>
And this is all capnp rpc, not HTTP communication. Which is like your Coyotos statement, nwf.
<zarvox>
I skipped a couple implementation-detail steps in there, like Sandstorm calling save() because we can't actually pass liverefs over postMessage
<nwf>
zarvox: I am OK not knowing all the details, just having a good enough model to make deductive statements.
<nwf>
Fundamentally, I do not want to mis-speak when writing. :)
<zarvox>
But basically: Sandstorm knows that B offered C to the user in response to a request for A, and can make sure that the sturdyref produced by that save() call can only be restore()'d by A.
<nwf>
OK, so, to go back to the file-picker example, can I request a JPEG from e.g. my Davros grain and then share access to just that JPEG with another user?
<nwf>
(In theory, if not in practice?)
<zarvox>
I don't think we have stuff for sharing non-UiView capabilities between users.
<zarvox>
In theory, maybe.
<nwf>
So "yes, if Davros offers a UiView specific to that JPEG" ?
<zarvox>
Alternately, the grain that Davros offers the FileReader to gets shared with that user
<nwf>
Right, a more membrane-esque design.
<zarvox>
But I suppose there's nothing keeping Davros from offering file-specific UiViews.
<zarvox>
In theory. In practice we haven't built non-main UiView support yet.
<nwf>
Lemme bang on some prose for a minute and then ask your opinion.
<zarvox>
nwf: Yeah, I think you've hit on the essence of it. Part of the high-level goal is to reduce the UX cost of using multiple grains, making it more attractive/less painful to split things into different contexts.
<nwf>
Thanks for all your help. How would you like to be acknowledged? :)
<zarvox>
I am Drew Fisher. I also work on the Sandstorm core team. :)
<nwf>
200 OK
<zarvox>
I got to work with David Wagner when I was at Berkeley! It's kind of great getting to work on making a practical capability system. :)
<zarvox>
I'm gonna wander off for now, but feel free to ping me if you have more questions; I'll read the scrollback later
<nwf>
I am very excited to see ocap escape the lab, as it were. :)
rustyrazorblade has quit [Quit: rustyrazorblade]
decipherstatic has joined #sandstorm
jemc has joined #sandstorm
jemc has quit [Ping timeout: 248 seconds]
BigShip has joined #sandstorm
TwoJames2 has quit [Ping timeout: 252 seconds]
jemc has joined #sandstorm
jemc has quit [Ping timeout: 252 seconds]
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mnutt has joined #sandstorm
tierce has quit [Ping timeout: 248 seconds]
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nowhere_man has joined #sandstorm
<nowhere_man>
Hi all*
<nowhere_man>
I'm experimenting using Sandstorm apps to manage the preparation of a scout camp
<nowhere_man>
WeKan, Rocket Chat and Framadate come handy
<nowhere_man>
is there a way or is it planned to be possible to manage groups of people to which we grant access?
<nowhere_man>
so I could create my "Camp" group and when I create a new grain, I can give a type of access to each person in that group
synchrone has joined #sandstorm
tierce has joined #sandstorm
tierce has quit [Ping timeout: 244 seconds]
<dwrensha>
nowhere_man: groups management is a feature we're planning to implement, but we don't have it yet
synchrone has quit [Ping timeout: 244 seconds]
synchrone has joined #sandstorm
TwoJames has joined #sandstorm
jke has joined #sandstorm
<jke>
Is there anyway to log into a wordpress grain running on Oasis?
<nowhere_man>
dwrensha: this is a lazy question so feel free to answer UTSL, but would it be a hard feature to hard in the current codebase?
shout-user65 has joined #sandstorm
shout-user65 has quit [Client Quit]
twodimes-shout has joined #sandstorm
synchrone has quit [Read error: Connection reset by peer]
synchrone has joined #sandstorm
rustyrazorblade has joined #sandstorm
rustyrazorblade has quit [Quit: rustyrazorblade]
<BigShip>
dwrensha: ooo, fancy. Groups!
<BigShip>
I'm still convinced I need to set up Sandstorm for work. Even though I don't have my own business.
<dwrensha>
nowhere_man: I think it's more of a design question than a coding question. That is, "what is a group, and how does it fit with our existing notions of accounts, identities, grains, etc.?"
<dwrensha>
jke: you can download a backup of the grain and examine the content
<dwrensha>
jke: are you debugging anything in particular?
BigShip has quit [Quit: Leaving]
BigShip has joined #sandstorm
BigShip has quit [Client Quit]
BigShip has joined #sandstorm
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<XgF>
dwrensha: And I suppose the other question for BlackRock deployments: can groups be mapped to LDAP groups? :-)
<dwrensha>
XgF: note that LDAP is part of "Sandstorm For Work", which doesn't necessarily require Blackrock, our clustering backend
mnutt has joined #sandstorm
<XgF>
Oh, that's a thing now. Hmm, $15/mo, guess I won't be tying that into my home AD server :P
IceQUICK has joined #sandstorm
jemc has joined #sandstorm
IceQUICK has quit [Ping timeout: 240 seconds]
erikmaarten has joined #sandstorm
synchrone has quit [Ping timeout: 250 seconds]
jemc has quit [Ping timeout: 264 seconds]
synchrone has joined #sandstorm
erikmaarten has quit [Ping timeout: 260 seconds]
erikmaarten has joined #sandstorm
erikmaarten has quit [Ping timeout: 240 seconds]
<nowhere_man>
dwrensha: what about a first simple feature where groups are just a list of names (possibly with email), and I can choose to select all or part of them to grant an access
<nowhere_man>
I can send an email to those with email, and I get a URL for all others