gopar has quit [Remote host closed the connection]
ArcTanSusan has quit [Quit: ArcTanSusan]
ragesoss has quit [Ping timeout: 246 seconds]
ragesoss has joined #sandstorm
mort___ has joined #sandstorm
mort___ has quit [Quit: Leaving.]
mort___ has joined #sandstorm
decipherstatic has quit [Quit: No Ping reply in 180 seconds.]
decipherstatic has joined #sandstorm
erikoeurch has joined #sandstorm
YuviPanda|brb is now known as YuviPanda
mort___1 has joined #sandstorm
mort___ has quit [Ping timeout: 246 seconds]
itscassa|away is now known as itscassa
amyers has joined #sandstorm
erikoeurch has quit [Ping timeout: 264 seconds]
itscassa is now known as itscassa|away
<XgF>
It would be cool if sandstorm came with some form of data store so it would be possible for each grain to not carry it's own, say, mongodb instance
<XgF>
I guess this will be a thing for when sandstorm has proper services
<XgF>
(A 'nosql store' driver)
<XgF>
I,I I guess this way heads enterprise stuff like distributed transactions
pixelport has joined #sandstorm
<ocdtrekkie>
mattermost.org < another open source Slack replacement from a video game development company
<simonft>
Is it possible with sandstorm to restrict sign-in to a google apps domain?
<ocdtrekkie>
Not currently.
<ocdtrekkie>
But you can extend invites only to those people, and nobody else can create grains.
<ocdtrekkie>
While anyone can login, if they can't create grains, nor is anyone sharing grains with them, they can't do anything.
erikoeurch has joined #sandstorm
NwS has joined #sandstorm
erikoeurch has quit [Ping timeout: 250 seconds]
prosodyContext_ is now known as prosodyContext
JJ2 has joined #sandstorm
<JJ2>
Hey guys, is it somehow possible to enter a running sandbox for debug reasons? I have vagrant-spk dev running and would like to check the mysql database for issues.
<JJ2>
and I have launched a grain
<paulproteus>
zarvox: ^ does vagrant-spk nsenter (or whatever you were scheming) work yet?
JJ2 has quit [Client Quit]
<paulproteus>
JJ2: I'm AFK most of today but zarvox should be your go-to person.
<paulproteus>
Aw, oops.
<paulproteus>
I'll email you two.
<paulproteus>
(done)
JJ__ has joined #sandstorm
JJ__ has quit [Ping timeout: 246 seconds]
ArcTanSusan has joined #sandstorm
hrjet has joined #sandstorm
erikoeurch has joined #sandstorm
pixelport has quit [Ping timeout: 252 seconds]
pixelport has joined #sandstorm
achernya_ has quit [Ping timeout: 248 seconds]
mort___1 has quit [Ping timeout: 256 seconds]
joshbuddy has joined #sandstorm
mort___ has joined #sandstorm
jadewang has joined #sandstorm
ArcTanSusan has quit [Read error: Connection reset by peer]
JJ2 has joined #sandstorm
ArcTanSusan has joined #sandstorm
JJ2 has quit [Client Quit]
<jadewang>
good morning
ArcTanSusan has quit [Read error: Connection reset by peer]
ArcTanSusan has joined #sandstorm
ArcTanSusan has quit [Read error: Connection reset by peer]
<simonft>
ocdtrekkie: thanks
ArcTanSusan has joined #sandstorm
achernya has joined #sandstorm
pixelport has quit [Quit: Leaving]
achernya_ has joined #sandstorm
achernya has quit [Read error: Connection reset by peer]
jadewang has quit [Remote host closed the connection]
gopar has quit [Quit: Leaving]
amyers has quit [Ping timeout: 248 seconds]
jadewang has joined #sandstorm
pixelport has quit [Quit: Leaving]
<XgF>
(BTW, part of the reason I was thinking about database services earlier is related to "popular" apps on Blackrock where you might want multiple instances)
<zarvox>
Part of the upside of having each grain's datastore be separate is that you get some nice security/isolation properties from the fine-grained separation.
<zarvox>
Said another way: if multiple app instances share an e.g. mongo instance, then they can also compromise each other. You'd probably need the user to configure the interconnect to avoid potentially leaking user data between instances.
<zarvox>
But I could see something where if the user wants to have a bunch of grains connect up to "one big DB" then you could write a capnproto interface to request/offer a capability that behaves like a mongo connection.
ArcTanSusan has joined #sandstorm
<dwrensha>
unrelated: once we start enforcing the new "membrane requirements" on sturdyref, there could possibly be more than one solution to the permissions computation
<dwrensha>
and we need to decide whether we want the least fixed point or greatest fixed point or what
<dwrensha>
e.g. If a token granting X permissions to B has a membrane requirement that Bob has X permissions
<dwrensha>
In the least fixed point, the token is invalid. In the greatest fixed point, the token is valid.
ArcTanSusan has quit [Quit: ArcTanSusan]
<kentonv>
dwrensha: My initial intuition is that there should be no way to set up a situation in practice where the two are different.
<kentonv>
but we should go with least fixed point to be safe.
<kentonv>
OK I can think of convoluted ways that this situation can happen (too long to describe here), and I think least fixed point is the correct answer in these cases.
<dwrensha>
yeah, that's my feeling too
ArcTanSusan has joined #sandstorm
ArcTanSusan has quit [Quit: ArcTanSusan]
NwS has quit [Quit: See you in Isla de Muerte!]
sasattack has joined #sandstorm
<XgF>
zarvox: So one case I was thinking of is "I have a bug tracker for my huuuge project. Lots of people using it. Needs more than one "instance""
<XgF>
[Also, a longer term thing to think about for BlackRock: Multi-Site installations.
erikoeurch has quit [Ping timeout: 244 seconds]
sasattack has quit [Ping timeout: 248 seconds]
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]