01:47 <isd> Ug, current meteor is already on sspl-licensed versions of mongo. I was hoping there'd be more time to deliberate on the issue.

01:55 <isd> Is it possible to upgrade meteor without upgrading mongo?

03:51 <isd> ...The meteor-testapp pr is starting to feel like way too much yak shaving. I think I'm going to start messing with implementing the AppHooks stuff and sleep on it.

09:56 <xet7> What is the problem with sspl-licensed mongo?

15:39 <ocdtr_web> xet7: The issue is largely that the OSI has not declared SSPL suitably "open source", and a lot of people put stock in that.

15:40 <ocdtr_web> Personally: I think things like SSPL are necessary to prevent Big Tech from ripping off good open source companies, and SSPL in particular is so narrowly written that it could never present a problem for either Sandstorm or even proprietary forks of Sandstorm.

15:41 <ocdtr_web> However, the downside I recognize is that many people consider OSI as the authority on what's open source, and hence could decide to claim Sandstorm is built on non-open source software. I don't think we should let one entity be the sole definer of what can and can't be called open source, but it might have a detrimental impact on interest in the

15:42 <ocdtr_web> project if people focus on it.

15:44 <xet7> I'm currently trying to install Wekan to RHEL7.2 s390x mainframe.

15:44 <xet7> Just for fun

15:46 <xet7> Well, is there alternatives to MongoDB ?

15:47 <xet7> other than full rewrite of software

15:56 <ill_logic> Furthermore, one that's compatible with their data.

15:56 <ocdtr_web> I think Meteor is fairly big on assuming you have MongoDB.

15:56 <ill_logic> Or else we'd have to migrate everyone's machine, and yikes.

16:00 <ill_logic> ocdtr_web: Is there any movement among Meteor to stay OSI-friendly?

16:01 <ocdtr_web> I have no idea, I haven't followed the conversation on it directly.

17:14 <isd> I'll admit my most pragmatic concern is that I think a lot of folks who would otherwise get excited about sandstorm are going to have a knee-jerk reaction about the sspl. ocdtr_web said something on the last call about how it looks bad to post links to googlegroups on /r/selfhosted, and I there's a similar thing going on there. I don't really want to have that argument if I can avoid it.

17:16 <isd> Re: "I don't think we should let one entity be the sole definer of what can and can't be called open source," I mean, they have a trademark and a definition and everything. You'll note mongo's site is careful not to actually come right out and say it's open source anywhere.

17:17 <isd> but that's a minor thing, and I agree "this particular group of people have a problem with it" isn't terribly compelling to me.

17:23 <isd> Re: being narrowly written, I mean, it seems to me like we're a textbook case of what the contraversial clauses are not supposed to cover. But from what I got from asking around part of the complaint is that it's actually really broadly worded and so vague that if you actually expose mongo to users it could be legally risky to have basically an infra at all -- dumb one-off scripts etc.

17:25 <isd> People spread a lot of FUD about there being risk of the GPL "infecting" basically everything in your org. But the GPL is very carefully worded about what it covers, and from what I've gathered the SSPL is ...not

17:27 <isd> There's a limit to how much engineering effort I'm willing to spend on this, especially in the short term, but I'd like to avoid dealing with it if possible.

17:29 <ill_logic> We had a discussion long ago about considering leaving Meteor in the long run for other reasons. We ultimately decided against that, correct? We wrongly assumed it wasn't active?

17:30 <isd> Yeah

17:30 <isd> More or less the concern was that meteor itself had stalled, but that seems not to be the case.

17:31 <isd> I can see two realistic ways out of this. (1) we find some drop in or close to it replacement for mongo.

17:32 <isd> I've looked around a bit and there are some potential options, but none of them is perfect.

17:32 <isd> Probably the closest to being something we could adopt without a ton of effort is foundationdb. It has a document layer that's wire compatible

17:33 <isd> There are two troubles: (a) I'm lead to believe foundationdb has trouble scaling down; it's really designed for huge deployments

17:33 <isd> But then again, so is mongo. short for humongous. So it's a question of degree, and I don't know whether it will be a problem.

17:35 <isd> (b), it doesn't support the op log yet, which meteor uses to subscribe to updates to push to the clients. It can fall back to a polling mode, but I don't know what impact that would have.

17:35 <isd> Option (2) is gradually moving away from mongo somehow.

17:36 <isd> This would have to be a long-term refactor in the background while other dev stuff is going on.

17:40 <isd> one possible route would be gradually move over to using apollo, initially just to access the same mongo database, but refactor all of the stuff that actually touches mongo behind a graphql interface that we use from the rest of the codebase. Once we've finally finished that, we'd have to swap out the query logic for some other data store. There are some options for automatically putting graphql interfaces on top of postgres

17:40 <isd> or such, so maybe we could use one of those.

