What I am proposing may not stand up technically and could be riddled with attack vectors. (Sorry Corey)
The purpose of this post is for us to open a discussion around a feature in OS or a Light Client for ‘mass’ on boarding into the Status Mobile App without the possibility of an App Store or WIFI connection.
In many countries people are not as privileged as we are with technology. There may be no infrastructure for internet. But many people could benefit from our applications. This shouldn’t stop us and I think there lies great potential in mass adoption.
If one of us should visit somewhere and want to empower someone or a group with our mobile application, how could we do that with only our phone? I believe it would do a world of good if I could onboard someone or a crowd of people from one access point. Why can’t I be an ‘App Store’ for the people around me?
Is it possible that we have ‘Core Nodes’ that are trusted users to transmit out and onboard anyone into Status with a phone? We could connect with people through bluetooth or a mesh network? If we have mesh network, users can download Status from a mesh network.
A smaller app could also be installed allowing .apk packages to be sent through bluetooth (Android)
Imagine on boarding a crowd of people all at once onto Status instantly. Can we do this? Thoughts?
First off, I love the idea of spreading the use of Status without the requirement of app stores. This comes with its difficulties though, as well as points to things we’ve just touched on in the recent principles marathons. I’ll try and itemize them now:
Something like this would need to live at the peer connection level, and then be enabled at the communication level.
Furthermore, in order for people to receive an apk or whatever they’d need to participate, we’d need an official build source to share to them (hosting and what not issues here), and then a means to distribute that channel through the peer connection level. This points to the deterministic build endeavors that are currently underway, so people could verify they’re getting a proper version of Status.
In the recent principles marathon discussion, we talked about the need to specify the “status protocol” vs an implementation of it. All of the previous points scream this, as it would potentially offload some of the burden of us to provide everything, and give people a more intuitive place to jump off at to do something like this.
As for trusted nodes, I think we are currently working on something in this area as well.
I feel as though @adam (among many others) would have a lot of input into some technicalities here, or feasibility. As for security:
If this were only a communication app, then it wouldn’t be as bad, but since Status holds funds, and provides an interface to exchanging those funds with other people, it is more difficult, as you’d have to be sure they’re getting a “properly behaving implementation” of the Status protocol, whatever that is. Otherwise you could just easily spread malicious versions to unknowing people.
What that “trust” looks like needs to be explicit, so people can understand what they’re potentially offloading to an individual (keys, routing, metadata, txn signing, etc). The answers to that question give rise to many other questions of what people can take advantage of.
Maybe an initial implementation of this would be the mesh network infrastructure, then allow a sub-app of status that was maybe only whisper comms to allow them to coordinate and communicate. Then, it could be steadily expanded in feature set as it was evaluated.
@petty Thanks for this. I just learned that @boris and @eugene were also researching this and believe they are working with two mesh network companies at the Hackathon. This is really exciting.
That would be Right Mesh https://rightmesh.io/ – I am an advisor and they are working on a micro-raiden implementation and are here in the Vancouver area.
Their team will be in Prague, not sure if they are coming early. I will point them at this and see. Other than this thread, who is the best person to connect RightMesh on the topic of Status + RightMesh proof of concept / user research in Uganda, Algeria, Bangladesh?
No app stores
That’s a long complicated discussion. Fortnite is going direct to APK. I think educating people on Android on verifying APKs is a good general literacy skill, much like desktop downloads.
I even had some thoughts about what an iOS Enterprise build of Status would look like, for certain markets and groups.
People as in person onboarding
Firefox go distributed by people going home at Thanksgiving (in the US) and putting it on parental computers. And school computers. And library computers.
I have personally onboarded close to 100 people mainly with Trust Wallet – because it supports my experimental BorisCoin as an arbitrary ERC20 token. Would love that to be Status – that probably means having a BorisCoin dapp or similar.
How can Status have simple use cases that gets people onboarded in person, phone to phone? And how can the app get on people’s phones without a central app store? Related but separate, as downloading from “official” app stores may be easiest initially … EXCEPT for areas where bandwidth is expensive!
Just to clarify, I think a “Light Client” here is referring to an application, and not to any kind of Light Ethereum Service (LES) or Ethereum Ultra Light Clients (ULC), which are speaking about running a node locally.
For developing countries, we need to re-write the app from ground up.
Opera, Twitter, Spotify and other companies have separate light applications for these markets for a reason. A fully native Status for Android or iOS apps can be < 10 MB in the installer size (taking into account that it will only run as a thin RPC client, maybe running an Ethereum node will take more traffic).
Also, one more important point there is traffic consumption in general. So far, most of the DApps I have seen are overbloated, which is understandable, because that is the state of the modern (javascript) development at the moment. But that might be tricky in the countries where traffic is expensive.
Just a side technical note: countries, that don’t have decent internet connection in rural areas (say, Kenya) adopt USSD and sim card menus as one of the main sources of interaction with their mobile wallets (and MPesa is huge in Kenya, much bigger than any of the card providers or anything).
If we want to proceed in this direction, I’m all up to help
The app however itself is just a small piece of the puzzle.
The bigger piece is the fact that Ethereum is a global central database that the app is tied to, with ongoing “online” demands - it’s simply not useful in a partial connectivity setting. To unshackle ourselves from there, we’d have to make some fair investments - for example in payment channels or side chains, where you meaningfully can get by without internet connectivity for some time and then “sync up” occasionally.
Having a meaningful offline capability is a direction I’d like to advocate for, for many reasons - starting with the chat - log-based comms are one way to get closer to there, but there are others as well - mesh networking, etc. These are all things things increase your powers to withstand censorship, coercion and bottlenecks, because they give you control over when you communicate - they also allow many small intermediaries to provide meaningful service, as opposed to restricting it to big actors due to a high barrier of entry.
