When it comes to proposal itself, I think that it would be better if you could focus on one location not whole cluster to be like that.
It will be way cheaper to focus on bulletproof bare metal owned server somewhere close to you, then relay on supporting infrastructure of big, grumpy, but also cheap guys.
With that, using similar budget there could be few independent providers, otherwise people will get lazy that your fancy cluster "just works" and scale up, which actually will contribute to centralization of such service.
(I think similar discussion took place with anyx proposal back in the days)
You are viewing a single comment's thread from:
I have said it in my previous proposal and can also say it in this one. I would be more than willing to help anyone who would like to start their own API nodes as well as their own clusters. The current EU cluster that I have is pretty much bulletproof and has been serving for the past two or almost three years. The average user on Hive does not care about the cluster or the node. All they care about is whether or not their transactions are getting through, and it feels fast and responsive. Despite being fast machines on their own, the network latency does add a feeling of things being "slow".
OVH's data center burned down. Even the most reliable/well-known data center could not become "bulletproof" enough. Right now, I am also utilizing Hetzner with my cluster. Because it is impossible to beat that price performance ratio. Despite being "bulletproof" for two years, there is no guarantee that it will continue to do so in the next two years.
Furthermore, at the moment, all Hive has is OVH and Hetzner. More than 90% of the public nodes are either in Hetzner or OVH. Unfortunately, centralization does not only come in the "node operator" aspect, but also the provider. Especially when one of the providers had their data centre burned down and the other one announced that they are anti-cryptocurrency nodes in the last few months.
Been there, done that. And of course you are 100% right.
It's just that I prefer bigger set of reliable nodes than a smaller set of high performance clusters. Of course both are needed, but spending money wisely, I would rather say that it's up to the dapps, so when they scale up, they also contribute to a decentralized infrastructure. That way it will grow organically with the projects themselves.
I wholeheartedly agree. dApps themselves having their own nodes, or even clusters, preferably in different parts of the world, would definitely be the way to go. But unfortunately, not everyone has the expertise (even though there's help), the funding to cover the costs (even though overall requirements went down in the last two HFs), nor the willingness to handle such an undertaking. If the proposal gets funded, the end goal is to have more nodes in more parts of the world, serving different populations.
In all honesty, the proposal itself is simply a case of:
I also think, choosing one location/continent where we lack enough servers would be better way to go. api.hive.blog is mostly US based, right, so api.deathwing.me could be Asia based and rpc.ecency.com or others could be EU based, etc. Not necessarily run on same continent but have more prominent exposure there. That way, apps, services, know and direct traffic coming from those areas to those nodes for better performance.
I have to disagree, this would create confusion for users and potentially result in one operator going down, taking down the entire region with them for whatever reason. In an ideal world, as I have discussed with Gandalf, we would have individual node operators operating their own nodes worldwide. Not having to rely on @blocktrades, myself or @ecency. But unfortunately, it is something that not many people are willing to undertake.
I didn’t say do entire region only, used prominent word. And users confusion part is not related, people don’t use RPC or at least they shouldn’t worry about them, services and apps should handle that so they don’t have to. Yes, ideally every service or app having their own instance.