Interesting idea. A few thoughts:
The encryption key could be generated by the first device to be added to this mesh of devices. When a new device is added, any existing device will perform a new share split and the user has to copy these share tokens to every existing device as well as the new one. The same has to happen every time a device is removed. This could be cumbersome.
Each share token is locally encrypted with a master password that is fed through a KDF. Changing this password requires decrypting and re-encrypting each individual share on every device. This is also cumbersome.
It’s true that if k out of n shares are needed to reconstruct the secret, then losing access to n-k shares does not result in the data being lost. However if n is small or if k is badly chosen, the user may lose access to their data anyway.
When using a central server, or a set of distributed and replicated copies of a single payload, every copy of the data or the master password has to be lost in order to lose the data. In the case of Shamir’s Password Store, a user could feasibly remember the password but still lose data if they lose a few devices.
Perhaps a paper backup of the encryption key can be made, but it could be argued that this defeats the point of the protocol. Instead maybe k shares can be generated and stored in k different places, as a backup, but this is cumbersome.
The problems outlined in the Local password managers section don’t make much sense to me. A password manager that stores encrypted data on an untrusted server can use a derived encryption key to secure it. You can easily memorise a high-entropy password by selecting a sequence of random words from a dictionary. You can feed a low-entropy password to a good password KDF like Argon2id in order to make a brute-force attack infeasible. In essence, the key to decrypt the data does not have to be stored anywhere except for in your brain.
My gut feeling is that this design is over-complicated – although I’m probably biased, because I’m personally fine with trusting a hosted password manager.
One of the author’s requirements is that if a device is compromised, the attacker won’t gain anything useful. That’s a pretty tall order. What if a compromised device tricks the other devices into sending it secret shares? There are ways to defend against that (like the suggestion of 2FA) but now you have extra doors to lock, extra parts that could break in weird ways (what if a 2FA token is replayed?). And this is completely ignoring the fact that if your laptop/phone is the device that’s compromised, those devices are already receiving all the shares of the secret in the course of normal operation.
I think the pragmatic approach here is to just use a longer master password. 9-10 words from a passphrase-generation wordlist gives you 128 bits of entropy, and that’s without any key stretching (meaning your passphrase can be shorter than that without sacrificing security). Memorizing 9 words and running an existing open-source password manager is going to be a lot easier than setting up and maintaining a custom password-management network (albeit maybe less fun).