utd_signaling 0.1.1

UTD-Stream signalling plane for Flutter: presence, 1:1 call invitations, chat messaging + groups, typing, push-token registration and media-upload presign over the engine WebSocket + REST. No media, n [...]

0.1.1

Capability surfacing on the session mint (additive, non-breaking).

• The session mint (POST /api/v1/auth/session) now parses the two independent, separately-billed capability flags and the plan limits when the engine surfaces them:
  • UTDTokenResponse.signalingEnabled / .chatEnabled — nullable bools; null when the engine omits them (older engine → "unknown, let the server decide"), distinct from an explicit false.
  • New UTDPlanLimits model (historyDays, maxGroupMembers, maxFriends, maxChatrooms) parsed defensively from the limits object; every field is nullable and tolerates missing/varying wire types. Exported via models.
• UTDApi.mintSession() now returns those flags + limits on its result record (additive named fields — the leading userToken/wsUrl are unchanged, so existing callers keep working).
• UTDSignaling exposes signalingEnabled / chatEnabled / planLimits getters (captured on every (re)connect) so app code can pre-check a capability before starting a call or enforce plan caps for UX.
• Error handling for a paid-capability gate: a non-ban 403 whose message says a capability is "not enabled/available/disabled" is mapped to the new UTDErrorCode.featureDisabled, surfaced via UTDStreamException.isFeatureDisabled (+ isSignalingDisabled / isChatDisabled). isForbidden still returns true for it, so existing "not activated" handling is unchanged — callers can now branch to show an upsell instead of a raw failure.
• New parsing helper boolOrNull (internal).

Billing model: signaling (call invitation + presence + rooms/broadcast, gated by the engine signaling_enabled) and chat (persistent messaging + history + receipts, gated by messaging_enabled) are two separate paid capabilities, each sold via a subscription plan (Free / Signaling / Pro / Enterprise) with per-plan limits. Billing is MAU-based — there is no per-message charge.

0.1.0

• Initial extraction of the shared signalling plane from the kits: REST client, signalling WebSocket, device id/facts, connection lifecycle, uploads, push-token API, and the shared wire models. No media, no UI, no local storage.