<dwrensha>
then, it uses a currently-undocumented Sandstorm feature called "offer templates" to generate secrete URLs to put in copy/paste instructions for the user
<dwrensha>
then the user copy and pastes those instructs to set up Git on their end
<dwrensha>
what part specifically are you wondering about?
mort___ has quit [Quit: Leaving.]
losvedir has quit [Quit: losvedir]
<ckocagil>
sorry I had to go afk
<ckocagil>
dwrensha: how does the user pull from or push to this repo? doesn't accessing the http API require tokens?
<dwrensha>
the app generates tokens and displays them to the user with "offer templates"
<dwrensha>
for GitWeb, the offer template text looks like:
gopar has quit [Remote host closed the connection]
bb010g has joined #sandstorm
jadewang has joined #sandstorm
<paroneayea>
okay! paulproteus suggested I ask more things in here rather than in backchannels :)
<paroneayea>
so to recap
<paroneayea>
<paroneayea> paulproteus: I'm basically curious about what methods you're using in sandstorm to provide object capabilities
<paroneayea>
<paulproteus> (1) Isolation (2) pass in all capabilities as Cap'n Proto remote objects (3) write shims so the weirdness of (2) is less obvious
<paroneayea>
<paulproteus> "hope that helps" : P
<paroneayea>
so next question:
<paroneayea>
do you sign them?
<paroneayea>
I assume that if they're being transmitted beyond a single process which has control over the datastructure a-la eros "vat" capabilities, some sort of signature mechanism would be required!
<dwrensha>
paroneayea: who would sign a capability, and what goal would the signing serve?
<paroneayea>
dwrensha: so I'm not very knowledgable on the subject, but from my reading
<paroneayea>
capabilities are supposed to be unforgeable; in a single memory-safe process, pointers within a datastructure are often considered good enough, as in Rees's lambda calculus version with Scheme, it's the procedures made available in the environment that are a basic stand-in, and I think E does similar things with its "vats"
<paroneayea>
but what if you have an actor model type setup
<paroneayea>
and you want to be able to provide access to invoking certain procedures via capabilities mixed with some message passing mechanism
<paroneayea>
or any other process where having a pointer just doesn't make sense because that boundary is lost
<paroneayea>
and there isn't a "shared kernel" there to provide it
<dwrensha>
I think our answer is: within a single Sandstorm server setup, the network/capnproto infrastructure is trusted
<paroneayea>
over the network, to make it unforgeable, the only way I can think of it is to have the local actor/object have its own key that it can sign with
<paroneayea>
dwrensha: aha, so with sandstorm, it doesn't cross servers
<paroneayea>
dwrensha: you can see how when I'm looking at something that crosses servers with federation work, I'd need to figure out how to implement the unforgeability elsewhere
<dwrensha>
as of now, not really
<paroneayea>
I know from paulproteus' mentions that capabilities are used in some places, I figured maybe you all had looked into a good solution :)
<paulproteus>
These keys fwiw are bound to a specific permission level and are bound to a specific API path of the app.
<paulproteus>
paroneayea: You might enjoy the way the Git app works in Sandstorm (or you might find it appallingly weird).
<paulproteus>
Use the demo server to create a private git repo with GitWeb and you'll be confronted with an "offer template." We use this mechanism to hide the actual API token from the app, so if it doesn't know it, it can't leak it.