Hotsock

website·Indexed 32 days ago

https://www.hotsock.io/docs

A private, infinitely scalable real-time WebSocket service deployed via AWS CloudFormation. It features JWT-based authentication, server-side message publishing via Lambda, presence channels, and message scheduling. The platform integrates with AWS EventBridge, SNS, CloudWatch Logs, and DynamoDB for scaling and event notifications.

Tokens
40.3K
Snippets
156
Records
304
Agent score
60%

What's inside Hotsock

  1. Overview of Hotsock WebSockets service

    Hotsock is a fully-managed, standalone WebSockets service that deploys private resources directly into your own AWS account. It is designed for developing real-time experiences in web and mobile applications using a serverless architecture. Because it is deployed in your account, you own all the data and the service is bound by your own AWS policies. The installation is fully automated via AWS CloudFormation and utilizes the following AWS services: API Gateway, Lambda, EventBridge, SQS, SNS, and DynamoDB.
  2. Overview of Hotsock WebSocket Service

    Hotsock is a fully-managed, standalone WebSockets service that deploys private resources directly into your own AWS account. It is entirely serverless, meaning there are no servers or containers to manage, and it scales automatically using a pay-as-you-go model. Because it resides in your AWS account, you maintain full ownership and control over your data and security policies.
  3. Overview of Hotsock Channel Storage

    Channel storage provides persistent, per-key state (key-value pairs) that lives alongside a channel and survives disconnects. It is designed for state that should be immediately available to anyone joining a channel, such as room settings, shared cursors, feature flags, user status, or the last known state of a value. It is not a general-purpose database; each entry is a single key with a JSON value scoped to a channel. For ordered, append-only data like chat history, use message storage instead.
  4. Define user metadata with the umd claim

    The umd claim allows storing up to 1 KiB of JSON data (object, array, string, number, boolean, or null) about the connected user. This metadata is shared with other members in presence channels and included in all published messages initiated by the connection. Binary data must be Base64-encoded.
    {
      "umd": {
        "name": "Dwight",
        "title": "Assistant To The Regional Manager"
      }
    }
  5. Implement message reactions in Hotsock v1.13

    Hotsock v1.13 introduces native support for message reactions, allowing users to attach reactions to messages within the platform.
  6. Hotsock installation stability and maintenance expectations

    Hotsock is designed for high stability and minimal maintenance. Key operational expectations include:

    • Maintenance: v1.x installations can run for years without manual maintenance. Automatic updates are enabled by default to provide security patches and bug fixes.
    • Availability: There are no long-running processes requiring restarts and no backing services requiring scheduled maintenance. Installations are self-healing following AWS service outages.
    • Updates: Updates are designed to keep existing WebSocket connections alive and messages processing. They should not break existing application behavior unless a security vulnerability or critical bug necessitates a change.
    • Key Rotation: JWT signing keys and backend Hotsock API keys can be rotated with zero downtime.
    • Compatibility: Future compatibility is based on documented interfaces. However, Hotsock-internal SNS events and CloudWatch Log shapes may change between minor versions and are not considered public APIs.
  7. Use message reactions and presence member events in Hotsock v1.13

    Hotsock v1.13 adds support for message reactions and presence member events delivered via pub/sub integrations such as AWS SNS and Amazon EventBridge.
  8. Understand the Hotsock Installer Permissions Stack

    The Installer Permissions stack must be deployed before the main Hotsock stack. It establishes a permissions boundary to ensure that roles created by the main stack cannot elevate their own permissions.

    Key components include:

    • HotsockInstallerRole: Allows CloudFormation to manage installations within the /hotsock/ IAM path.
    • HotsockSupportRole: Allows Hotsock support staff access for troubleshooting (denied by default; requires a future date in the trust relationship to enable).
    • HotsockLicensingRole: Handles licensing operations and usage metering.
    • HotsockMaximumPermissions: An IAM managed policy that serves as the mandatory Permissions Boundary for all roles created by the HotsockInstallerRole.
  9. Hotsock real-time WebSockets service overview

    Hotsock is a real-time WebSockets service installed securely and privately within a user's own AWS account. It leverages fully-managed AWS services (API Gateway WebSockets, Lambda, DynamoDB, SQS, EventBridge, SNS, and CloudFormation), meaning there are no servers or containers to manage and it scales automatically based on usage.

    Key features include:

    • Fine-grained permissions for private channel access using JSON Web Tokens (JWTs).
    • Support for both server-initiated and client-initiated messages.
    • Standard channels for updating connected clients with backend data.
    • Presence channels for tracking online status and connected devices.
    • Pub/sub events via EventBridge or SNS for webhook-style notifications.
    • Custom domain support for WebSocket endpoints.
    • A web console for debugging subscriptions, messages, and authorization.
  10. Understand Standard channel behavior

    Standard channels are the default channel type in Hotsock, supporting an unlimited number of subscribers for real-time message exchange. They are ideal for live dashboards, notifications, collaborative editing, and IoT telemetry. Unlike presence channels, Standard channels do not provide awareness of other connected clients.
  11. Authenticate Hotsock connections using JWT

    Hotsock uses JSON Web Tokens (JWT) to authenticate WebSocket connections and authorize permissions. Client applications pass a signed JWT to Hotsock, which verifies the token without needing direct access to the application's user database. A valid token must have a header with typ: "JWT" and a matching alg (algorithm) value. The payload typically includes an audience (aud), expiration (exp), and specific channel permissions.
    {
      "alg": "HS256",
      "typ": "JWT"
    }
    {
      "aud": "hotsock",
      "exp": 1686011549,
      "channels": {
        "user.123": {
          "subscribe": true
        }
      },
      "scope": "connect"
    }
  12. Access and use the hotsock Web Console

    The hotsock installation includes a web-based console (powered by hotsock-js) for debugging and testing JWT validation, token claims, connections, channel subscriptions, and messages. The URL for the console is located in the WebConsoleHttpUrl output of the CloudFormation stack.