What about the apps?

A project log for ZeroPhone - a Raspberry Pi smartphone

Pi Zero-based open-source mobile phone (that you can assemble for 50$ in parts)

ArsenijsArsenijs 02/08/2017 at 18:1215 Comments

"Apps" is a concept that has been with us for ages. I won't be talking about anything that Apple, Google or Microsoft might mean by "apps", I'll use it as "applications, software" because it's short, precise and gets the point across, as well as the most common usage at this point in time.

ZeroPhone is not my first project of a portable, personal assistant, communicator device. Indeed, the listed qualities are what made smartphones so important in our lives. During all the previous projects I've worked on, I understood one important thing - in the end, it's all about software.

Nowadays, software support makes or breaks a project, I won't get tired of repeating it because it's true and software really is so damn important. This project needs to have above average software coverage quality - I want to outline what "above average" means here, and what I'll be aiming for when planning my priorities for the project.

In general, it's good coverage of what users need - and coverage of what other platforms don't provide. For now, my guidelines are:

Other than these general focuses, I'll focus on those types of apps:

For the infrastructure to actually be able to survive in the long term, I'll be enforcing limitations.

  1. Apps should be open-source. This is something A/G/M trio have no interest in enforcing. They want the best user experience, but they are going the "let the market regulate itself" way, with a couple of regulations to avoid breaking laws, as well as usual "we reserve all rights and are not responsible" clause. My opinion is that a single user should be able to fork and change any of the apps if he/she desires, no matter if it goes against what majority might want from the app, and this is exactly what open-source always helped with.
    • Is open-source model a panacea? No. It's just damn good at what it does, which happens to be exactly what this project needs.
  2. No implicit tracking/analytics in apps. Ideally, make it opt-in. This is something an enoumous amount of people are tired of now, and I'll go to the slight extreme of "don't do it unless user explicitly agrees to help you". Open-source components and reviewing code should help with any bad actors on this, too.
    • I understand there are ways where analytics and statistics help (such as better user need targeting, bug fixing and feature priority adjustment), so I'll be making sure app authors have a way to remind the user that there's a checkbox they could tick to help the author make better apps - by being better informed on what people need and use. I, for example, will make this feature for ZeroPhone UI framework - a "send error log to help fix bugs" button, a "yes, send telemetry to help development" checkbox (off by default), and a "receive notifications on important updates" mechanism (that'll be asked when ZeroPhone will be first configured).
  3. There should be a "readable code" expectation from apps. It doesn't matter if an app (external to the core code) is not well-structured as long as it works, honestly - and doesn't interfere with anything else. However, readable code is usually the most modifiable one. To paraphrase - a code that does app-limited localization can have a switch statement with hardcoded things instead of a map, where it'd be shorter to write a map using a dictionary.
    • Of course, more elegantly-coded versions are better - but I know I can't expect too much from people that just want to share what they did for their own phones in their free time, and thought others could benefit from that as well. And the usual "no side effects" rules still stand - though more often than not it's easy to fix the side effects (hey, it's open-source!)

There are things I don't yet have a clue about, of course. For example:

  1. App distribution ways. There are app stores, there are mechanisms for adding GitHub repositories, there are distro-specific repositories and then there are custom package managers for things, all of those ways have its pros and cons, and I'm not yet sure what fits so it's bound I'll have to return to this later, when I'll have my requirements ready.
  2. If there's anything that has to be done about closed-source apps. While it's a requirement in my book, some people will be overriding it anyway and provide .pyc or .pyo files instead of plain .py apps. I'm going to discourage it, but sometimes people will do their own thing no matter what - and if you look at it, this whole phone is designed to allow people to do things without restrictions, so placing a restriction on it would be as inappropriate as to not allow people to change logos in the UI (a nice example of this is xscreensaver. I understand your reasons, and I disagree - the logo looks goddamn ugly to me).
  3. Something else that I have stupidly forgotten about? Any ideas, guys?

This guy can't wait to tell me about the extents of this post's suckery in the comments.

This post was hard, but satisfying to write - I know it addresses many important points and questions. As usual, I'd love to hear your feedback - here in the comments, or email me on info at zerophone dot org.

If you're coming from Reddit/HackerNews and you like this project:


Morning.Star wrote 07/26/2017 at 09:29 point

What framework(s) are you using for your apps, and how does that affect your security model if users can write around it? In Android this was controlled with an API and permissions to provide building blocks for apps, are you planning something similar?

  Are you sure? yes | no

Arsenijs wrote 07/26/2017 at 17:01 point

As for now, it's a self-designed framework made in Python, and it hardly exposes any API that could be limited  =) I'll be looking at FSO API (, it seems promising - after writing some wrappers around DBus, it could be made into something really simple and user-friendly, too =D Having said that, I don't yet know how it handles permissions, TBH - it's all still to be researched.

  Are you sure? yes | no

Morning.Star wrote 07/26/2017 at 19:01 point

I like the idea of to provide the structure, I didnt know something like that existed. Looking forward to getting my hands dirty ;-)

  Are you sure? yes | no

afshaan wrote 07/24/2017 at 09:03 point

maybe for an app store just have a website where you can go, to download and see the source code of the apps  as well as the github repo that dillon suggested 

  Are you sure? yes | no

Arsenijs wrote 07/26/2017 at 17:03 point

Yep, those are going to be likely features - granted, I now know I can't promise anything on the timing, but I do hope somebody could pick them up before I do =)

  Are you sure? yes | no

ActualDragon wrote 02/14/2017 at 16:50 point

how about the arduino ide?

  Are you sure? yes | no

Arsenijs wrote 02/14/2017 at 21:19 point

Writing sketches on this screen? Possible but unlikely. Compiling and flashing them? Did that last week, actually, worked as good as it does on Linux - which's "perfect" =)

  Are you sure? yes | no wrote 02/09/2017 at 23:20 point

We believe the future of ... our way of life will be determined by how well we prepare our children for success in the 21st century. Today we see great potential for the application of technology to enrich and transform education for all learners.

  Are you sure? yes | no wrote 02/09/2017 at 22:43 point

Apps for learning and teaching are vital as we look at next generation and just those who eager to know how ZeroPhone works (in order to hack it=make it the most sutable device))) as on a target audience too

  Are you sure? yes | no

