<zarvox>
Well, I confirm that I'm getting the same error you were.
<ckocagil>
kentonv: have you looked into sandboxing the grain iframe?
dwrensha has quit [Quit: ChatZilla 0.9.92 [Firefox 41.0.2/20151014143721]]
<kentonv>
ckocagil: we plan to do that at some point, yes
<zarvox>
ckocagil: I have patches for the "locking it down" portion, but not for the "grandfathering things in" portion, which is of course the hard part :P
<kentonv>
probably not "iframe sandboxing", but strict Content-Security-Policy rules
<ckocagil>
I did some experiments with it, and this app still manages to navigate the top frame
<ckocagil>
I see, kentonv
<kentonv>
ah, yeah we should probably block that. I guess that technically is an "iframe sandboxing" feature
<asheesh>
Arguably we should let apps opt into the new features now if they want to.
<asheesh>
But then we'd have to actually ship it, etc. and that'd have to be prioritized against other things etc.
<kentonv>
I guess it might not be too hard to introduce "API version 1" which has no other difference from 0 except that it adds CSP
bb010g has quit []
bb010g has joined #sandstorm
<mnutt>
zarvox: fwiw when I try to `spk unpack` it, I get “sandstorm/util.c++:99: failed: fstat(fd, &stats): No such file or directory”
<zarvox>
mnutt: that's odd, I got the issue you mentioned above, with the "Archive contained invalid file name"
<zarvox>
it's "spk unpack path/to/davros.spk folder-to-extract-int" - do you maybe have a typo in there somewhere?
<mnutt>
I’m running `spk unpack ./davros-0.10.0.spk outdir` and ./davros-0.10.0.spk exists and outdir gets created
<zarvox>
let me try again with a clean rebuild of master
<zarvox>
opt/app/app/components/.
<zarvox>
there's your problem
<mnutt>
huh, weird. that was inside virtualbox. on a real(er) linux system I do get the “archive contained invalid file name.;” message
<asheesh>
(sandstorm version # skew?)
<mnutt>
ahh, good catch. both running sandstorm 128, although the file list was probably generated with an earlier version.
<mnutt>
thanks zarvox!
<mnutt>
I have those “/.” all over the place
<zarvox>
FWIW, the way I figured it out was by doing the "spk unpack", then looking at how far the unpacking progressed
<zarvox>
by find | sort | less
<zarvox>
and comparing against sandstorm-files.list
<zarvox>
oh yeah, opt/app/app/styles/.
<zarvox>
are those autogenerated, or did you add them manually?
<zarvox>
I would hope the tracing wouldn't add things it can't handle later
<mnutt>
autogenerated, although possibly from a much earlier version of sandstorm
<zarvox>
Ahh.
<asheesh>
Perhaps Sandstorm generally doesn't canonicalize things.
<asheesh>
So if Ember likes to stat("$PATH/.") (or something) maybe this leads to doom.
<zarvox>
If you know for a fact you want everything in the source repo, you might just use alwaysInclude (and maybe hide .git or other things that you know you don't need in the package)
<mnutt>
got it
<mnutt>
confirmed it works fine with the weird paths removed
<zarvox>
I alwaysInclude "opt/app" in my Piwik package, and hide opt/app/.git and opt/app/.sandstorm/.vagrant
<zarvox>
yaaaaay Davros coming to the market Soon™!
<zarvox>
\o/
<mnutt>
zarvox: yeah, the only two things left are cold start / help pages and pushing a lot of data through it
<mnutt>
I’m trying to be particularly careful since as soon as I release it people could start using it for things they care about (files) and the last thing I want is to have it eat a bunch of their important files
<asheesh>
"Obviously" you "just" need to create a click-through EULA
<mnutt>
I’m leaning on the MIT license here :)
<kentonv>
I vaguely feel like I remember fixing a bug in tracing that might have involved trailing '/.', but I'm not sure
<kentonv>
it was many months ago though
<zarvox>
mnutt: I respect and approve of your caution, particularly with respect to other people's data. :)
<mnutt>
zarvox: thanks, I’ll keep an eye out. I’m currently syncing 11GB of data, so far so good. no individual files are huge though, I’ll try some of those next
mnutt has quit [Quit: mnutt]
<asheesh>
Man, if mnutt adds web publishing to this, I can find a use for it Right Now
todayman has quit [Quit: No Ping reply in 180 seconds.]
<warren>
Hmm, Zulip looks pretty good, and I like the concept of streams instead of channels, but I wonder if that is too confusing for end-users.
mquandalle has quit [Quit: Connection closed for inactivity]
<asheesh>
kentonv: I want an app called "Simple Todos" to, when I click New, give me a grain entitled "Untitled to-do list" rather than "Untitled Simple Todos to-do list"
<asheesh>
I think this is impossible; is that right?
<asheesh>
I tried appTitle="Simple Todos" and nounPhrase="to-do list"
<kentonv>
asheesh: I think zarvox would know better than me at this point.
<asheesh>
K
<kentonv>
I would be mildly in favor of adding options to control that
<asheesh>
I don't know exactly what I want but I find this transition frustrating.
<asheesh>
I figure probably what I want is a preview tool on 'spk dev' time, which tells me what will happen when I click New.
<asheesh>
Most of the frustration is surprise, which can be fixed with preview. Maybe this experience, though, indicates that the full "New" string should be burned into the SPK. But then i18n. )-:
<asheesh>
Looks like I can't get quite what I want so I'll get crafty.
<kentonv>
hmm, well arguably we want users to always rename their grains anyway, so maybe trying to make the default title aesthetically pleasing should be prioritized below giving it maximum informational value (for the cases where the user forgets to rename)
<kentonv>
if I had several todo apps I might not like it if they all name new grains "untitled todo list"
<asheesh>
Yeah so I figure I'll make "New Simple Todos list"
<kentonv>
ah
<kentonv>
yeah I guess the problem here is the redundancy
<asheesh>
Ramblingly, I kind of love the idea that the code behind a grain is safe to forget so make them all generate "New todo list" : D
<asheesh>
(That is, in some crazy world, all to-do list apps are the same)
<asheesh>
Also I can't decide if I should call it "Simple To-do"
<asheesh>
Todo as a proper noun makes almost sense to me but todo as a lowercase word mfeels like it should be corrected to to-do.
<asheesh>
This might be the most paralysis I've experienced in a while from my desire for syntactic accuracy.
<kentonv>
FWIW I don't feel like I've ever seen "to-do", only "todo"
<asheesh>
Also now it's Untitled Simple Todos list
<kentonv>
and "to-do" makes me mildly uncomfortable
<asheesh>
Which looks like a proper noun where someone forgot to capitalize the last word.
<asheesh>
But it's not, but oh, well, I think that's the best I can do.
<kentonv>
btw what's with the 0x7F chars in your chat lines?
<asheesh>
Whoa.
<asheesh>
Beats me.
<asheesh>
That's appalling.
<kentonv>
"lowercase word mfeels"
<kentonv>
was that supposed to be a backspace deleting the 'm'?
<asheesh>
Oh mid-sentence? That's an irssi thing where if I ctrl-left ctrl-right etc. around before irssi notices, then it'll misunderstand something buffers something.
<asheesh>
Yeah, I guess so.
<asheesh>
OK I just got confused again by how nounPhrase and title interact but I'm good now.
<asheesh>
kentonv: If you could reject meteor-todos-sandstorm-4.spk and accept meteor-todos-sandstorm-5.spk I would appreciate it.
<asheesh>
oh wait #5 isn't uploaded yet...
neynah has joined #sandstorm
<kentonv>
I don't see filenames
<asheesh>
...OK now it is.
<kentonv>
I see package IDs
<asheesh>
0dp7n6ehj8r5ttfc0fj0au6gxkuy1nhw2kx70wussfa1mqj8tf80 is a happy one
<kentonv>
but I think the page loaded before the new one was up so I'll reject what I see so far
<asheesh>
cool
<kentonv>
that's not a package ID, that's an app ID
<asheesh>
5830d70137cdae158118884da8790870
<kentonv>
approved
<asheesh>
Yay
<neynah>
!
<asheesh>
BTW kentonv I think last time I submitted an SPK to you for the app list, I forgot to 'git push' first.
<asheesh>
I think I'd be very happy with a 'git tag' aka 'github releases' based workflow since I couldn't forget to do that that way.
<asheesh>
I almost just forgot to 'git push' right now.
<kentonv>
well, I don't want to require users to be using any particular VCS but feel free to write tools that layer on top. :)
<mnutt>
is it possible to get free/available disk space from inside a grain? is sandstorm using disk quotas?
jadewang has quit [Remote host closed the connection]
ripdog has quit [Ping timeout: 240 seconds]
keturn has quit [Ping timeout: 268 seconds]
ripdog has joined #sandstorm
jadewang has joined #sandstorm
keturn has joined #sandstorm
jadewang has quit [Ping timeout: 264 seconds]
ckocagil has quit [Ping timeout: 244 seconds]
paroneayea has quit [Remote host closed the connection]
<asheesh>
JJ: If you're reading comments, do email support@sandcats.io
<asheesh>
I can probably help! Ciao for now.
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 240 seconds]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 256 seconds]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 255 seconds]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 250 seconds]
mnutt has joined #sandstorm
<mnutt>
is it possible to get free/available disk space from inside a grain?
<dwrensha>
mnutt: not at the moment
<dwrensha>
I'm not sure whether that's something it would make sense to expose eventually
<dwrensha>
what use case do you have in mind?
<mnutt>
ok, got it. my app is essentially a dropbox replacement and it would be nice to give people an idea of how much storage space they have available to them
<dwrensha>
actually, no I'm not so sure... I wonder what happens when you run `df /var/` inside a grain?
<dwrensha>
I think I'm going to try that right now...
<mnutt>
for me, it’s missing /proc so it fails
<mnutt>
rather, mtab is symlinked to /proc so it can’t find what is mounted
<dwrensha>
according to strace, it looks at /proc/self/mountinfo
<mnutt>
I guess it’s complicated by the fact that what df tells you may be different than what you actually have available, with quotas
<dwrensha>
on Oasis we do let users see how much disk space they are using
<dwrensha>
and we cut them off if it's over their quota
<mnutt>
yeah, though if possible it would probably be better for me to show them their usage out of their quota rather than out of total, since total could be some insanely large amount on oasis
<dwrensha>
allowing apps to ask "how much space is available for the current user?" sounds reasonable to me
<dwrensha>
I wonder whether it would make sense to allow fancier things
<dwrensha>
like, when you create a grain, you provide a cap on how much storage it is allowed to consume
<dwrensha>
which may be far less that your total quota
<mnutt>
that could work, although it may be too much up-front configuration
bb010g has quit [Quit: Connection closed for inactivity]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 240 seconds]
mattl has quit [Ping timeout: 240 seconds]
_jax_ has quit [Ping timeout: 240 seconds]
bpierre has quit [Ping timeout: 240 seconds]
hunterm has quit [Ping timeout: 240 seconds]
chris_severs has quit [Ping timeout: 240 seconds]
_jax_ has joined #sandstorm
hunterm has joined #sandstorm
mattl has joined #sandstorm
chris_severs has joined #sandstorm
bpierre has joined #sandstorm
jadewang has joined #sandstorm
home has joined #sandstorm
jadewang has quit [Ping timeout: 240 seconds]
natea has joined #sandstorm
natea has quit [Quit: natea]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 252 seconds]
natea has joined #sandstorm
spangattack has quit [Ping timeout: 250 seconds]
<ckocagil>
hi #sandstorm
<dwrensha>
hi!
<ckocagil>
NodeBB should be ready!
<ckocagil>
shall we do another round of testing? or should I just submit?
<dwrensha>
I'd be happy to take it for a quick spin right now
<dwrensha>
Do Groups work? If not, would it make sense to hide the Groups tab?
<ckocagil>
it doesn't, I should hide that button
spangattack has joined #sandstorm
natea has quit [Quit: natea]
<dwrensha>
it would be nice if links in discussions had 'target"=_blank"' so that they would actually open (in a new tab)
<ckocagil>
oh, I didn't notice
<ckocagil>
aha, there seem to plugins that allow replying by email!
<dwrensha>
ckocagil: I suspect it won't be worth trying to hook that up now with HackSession, but once we have proper PowerBox email it would be cool to add it
<ckocagil>
dwrensha: why not now?
<ckocagil>
because sandstorm will kill the server when the app isn't used?
<dwrensha>
because HackSession is "pre-deprecated"
<ckocagil>
oh I see.
<kentonv>
well... the real email interfaces will be similar to the HackSession ones. The difference will be that there will be an extra step to obtain the capability, rather than just calling a method and receiving it no questions asked...
<ckocagil>
how about keeping the grain alive? or maybe receiving an email will boot the grain?
<kentonv>
receiving an email will in fact boot the grain. :)
<dwrensha>
ckocagil: if I remember correctly, plugin code lives in writable storage under /var? is that correct?
<dwrensha>
or was that just "theme" code?
<ckocagil>
dwrensha: the entire public/ directory
<ckocagil>
which shouldn't contain any code
<dwrensha>
hm. then what is it that's taking 10MB on startup?
<ckocagil>
that directory
<dwrensha>
i guess nodebb needs that directory to be writable because it produces minimized javascript on the fly?
<dwrensha>
well, also /uploads needs to be writable
<dwrensha>
I just wondering whether it would be possible to do some static generation of assets/minimized javascript
<dwrensha>
and whether that would help simplify symlink structure and minimize startup storage requirements
mnutt has quit [Quit: mnutt]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 240 seconds]
spangattack has quit [Ping timeout: 240 seconds]
<ckocagil>
dwrensha: it should be possible, but I don't think it's a high priority
xet7 has quit [Remote host closed the connection]
spangattack has joined #sandstorm
bb010g has joined #sandstorm
spangattack has quit [Ping timeout: 252 seconds]
<dwrensha>
ckocagil: how will upgrades work in your current setup? It seems like you're going to need to copy a bunch of new stuff into /var/nodebb/public/src
<kentonv>
woo, getting downvoted by google fanboys on HN. Is this what it's like to be ocdtrekkie?
<mrshu>
kentonv: while I am definitely biased (affiliated with DuckDuckGo) I feel very similar with regards to any big centralized walled garden
<kentonv>
well then you're in the right place. :)
<mrshu>
I thought so =)
<ckocagil>
HN is much worse than proggit.
<gwillen>
Hello sandstormers, question for you. What would it take to get the ability to move cards between different boards in the Wekan port?
<gwillen>
This has a whole host of tricky issues -- it involves cross-grain capabilities, potentially different sets of users on the different grains, as well as UX issues.
<gwillen>
But it would make our lives much better! :-)
<kentonv>
gwillen: if implemented by HTML5 drag-and-drop, it might not require any changes in Sandstorm, actually.
<gwillen>
hmmmmmm, oh that's interesting.
<kentonv>
at least as long as cards are "just data"
<gwillen>
So the client would just carry the content along and not require the server to know at all.
<kentonv>
if cards can eventually hold capabilities then the platform needs to be involved
<kentonv>
yep
<gwillen>
Well, cards can have 'labels' and 'members'
<gwillen>
which are (to all appearances) normalized references to things the board knows about
<gwillen>
The labels you can fake if you bring those over too.
<gwillen>
Members are harder because they're effectively capabilities to people.
<gwillen>
(I don't know how they're handled internally in the port.)
<kentonv>
"members" could be represented as sandstorm user IDs, which are globally consistent
<gwillen>
Ok, that would totally work.
<gwillen>
How globally is globally, just out of curiosity
<gwillen>
(We have one server anyway so we would never care.)
<kentonv>
user IDs are based on a hash of your login identity, e.g. "github:1234" (github user IDs are numeric under the hood)
<kentonv>
so global global
<gwillen>
ahh, nice
<kentonv>
the receiving Wekan may not know what to do with that user ID if the user has never accessed the board, of course
<gwillen>
right, but we can flush the user in that case, or put in a placeholder, or whatever
<gwillen>
(it's not even critical to us to copy users at all, I'm just thinking about the design more broadly)
<kentonv>
eventually it would be neat for the card to actually bring along a capability to the user
<gwillen>
right
<kentonv>
we are planning to add features to Sandstorm to allow @-mentions of people who haven't ever accessed the particular grain, and those will deliver a capability to the grain
<gwillen>
Aha, cool.
<kentonv>
(which isn't necessarily related to this, but seemed worth mentioning)
* gwillen
nods
* asheesh
waves groggily.
<gwillen>
kentonv: hm, the dragging that wekan uses now appears to be simulated; it doesn't allow dragging outside the window. I suppose I'd have to look into ripping it out and replacing it with native HTML5 drag-drop.
<gwillen>
hi asheesh!
<asheesh>
Hi gwillen!
<kentonv>
gwillen: yeah I would have been quite surprised if they already used HTML5 drag and drop. :) My understanding is that it's a pretty hairy API... but theoretically it should work
<gwillen>
*nods*
<asheesh>
BTW you could ask mquandalle at the meetup on Tuesday gwillen if you want (-;
<gwillen>
heh, *nods*
<gwillen>
hm, I wonder if there's a way for the drop target to communicate back to the sender 'yes, I am a wekan board, you can delete the drag source now'
<gwillen>
you wouldn't want to delete the card if someone dragged it into the finder or something and dropped it by accident
<gwillen>
(even if the finder felt it could do something with it.)
<gwillen>
But even being able to copy would be plenty good
<ckocagil>
I very vaguely remember that the app could know whether it was a successful drag-n-drop or not
<kentonv>
yeah, I think there is some sort of two-way channel created
<kentonv>
luckily it's a channel we don't need to block because it's capability-based. :)