We've considered extending MobiLink for peer-to-peer (and variants) synchronization over the years, but haven't been sufficiently motivated. It is also a tricky problem with many different approaches and possible contraints. It comes up once in a while in both internal and customer discussions. Technical proposals have been made but I am not aware of any working implementations.

Peer-to-peer is designed to avoid centralization, ie. the one true consolidated database. Fundamentally, though, MobiLink requires a consolidated database to store remote progress offsets on a per subscription basis. Once you start decentralizing, then all your nodes need to track state, but since they are not always in communication, they all have different states, and it can get complicated, or at least very inefficient.

Consider, for example, a system with every node having a consolidated database, and every other node having a subscription to that consolidated database. In this system, if node B downloads all of node A's changes, then node C synchronizes with node B, then node C will get all of node A's changes, but if node A synchronizes with node C, what is to keep it from getting all the original changes back again? That may not be a problem, per se, but it would definitely be inefficient. Preventing it means assigning and tracking A's creation/ownership of the rows. There are cases when even this approach can cause redundant transfer of rows.

To make a long story short, I do think peer-to-peer with MobiLink is possible. The simplest implementations would likely cause (a) lots of redundant row transfers, and (b) transaction logs to accumulate without truncation. That may be good enough for some. The complexity increases as you work harder to diminish or eliminate redundant row transfers -- assuming the latter is even possible.