Glad you liked the presentation. One of the things I worked on in the past was iChat, including the Bonjour IM system, so I’m definitely interested in presence.
I think this is the better of the two approaches, but it’s still not ideal.
Problem 1: Lots of revisions, as you point out. The ForestDB storage in 1.1 handles this a lot better than the SQLite-based one does, because it proactively prunes old revisions when new ones are added. The default maxRevTreeDepth is 20, so at most 20 revisions of a doc will be kept around. But regardless of storage, the more frequently state is updated, the more replication traffic there will be.
Problem 2: When a device goes offline (app is backgrounded) it has to update its presence document, and then replicate it to other peers. But there are cases where that isn’t possible, like if the app moves out of range of the LAN or otherwise loses connectivity, or if the app crashes. The typical way around this is to put a timestamp on the presence document and give it a fairly short time-to-live, so that if the peer keeps updating it, they’re assumed to have gone offline. But now you have a conflict between timely notifications of offline state, vs. the number of updates. (If you have 20 peers each updating their state every minute, that’s an update every 3 seconds.)
If everyone’s on the same LAN, it works better to use Bonjour alone. That’s what iChat does. Your app’s published replication service is its presence. Bonjour is pretty good at keeping its state of the world up to date (well, in Yosemite it wasn’t, but apparently 10.10.4 fixed the regressions.)
—Jens