In lieu of @petty’s return and as discussed during Core Dev call last week, kicking of a thread on alternative app distribution. Please share your thoughts on alternative distribution means, their requirements as well as dealing with other risks, such as 3rd party services like Infura being blocked
Sidenote: There have been many discussions on removing reliance on 3rd parties altogether. I’d like to focus here on parallel short-term mitigations, i.e. ‘how to keep the app usable’ if a service is blocked
Objective
Make the app safely, accessible and discoverable to as many people as possible, in a way that is future-proof and censorship resistant
Problem
Status’ mobile app distribution relies on Google Play store and App store reviews. While an apk is also provided on status.im, this is not a catch all solution for the risks outlined below and does not necessarily meet the objective discoverability.
A strong mitigation for the risks below, is to explore alternative means of distributing the app that are safe, accessible and discoverable.
Risks
There are different scenarios that (can) lead to inability to access Status; each might need a different mitigation:
The app being rejected, removed or getting suspended from App store or Play store
Currently done. Doesn’t meet easily discover requirement for those not familiar with Status, requires organic search optimization. Platform like App Search might help for as long as APK is available
Reduce risk of getting rejected/removed/suspended (Mitigates 1)
These options were discussed during Core dev call 31, mostly in response to these sections of the app store policy
Release without browser on iOS
Depending on problem, remove some dapps? Would be weird. How to select?
Sideloading. Not super realistic
Remove front page dapps entry
Contract calls to e.g. Uniswap through Chat API (Implies custom integrations for every dapp)
Amazon resolves this by purchasing through webbrowser to buy
Release through Testflight (targets 1)
Offer Status through F-droid (Mitigates 1, 2, 3, 4)
@jakubgs can you explain what is required to do this? I’ve understood it’s not straightforward
Offer Status through a Play store client (Mitigates 2, 3, 4)
e.g. Aurora or Yalp store
Provides users more privacy when installing, but still requires submitting to Play Store
F-Droid is a bit of a pain because we have to use their own weird way of building the application and considering our unusual Nix setup it requires understanding F-Droid’s way of doing things on a deeper level than most apps would require. Once I finish work on MacOS application signing and Linux CI builds for desktop app I’ll focus on F-Droid because I’ve been neglecting it.
See this response to my post on F-Droid forum to my queries:
Which suggests that this will be much more of a pain normally.
So the goal I set for @petty was that I wanted Status to no longer distribute binaries by the end of the year. In other words, Status should only produce code under free speech.
What I was envisioning was that of a launcher app that handles updates and allows the user to choose binaries. This is similar to how many games and game engines handle their updates. Another way to look at it is as our own “app store”, since they are functionally analogous.
The launcher approach is good because it’s focused, the app store approach is good because it allows for more participation. Both run the risk of relegating us to moderation, meaning this is a feature that needs to be a decentralised ‘market’ of users and publishers.
A in-app update approach has issues as it doesn’t solve distributing the original binary, which becomes a problem as iirc Google does not allow apps to self-update if distributed through Google Play.
The idea is more about creating a spiritual successor to the idea behind the Cryptoeconomic Release & Version Control rather than how we handle distribution, because us handling distribution of the app should be a moot point for us, and rather it should be a community concern which is reflected in binaries that the community chooses to build and publish, and what users binaries users choose to run.
Realizing this ideal allows us to focus on creating software designs unhindered, while also becoming flexible enough for the community to create per-market adaptations of the software, without our intervention.
This is an important concept to get because it fundamentally changes the perspective and nullifies the proposed solutions in this thread, particularly with “Reduce risk of getting rejected/removed/suspended” section as almost all these imply a decision on our part, a decision that the user should be making either by building it themselves, or by choosing community generated binaries suitable for their own constraints.
At the current stage this should be a purely technical pursuit lead by Corey and shouldn’t involve Design or Core as they need to be focused entirely on growth and v1.5.
…