The model for presence revolves around contacts. You have a bunch of contacts, and you want to get their presence when you sign in, and if they signed-in after you did, then you get their presence at that point of time. That is, the programming model is a subscription model. The infrastructure automatically subscribes to the presence, capabilities and objects of a user's contacts. All API calls are simply local at that point (for instance, getting presence, capabilities, objects).

With People Near Me however, the model is a polling model. Since there can be a very large number of people on the same subnet, we do not automatically subscribe to everyone's capabilities and objects. Instead, we expose a method (RequestPublishedItems) for the developer to get the published items (capabilities, objects etc) on demand. Once this API is called, then all operations become local after that much like it is with presence. So, when dealing with people near me, this is an additional API to call for the people you are interested in getting more info from. Now, the API ends up keeping data for future callers as well. Consequently, if another application were to call PeerCollabEnumObjects, it will return the objects returned in a prior call to RequestPublishedItems.

Some APIs, by design, do not work for People Near Me. For instance, setting the endpoint name does not work, because it is automatically set to the machine name. If you want to get the endpoint name, you get that via the peer_collab_endpoints_near_me event. I'll keep this post updated with other APIs that will not work for one signin option vs another.