There is one advantage to the design: only the salt has to be synced, and only once. This means that you can transfer it securely, and you don't need to sync your password database, ever (which means there's not even a third party involved).
Something like this could actually help backport a limited form of two factor auth (something I know: password + something I have: salt) to single-password systems.
That's of course barring the crypto issues this algorithm has (see comment by
anon081312) but maybe things could be improved on that front (not that I want to 'roll my own', but maybe this function could be designed better, and reviewed)
In the instance of this particular algorithm, the salt must be kept secret, because it is the only unknown in the process from an attackers point of view.
Fair enough, but then the "salt" is not really a "salt" anymore as that term is known from "password salt", because it is no longer a random input value unique to each different password. It is simply a piece of known-plaintext input for every "hashing" session.
I am ignoring the fact that in a general sense an attacker with resources to obtain the salt can also likely log the master password, in which case no attack against the algorithm is necessary.
Something like this could actually help backport a limited form of two factor auth (something I know: password + something I have: salt) to single-password systems.
That's of course barring the crypto issues this algorithm has (see comment by anon081312) but maybe things could be improved on that front (not that I want to 'roll my own', but maybe this function could be designed better, and reviewed)