Can anyone point me to patterns for, or material on decentralised federated system design / federated data/service architectures?
To give some more background on the problem I'm looking to solve, here's the full context. I've had an idea floating around for a while to create a "reverse address book". i.e. Rather than me having a list of all my friends, their phone numbers, addresses, birthdays, etc, I just take responsibility for managing my own address book entry. I can then connect to my friends to see their entries (or whatever parts of their entries they're happy to share with me). That way, if I move house or get a new phone number, I update my record and everyone I've given permission to see that information sees my record automatically updated in their address book.
The above is simple if we're talking about a single system... But this idea's big (i.e. it solves a lot of GDPR issues, it potentially means that I no longer have to contact 50 different companies when I move house to tell them I've moved, companies can save a fortune wasted trying to track down those who've not given them this information, etc.).
As such, it seems unreasonable to have one system which holds & controls all of this information. Security concerned users may want to run their own instance which holds their information; but still enable friends using the "status-quo implementation" to access their data. Alternatively, other companies may want to host their own flavours of such a system, so it's not a monopoly; but again we'd want users of any implementation of this solution to be able to see other users even if they're on a different implementation (in the same way you can use any email provider and still talk to friends on other mail providers).
Apologies that this is quite a loose question; I've tried searching but don't know enough terminology in this area to know the correct search terms, as all systems I've worked on to date have been centralised, or at most had a master database with multiple slaves, rather than being fully decentralised / federated.
I've come up with a few ideas on this for this:
Having a centralised register, but leaving everything else decentralised. So any system providing this functionality adds their URI to the register after which all systems can see it... However I don't like this solution as if possible I don't want any centralised dependency.
Have each implementation holding a list of approved providers (i.e. for any big companies hosting public solutions), and allowing users to add "ad-hoc providers" to their personal "trusted provider" lists to cater for special cases (e.g. friends running their own personal instances / companies running in house instances). Essentially a similar pattern to how SSL certificates are currently handled in browsers; i.e. the recognised CAs are provided by your browser's vendor (some of these lists being published for general usage), but you can always add your own CAs to your browser as the need arises.