I’m not really sure why we keep 30 days (https://github.com/status-im/infra-eth-cluster/blob/c6a847fefa7267a731ac1e0eee638fdad2c6be00/ansible/roles/statusd-mailsrv/defaults/main.yml#L57) since we only ever fetch 24h in the mobile app.
@roman is working on more fetching atm… we will be able to fetch (with user interaction) more data in 24h chunks.
Right, I recall #7961 that was closed. Didn’t know the work continued, cool.
Not really. We still have many other things that we would want even if we get rid of the cluster, like:
- Jenkins CI master and slaves(linux and macos) for building the app
- Ropsten & Rinkeby Faucets necessary for testing
- Nimbus test & research fleet
- Ghost instances
- universal-links-handler for redirecting to Status contacts
- Other fleets like swarm, proxies(ipfs), sites like this one - https://discuss.status.im/ - or https://notes.status.im
- All the monitoring infrastructure for the above mentioned
So no, our main cluster is just part of our infra.
It’s a great idea and a very important line of thinking. Not only out of principle, but for this reason:
I argue that who cares if we have an app in the main store if it doesn’t have a resilient network to support it. If we get a massive on-ramp of people who want to know how to run their own node, and we can’t on-board them quickly to the right way of doing it, when we’ve failed.
Beginning to think about our go-to market strategy and we use 100k users as a milestone. Do we know if our cluster could support that many people, in the optimistic scenario that a significant number of them used Status daily?
I’d love to see data on what the current cluster can support, because this actually represents a risk in taking the app public. If we can estimate the node : user ratio required to support daily use, won’t we have a better sense for how much to invest in setting up core contributors? As well as how aggressively we can pursue user acquisition.
The teach a man to fish ethos embedded in this post is a nice mentality for onboarding additional node hosts.
Though the idea as it’s expressed sounds almost totally win-win, I’m sure there’s considerable effort to realizing it.
I personally think investment of design & core UI resources to scale those efforts should be conservative at first. We won’t have an overload problem if the app is unpleasant to use.
We do need to be self sufficient, and as CCs, knowledgeable about this critical function. Just not at the cost of too much of too many of our people’s time right now.
6 Likes