Yes, there are plenty of people that would love to see this service provided by Chia. However, none of those people want to add one more problem on the top of what they have already. So, I am afraid that by promoting it here, you will only be considered as malware provider.
It is really easy to at least reach out to Chris from Flex pool but would assume that it takes no time to contact Space Pool as well. I would also go on github Discussion page, as Chia people read it (at least from time to time) and may contact you about it.
They provide bandwidth. So, one way of looking at that would be that Flex would generate one db a day (week still would be OK for me), and have one extra page with links to their download also providing the checksum (basically copy of what their page is right now, but hosted by you, and using their links). This way, the end user would know that Flex checksum has to match with what is being downloaded from their links. Maybe that would be the simplest solution if both of you would agree on that.
To me, that would be a legit solution.
I understand that people have concerns about db being poisoned, but as long as chia software is out of whack, having a legit download would do for me. Potentially, that could put a bit more pressure on Chia to clean up their side.
How much do you understand about blockchain db poisoning? This has nothing to do with a db being corrupted in a normal sense (e.g., broken tables). If it is poisoned, it will still work fine for you and of course others, but you may be spreading blockchain db that is basically altered.
That is the reason that db and hash should be provided by some authority that we “trust” not someone that just created his first post advertising such service. That is the reason that I asked for that partnership with someone like Space, Flex, …
If you read again what I wrote in reply to Chris, you will notice that I asked him to generate db and pass it to you. On the other hand, they will generate hash, and keep it. They will also host the download page that would have your links. This way, Flex controls both db and hash, but you only get db. The instructions provided by Flex would include steps to hash-validate what has been downloaded. The only tricky part (to some degree) is daily synchronization of link changes and respective hashes, what would be done with some simple REST API.
This way, there would be no chance to have such database being poisoned between say Flex generating them and the end user downloading them, and the trust level would be maintained by Flex.
I would suggest that you PM Chris to check whether Flex would be interested in this collaboration. I would also not wait, but jump on Space discord channel, to explore it there.
In my opinion, you both would earn a big credit from those that are currently screwed and are looking for such solution.
By the way, I think that adding that hash on your page is not really that helpful, as the problem is with trust, and you are just self-certifying that db. Kind of a nuisance, IMO.
They are the main reason of db corruption on chia exit (as they cannot properly synchronize all those processes to shutdown cleanly). They also run really lame synchronization (i.e., downloading db from one peer at a time - upstream bandwidth problems for a single peer). (Downloading that db took about 30mins for me, on the other hand, syncing takes 2+ days and that is by order of two magnitudes slower - if things go right.) So, when do you think they will have that test done? I am with you, and I would really love to have this solution work properly / safely.
I bet, the reason to so easily differentiate mainnet and testnet dbs is that either table names are different, or there is some marking in the “config” table, to prevent those dbs from jumping into production stream. And that is really similar to a file name check, nothing more than a dumb check.
It may be synced, but if someone altered it, and enough ppl used that altered data, the fear is, the history is re written, coins could start jumping from 1 wallet to another or a fork type event happen.