Arsenijs wrote 02/10/2017 at 07:27 point

Agree! Forgot about this as a priority - but then, it's kinda included in "tinkering apps". I'll think of what apps we'll need for this and include it in one of the updates further down he road =)

  Are you sure? yes | no

Dillon Nichols wrote 02/09/2017 at 13:56 point

After reading this, I thought of an interesting method of distributing apps. What if you make a git repo in the style of ? Then app developers can create pull requests that link to the github where their application resides. You can make some app store-type program that parses the list and gives information/ability to install all of the apps. Each app would need a specific format, preferably hosted on github - maybe an /app/ directory with a readme for a description and images and an install script or something. 

Point of contention is that you control what apps make the list. You may see this as a good thing because you can keep spam out, but also bad because you're in control and hold the same power as the big 3 companies. Just something to consider.

  Are you sure? yes | no

Arsenijs wrote 02/10/2017 at 06:44 point

App format is something absolutely necessary, indeed, at least something like "app.manifest" document. Currently, pyLCI uses "has and, has menu_name variable (optional) and init_app function in it" criteria. I like it because it's quite minimalistic but I'm sure it won't be enough at some point =)

RE: all kinds of "awesome" lists out there - it wouldn't have to be hard-coded, I still need to give people a way to share their apps without some kind of approval (like Ubuntu PPAs).

Problems I see with "awesome" kind of lists: 

1) Depends on GitHub (though can be self-hosted on, for example)

2) Depends on maintainers (more of a good thing, and if I give a self-hosted option, even a better way to)

3) Scalability? Though apt IIRC uses a similar way with its Packages.gz file, and this can and should be gzipped

4) Updates? There'd need to be a mechanism to provide people with new releases, and yet not have to update apps with each new commit (also, trusting apps to not become malicious as they are upgraded - this is very important!)

5) I'll think about it some more, too.

  Are you sure? yes | no

Dillon Nichols wrote 02/10/2017 at 14:06 point

There's a ton of options for the app format. Just have to find the one you like or roll out your own.

Good point on the updates. That's something I didn't think of. In that case, it might work out well to use a system similar to apt. You'll have to think of a clever way of entering the PPAs. Perhaps an app ID that you automatically issue (so there's no duplicates) (which an user that wants to install can just type in)? Maybe the site that generates the app ID can also generate the app format file? 

There's lots of options when you have a blank slate.

  Are you sure? yes | no

Arsenijs wrote 02/10/2017 at 19:17 point

I think that in the end rolling your own is always preferrable - provided you have seen enough other formats, of course =)

Hmm, I for some reason would rather go the Linux package management way and use human-readable app names, whatever the author picks that isn't taken =) Names that make sense are also usually more readable, and I don't think using a Markov chain generator is the way to go =) App format file could  be generated with a command-line tool. Now, if we were to talk about app verification, that's another story.

The reason I'm basically using whatever Internet now uses for websites is that this allows the most flexibility and the most decentralization possibilities. My aim is so that you could deploy a ZeroPhone app repo at your home and it'd be nobody's business except yours - and that's what we currently have with websites and webservers, I like it. The only thing I don't like are SSL certificates which cost and are centralized - but open systems allow you to do whatever the heck you want with certificates anyway =)

Lost of options, indeed. And they all become irrelevant when you roll out your first release including a choice you made - once you do that, you typically have to support it for the rest of your life =D

  Are you sure? yes | no

Craig Hissett wrote 02/08/2017 at 20:36 point

The software plans sound amazing!

It's going to be great seeing the app development take shape, and also see what users can come with too. The app repository could be phenomenal! :-)

  Are you sure? yes | no