It is possible to set up a presence webhook, and, using webhook events (or some other Reactor output — amqp messages, Reactor functions, etc.), maintain your own copy of the presence set. But for a few reasons, it would not work very well, and we do not recommend it.
The main reason is that there is no synchronization mechanism. If the recipient server goes down or fails to process a message, you will then be permanently out of sync, and you will not know it.
Ably will retry a webhook if we notice it has been rejected (timed out or has a non-2xx status code), but only within limits: sufficiently old messages that have been retried a few times will be discarded, and there are limits on e.g. the number of messages per post body and the total number of messages per second you can send through webhooks. (Capping or limiting is logged to the log channel, and so visible to you if you are watching the dev console or have any rules set on the log channel).
Something like Reactor queues improve on webhooks in a few ways. The consumer can ack a message only once it has processed it, and if the consumer dies, unacked messages will be requeued, which makes it significantly more reliable than webhooks. See our blog post on this for more.
But ultimately, while a message queue is better than a webhook, it still has no synchronization mechanism.
Another reason is that building presence events into a presence set is not completely trivial to implement. There is a detailed protocol that must be followed to correctly merge events into the presence set, designed so that (for example) events can commute (be applied in any order), synthetic leave events are treated correctly, members are identified by both clientId and connectionId, and so on. Our client libraries handle this for you, and are backed up by rigorous test suites.
Our realtime client libraries have a built-in synchronization protocol (either client or server can initiate a sync of the presence set at any time if there is a loss of channel continuity), ensuring that the presence set you see is synced and up to date at all times the client library is connected. That is a level of battle-tested reliability that is not available by maintaining a presence set using a Reactor rule.
So if you need an always-up-to-date copy of a presence set, our strong recommendation is that you use one of our Realtime client libraries and attach to that channel.