17:41 <isd> We'd also have to actually move people's data over, but I'm not convinced that would be too bad. postgres supports a jsonb column type, so I think we could for a first pass just have a 1:1 mapping between mongo collections and sql tables, where each table is just an ID column and a json blob

17:42 <isd> Option (2) is obviously a lot more work, but it can at least be done in the background, and I'd feel ok about having conversations with folks where I can say "yeah, we're working on it, but migration away is going to take a while because ... "

17:44 <isd> And in the longer term, I think moving over to something like postgres would have some engineering benefits. mongo isn't really a good fit for sandstorm imo. We're focused mostly on small deployments and empowering users, rather that huge companies. if we hit the kind of scale where postgres doesn't cut it I'd say we've lost the plot pretty hard.

17:45 <isd> And we're sacrificing some really useful things that we'd get with a relational db: transactions, joins, schema validation...

17:45 <isd> There's some denormalization in our schema currently, basically because you can't do joins in mongo, and that kinda sucks.

17:47 <isd> If we were going to do option (2) I think there are a few things that I'd want to do before we even started, most of them are things I want to do anyway (though others haven't really weighed in afaik).

17:47 <isd> The big one is starting to move over to typescript. Having a type system will make things more maintainable in general, and for big refactors it's an enormous boon. I wouldn't want to consider a project like this without it.

17:47 <xet7> For Wekan, I'm thinking of making single binary executeable with Go/FreePascal/something else

17:48 <xet7> Currently Wekan bundle is about 30k Javascript etc files

17:48 <isd> I want to do it anyway. When working on the cron pr I spent like 2 hours hunting down what turned out to be a straightforward type error.

17:48 <xet7> I would like to have simpler deployment

17:48 <isd> xet7: sounds like that would require a full rewrite, no?

17:49 <xet7> From Meteor to Apollo is also full rewrite, I think

17:49 <xet7> Well, I'll look at some Apollo tutorials, is converting easy or not

17:50 <xet7> When I tried Apollo Sdk, Apollo example did start fast, but there was anyway about 2 GB of files

17:50 <isd> I was under the impression Apollo integrates with meteor? it would just be the db layer I think. Which is still a lot, but criticially I think it can be done incrementally, at our own pace, without having to halt development and get nothing done for a long time.

17:50 <xet7> I don't know how many files would be in deployment

17:50 <xet7> Yes it's possible to use Meteor and Apollo in same project

18:03 <isd> Has anyone heard from kentonv as to whether he's planning to make the next call? I know he ended up coming back from shanghai early.

18:07 <xet7> Meteor+Apollo+React https://www.youtube.com/watch?v=m0TC5DcFHDY&list=PLLnpHn493BHFTDL9M1PKnxQwBwOZ8J-h4

18:13 <ErikMelton> I'm having a small issue on a Sandstorm install. I'm trying to install it in tandum with an nginx instance, and the sandstorm.log file has no errors, but I'm getting an nginx 404 page on the admin token link. Any suggestions?

18:14 <ErikMelton> I'm having a small issue on a Sandstorm install. I'm trying to install it in tandum with an nginx instance; I've set up nginx as a proxy and the sandstorm.log file has no errors, but I'm getting an nginx 404 page on the admin token link. Any suggestions?

18:14 <isd> If you just go to the base sandstorm URL, what do you get?

18:15 <ill_logic> nginx error log?

18:15 <ErikMelton> It directs to my nginx webpage. (sandstorm.mysite.me => mysite.me)

18:16 <ErikMelton> I think something is messed up with either DNS or my nginx config, but I'm quite new, so having difficulty troubleshooting

18:16 <isd> Can you show us your nginx config?

18:16 <abliss> ErikMelton: have you read through the nginx docs at https://docs.sandstorm.io/en/latest/administering/reverse-proxy/#configure-nginx ?

18:16 <ErikMelton> Yep abliss. Went through it

18:17 <ErikMelton> Uploaded file: https://uploads.kiwiirc.com/files/b370e1595c99439df716666f236fb4d1/pasted.txt

18:17 <ErikMelton> Setting it up without HTTPS just to get it working, then will upgrade it once it's up

18:20 <isd> ErikMelton: I got a 502 from your server when going to http://sandstorm.erikmelton.me, and a cert error on https. Maybe the former put something in your error log that would be useful?

18:21 <isd> Hm, it's got the sandstorm favicon on it. Maybe also look at the sandstorm log now?

18:21 <ErikMelton> My bad, I just had not named the file with a .conf extension x_x

18:21 <isd> :P

18:21 <isd> glad you figured it out

18:21 <ErikMelton> Now just getting refusal load errors

18:22 <ErikMelton> It violates the following Content Security Policy directive: "default-src https: data: 'unsafe-inline' 'unsafe-eval'". Note that 'style-src-elem' was not explicitly set, so 'default-src' is used as a fallback.

18:22 <isd> I think you're going to have to set up https before this is going to work.

18:25 <isd> The server is insisting on only loading scripts via https.

