<kentonv>
dlitz: my former-Android-dev friend argues that the Play Store is the backup security mechanism: someone not only needs to compromise your signing key, but also compromise the Google account you use to publish to the Play Store, in order to push updates to your app. (Or, they need to convince people to sideload their update, which requires some additional social engineering.)
jadewang has quit [Remote host closed the connection]
<dlitz>
That sounds plausible. I guess you target the intents at a particular package & class name, then?
<dlitz>
and then if you want to do FOSS development against the app, you just uninstall the official version and install your own using the same package name, signed by your own key?
<dlitz>
I suppose that could work. I still wouldn't want all communication to go through the app (and I'd also want anonymous "sharable link" access to work---I have a non-secured tablet that currently only serves a GrooveBasin stream to my Bluetooth speakers. I don't want it to have lots of privileges.)
<dlitz>
Also, even with my phone---because it can be stolen (and runs a GSM baseband, which is probably full of security holes), I want it to have somewhat less than full privileges.
<dlitz>
^ That's one area where Android itself is lacking. Access to a Google account is all-or-nothing. :/
frigginglorious has quit [Quit: frigginglorious]
<dlitz>
I really like Sandstorm's approach that passes revocable capabilities around.
jacksingleton has joined #sandstorm
<dlitz>
My current gut-feeling is that the Sandstorm app would hand out webkeys. Apps could also get these independently, via QR codes + the web interface.
<dlitz>
I'm also thinking that, the long-term bearer token should *never* be displayed on any screen or passed through any intents, if we can avoid it. Time-limited, one-time-use codes and/or public fingerprints only, used to negotiate the actual token via something like oauth2.
<dlitz>
I'd want to avoid sending long-term secrets through any UI, both to preserve their confidentiality and also to allow future protocol upgrades like key rotation, hardware tokens, etc.
<DanC_>
I'd like to use TOTP (google authenticator).
xobs has joined #sandstorm
<dlitz>
I've been thinking about TOTP, but I haven't really seen where it would make sense on mobile. We're already talking about a password-free world, and TOTP is basically a workaround for the problems with password authentication.
<dlitz>
I could see a use if you're using something like a YubiKey for TOTP, but we could do things that are much stronger (and much more usable) if we're already assuming that the user has separate hardware.
<dlitz>
DanC_: Or are you talking about a different use-case?
<DanC_>
maybe... sort of a drive-by comment
<DanC_>
the use case would be: self-hosting
<DanC_>
with no reliance on cloud identity providers
saggy2 has joined #sandstorm
amyers has joined #sandstorm
<saggy2>
Hi, first timer on this channel. I am liking Sandstorm very much. I just want to know if rocketchat app voice and video chat options being disabled or they just don't work on sandstorm? Thanks
<dlitz>
DanC_: I can see TOTP being handy as a second factor for a web-based login when using one of those cloud identity providers (after that, I'd store a cookie in the browser and bypass TOTP)
<dlitz>
DanC_: It'd also be handy if Sandstorm ever gets plain old email+password authentication, but I'm hoping that's never necessary.
<dlitz>
Beyond its use as a second factor over an air-gap, TOTP is worse than most alternatives. (It's too short, it requires both sides to store a secret as cleartext, it requires human intervention every time you use it, etc.)
<kentonv>
saggy2: I haven't tried them, but I wouldn't be surprised if they need some tweaking to work within Sandstorm's sandbox
<kentonv>
saggy2: please file a bug on the rocket.chat issue tracker if they don't seem to work.
<dlitz>
It'd be nice if the Sandstorm app market had some sort of matrix of what works with each app. It's really hard to find out what apps will actually work for a particular use-case, when not everything works inside Sandstorm.
<saggy2>
ok thanks
<kentonv>
dlitz: In theory an app should mention known-not-working things in its app market description, and anything else is a bug.
amyers has quit [Ping timeout: 260 seconds]
<saggy2>
certainly will do that. as I understand it uses websockets and that didnt work in docker either so i was curious
<dlitz>
kentonv: That's unrealistic, though (limited developer resources, etc), and it's impossible to search for e.g. apps that have a working native Android client
<saggy2>
is there a way to connect rocketchat on sandstorm to android app? I am new to sandstorm, running my own sandstorm server with sandcast.io setup ( started just a couple of days) so i am unable to find a way
<dlitz>
kentonv: My overall experience with Sandstorm has been "nothing works; this is a wasteland". The only reason I stick around is because my views are aligned with the technical vision of the project, and I seem to get along with people like you & asheesh.
<dlitz>
kentonv: but coming from my perspective of "I want to play with native apps on my phone that can use Sandstorm as a backend", it's really, really awful and frustrating
<kentonv>
we have a lot of work to do on mobile
<dlitz>
I feel like mobile is particularly eggregious, but it seems like there are still a lot of things missing, and that's *fine* if people have a good way to navigate it. With my "end-user" hat on, my overall impression in general is that the Sandstorm app market is in desparate need of curation.
<dlitz>
As another example, WeKan is basically an alternative to Trello, but it's much less mature. (IIRC, basic stuff like deleting lists (or someting) was unimplemented when I tried it?) Even something like Trove specifiers like you see on PyPI would be helpful.
<kentonv>
Wekan supports deleting lists
<dlitz>
I don't remember what the feature exactly was. It's a red herring, in any case.
<dlitz>
The app market seems to oversell everything, which makes the overall experience feel like a cheap low-quality knock-off of centralized cloud stuff.
<dlitz>
Maybe there are a few Sandstorm apps that are really awesome, but as a new user, I have no way of knowing which ones those are, and for what use-cases.
<kentonv>
fwiw, the first two rows or so of the app market are the top apps by popularity
<dlitz>
It feels disrespectful of my time. I basically have to install things myself, and spend an hour playing with them in order to find out that they don't do what I want.
<dlitz>
"Popularity" doesn't convey useful information, though. If I cared about popularity, I'd be using Evernote, Gmail, Trello, etc, etc
<asheesh>
BTW, hi dlitz, I totally get where you're coming from. FWIW, I use WeKan all the time, but I hardly use Trello, and there are important features missing.
<asheesh>
For me, the biggest one is notifications.
<asheesh>
I quickly get used to those differences because I'm invested in the platform, but if I weren't, I would probably quickly lose patience.
<asheesh>
Admittedly there are bunch of people who seem to use Sandstorm frequently based on our stats.
<asheesh>
But not like billions of people.
<asheesh>
And hi! Hope you've been well.
<dlitz>
asheesh: Hi! :)
<dlitz>
Yeah, I'm pretty invested, too, but it seems like I'd have to be developing on Sandstorm every day in order to know what works and what doesn't.
<asheesh>
Would "using Sandstorm for daily work" be adequate, rather than "develping on Sandstorm"? And/or maybe you say "developing on Sandstorm" because "developing" is your daily work.
<dlitz>
My personal use-case is really to put together a set of apps and habits that I can use to function and get a lot of stuff done despite my ADHD and poor sleep hygiene.
<dlitz>
I actually meant "developing Sandstorm"
<dlitz>
like you guys, basically
<dlitz>
It seems like there's information about all of the apps, their quality, their featureset, etc. that's encoded in your brains instead of made accessible in the app market.
<kentonv>
I mean, how do you know if an Android app works before trying it? I think the answer here is reviews, not just in the market, but externally. It takes an ecosystem. It will take a while to build, of course.
<dlitz>
kentonv: I usually search Google or the Play Store for keywords I'm interested in.
<dlitz>
kentonv: If I search the Sandstorm app market for *anything* is basically always says no results. "android", "imap", "rss", "offline", "pretty"
<asheesh>
Along those lines, today I "shopped" for two free-of-cost Android apps. I relied heavily on star ratings, fwiw.
<dlitz>
yes, ratings too
<asheesh>
Also fwiw, I'm the ostensible maintainer of the Sandstorm App Market. (-:
<kentonv>
yes, we need to fix the search feature, and we need to fix how reviews are displayed, and create a way to reply to reviews (e.g. to say "this is fixed now). There is a lot of work to be done.
<dlitz>
I mean, I don't blame you. It's *obvious* that your development resources are less than what you'd ideally be able to accomplish.
<asheesh>
It's interesting; we could be tracking these kinds of failed searches.
<dlitz>
fwiw, I think Sandstorm is basically the most promising project I've ever seen that has any hope of being trustworthy for people who don't want their data hosted by a few centralized providers. ownCloud seems nice, but I can't trust a PHP app to be secure against the whole world.
<dlitz>
Sandstorm is actually something I could point new/hobby developers to and say, "build your stuff on that" and be reasonably confident that everything won't just get hacked.
<dlitz>
People good at building app UIs usually suck at getting the security right. Sandstorm separates those two concerns and as far as I'm concerned, nobody should *not* do that anymore.
<kentonv>
:)
<dlitz>
So yeah, I'm not just sitting here complaining that Sandstorm sucks. :) I just want you folks to nail the usability stuff.
<dlitz>
and the community-building stuff
<dlitz>
and right now, if I take off my free-software-social-justice-tech-visionary hat, my experience with Sandstorm has been "promising, but meh", and the app discoverability is a big reason for it
<asheesh>
I think for now, given that, most end-users who successfully use Sandstorm are going to have to rely on guidance from a friend/coworker who is an IT professional in some way. To some extent, that's what I'm seeing with https://oet.sandcats.io/ and tutorials like http://networkeffects.ca/?p=2186 made by the main maintainer of oet.sandcats.io.
<asheesh>
I must AFK a bit, but I want to get this stuff increasingly right over time, so it's always good to hear feedback about what is/isn't working.
<asheesh>
FWIW kentonv I'm working on fixing the installer-tests failures now/over the next little while.
<kentonv>
Sandstorm is a project being developed in public, so everyone gets to see it in its horribly-not-done state. Of course, the whole reason we do that is so that we can get feedback on what people care about most, so thanks for that. :)
<dlitz>
:)
<kentonv>
asheesh: I didn't realize they were failing. Is the installer broken?
<asheesh>
I *believe* it's only broken in that I added an assertion that doesn't work because I misunderstand something about how the installer-tests work.
<asheesh>
Maybe I'll push a change that removes that assertion now, and let them re-run, and then fixing my own understanding isn't as essential.
<kentonv>
asheesh: so, the test is broken, not the installer?
<asheesh>
Yeah, that's my understanding, based on manual testing.
<kentonv>
good because I just pushed a release. :P
<asheesh>
:)
<asheesh>
Thanks for catching my z-index bug. I'm curious what the symptoms were, but we can discuss later if you prefer.
<kentonv>
asheesh: the at-account-creation profile editor was invisible because it was behind other things
<kentonv>
it has z-index: 1 set elsewhere, but your z-index: 0 was taking precedence
<asheesh>
I just literally face-palmed.
<asheesh>
It's too bad Selenium didn't catch that.
<asheesh>
I thought it only wanted to click on elements that are "visible", nowadays.
<kentonv>
maybe we don't have an automated test covering the first-time signup form? That seems weird though.
<asheesh>
I can find out on Monday and perhaps add it if needed.
<kentonv>
note that for manual testing you can do testFirstSignup()
<asheesh>
b
<dlitz>
Unrelated question: Is there any reason why Groove Basin would suddenly just fail to spin up? I don't know if it self-updated and is just broken, or if it's something on my end. I've tried restarting the app and restarting the Sandstorm host, to no avail. There's some crap in the admin log about "getaddrinfo ESRCH" but I think that's from before I restarted.
<dlitz>
(It'd be nice if the admin log was timestamped.)
<dlitz>
oh wait, it sort of is
<dlitz>
ok, yeah, nothing in the log since I rebooted
<dlitz>
(I should say, nothing interesting. Just mongo startup and sandcats stuff, and something about migrations)
<dlitz>
Other apps start (TTRSS and a brand new instance of WeKan)
<dlitz>
app log is just a long series of: ** SANDSTORM SUPERVISOR: Grain still in use; staying up for now.
<dlitz>
which looks normal
<dlitz>
The sharable urls list doesn't have the usual permissions drop-down lists.
<kentonv>
dlitz: is it just showing the loading spinner forever, or what?
<dlitz>
kentonv: yeah
<kentonv>
try clicking the "restart app" button in the top bar?
<dlitz>
Did that already, a bunch of times.
<dlitz>
It might be a local problem on my LAN (I've seen weird 70ms ping times on my local LAN recently; rebooting the Ethernet switch made it go away, weirdly), but I think probably not.
<kentonv>
is it just that one grain? if you create a new one does it work?
<dlitz>
oh, good idea
<dlitz>
yup, an empty grain works
<dlitz>
I uploaded a few GB of music to the one that doesn't work.
<dlitz>
I'm not sure if that matters.
<kentonv>
shouldn't
<kentonv>
thought I guess I don't know if it scans all mp3s at startup or something silly like that
<kentonv>
weird that there's nothing in the app debug log
<kentonv>
I guess file a bug against the groovebasin sandstorm repo, or try to catch dwrensha here (he's the packager)
<asheesh>
kentonv: An update: installer-tests is failing, but install.sh is fine.
<asheesh>
Sorry abot the flakeage; afk a little bit.
<kentonv>
asheesh: great, thanks
<dlitz>
kentonv: I'll wait until I actually figure out what's wrong, and probably after I figure out my local network issue. So far, I just have: "it's broken, no idea why", so if it's not happening for anyone else, then a bug report won't be all that useful. :)
<kentonv>
I doubt it's network-related. The grain spinner spins until Sandstorm gets an initial HTTP response from the app.
<kentonv>
it sounds like the app is hanging
<dlitz>
kentonv: ohh, okay, that's good to know
<kentonv>
but I guess not crashing because then the supervisor would log that
<dlitz>
Is there a command to run a shell inside the grain's container?
<dlitz>
or a guide to debugging these things?
<dlitz>
if not, I'll figure it out eventually
<dlitz>
actually, I could probably just read the docs
<dlitz>
that's actually hugely helpful, just to know that it's not implemented yet
<dlitz>
I won't waste time looking for the canonical way to do it, then :)
<kentonv>
apparently asheesh and I found the same link at the same time
<dlitz>
:)
<kentonv>
you *can* find the grain's raw data under /opt/sandstorm/var/sandstorm/grains/<grain-id>
<kentonv>
/sandbox
<dlitz>
kentonv: thanks!
<dlitz>
do all of the processes inside the container show up in the host's "ps", "top", etc?
<kentonv>
dlitz: yep
<dlitz>
kentonv: perfect, thanks!
<dlitz>
ohh, I see how the filesystem works now. I'm temped to run sshfs on the host to map my whole music library from my NAS, and just blow this container away, but I won't do that yet. :)
<kentonv>
dlitz: note that groovebasin might have some sort of database it uses too so simply copying the files in may not work
<dlitz>
"TypeError: Cannot read property 'key' of undefined"
<dlitz>
also this, (but I'm not sure if it's normal yet): sandstorm/supervisor.c++:1168: warning: ip_tables kernel module not loaded; cannot set up transparent network forwarding.
<kentonv>
yeah ip_tables is a red herring, we should really remove that warning
<dlitz>
yeah, it's in all of my app logs, and it wouldn't really make sense for that to be the issue, if another instance of the same app works
<dlitz>
If I download a backup of the grain and re-upload it to the same server, will I get a new grain or will it overwrite the existing one?
<asheesh>
new grain
<dlitz>
perfect. with any luck, it'll reproduce with just the backup
<dlitz>
it's only 1.1GB. Not something I'd post publicly because copyright, but I'd be fine sending it privately to someone to have a look at
mnutt_ has joined #sandstorm
<dwrensha>
dlitz: this is a grain that hits the groovebasin problem you referred to above?
<dlitz>
dwrensha: yup, seems to be
<dwrensha>
oh, sorry, by "reproduce" I meant "trigger the bug starting from a new grain". I already have a zip of a grain that exhibits the problem (assuming this is the same problem), but I don't know how it got into that state.
<dlitz>
ah, ok
<dwrensha>
if you have shell access, it might be possible to repair the grain
jacksingleton has quit [Ping timeout: 260 seconds]
<dwrensha>
The easiest thing would be to do `rf -rf sandbox/groovebasin.db`
<dwrensha>
which will clear all the metadat
<dwrensha>
a
<dlitz>
heh.
<dlitz>
thanks
<dwrensha>
so you'd lose tags and playlists
neynah has joined #sandstorm
<dwrensha>
but all the audio files would stay there
<dlitz>
oh, as far as reproducting it goes, I was uploading several directories throught the web interface, one directory at a time
<dlitz>
at some point, some of the uploads choked (probably because of my broken LAN)
<dlitz>
I ended either reloading the page or restarting the grain (can't remember)
<dlitz>
It *worked* after that, for a few days
<dlitz>
but I don't think I'd restarted Sandstorm until later
<dlitz>
but yeah, I had parallel uploads going on
<dwrensha>
interesting
<dlitz>
I also had the window open on several machines (and I think a couple of windows open to the same grain on the same brower)
cozy-165 has joined #sandstorm
<dlitz>
a Sandstorm upgrade might have been the point where it broke; I have no idea.
<dlitz>
or maybe an app upgrade, if there was one in the last few days.
<dlitz>
something to do with migrations, perhaps?
<dwrensha>
no, there has not been a recent Groove Basin update
<dlitz>
hm. I also wonder about concurrency. Like, this is leveldb, right? What happens if more than one process tries to access it at once? Can that happen?
<dlitz>
assuming the leveldb isn't just horribly corrupted, it seems to me that the app should be able to handle corrupt track metadata, in any case
<dlitz>
oh, also, one of the browsers I used was Chrome on Android, accessing the grain via a sharable link that's only allowed to play the stream
<dlitz>
it doesn't have playback control access, yet the "play/pause" UI pretends to work, which is weird
<dlitz>
so maybe the access controls aren't fully implemented, and it changed something and then failed out due to access control?
<dlitz>
I'm just guessing, here
<dwrensha>
yeah, that's because the Sandstorm app allows finer grained permissions than upstream
<dlitz>
*nod*
<dwrensha>
upstream defines a bunch of permissions, but only allows them to be assigned in a few limited bundles of permissions (what we call "roles")
<dlitz>
oh, this is fun
<dwrensha>
so our "can only listen" role isn't actually possible to achieve upstream
<dlitz>
dwrensha: oh, I also had created a new playlist ("Ambient") and removed most of the files from an existing playlist ("Incoming"?), and I may have renamed the playlist a couple of times.
<dlitz>
I think that was the most recent thing I did, aside from just playing things.
<dlitz>
It might have even died immediately, and I would have written it off as a LAN issue, because my LAN is currently broken.
cozy-165 has quit [Remote host closed the connection]
cozy-165 has joined #sandstorm
<dlitz>
(I might have also gotten distracted by my desire for AAAA support in sandcats.io, since my IPv4 traffic would go through a crappy little OpenWRT router in order for DNAT to work.)
cozy-165 has quit [Remote host closed the connection]
cozy-165 has joined #sandstorm
<dlitz>
So I started looking at that, and saw that the UDP ping protocol has no authentication at all.
cozy-165 has quit [Remote host closed the connection]
<dlitz>
which makes me think that I could probably hijack a sandcats.io domain and then get forged foo.sandcats.io certificates via letsencrypt. It wouldn't be wildcard, but it would be good enough to hijack a particular list of grains.
cozy-165 has joined #sandstorm
<dlitz>
I'd have to know the hostnames I'd want to hijack, but of course SNI is sent cleartext, so it would basically just be a matter of sniffing the same wifi connection that I'd eventually want to MITM.
<dlitz>
I wouldn't be surprised if the whole thing can be automated.
<dlitz>
An workaround specifically for letsencrypt might be to publish CAA records (RFC 6844) to tell letsencrypt not to issue certs, but I'm not sure whether that's actually desirable or helpful. If I can hijack DNS, I can probably get a traditional CA to give me a domain-validated cert, albeit manually instead of via ACME.
<dlitz>
*hijack the DNS record
<zarvox>
dlitz: I'm reading sandcats/server/udppings.js; the UDP ping protocol doesn't do any writes on the sandcats server
<dlitz>
*blink* oh wait, did I misread the comment?
<dlitz>
"When the client receives a reply, and it matches the last challenge they sent out, then they know that they should update the IP address we have on file for them."
<dlitz>
oh, so the server doesn't actually do the update directly from the UDP ping protocol?
<zarvox>
Correct, it requires an authenticated request
<dlitz>
oh ok, good
<zarvox>
which I'm guessing is over HTTPS
<dlitz>
lol, I must have been pretty tired when I read that
<zarvox>
no worries
<zarvox>
Better to double-check things :)
frigginglorious has quit [Quit: frigginglorious]
mnutt_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
cozy-165 has quit [Remote host closed the connection]
cozy-165 has joined #sandstorm
cozy-165 has quit [Remote host closed the connection]
cozy-165 has quit [Remote host closed the connection]
cozy-165 has joined #sandstorm
cozy-165 has quit [Remote host closed the connection]
cozy-165 has joined #sandstorm
cozy-165 has quit [Remote host closed the connection]
cozy-165 has joined #sandstorm
cozy-165 has quit [Remote host closed the connection]
cozy-165 has joined #sandstorm
neynah has joined #sandstorm
<digitalcircuit>
dlitz: you mentioned running Groovebasin on a tablet? If it's not too off-topic for this channel, may I ask what setup you use? I've always had Firefox Mobile stop working when the screen turns off (activity onPause, I think) - it no longer sends the keep-alive pings to the Sandstorm supervisor. And keeping the screen on isn't all that wonderful of a work-around...
<kentonv>
digitalcircuit: hmm, are you saying the music would keep playing with the screen off if not for the keepalives ending?
<digitalcircuit>
kentonv: yup. I tested it by opening Groovebasin on my desktop, and it kept playing on mobile. Android/Firefox -might- eventually kill the audio stream, but it keeps going for at least 30 minutes, unlike the ~5 without keepalives.
<digitalcircuit>
(There's an unrelated issue where if Firefox Mobile isn't the foreground app regardless of screen status, audio sounds horribly choppy, but I think that might need a dedicated Groovebasin app to fix)
<kentonv>
does the battery drain quickly when playing audio like that?
<kentonv>
I would think that because groovebasin is real-time, the CPU would keep having to wake up to execute Javascript
<kentonv>
whereas with say an mp3 player app, it could queue up a lot of audio and offload it to the dedicated audio processor while the CPU sleeps
<digitalcircuit>
I'm not sure..? I can try monitoring battery more closely in the future. I don't know if local audio is offloaded in chunks that are much bigger than streaming.
<digitalcircuit>
That said, locally buffering would be nice so Groovebasin could more accurately synchronize playback.. but that's a whole 'nother level of changes :)
* digitalcircuit
's using Groovebasin as a whole-home audio solution, and there's.. some to be desired.
<kentonv>
oh I suppose the lack of keepalives demonstrates that firefox is not running any javascript while it sleeps. It's just continuing the audio stream entirely in native code I guess.
<kentonv>
I suppose we should detect when a significant amount of traffic is still going through the session and auto-keepalive it
<kentonv>
either that or groovebasin could use the backgrounding API to keep itself awake as long as there is one listener open
<kentonv>
maybe that's the better approach, as long as it is done right. (It would be easy to do it wrong and have groovebasin stay awake as long as the stream is playing, even with no listeners, which would be bad...)
<digitalcircuit>
Might other apps potentially accidentally keep sending/receiving data when the .... Yeah. You're thinking much more quickly than me :)
<kentonv>
try having a text conversation with asheesh sometime. It's like drinking form a firehose.
<kentonv>
dwrensha: perhaps groovebasin should enable backgrounding whenever at least one client is still streaming? See above.
<kentonv>
(I'm sure he's asleep right now, but he'll see it later)
<digitalcircuit>
Heh, the firehose analogy sounds a bit like a mathematician friend I have :)
<kentonv>
oh, this will be extra-important if/when we start making background tabs not send keepalives
<digitalcircuit>
Is backgrounding something allowed by default? That'd be an odd thing for Groovebasin to have to prompt for.
<kentonv>
digitalcircuit: it's allowed by default but it creates a notification to the owner so they are aware and can cancel it
<digitalcircuit>
Sounds good!
<digitalcircuit>
Does the same apply with APIs, or is keepalive handled differently there? Groovebasin has MPD support disabled right now, but that might be a good way to get an Android app without it having to be dedicated to Groovebasin.
<kentonv>
yeah any time the app is running it can potentially start background processing
<kentonv>
the notification always goes to the owner
<kentonv>
so they'll see it if they have sandstorm open
<digitalcircuit>
Hrm. Does canceling background processing keep it canceled until the next time the app's open? And, does the notification persist once background processing has stopped (e.g. "is" versus "was")? Say, if a user's on Oasis and want to conserve bandwidth/memory/whatever's billed.
<digitalcircuit>
Err, by "opening the app", I'm referring to inside the Sandstorm interface.
<kentonv>
canceling the notification ends the specific lock that the notification represented. The app can create a new lock. If the app is maliciously using more resources than desired, the owner will have to delete the grain(s).
<digitalcircuit>
Makes sense. I forgot about resource-tracking for individual grains/apps, since most of that's unfortunately hidden when self-hosting (I think).
<kentonv>
we actually haven't implemented "compute unit" accounting on Oasis yet either
<kentonv>
only storage accounting
<kentonv>
it hasn't been a problem yet, though
<kentonv>
but I probably would want to get that done before too many apps start using backgrounding
<digitalcircuit>
Ah, okay, no worries :) I'd suggest considering accounting for self-hosting, too, so you don't have someone accidentally filling up your server.
<kentonv>
I think we'll probably add some storage accounting at some point, but note that the self-hosting version will be based on scanning files and inotify. A malicious user might be able to hide things with careful timing.
<kentonv>
the Oasis mechanism for storage accounting is based on a totally different storage back-end and cannot be evaded
<kentonv>
the mechanism for resource usage might similarly need to be implemented differently on single-machine sandstorm vs. cluster sandstorm... as I understand it, cgroups don't take well to being shared by multiple daemons on the machine, and docker and systemd are already fighting over them, so we may want to stay out
<kentonv>
RAM usage, that is
<kentonv>
anyway, bed time, ttyl
<digitalcircuit>
I'm not worried about actively malicious users, just inadvertent misuse. I'm guessing that might apply for some other self-hosters, too.
<digitalcircuit>
Alright, thanks for talking with me, and sleep well~!
<kentonv>
yes, that is my guess as well. Anyone who is worried about actively malicious users is probably a hosting provider and probably wants cluster sandstorm for scalability too. :)
<ragesoss>
yikes. that's just full of meaningless directory names.
<dwrensha>
the directory names are the app IDs
<dwrensha>
if you want to do development on the Rocket.Chat app, I recommend getting a dev environment set up with vagrant-spk
<dwrensha>
editting the installed app in-place is not really a supported activity
bb010g has joined #sandstorm
dwrensha has quit [Ping timeout: 244 seconds]
amyers has joined #sandstorm
<zarvox>
Yeah. Also, you'd be editing the build artifacts, which are likely minified/concatted JS/CSS, at least for the "browser" Meteor target, rather than the source.
<zarvox>
Which might be more painful than necessary.
amyers has quit [Ping timeout: 244 seconds]
amyers has joined #sandstorm
amyers has quit [Ping timeout: 250 seconds]
amyers has joined #sandstorm
amyers has quit [Read error: Connection reset by peer]
amyers has joined #sandstorm
amyers has quit [Ping timeout: 248 seconds]
<ragesoss>
I see. I really just want to uncomment one of the packages in the Rocket Chat meteor packages file. But not enough to set up a dev environment.
jadewang has joined #sandstorm
dwrensha has joined #sandstorm
gkoz has quit [Ping timeout: 240 seconds]
gkoz has joined #sandstorm
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
dwrensha has quit [Ping timeout: 268 seconds]
dwrensha has joined #sandstorm
<zarvox>
ragesoss: On Sandstorm, apps don't have raw network connectivity unless an admin grants them such connectivity, and then they have to speak a slightly different API. So even if you enabled the package, you still wouldn't be able to use Rocket.Chat as an IRC client, for now at least.
Rym has joined #sandstorm
tierce has quit [Ping timeout: 268 seconds]
jadewang has quit [Remote host closed the connection]
tierce has joined #sandstorm
prettyvanilla has quit [Remote host closed the connection]
<DanC_>
that's something of a pattern, for me: "ooh! I can use sandstorm to get that app running in 15 seconds. Done. But... the feature I want relies on network connectivity that sandstorm doesn't allow out-of-the-box. Darn."
prettyvanilla has joined #sandstorm
jadewang has joined #sandstorm
<zarvox>
Acknowledged. I think jparyani has a TCP bridge implementation that he used to make a (not-polished-yet) Mumble package, and the Powerbox supports granting IpNetwork and IpInterface, so we're moving in that direction.
<zarvox>
DanC_: I'd love to hear which apps/features you'd like to see that need raw network access! A couple that are particularly interesting to me are running a Minecraft server and the Nylas Sync Engine.
<DanC_>
it would be nice to be able to do `pip install ...` from IPython
<DanC_>
not to mention access datasets
<DanC_>
I think the rocketchat issue turned out to be desktop notifications; a fix is percolating thru the works on that one, I gather
<zarvox>
Desktop notifications should work in the published package, as of...Thursday?
<zarvox>
I placed that work on ice until I had a package that could realistically test the shim - now that Rocket.Chat has working notifications, it'd be nice to get that fleshed out.