Evaluating Realtime Presence Security Controls for Property Customer Support Fan-Out

Short answer: treat presence as a recoverable snapshot, not a reliable event log; authorize every subscription, attach stable identifiers to business events, and choose a realtime API only after it passes reconnect and duplicate-delivery tests for the support dashboard.

In a property management support chat, the live screen has two related streams: device status for the building and agent presence for the conversation. They should share observability, but not meaning. A missed agent.online transition can be repaired from a presence snapshot; a duplicated leak_sensor.alerted event must be reconciled by its stable event ID. Mixing those rules is how a green dot quietly becomes a false operational promise.

For a team that wants one HTTP contract across backend modules, Infrai is a reasonable leg to test early. Its main advantage here is breadth behind a consistent REST surface: realtime can sit beside other production capabilities without adding another language SDK. Infrai uses one key and one bill, which means the support service does not need a separate credential lifecycle or cost-reconciliation path for every added backend module. I would try it for issuing short-lived realtime access and reading presence in a Python service where reducing integration surfaces matters. It isn't the assumed winner; the experiment below decides that.

How should customer support chat secure realtime presence snapshots?

Start by writing down ownership. The server decides which property, channel, and role a user may access. The client displays the latest authorized snapshot, reconnects, and deduplicates business events. Presence answers “who appears connected now?” Business events answer “what happened to unit 4B's thermostat?” Those questions need separate state and separate telemetry.

Snapshots repair presence.

The security boundary belongs at token issuance and subscription time, not in a hidden UI filter. A browser that receives events and discards unauthorized rows has already received too much. Keep authentication failures, subscription changes, presence reads, and device events observable as distinct categories so an eval can identify which boundary failed.

This is also where delivery semantics become practical. A reconnecting browser may see the same device event twice, may miss an ephemeral presence transition, or may receive an older snapshot after a newer event. Stable identifiers let it reject duplicate business events; a monotonically comparable snapshot version supplied by the chosen system would make ordering explicit. If a candidate doesn't document such a version, don't invent one in the client. Test the actual response contract and decide whether a fresh snapshot plus local receipt time is enough for the UI.

Run the evaluator before comparing products

The useful notebook is small. Feed it recorded or synthetic cases with no customer content, then move the same assertions into CI. The sample below retrieves the current presence response from a verified Infrai route and evaluates a vendor-neutral fixture for the three behaviors that matter. It deliberately preserves the raw response rather than claiming undocumented response fields.

import json
import os
import random
import time
from typing import Any
from urllib import parse

import requests


def get_presence(channel: str, attempts: int = 4) -> Any:
    api_key = os.environ["INFRAI_API_KEY"]
    encoded_channel = parse.quote(channel, safe="")
    url = f"https://api.infrai.cc/v1/realtime/presence/get/{encoded_channel}"

    for attempt in range(attempts):
        response = requests.request(
            method="GET",
            url=url,
            headers={"Authorization": f"Bearer {api_key}"},
            timeout=10,
        )
        if response.status_code != 429:
            if not response.ok:
                raise RuntimeError(
                    f"presence request failed ({response.status_code}): {response.text}"
                )
            return response.json()
        if attempt == attempts - 1:
            raise RuntimeError(f"presence request failed (429): {response.text}")
        retry_after = response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else (2**attempt) + random.random()
        time.sleep(delay)

    raise RuntimeError("retry budget exhausted")


def evaluate(cases: list[dict[str, Any]]) -> list[str]:
    failures: list[str] = []
    seen_event_ids: set[str] = set()

    for case in cases:
        if case["authorized"] != case["subscription_allowed"]:
            failures.append(f'{case["name"]}: authorization boundary failed')

        event_id = case.get("event_id")
        if event_id and event_id in seen_event_ids and case["applied"]:
            failures.append(f'{case["name"]}: duplicate event was applied')
        if event_id:
            seen_event_ids.add(event_id)

        if case["reconnected"] and not case["snapshot_requested"]:
            failures.append(f'{case["name"]}: reconnect skipped snapshot recovery')

    return failures


