Feature idea: Let app know it's a user's first grain

[ocdtrekkie]

I find Etherpad sample data super annoying to delete when I open a new grain. I think some apps (Firefly III, I think) have demo experiences that show you where things are.

I am wondering if it would be a good feature to have an HTTP header or something that would be present on a user's first run of their first grain for an app, so an app knew it should offer a first run or demo experience or have sample data, but on subsequent runs, start ready for use.

[zenhack]

I generally like this idea. I think it might be easier to work with programmatically if we gave the grain the information during the startup process, rather than as part of an http request, once it's already done db initialization and such.

[ocdtrekkie]

I just find the method we hand display name and such out by far the easiest for the app developer to use.

My biggest query is if anyone would see any potential for abuse. I feel like it would be hard to abuse in any meaningful way? But I'm curious if anyone can think of a risk.

[ocdtrekkie]

Ah, on another read I understand what you mean. Though I do wonder how much use it would be prior to having the other information passed via the HTTP headers: A good demo startup experience might also want to know the user's display name, or be able to set up the initial user in it's internal users table before it can work right anyways.

The relative simplicity of integrating with the HTTP API (at least from my experience) makes me kinda want as many API features to be delivered that way as possible, at least when providing the app information.

[kpreid]

Why not make the information available through both startup and first request? The idea of having it available on very first startup so that different initial data can be written sounds useful to me.

Unrelated caution: making this information available through any path creates a case that apps might need to add specific test coverage for, if they use it. (Imagine an app that works fine for its maintainer and existing users, but is subtly broken for new users.)

[ocdtrekkie]

@kpreid That's a good note. We should make sure there's a relatively good way to test it. Presumably, Sandstorm will have to track that a given user has run the app before so it knows not to present this flag/boolean/etc. If this is a stored value with the the data on the app being installed for that user (rather than based on existing grains or something), uninstalling and reinstalling the app (rather than updating it) would presumably treat the next grain as your first grain for this purpose. When approving apps, I often both upgrade an existing grain and create a new grain, so this would create a third potential testing path I'd need to explore.

I think it's also important we strongly discourage significant changes in configuration or data based on this: At the end of the day, once people get started, they should be working with the same app/environment. So maybe some sample text or records, maybe a visual-only demo flow that doesn't change what's actually in the grain, etc.

[kpreid]

Thought of an abuse potential: app that asks for money or otherwise provides inferior functionality after the first grain. This is different from existing possibilities for circumventable usage-restriction policies in that it persists across grains.

[ocdtrekkie]

@kpreid Hmmm, I think that would be an (ab)use of this that would be sad, but I am not sure it's inherently problematic, as Sandstorm has never attempted to discourage commercial or proprietary apps. (We just don't actually have any right now... as our only proprietary app later became open source.)

I also think the use for that would be pretty poor: I advocate only offering this information on the first run of the first grain. Presumably, on this run, an app could store something to remind itself that this was the first grain, but I imagine the use of this would mostly be limited. Presumably someone could attempt to make an app that only let you have one grain of it, but it'd be a terrible licensing mechanism, as uninstalling and reinstalling would clear it (based on my previous comment suggestion), and cloning the grain would carry forward any information the app tried to save for itself about being first.

I also feel like if you wanted to ask a regular user of your app for money/donations occasionally, it might be more practical (and functional today) to store a counter of each time the grain is opened, and every so often, prompt the user.

[zenhack]

There's a policy discussion to be had about what happens when somebody submits a proprietary app to the app market. There are some licensing questions to figure out, and personally I'd like to set some policy of "respecting the platform's norms," which would mostly mean not trying to circumvent things the user is supposed to be able to do with grains, not requesting permissions that are excessively broad for your use case, etc.

For development purposes, app developers should have an easier way to control the "first grain" bit than uninstalling/reinstalling the app (and there's a question about what should it do in dev mode?) Maybe we can design some setting about whether to show "first run" demos and such. If we do it right this should also make it even less attractive as a vehicle for the abuses @kpreid suggests, as the user could just go into settings and set it to "always" for a given app if an app author tried to do this.

[ocdtrekkie]

Yeah, generally since the app market has had a single reviewer (previously Kenton, currently myself), nobody's written up a clear guide on it, but I do feel the app market review should choose to decline to accept an app that has poor security practices or feels scummy. I do somewhat wish it was easier at a glance to see what APIs/Powerbox stuff/etc. an app could/did invoke for review and management purposes. (A good example with your new TTRSS: Sandstorm users can't see what permissions they've granted and revoke them anywhere in the Sandstorm UI yet.) Presumably the deadline for that rulebook existing is when someone tries to submit an app that feels bad to accept, but maybe I should work on writing something up.

I am not too worried about dev mode, and think it should work as it would in an actual Sandstorm server... the Sandstorm install in dev mode has multiple users to play with already, and of course, anytime you vm destroy, you'll start over too.