kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
<isd> It works!
<isd> Still need to clean up one or two things though.
nicoo has quit [Ping timeout: 240 seconds]
nicoo has joined #sandstorm
digitalcircuit has quit [Quit: Signing off from Quassel - see ya!]
digitalcircuit has joined #sandstorm
georgeowell has quit [Quit: Leaving this Club]
kawaiipunk has joined #sandstorm
heliostatic has quit [Quit: The Lounge - https://thelounge.github.io]
michaeln3 has quit [Remote host closed the connection]
michaeln3 has joined #sandstorm
michaeln3 has quit [Ping timeout: 260 seconds]
<ill_logic> Ian Denhardt: I was thinking - if we get to the point where we have a robust backup plan, I think it gives us a *practical* leg up over the proprietary competition.
<ill_logic> Not just a "you own your own data" sort of dignity leg up.
<ill_logic> I guess some services let you do that.
<CcxWrk> But you'd want good, granular encryption to prevent that being huge infoleak vector. Tahoe-LAFS backend when? :D
<isd> I mean, presuambly the storage for Google docs is backed up/redundant. But the ability to roll back to arbitrary frequent snapshots is a feature that is at least inconsistently present on cloud apps.
<isd> CcxWrk: yeah, I want to do an encrypted backend. I have a hunch adopting Tahoe as an off the shelf thing to plug into probably has some downsides, but we'll do something.
<CcxWrk> Tahoe as it stands can't be considered reliable sadly. I have some sketches on how to improve both the node distribution/redundancy algorithm and multi-writer collision issues. But I don't know when I'll actually have enough free time to delve back into it.
<isd> I think for what I'm building we can get away with something a lot simpler.
<CcxWrk> Certainly. Though I'd love to see encryption-at-rest as a first-class feature.
<ill_logic> Well, like can you roll Google Calendar back to a previous state? Or do you mean like I dunno NextCloud has a "roll back to this snapshot" feature for its calendar?
<CcxWrk> Etesync has edit log at least, never tried rolling back though.
jmm_ has joined #sandstorm
<jmm_> Hello.
<JacobWeisz[m]> Hey!
<isd> Ahoy!
<jmm_> is 0.271 the latest stable version of sandstorm ? I'm a bit confused.
<isd> Definitely some cloud services have rollback features. But having it for every sandstorm app automatically (including rolling back to old versions of the software) would be neat
<kentonv> yes, 0.271 is the current version
<isd> jmm_: that sounds right?
<JacobWeisz[m]> kentonv: I think we're short a version bump push though
<isd> 0.271 is tagged on github.
<jmm_> it's strange when I use chrome there is a problem with cookies making grain unreadable on a local install ( that has auto updated it seems )
<jmm_> but when I try the demo online there is no problem.
<kentonv> isd, it's tagged but, as usual, I forgot to push it to the master branch, ugh
<JacobWeisz[m]> What error are you seeing? Is it only for grains of a specific app?
<isd> Can you be more specific? error messages?
<isd> opened a pr fixing the app index.
<isd> ocdtrekkie: raather than just bumping appVersion automatically, what if we derived it from a git tag? That would also make it easier to pin down which commit a given .spk corresponds to.
frigginglorious has joined #sandstorm
<JacobWeisz[m]> That probably requires a lot of assumptions about how people manage their git repos.
<JacobWeisz[m]> Problematic for upstreamed projects in particular.
<jmm_> JacobWeisz[m] / isd , when I click on grain and choose an etherpad for eg, it just load forever with the wheel spinning.I checked in the console it cannot load some ressource and give the following message :
<jmm_> Unauthorized due to missing cookie. Please make sure cookies
<jmm_> are enabled, and that no settings or extensions are blocking
<isd> Hm, I wonder if this has to do with the samesite cookie thing they changed recently?
<isd> ocdtrekkie: I'm kinda not a fan of the pattern of forking an upstream repo anyway... makes it harder than it should be to tell what the sandstorm specific changes are.
<JacobWeisz[m]> isd: I mean where the Sandstorm stuff lives upstream, tags aren't determined by the Sandstorm package.
<isd> We'd need to continue to support setting appVersion manually anyway
<jmm_> isd: I thinked so. but the online demo works fine.
<isd> jmm_: what's your BASE_URL & WILDCARD_HOST?
<jmm_> I check it.
<isd> ocdtrekkie: yeah, that occurred to me.
<jmm_> BASE_URL=http://glutamine:6080
<jmm_> WILDCARD_HOST=*.glutamine:6080
<kentonv> ah yeah, Chrome probably interprets glutamine as a TLD and so each subdomain is a separate site
<kentonv> if you could do, like, sandstorm.glutamine and *.sandstorm.glutamine, it might work better
<jmm_> let's try it.
<isd> This probably means anyone who doesn't have WILDCARD_HOST=.${BASE_URL} is going to see breakage.
<isd> s/././
<jmm_> that works !
<JacobWeisz[m]> Single-name internal web addresses is pretty normal in corporate environments, I feel like Chrome should know better than to assume it's a TLD.
<JacobWeisz[m]> Though I suppose wildcard subdomains of single-name internal web addresses is kinda weird.
<jmm_> note it's not me that did the install. I would have used glutamine.lan.
<jmm_> thanks for your help !
<isd> Maybe we should try to detect that and set SameSite=lax explicitly in that case? But I'd kinda prefer to push people towards not using configs that downgrade security in that way...
<isd> jmm_: no problem!
<abliss> i'm not all caught up on scrollback, but you could also try `glutamine.` (note trailing period)
<kentonv> abliss, I'd expect Chrome to treat that the same way
<isd> We've been wanting to set SameSite=strict anyway
<jmm_> abliss: I try it too.
<jmm_> abliss: nop it doesn't works when using a dot at the end . I have a bunch of errors in the console.
heliostatic has joined #sandstorm
TC01_ has quit [Ping timeout: 260 seconds]
TC01 has joined #sandstorm
<isd> Ok, I'll update the package.
<JacobWeisz[m]> isd: Note comments about self URL path issues.
<JacobWeisz[m]> I think they may affect your package
<isd> Noted. Will test of course.
XgF has quit [Remote host closed the connection]
XgF has joined #sandstorm
<isd> Seems to still work.
<isd> Ah, no it does not.
<isd> pushed an spk
TMM has quit [Remote host closed the connection]
TMM has joined #sandstorm
<JacobWeisz[m]> I am not close to using the vagrant-spk release script again, because I haven't tackled many of my goals for it this year yet, but #279 is a draft of solving one problem with the script. ...It just also creates one more issue.