18:25 <ErikMelton> Hm, that may be the case. At least it seems to be loaded now, so adding HTTPS should be a lot less painful

18:25 <ErikMelton> Thanks for the help :)

18:25 <isd> no problem. Let us know if you need anything else.

18:25 <ErikMelton> Always better to debug one thing at a time xD

18:25 <ErikMelton> Cool, thanks!

19:20 <ocdtr_web> ErikMelton: The one thing I'd mention right now (and if you're versed in Nginx, solicit feedback on!) is we do have an open PR to modernize/improve our sample Nginx config.

19:22 <ocdtr_web> https://github.com/sandstorm-io/sandstorm/pull/3158 for more modern HTTPS config

19:22 <ocdtr_web> Also, hi and welcome. :)

19:23 <ErikMelton> Cool! I'll take a look :)

21:26 <ocdtr_web> Notes from HN today:

21:26 <ocdtr_web> https://news.ycombinator.com/item?id=22192779 :D

21:26 <ocdtr_web> https://news.ycombinator.com/item?id=22194377 :'(

21:32 <ocdtr_web> Question: https://github.com/silverwind/droppy as a currently updated Sandstorm file manager?

21:33 <ocdtr_web> Node app that is allegedly built to perform on cheapy hardware like Pis, and has easy cli flags to set the file storage and config locations.

21:53 <ill_logic> Ian Denhardt: I'm at the point where I'm having the problem described here: https://groups.google.com/forum/#!topic/sandstorm-dev/e-RgaMANZb0

21:53 <ill_logic> I'm trying your trick of writing to /etc/passwd (slightly differently, but I think it's unrelated to what I'm about to describe)

21:54 <ill_logic> In so doing, I realized that /etc/passwd simply isn't visible from within sandstorm.

21:54 <ill_logic> Is it hidden on purpose?

21:57 <ill_logic> Super, thanks!

21:58 <abliss> now that you mention it i do seem to recall it being explicitly blacklisted somewhere... it might be the same reason python dies with pwd.getpwid()

21:58 <ill_logic> holy cow it worked. Got to the next error, at least.

21:58 <isd> Hooray!

22:00 <ill_logic> I mean, it required some surgery to my build environment. Moving /etc/passwd to /var/etc/passwd and making a symlink. And of course sudo didn't work for that last step, thankfully su did.

22:00 <ill_logic> It would be super dangerous to use. Probably we want a better option eventually.

22:01 <isd> I think you should be able to put the symlink in your build directory, rather than messing with the system's passwd. Note the searchPath searches "." before "/" by default, and its not blacklisted if found in "."

22:02 <ill_logic> Okay, so that's why you see your build directory at / within the sandstorm environment. I should play with that more...

22:02 <ocdtrekkie> isd: Have you been talking and not being visible on IRC?

22:03 <ocdtrekkie> ill_logic seemed like he was responding to you (and quoting you as Ian Denhardt), but I saw nothing in either webchat or the whitequark logger.

22:03 <ill_logic> Thank you again, that makes things much less precarious.

22:04 <ill_logic> Oy. We've been in contact in The Matrix. I guess this is a problem, huh.

22:04 <isd> NickServ booted me momentarily I think. had to re-identify and then rejoin, but I guess folks on matrix still saw stuff.

22:05 <ill_logic> As far as Matrix is concerned, Ian and I are in a Matrix room, I thnk. Though it did tell me at some point Ian was booted and rejoined and booted again and rejoined again.

22:05 <isd> Yeah, it bridges the matrix room to the IRC channel

22:05 <isd> I think I got booted from the former, which is why stuff doesn't show up on IRC.

22:07 <ocdtrekkie> Just wanted to point out the oddity, such that nobody assumes everyone saw x or y. I feel like I'm missing out now. :'(

22:08 <ill_logic> Recap is that in the 2017 mailing list link I posted, Ian recommended symlinking from /etc/passwd to /var/etc/passwd and writing something useful to it on launch. But,

22:08 <ill_logic> I thought that required messing with my build system's /etc/ to make it all work. But it turns out I can probably just put it in my build directory since searchpath starts with . before /

22:09 <ill_logic> Which means my build script won't require me to do something super dangerous like mess with the builder's /etc/passwd

22:29 <isd> General recommendation: read all the comments in the scaffolding pkgdef, they're useful.

22:30 <isd> Also the capnp source under src/Sandstorm in the repo is very well commented and really useful in understanding the platform apis.

22:32 <isd> Package.capnp, grain.capnp, powerbox.capnp, and sandstorm-http-bridge.capnp are of particular interest.

22:34 <isd> I think people don't think to look there because it's not up on the website in html form, but those files are a major chunk of our docs

22:42 <ocdtr_web> A first impression from someone of Sandstorm's model: https://news.ycombinator.com/item?id=22196388

22:47 <ill_logic> Ian Denhardt: TIL there's actions.command and continueCommand. Your advice is paying off already.

22:48 <isd> You're welcome