00:16 <JacobWeisz[m]> David replied to my tracking issue, so he can probably either handoff or run your patch for you.

00:20 <isd> Yeah, I'll poke him about it.

00:39 <JacobWeisz[m]> I think at Office Hours we should see if anyone wants to volunteer to tackle ofher apps with CSP issues.

00:54 <isd> not a bad idea.

01:02 <isd> ...I hate it when you click on an app's generic install instructions and it just points you at a docker container.

01:03 <JacobWeisz[m]> Yeah, that's the "we don't want to support anything but the box we designed" mentality.

01:04 <JacobWeisz[m]> FWIW, it works for a lot of people (including some Sandstorm alternatives)

01:06 <isd> I'd be okay with it if I could just feed it to docker-spk, but it will no doubt need a bunch of hackery to actually _run_

01:06 <JacobWeisz[m]> It would be neat to have a docker-spk production app!

01:07 <isd> It's also just a red flag that small deployments were probably not considered.

01:13 <isd> the other bit is that best practices in the docker world usually imply running the db in a separate container, which really doesnn't map to sandstorm at all. Maybe we could rig something up to accommodate that once we have subordinate grains.

01:14 <isd> Also, through working with sandstorm I have come to hate redis. I recognize, rationally, that it has legitimate use cases, but they don't apply to sandstorm and so for us it's just bloat.

01:15 <isd> I have never actually used redis. I hear it's lovely. I just wish we had fewer apps using a separte daemon for a hash table.

01:16 <JacobWeisz[m]> Ideally docker-spk would look at the "run DB in a separate container" instruction and run it in the same container instead. :P

01:16 <isd> Eh, you have to deal with possible path collisions...

01:17 <JacobWeisz[m]> I don't really like subordinate grains unless we can both hide them from your normal UI usage and show them transparently when you want to know.

01:17 <isd> I mean I think It'd be fine to spin up a separate sandbox; they're not terribly heavyweight.

01:17 <JacobWeisz[m]> I neither want piles of useless grain list items nor magic hidden grains I don't know exist.

01:17 <isd> What I'm thinking of is really an implementation detail (and one that I have more compelling use cases for app authors)

01:18 <JacobWeisz[m]> I think I get what you're suggesting then.

01:18 <JacobWeisz[m]> I withdraw my concern. :P

01:26 <isd> Ok, enough staring into the abyss for one day.

01:27 <JacobWeisz[m]> It has stared back, hasn't it?

01:28 <isd> A bit.

