<isd>
I think "require admin" is very much the wrong way to be thinking about this stuff. At some point I want a way for users to have a "keyring" of capabilities, and an admin can grant access to things by giving the capability to users, which they can store in their keyring. You could also add "groups" which would be basically shared keyrings.
<JacobWeisz[m]>
I think we discussed the idea of an admin approval flow, potentially, back in the day. Apart from the system app idea, where an admin is presumably setting them up for users to then be able to use freely, apps should generally hopefully not require you be a server admin to run... that's a bad place to go, design wise.
<isd>
...some specific range of ports is probably the right thing. But I also just want to push us away from ACL thinking; it results in really inflexible designs.
<JacobWeisz[m]>
True, though range of ports is probably a key config limitation due to firewalls.
<isd>
See also: I'd like to be able to give different users different levels of network access, but right now anyone who can access a grain can give it an ApiSession, and I have one place where I can change the filtering rules for ip addresses.
<isd>
I'd like to be able to have the default (public only) filter for most users, but also be able to give something more permissive to others, so e.g. they can connect to a local printer.
<isd>
The keyring approach would let us reduce these decisions from "does this require admin?" to "Is this in the default keyring for users?"
<JacobWeisz[m]>
That seems sensible.
nicoo has quit [Remote host closed the connection]
nicoo has joined #sandstorm
<JacobWeisz[m]>
Question, would a good first start to this Keyring idea be something people have long requested: The ability to share a grain by default to all new users?
<isd>
I'd have to think about it; not sure how much implementation overlap there would be, though I see the conceptual relationship.
<isd>
I guess you could turn the default-shared grain into a poor-man's keyring.
<JacobWeisz[m]>
I mean, my thought is if a keyring is capabilities a group of users, or all users, can be granted, presumably a capability to access a grain should be one of those.
<isd>
Yeah.
<JacobWeisz[m]>
My thought was also that it would be harder to make a meaningful feature release out of "add major plumbing to give permissions for other new plumbing that some apps we don't have might explicitly use", than if we can launch keyrings as a way to create a feature people already want, and then expand it into the support for other permissions.
<isd>
...we could experiment with this by making a "keyring app" whose grains could make powerbox requests and then just store the resulting capabilities, so they can be used in response to other requests.
<isd>
Yeah, I think sharing a grain by default would be a good stepping stone to play with this kind of thing.
<JacobWeisz[m]>
Is that kind of also the Collections app, though just exclusive to grains?
<isd>
Yeah, it's sortof a generalization of collections.
<isd>
I'm thinking that admins see some extra admin-only options on the grain-settings page, and making something shared-by-default is one of them.
<isd>
I guess we could also cross-reference this somewhere in the admin panel.
<JacobWeisz[m]>
Would it make sense to expand the Collections app into holding non-grain capabilities?
<JacobWeisz[m]>
Or would it make sense to start a separate app?
<JacobWeisz[m]>
All of the Powerbox narrative I've been indoctrinated with over the years suggested that generally capabilities to access grains or outside resources should be somewhat interoperable where sensible to do so.
<JacobWeisz[m]>
I wish I felt I had the code literacy to hack on the app index. There's so much I'd do.
<isd>
Yeah I think trying to generalize the collections app directly makes some sense.
<isd>
Re: app index: yeah. I wish it were not written in C++; there's no particular reason for it to be, and I think it's a barrier to contributors. Also, just generally, working on potentially-malicious-user facing C++ makes me super nervous, and I wish we could assume memory saftey everywhere.
<isd>
I wish there was an automated C++ -> rust translator or such; there are some for C, but C++ is much harder (which is sad and ironic, given that the style of C++ we use is conceptually quite close to idiomatic rust)
<JacobWeisz[m]>
Well, the app index is probably simple enough on its own that "rewrite it" is possible, though I know it pulls in stuff from Sandstorm that might add problems.
<isd>
Rewriting it definitely seems realistic.
<isd>
Whether it's the best immediate use of someone's time is another question, though if this is your passion porject, go for it.
<JacobWeisz[m]>
It's kinda in the "I'd love to play with it, but I know the number of roadblocks to get there is high for my skill level". I agree there's definitely better uses for people's time.
<JacobWeisz[m]>
In most cases, app index quirks solely irritate me personally and me alone.
<xet7>
Is there some Rust web framework that does not leak memory, have slowloris problems, etc?