What architecture/design pattern for sharing data between several people, without centralization?

Question

Let's say my software lets you place a square on the map and say "This is a good place to find Pokemon". I need this data to go to my gym leader's map, and to my friend's copy of Pokemon Go (through their API). If my gym leader moves the square to the east, his copy of the software needs to tell my copy about the new map data, and I need to update my copy of the map and tell my friend to update their copy of the map.

I want to know, what is the abstract problem I'm trying to solve? What concept do I need to Google here? I tried terms like "Distributed computing", but got stuff like map-reduce.

Should I look at something peer-to-peer like BitTorrent, even though I'm just sharing little bits of data and not files or chats? Or something like Change Data Capture or a Source Of Truth/System of Record architecture?

Approaches I rejected:

• The naive approach would just be to say "Whenever I update data, send a message to my gym leader and friend". I just feel like this is overlooking issues of eventual consistency, out of order delivery, what if my gym leader sends me an update to the same thing while mine is on the way, and so on.
• I can't just use a centralized data store server or enterprise service bus. It's been decided.
• Advice about sharing data between microservices doesn't seem like it should apply to me, especially when talking about two computers running the exact same software that are just trying to keep their data in sync.

Answer 1

This sounds like a very simplified blockchain approach might be usable. If the information you're sharing isn't especially valuable and participants don't have an incentive to cheat, consensus should be reachable by simple comparison of event timestamps. You also don't seem to have complex interaction between different pieces of information (such as crypto currency transactions) so each piece of information can essentially have a separate history, and to know the current state of a piece you only need to agree on the events related to it.

When two participants edit a piece concurrently (i.e. both starting at the same state) you need a conflict resolution to decide how the item appears after both events. There are many options (first change wins, last change wins, fields are merged, etc.) and you need to decide which is best suited for your application.

There are lots of details to be filled in (how to create item IDs, do users have public keys to sign their messages, will all information shared throughout the network or just between interested participants) but these all need to be decided in the context of your application.