01:29 <isd> (In fairness, I don't think the situation is any worse than what the current sharelatex package has to deal with)

02:15 <JacobWeisz[m]> Looks like we have a ShareLatex submission, Ian!

02:20 <isd> huzzah.

04:42 <isd> So I was thinking about the key rotation thing again for app handoffs. maybe we could embed the key change info in the packages themselves? So rather than giving the new maintainer the old key (and the old maintainer retaining access), both maintainers would sign a thing asserting the transfer of maintainership, and then that would get embedded in the package. We could populate revocation lists by reading spk metatadata - the

04:42 <isd> first time we see a package with such an assertion in it, we record the fact that we should not trust the old key for updates anymore.

04:42 <isd> Should obviously more carefully pin down a design, but I think bundling the change info in the package would scale much better than the current nuclear option of patching sandstorm itself.

05:13 <JacobWeisz[m]> The challenge is that doesn't cover he "the old maintainer or key is long gone" case, which I feel is the number one way we use that system currently.

05:14 <JacobWeisz[m]> So we'd still need the existing system for those.

05:14 <isd> I mean, yes, this would not replace appid-replacements

05:14 <isd> I'm more thinking of how to get better hygene around the more organized case.

05:14 <isd> c.f. the discussion we had when Jason handed off ttrss maintainership

05:17 <JacobWeisz[m]> Yeah, something there in the app package might be a good approach.

05:19 <JacobWeisz[m]> I think at some point we need the app index to understand these cases too. People should probably have a way to see some of the history of packages and their maintainership.

05:20 <JacobWeisz[m]> I don't think the market/index even understands that app replacements happened, does it?

05:30 <JacobWeisz[m]> ...If/when someone rewrites the app market, I still kinda wonder if it should be presented in a frame.

05:31 <JacobWeisz[m]> Like, if the market interface was built into Sandstorm, but the app index was the external service you were accessing for the data to populate it.

05:32 <JacobWeisz[m]> ...That'd be one way Sandstorm would be able to show you a preview of the app market page for a dev package.

05:35 <isd> Yeah. I have some thoughts about the app index. I think it would be neat to package it up in such a way that you could run your own app index just by spinning up a grain making an offer iframe and pointing sandstorm at the URL from that. You could also have a grain type that was just a mirror of another app index.

05:38 <isd> There's a bit question wrt what to do about reviews; I think a lot of the same issues come up as did with the disqus/isso app I tried to write.

05:39 <isd> This is one of those things where I feel like I should just write something janky and experiment.

05:48 <JacobWeisz[m]> You never gave me feedback on that writeup I did for system grains, speaking of mirroring the app index...

05:50 <JacobWeisz[m]> wrt reviews, I don't know if I see huge value in bringing it back until Sandstorm is much more popular of a platform.

05:52 <isd> Thanks for the reminder; I started typing up some notes and then got distracted. I'll try to finish that up sometime tomorrow.

05:52 <isd> I would like to do the discussion somewhere public-ish. Should we create an issue or something re: fleshing out the design?

05:52 <isd> re: reviews, yeah this isn't urgent, I'm thinking long term.

05:52 <JacobWeisz[m]> I would almost just rank apps by the regularity they're used according to opt-in statistics sharing and call it good enough.

05:53 <JacobWeisz[m]> Instead of counting on reviews.

05:53 <isd> "bringing it back" -- are they broken or someting?

05:53 <JacobWeisz[m]> Kenton shut reviews off on the app market a long time ago.

05:53 <isd> Ok. I didn't even notice, so I guess that reinforces your point.

05:53 <JacobWeisz[m]> It's literally a Meteor app that functions as a static site these days.

05:54 <JacobWeisz[m]> Yeah, when I realized it, it was months after they were gone, lol

05:54 <isd> So we could start moving on a replacement without a strategy for comments for now.

05:54 <JacobWeisz[m]> We had apps with no reviews, apps where the score was set by like one person's review. Apps which had a lot of bad reviews from an old version that was since addressed, etc.

05:55 <JacobWeisz[m]> The reviews weren't providing much value.

05:55 <isd> fair enough

05:55 <isd> Maybe we should update the contributing doc then -- this is one of the possible projects, and it lists this as a design challenge.

05:56 <JacobWeisz[m]> I mean it's not an insanely hard project. Use the app index API to present the metadata, is all the app market currently does.

05:57 <JacobWeisz[m]> I like the CSS on the app market (kinda), but I'd easily prefer an in-Sandstorm UI over it.

05:58 <JacobWeisz[m]> Probably the main downside to that would be difficulty presenting the app market to non-Sandstorm users. Which is a marketing pain.

05:58 <isd> I mean it's nice to be able to just view the app market without being on an actual sandstorm box.

05:59 <isd> But, there's a contributing file in the main repo that lists re-writing it as a possible project, and it lists figuring out reviews as a challenge. If it's easier than that, the doc should say so.

06:09 <JacobWeisz[m]> Arguably we could both host an in-Sandstorm app market view, and also host it separately on apps.sandstorm.io outside of Sandstorm.

06:10 <JacobWeisz[m]> If it's not a super sophisticated thing, mostly just parsing the app index data into something readable, that isn't a difficult requirement.

06:11 <JacobWeisz[m]> But yeah, it may be warranted to note comments/reviews aren't a priority for that feature.

08:31 <isd> ocdtrekkie: https://thelibrary.sandcats.io/shared/LbD5T72T4Uf4DSwWDYkYAqL97BbJMmc-UmILN87KNBl

08:31 <isd> ^ Comments on your system grain ux thing. I wrote most of that closer to when you sent me the thing, and I feel like I had a couple more thoughts but I've lost them.

23:42 <JacobWeisz[m]> Got a DokuWiki update to the 2020 version at experimental now.

23:57 <isd> Reminder: office hours in 1 hour