For the filesystem API, I believe the way that worked before is that you would fix up "the" file however you liked, and then delete all the relevant conflict-marker files.

(On a local scan, we could notice this situation: the database says "foo" is conflicted, but there are [no longer] any conflict-markers for it -- so we take all the conflicting remotes, produce a new Snapshot with them as parents etc etc)

The HTTP API design is somewhat easier: we make an endpoint that declares "here is a resolution for the conflict on foo" -- which I would propose at first takes a single revision, e.g. ours or theirs=participant-name. Then all the content of that Snapshot is considered the resolution.

We could introduce more args (or a different API) extension in the future to allow a more-complex resolution (e.g. "here are the bytes that constitute the resolution").