sydney_untangle has quit [Read error: Connection reset by peer]
sydney_untangle has joined #sandstorm
phildini has quit [Ping timeout: 250 seconds]
phildini has joined #sandstorm
xet7_ has quit [Ping timeout: 250 seconds]
decipherstatic has quit [Ping timeout: 260 seconds]
asheesh_ has joined #sandstorm
asheesh has quit [Ping timeout: 250 seconds]
<gwillen>
collections are exciting!
<gwillen>
so far I have successfully added a collection to itself.... twice. ;-)
<gwillen>
I assume it's using some sort of proxy capabilities, to implement the feature where revoking access to a collection also revokes access to the things contained within (presumably unless access is also granted through some other path in which case that capability is retained?)
<gwillen>
This makes me curious how Sandstorm handles me having multiple distinct capabilities which access the same underlying capability.
<asheesh>
I don't actually know the answers but I think membranes and systemrequirements are relevant.
<gwillen>
I'm surprised that bob's write access to Foo is on the critical path for Alice's use of the capability
<gwillen>
hehe, *nods*
<gwillen>
this also seems like it should answer another question I had
<gwillen>
which is, if alice gets a capability to a collection, and grabs some other capability from it, and then passes that to bob, and then alice's access to the collection is revoked, then bob loses that capability
<gwillen>
this makes sense from a security perspective but might be quite surprising to bob :-)
<kentonv>
capabilities held by a user -- i.e. things that appear in the grain list -- are automatically merged if they point to the same grain
<gwillen>
merged in a UI sense, or some deeper sense?
<gwillen>
i.e. if one is lost can the other be retained?
<kentonv>
deeper. When you open the grain, you get all the permissions from all capabilities you have to that grain.
* gwillen
nods
<kentonv>
and yes, we default towards "if the way you got the capability is revoked, then the capability is also revoked"
<gwillen>
right, makes sense
<kentonv>
this isn't always what the user wants, of course
<gwillen>
it's the right default though
<kentonv>
longer-term I want there to be a UI that comes up and says "Hey, you're revoking this thing. All these other things were obtained through it. Did you want to revoke them too?"
<gwillen>
might be interesting if a user could query how their own access to a resource is spelled, e.g. "This is a write capability to a foo grain, conditional on Bob's read capability to the bar grain" or something
* gwillen
nods
<kentonv>
and if you choose "no" then what actually happens is you revoke them, but replace them with new shares created directly from yourself
<gwillen>
ahhh hmm interesting
<kentonv>
yes we will want users to be able to visualize where a capability has traveled, although in some cases that information may be private to another user
<kentonv>
so it's tricky
<gwillen>
right, *nods*
<gwillen>
I'm curious about the idea that e.g. if I take a capability, store it into a document, and alice retrieves it from a document and gives it to bob, bob's capability is contingent on BOTH alice's read access AND my write access to the document
<gwillen>
does this mean the thing that's actually stored in the document is the original capability, wrapped in a condition of "whatever capability was in use at the time it was stored there"?
<gwillen>
I'm curious if this is a sort of fully-general mechanism that conditionalizes based on the "currently used capabilities"
<kentonv>
edges on the capability/sharing graph can have "membrane requirements" -- basically requirements which, if they cease to hold, the capability is automatically revoked
<gwillen>
right, asheesh's links were helpful
<kentonv>
when a grain makes a powerbox request, it specifies what permissions the user fulfilling the request must have on the requesting grain, and that becomes a membrane requirement on the returned capability
<gwillen>
hmm
<kentonv>
similarly when a grain offers a capability to the user, it specifies what permissions the user must have on the offering grain in order to keep using the capability
<kentonv>
if a capability travels across another capability (e.g. being passed into a method call), it picks up the membrane requirements of the latter capability
<gwillen>
ahhhh hmm
<gwillen>
so if I send a capability by way of a method, and I _rely on_ a capability of mine to do it, the thing that comes out the other end is wrapped in a membrane that requires my relied-upon capability to be valid
<gwillen>
that's pretty neat
jemc has quit [Ping timeout: 265 seconds]
Lionel_Debroux_ has quit [Ping timeout: 276 seconds]
ecloud_wfh is now known as ecloud
rafaelmartins has joined #sandstorm
rolig has quit [Read error: Connection reset by peer]
XgF has quit [Quit: No Ping reply in 180 seconds.]
XgF has joined #sandstorm
xet7_ has joined #sandstorm
asmyers has joined #sandstorm
amyers has quit [Ping timeout: 244 seconds]
wolcen has joined #sandstorm
jemc has joined #sandstorm
wolcen has quit [Quit: Leaving]
wolcen has joined #sandstorm
gambatte has quit [Ping timeout: 258 seconds]
gambatte has joined #sandstorm
asmyers has quit [Ping timeout: 244 seconds]
asmyers has joined #sandstorm
Lionel_Debroux_ has joined #sandstorm
Telesight has joined #sandstorm
wolcen has quit [Ping timeout: 265 seconds]
prettyvanilla has quit [Quit: Konversation terminated!]
prettyvanilla has joined #sandstorm
pie_ has joined #sandstorm
<pie_>
hey dudes.
<dwrensha>
hi pie_
<pie_>
i was playing with the demo earlier and the "share link" stuff was broken(?) for some of the apps, it would give a link that takes me to the same "administrator"/sandstorm view instead of to whatever the user is supposed to see?
<pie_>
i think it was one of those survey apps
<dwrensha>
pie_: were you the admin on those grains?
<kentonv>
pie_: You see the "administrator" view because you own the grain. Try opening it in an incognito window, or logging out.
justincormack has joined #sandstorm
<pie_>
kentonv, ah, makes sense i guess. though that still seems a bit weird
<kentonv>
admittedly the sharing link system wasn't precisely designed for this use case. We could probably improve it.
<pie_>
kentonv, i mean, im not using the sandstorm link sharing, the app link sharing used the sandstorm link sharing
<pie_>
so you might say its the apps fault
<pie_>
idk
<kentonv>
the app has no choice -- it cannot create a link to itself without Sandstorm's help. This is part of our security.
<pie_>
ah.
<pie_>
makes sense.
<kentonv>
I do think that for something like the survey app, it would make sense for us to support creating a link that always forces incognito access and perhaps hides the Sandstorm UI.
<justincormack>
is this the right place to ask capnproto questions?
<kentonv>
yep
<justincormack>
ah cool. Just trying to get used to it, have some stuff working now. When I get a response from rpc, I have a capnp::Response and I can get the data out of it with the Reader interface fine, but I really just want it as a raw byte array I can pass to somewhere else (in particular the Lua bindings which can deserialise fine but dont have an rpc interface so I
<justincormack>
am doing that in c++)
wolcen has joined #sandstorm
<kentonv>
justincormack: The actual response message received on the wire contains various RPC metadata. The application-level results are one branch within that overall message. So there isn't a raw byte array to provide.
<justincormack>
ah ok
<justincormack>
so I could re-serialise it? Not too worried about performance at this point..
<kentonv>
maybe it would make sense to have some API by which you can discover the overall message segment set and the location of the pointer which you're interested in, in order to pass off to a different runtime...
<kentonv>
oh, yeah, if you don't mind a copy, you can create a new MallocMessageBuilder and call setRoot(response)
wolcen has quit [Client Quit]
<kentonv>
then getSegmentsForOutput() will give you the raw message segments
wolcen has joined #sandstorm
<kentonv>
or you might need a second copy if lua is expecting the message in full serialized form including segment table header... which you get from messageToFlatArray()
<justincormack>
ok, will try that, thanks!
peterood has joined #sandstorm
asmyers has quit [Remote host closed the connection]
asmyers has joined #sandstorm
wolcen has quit [Ping timeout: 265 seconds]
asmyers has quit [Ping timeout: 244 seconds]
isd has joined #sandstorm
wolcen has joined #sandstorm
asmyers has joined #sandstorm
<mrdomino>
huh, i hope sandstorm ushers in a new era of apps using the filesystem as a db
<dwrensha>
mrdomino: are you reading my code? :P
<mrdomino>
yes
<mrdomino>
i was initially thinking of using sqlite for this
<mrdomino>
but it actually fits decently enough in the fs
asmyers has quit [Ping timeout: 250 seconds]
<pie_>
when i saw that owncloud stores everything in the db i was like "but why?"
<pie_>
not that i know anything whatsoever about backend web dev
<pie_>
or front end for that matter
<mokomull>
In the not-Sandstorm world, giving my whole webserver write privileges anywhere in the filesystem gives me the shivers.
<isd>
There are a few reasons to prefer the "everything in the db" approach, which is not to say it's always the right solution
<pie_>
ah well.
<pie_>
*ah wel....
<pie_>
TIL
<isd>
obviously doesn't apply to sqlite or sandstorm, but with dbs that have a server, it means you can have the storage on another machine. You could also use a network filesystem though
<isd>
the bigger reason is the whole ACID thing;
<pie_>
ACID?
<isd>
it basically means you don't have to worry about corrupted data ever.
<mokomull>
I would guess one of those is to be able to BEGIN; write contents; write data; COMMIT; whereas it's harder to synchronize raw filesystem operations with database commits.
<isd>
Like, there's no "my app was writing to a file and the server died"
<isd>
transaction gets rolled back, it never happened. done
<pie_>
hm.
<pie_>
thats a valid point...
<isd>
also even if you're not in a BEGIN;... COMMIT; each statement is a transaction by itself.
<zarvox>
Databases certainly provide better user-understandable invariants than the filesystem
<mokomull>
"better" certainly doesn't mean "good" though :)
<pie_>
data integrity is scary
<isd>
So, the license list in the docs includes gpl* but doesn't seem to say anything about presence/absence of "or later"
wolcen has quit [Ping timeout: 240 seconds]
<isd>
it would be nice if there was an easy way to get the ACID stuff while still having the usual filesystem API (plus commit()/rollback())
Telesight has quit [Quit: Leaving.]
<isd>
really shouldn't be *that* hard to implement well for situations like sandstorm, where the directory is basically all owned by one app. stuff like btrfs is already cow to begin with, but I don't think the snapshot APIs are available to non-priviledged users, and it strikes me as a bit clumbsy
<isd>
*sigh*
<zarvox>
I would love for filesystem implementations to have some transactional API and guarantee that I will see all or none of the changes, and that conflicting writes will fail
daemoen has quit [Remote host closed the connection]
daemoen has joined #sandstorm
<mokomull>
zarvox: And DBMSes seem to default away from SERIALIZABLE :(
<isd>
The annoying thing is, filesystems all actually have these facilities for their own data structures, but they don't expose them.
<isd>
granted, you have to worry more about controlling apps tying up the filesystem.
ocdtrekkie_web has joined #sandstorm
<ocdtrekkie_web>
I clearly don't know how this web IRC client works
<isd>
What's the current state of the powerbox stuff? Last I checked, it wasn't really there yet, and there was some specific weirdness around stuff like IpNetwork/IpInterface
<isd>
Ideally my app would just request a TcpPort, but I don't know if that actually works yet?
<kentonv>
isd: You can request IpNetwork and IpInterface through the powerbox, with only the admin having the rights to fulfill such requests
<isd>
Okay, that's roughly my memory. Am I still restricted to those two? TcpPort is all I actually need.
<kentonv>
currently you can't request specifically a TcpPort although it would make a lot of sense for us to add that
<isd>
Although the hiccup with that it doesn't give me a hostname, without which I can't do TLS verification (and it doesn't seem like there's an interface for just getting a TLS connection).
<kentonv>
we should probably implement a parallel way to request TLS, so that the app doesn't need to hold any private keys
<isd>
kentonv: there are some comments about this re udp, but more generally you probably should just abstract these notions to the general interfaces and the communication properties/guarantees they offer
<isd>
"UnreliableDatagram" "reliable stream" "encrypted/authenticated reliable stream" etc.
<isd>
The latter two would likely have the same set of methods, but probably good for an app to be able to at least hint that it really cares that something is encrypted/authenticated
<kentonv>
does the app care, or does the user care? :)
<kentonv>
I find in many cases it's really the user that cares.
<kentonv>
so maybe the app should be requesting a "ConnectionReceiver" and it's up to the user to decide if that's TCP, whether TLS is layered on, etc.
<isd>
kentonv: yeah, and there's no reason the platform necessarily has to honor it, but it might be nice to tell the platform at least it should display a big nasty warning or something if the user gives it something insecure
<isd>
The app is more in a position to know how sensitive stuff is than the platform itself. hints might be useful
<isd>
Could also be some transport encryption/auth layer that's less horrible than TLS.
<isd>
Or just a unix socket, which doesn't need encryption for obvious reasons.
<kentonv>
or it might be capnp all the way to the other end. :)
<isd>
Yeah, if it's local or the crypto is somewhere beneath the sandstorm you're requesting from.
<isd>
Could also be a websocket, etc.
<isd>
Would be really nice if desktop OSes work like this. That last case is something I'm having to write an explicit wrapper for going the other way
<mokomull>
From another discussion, that reminded me - git and friends use the filesystem heavily as an object store database :)
<isd>
mokomull: yeah. but it means having to design each app around the possibility of failure.
<isd>
sometimes the right call anyway
jemc has quit [Ping timeout: 264 seconds]
<isd>
I see all these references in grain.capnp to 'postMessage', but it doesn't seem to actually be defined anywhere -- grep postMessage *.capnp only turns up stuff in comments. What gives?
<kentonv>
isd: postMessage is a Javascript API
<kentonv>
in the browser
<kentonv>
it lets, for example, iframes send messages to each other
<kentonv>
in our case, we're talking about the grain sending a message to the parent frame (Sandstorm)
<isd>
That sounds familiar.
jemc has joined #sandstorm
isd has quit [Quit: Leaving.]
rafaelmartins has quit [Quit: No Ping reply in 180 seconds.]