Now I know this goes against the grain of the peer-to-peer system, but in order for the API to be compatible with existing OSM tools, we need to only return a single fork of forked elements in requests, otherwise behaviour by tools will be unpredictable. We cannot guarantee that a client will end up with the same element for two identical requests, which can lead to all kind of trouble.
I think the best way to solve this is to make the p2p part "opt-in" by specifying a URL parameter forks=true. This was tools that are "p2p-aware" can add this param to get all forks.
To make this work we need the following (list probably incomplete):
[ ] When a client tries to update a forked element, throw a conflict error.
That last one is perhaps the most controversial, but I think it is the only way for legacy clients to work with the system without forks getting out of control. OSM already has the concept of conflicts - i.e. when another user updates an element between the user downloading and modifying an element. We should treat a fork in the same way: a user downloads the most recent fork, edits it, and the server responds with the second fork as if that was an edit that happened in conflict. The user is forced to resolve the conflict (i.e. merge the forks) before continuing. We can take advantage of existing merge tools in iD and JOSM this way.
Now I know this goes against the grain of the peer-to-peer system, but in order for the API to be compatible with existing OSM tools, we need to only return a single fork of forked elements in requests, otherwise behaviour by tools will be unpredictable. We cannot guarantee that a client will end up with the same element for two identical requests, which can lead to all kind of trouble.
I think the best way to solve this is to make the p2p part "opt-in" by specifying a URL parameter
forks=true. This was tools that are "p2p-aware" can add this param to get all forks.To make this work we need the following (list probably incomplete):
That last one is perhaps the most controversial, but I think it is the only way for legacy clients to work with the system without forks getting out of control. OSM already has the concept of conflicts - i.e. when another user updates an element between the user downloading and modifying an element. We should treat a fork in the same way: a user downloads the most recent fork, edits it, and the server responds with the second fork as if that was an edit that happened in conflict. The user is forced to resolve the conflict (i.e. merge the forks) before continuing. We can take advantage of existing merge tools in iD and JOSM this way.