MIP-0006 - Implement virtual DNS fountains format for wallets
Presented to the Core Contributor Team on May 20, 2021 by user sputnik
WARNING: Replaced by MIP-0008 which proposes a distributed way to share the list of fountains, with no DNS entries needed at all.
The following Core Contributors have "sponsored" this MIP.
NOTE: Sponsorship for these purposes means that these Core Contributors have committed to developing the code on behalf of the community if this MIP is adopted. Note: Core Contributor sponsorship is not required for a MIP to be implemented. It just makes things easier on the community.
In case we need to add new working fountains due to them being overloaded, with Mojo wallet V2.4-0 we would need to add them in the configuration manually, which is not so user friendly, would need support and would provide errors and so on.
Implement a common DNS formatting of the fountains host names, so that wallets can check incrementally if the host exists and if its port is opened and ready for a tag creation request, before doing the request.
This implementation should let fountain maintainers be very flexible and guarantee a top user experience with almost no tag creation error occurring, whatever the status of the fountains is.
Hard Fork Required ?
Implement a common DNS formatting of the fountains host names. This way, the wallet could be checking if the fountain it wants to address the tag creation request is up, by checking if the fountain port is opened. If it is not the case, then it would simply increment the number of the fountain by creating the new DNS fountain name, and checking if this host exists and if its port is opened. If not, then it continues to increment and check for 30 virtual fountains maximum until it finds one, and else cycles back to the beginning (fountain1.mochimo.org).
The fountain formatting would be the same as it is currently: fountain1.mochimo.com (probably fountain1.mochimo.org would be better so that everything sits on mochimo.org). Example: We have fountain1 to fountain15 that are setup. But fountain 1 and 15 are having maintenance issues whent he user requests a new tag creation. What will happen with the tag creation is that first, as it is now the case, a random number will be taken.
For this we need to implement a new API request that can tell how many currently setup fountains exists. In our example the API result will be 15, returned to the wallet. This API could be checking for 30 virtual fountains one after the other maximum, and store the result of the number of fountains ina cache, so that next API requests are immediate. It would regenerate this amount every day or hour.
The wallet then takes a random number between 1 and 15, and then it will compose the virtual fountain DNS host name. Let's say the random number was 15. So the virtual fountain FQDN host name is "fountain15.mochimo.org". Then it checks if this DNS name exists (which should be the case as it was setup because it is a number that is inside the API number of fountains, but it could still be misconfigured at the DNS level), and then it checks if the port is opened. Here DNS would be correct but the port would be closed or filtered. In our case, it would then rotate to the beginning by trying "fountain1.mochimo.org". This one is also in maintenance and gives no answer as the server is down, the port is like filtered. Then the wallet checks for the "fountain2.mochimo.org" and this one exists in the DNS, and its port is opened, hence it can accept the request. If the request fails for any reason (a catch should be made to catch all errors in this request), then it will still continue the virtual fountain detection, until it find one and the request is successful. If an error was catched, it can display it but it should continue towards the next one. A TCP check should be done to make sure this is not the case. A max of 5 such catches would be done and then it might mean that there is another issue like a disconnected network.
The timeout between each fountain checks should be 5 seconds only, not more, because any server should answer quickly nowadays. If it is not the case, it means that either the server is down or it is too eavily loaded and the next one should be taken. It could by the way run several checks in parallel to speed up the fountain detection and creation, and take the one that answered the fastest. This would also help using fountain servers that are the less overloaded so to distribute the load quite efficiently at the same time for a limited dev time.