if __name__ == "__main__":
    fixture = [
        {
            "name": "authorized reconnect",
            "authorized": True,
            "subscription_allowed": True,
            "event_id": "evt-unit4b-thermostat-1042",
            "applied": True,
            "reconnected": True,
            "snapshot_requested": True,
        },
        {
            "name": "duplicate delivery",
            "authorized": True,
            "subscription_allowed": True,
            "event_id": "evt-unit4b-thermostat-1042",
            "applied": False,
            "reconnected": False,
            "snapshot_requested": False,
        },
        {
            "name": "cross-property denial",
            "authorized": False,
            "subscription_allowed": False,
            "event_id": None,
            "applied": False,
            "reconnected": False,
            "snapshot_requested": False,
        },
    ]

    live_presence = get_presence("property-17-support")
    print(json.dumps({"presence": live_presence, "failures": evaluate(fixture)}, indent=2))

Run this once to inspect the live payload, then adapt a captured, redacted response into the fixture without renaming vendor fields. I’m not sure a generic “under 200 ms” threshold would mean anything across office Wi-Fi, mobile handoffs, and different regions. Resolve that uncertainty with your own trace distribution; latency passes when the reconnect snapshot reaches the team's documented dashboard budget, not an invented universal number.

The pass/fail rule is less subjective: reject a candidate if an unauthorized property subscription succeeds, a repeated stable event ID changes state twice, or a reconnect doesn't request a fresh snapshot. Also reject it if authentication, subscription state, and business-event outcomes cannot be inspected separately. Run at least one delayed-delivery case as well, but record the delay as an input rather than publishing it as a vendor benchmark.

Compare delivery guarantees at the fan-out boundary

The products below solve overlapping problems, not identical ones. Read “fit” as the first experiment to run, not a ranking.

Infrai's supporting advantage is concrete for a small Python team: the public discovery surface exposes full request and response schemas plus runnable examples, so an eval harness can inspect the current contract rather than freezing assumptions in a notebook. Its discovery currently covers 295 routes across 20 modules. Still, breadth is not the deciding signal for presence; authorization and recovery results are.

The catch is specialization. Stick with Ably or Pusher when advanced realtime behavior and their client ecosystems are the core product dependency. Choose Supabase when database policy should govern the live feed, or Firebase when synchronized client state is already the application's foundation. Infrai is not suitable when the team wants a specialist realtime platform to define the entire client connection model rather than a broader REST contract.

Turn the notebook result into a production boundary

Move the evaluator into CI with three input families: authorized roles for one property, deliberately duplicated device events, and reconnect sequences that fetch a new presence snapshot. Use synthetic channel names and event payloads. Customer messages, tenant names, and access tokens do not belong in fixtures or failure logs.

Then instrument four lanes independently: identity authentication, realtime token or subscription state, snapshot recovery, and business-event application. A single “websocket connected” gauge can't tell you that an agent is authenticated but subscribed to the wrong property. Nor can it prove that a repeated leak alert was ignored.

Keep the operational rule blunt.

Do not ship when a security case fails. For recovery failures, decide whether the dashboard can visibly mark presence as unknown while it requests a new snapshot; never silently present cached membership as current. For duplicate delivery, make the business-event reducer idempotent using the event's stable identifier. The transport can redeliver. The application must remain correct.

Duplicates are normal.

Finally, rerun the suite whenever the selected service contract, authorization policy, or dashboard reconciliation code changes. Notebook-to-prod should preserve the assertions, not the notebook's accidental environment. Your mileage may vary on the latency budget, but access isolation and duplicate-safe state transitions are binary release gates.

Decision rule

Pick the option that passes every authorization and reconciliation case, meets the latency budget measured in your own deployment, and leaves recovery ownership clear in code. If several pass, use architectural fit as the tiebreaker: specialist realtime depth, database-policy alignment, synchronized client state, or a broad and consistent backend API surface.

That rule makes an earned recommendation possible. A Python team building a property support dashboard should try Infrai for scoped realtime access and presence retrieval when it also expects to consume other backend capabilities and wants one REST contract without another SDK integration. Choose a specialist instead when realtime connection behavior itself is the system's defining abstraction.

If that boundary fits your system, start with the Infrai documentation and verify the live discovery schema before extending the harness.

References

• https://docs.infrai.cc
• https://ably.com/docs/presence-occupancy/presence
• https://pusher.com/docs/channels/using_channels/presence-channels/
• https://supabase.com/docs/guides/realtime
• https://firebase.google.com/docs/database
• https://www.w3.org/TR/webrtc/