WebSub lets an ordinary present-day software agent learn that a publisher has updated a feed without repeatedly asking the publisher for a new copy. A subscriber discovers a topic and hub, requests a subscription using a public callback endpoint, proves control of that callback by echoing a hub-issued challenge, and then receives HTTP POST updates. The agent still must validate what arrived, process it safely, renew expiring subscriptions and recover from lost or duplicate delivery.
This is event-delivery engineering, not evidence that artificial superintelligence currently exists. The same mechanisms can support a reading assistant watching academic publications, a school information dashboard or a permitted service synchronising public notices. W3C’s current WebSub Recommendation defines the protocol; a robust agent adds operational safeguards such as a durable inbox, permission-aware processing and independent reconciliation.
Contents: The three roles and the actual flow · Discovery is part of the security boundary · Forming a subscription request · Why the hub performs challenge verification · Model the subscription as explicit states · Lease arithmetic and renewal margins · A checked comparison with periodic polling · What the POST delivery actually means · Authenticate the body when a secret is provided · Exactly what a valid HMAC does not prove · Separating multiple subscribers and topics · At-least-once delivery and idempotent consumers · Recovering when the callback crashes · When the subscription expires unexpectedly · Moving safely when the publisher changes hubs · Rate limits, callback pressure and backoff · Separate freshness, coverage and correctness · A monitoring calculation with honest denominators · A practical school information agent · A test plan that catches real failures · Privacy and organisational responsibility · Changed-context transfer exercise with solution · Mistakes to avoid and how to repair them · What the protocol does not provide · Frequently asked questions · Primary references and related reader pathways
The three roles and the actual flow
WebSub has three main roles: a publisher owns a topic, a hub manages subscriptions and content distribution, and a subscriber wants to learn about topic updates. The publisher need not maintain a separate connection to every subscriber. Instead, the hub coordinates delivery. An educational agent is often the subscriber, although an organisation may operate both publisher and subscriber components in different systems. The existence of an HTTP callback does not make an agent autonomous or intelligent by itself; that endpoint is only a communication boundary.
A topic is a resource URL, often an Atom or RSS feed, though the standard is not limited to those formats. A publisher advertises a canonical topic URL and one or more hub URLs. A subscriber discovers those relationships, asks a hub to subscribe and identifies its callback. The hub then checks whether the callback really wants the subscription. Only after successful intent verification should the agent consider the subscription active.
When the topic changes, the publisher alerts the hub. The hub distributes updated topic content, or a permitted reduced feed representation, to subscribers through HTTP POST. The subscriber acknowledges receipt promptly; heavier parsing, summarisation, indexing and notification can happen asynchronously. That separation between receipt and durable processing is central to making agents reliable rather than merely fast.
Discovery is part of the security boundary
A subscriber does not invent a hub by appending a path to an arbitrary domain. It follows the discovery methods specified by WebSub, which may involve HTTP Link headers, XML feed relationships or HTML links, and it must respect the published canonical topic. A hub address discovered from untrusted content is still an untrusted network destination until policy approves it. The application should make clear whether it follows publishers from an allowlist or accepts general public feeds.
An agent that follows external links freely can be exposed to server-side request forgery risks. A malicious document might advertise a hub pointing to a private-network address or an attacker-controlled service. Validate URL schemes, public-network reachability where relevant, permitted hosts, redirects and DNS resolution at the network layer. Do not treat a publisher’s feed as authority to reach arbitrary internal resources.
Discovery can legitimately return more than one hub. A robust client records which hub was selected and why, along with the canonical topic, content type and retrieval time. If the publisher later changes its advertisement, the client should evaluate the migration explicitly rather than silently sending authenticated secrets to a new endpoint.
Forming a subscription request
The usual request is an HTTP POST to the selected hub with form fields including hub.callback, hub.mode and hub.topic. Use the literal mode subscribe to establish a relationship, and unsubscribe to terminate one. The callback URL is an endpoint reachable by the hub over the network. A local-only notebook address cannot complete the verification flow unless it is exposed through a deliberate, secured gateway; the protocol does not magically reach a laptop behind a firewall.
A subscriber may request a lease duration and provide a shared secret for content authentication. The hub has discretion over the final lease it grants, and its verification response communicates the actual lease seconds for a subscription. Store what was granted, not merely what was requested. The subscription key is the pair of topic URL and callback URL, which makes it important to avoid reusing callback identities carelessly across unrelated tenants.
Use distinct long-lived subscription state rather than treating the initial POST response as final activation. The hub’s acceptance of a request and the subsequent callback challenge are separate steps. Application logs should preserve the request identifier, selected hub, topic, callback and state transitions without exposing secrets or full sensitive payloads.
Why the hub performs challenge verification
Without verification, anyone could ask a hub to bombard an arbitrary third-party URL with deliveries or cancel another site’s feed updates. WebSub therefore requires the hub to send a verification GET request to the declared callback. That request includes hub.mode, hub.topic and a random hub.challenge string. For a subscription the hub also supplies hub.lease_seconds. The subscriber checks that the topic and mode match an actual pending intent.
If the pending intent matches, the callback returns a successful 2xx response whose body is exactly the challenge value, using a safe response media type. If it does not agree to the action, the callback should return 404. A redirect or a success response with a different body does not complete intent verification. Do not build a callback that echoes every incoming challenge before checking topic and mode; that defeats the purpose of the handshake.
The W3C Recommendation updated in June 2026 added explicit mitigations for reflected cross-site scripting. A callback that takes an untrusted challenge parameter and inserts it into an HTML page with unsafe content type could become a reflection surface. Use an appropriate safe content type, strict response construction and reasonable input length checks. Being a machine-to-machine protocol does not make web-content injection irrelevant.
Model the subscription as explicit states
An implementer can use the states DISCOVERED, REQUESTED, VERIFYING, ACTIVE, RENEWING, EXPIRED, DENIED and UNSUBSCRIBED, with a durable record of each transition. These names are an engineering suggestion, not mandatory status values from the WebSub specification. They prevent a common mistake: treating a delivered verification request as confirmation that all future notifications are guaranteed to arrive.
Record topic URL, chosen hub URL, callback URL, request mode, a hash or sealed reference to the shared secret, last challenge timestamp, start of the verified lease, granted lease seconds, calculated expiry, next renewal time and latest successfully reconciled topic version. Update the record transactionally so a crash between receiving a callback and saving its result does not leave the state impossible to reason about.
Reject unsolicited verification for topics with no pending local request. A callback handler should also distinguish subscribe from unsubscribe because confirming the wrong mode may unexpectedly end deliveries. If verification arrives after a user has withdrawn consent or disabled a watcher, the system must not revive that watcher merely because a stale GET request arrived.
Lease arithmetic and renewal margins
Suppose a hub grants a lease of 7,200 seconds, equivalent to two hours, beginning at a recorded verification instant. An agent chooses to renew after 5,400 seconds, or 90 minutes, leaving a 1,800-second margin before expiry. The arithmetic is 7,200 minus 5,400 equals 1,800 seconds, which is 30 minutes. Those numbers are invented operational settings, not a protocol-mandated renewal schedule.
Why leave a margin? Network outages, temporary hub failures, rate limits, maintenance windows and queue delays can all cause a request sent at the exact expiry time to arrive too late. Jitter renewal attempts across subscriptions to avoid every watcher waking on the same clock boundary. Use server-issued lease seconds and a monotonic elapsed-time calculation where practical; record absolute timestamps for audits, but do not assume that wall clocks never jump.
The hub may grant less time than the client requested. A subscriber should therefore recalculate its schedule when verification succeeds. If a lease expires despite retries, transition to an expired or degraded state and reconcile the topic directly before restoring normal status. A live callback URL alone does not prove that the corresponding subscription is active.
A checked comparison with periodic polling
Consider a reading agent watching twelve independent public feeds. If it polls each one every ten minutes, there are six polls per hour per feed, 144 per day per feed and 1,728 feed-fetch requests per day across twelve feeds. This calculation is twelve multiplied by twenty-four multiplied by six. It assumes constant polling without conditional responses, downtime or changed schedules.
Now suppose each feed experiences exactly three update events per day, and for this illustrative comparison the hub sends one successful notification for every event. That is thirty-six initial delivery POST requests per day across twelve feeds, plus discovery, subscription and renewal traffic. This can reduce unnecessary checks, but the protocol may batch, retry or deliver updated feed bodies that cover multiple changes. Thirty-six should not be advertised as a universal WebSub request count.
A large feed body delivered many times can consume more bandwidth than conditional GET polling with 304 responses. Compare bytes, server work, latency, missed updates and security operations, not only request totals. At low change frequency a push model can help; with highly volatile topics or strict audit requirements, a combined push-and-reconciliation design may be superior.
What the POST delivery actually means
When new content is available, the hub sends an HTTP POST to the subscriber callback. The body is topic content, and the Content-Type corresponds to the topic’s content type. For Atom and RSS, the hub may remove entries it has already delivered. The request also includes hub and self link relations identifying topic metadata, but the specification warns subscribers not to rely on those Link headers alone to identify which subscription is being notified.
The callback should verify the delivery as applicable, store it durably and return a successful HTTP status quickly. That status reports receipt, not that all downstream enrichment and indexing have completed. If a summariser is slow or unavailable, the inbox can retain the content for later processing. This is a familiar separation in queueing systems: accept, persist, acknowledge and then execute expensive work with retry controls.
Do not claim that an HTTP 2xx proves the information has been understood or acted upon. The protocol defines a transport exchange; any promise of completed classification, source verification or learner notification belongs to the application. The hub itself can retry deliveries after failures within its limits, making duplicate processing a realistic possibility.
Authenticate the body when a secret is provided
If a subscriber supplies hub.secret, the W3C protocol requires the hub to generate an HMAC signature of the HTTP request body and include it in the X-Hub-Signature header. The header represents an algorithm name and a hexadecimal signature, such as sha256 followed by an equals sign and a digest. The subscriber should compute the HMAC over the exact raw body bytes using its configured secret and compare digests safely.
Do not parse and reserialise JSON or XML before verification. Reformatting whitespace, reordering keys or normalising Unicode can alter the byte sequence and cause a legitimate signature to fail. Read the raw request body once within configured size limits, verify it, and only then pass authenticated bytes to the parser. Use a constant-time digest comparison to avoid leaking information through timing variations in a homemade comparator.
The updated W3C recommendation documents legacy SHA-1 interoperability and recognises stronger SHA-2 algorithms. Engineering policy should prefer supported modern algorithms where interoperability allows, and should explicitly assess weaker legacy signatures rather than silently treating every digest as equally desirable. Never print the shared secret in logs, retry traces, exception messages or public diagnostic pages.
Exactly what a valid HMAC does not prove
A correct content signature supports a claim that the body was produced by a party possessing the shared secret and was not altered after signing, under the assumed cryptographic properties. It does not prove that the publisher’s claims are true, that every URL inside the payload is safe, or that the topic owner endorses every external link. HMAC does not supply independent fact-checking or semantic trust.
The WebSub specification also notes that its payload signature does not automatically authenticate all HTTP headers. Link headers and forwarding metadata need appropriate transport protections and application checks. Use HTTPS for callbacks and hub communications when possible, bind a delivery to an expected subscription context and avoid elevating untrusted headers into user permissions.
WebSub signatures should not be presented as full anti-replay protection. An attacker who replays a previously valid signed payload may produce the same valid HMAC. Application-level duplicate detection, bounded staleness policies where possible and idempotent processing remain important. These are design protections layered onto the protocol.
Separating multiple subscribers and topics
A tutoring organisation could have one subscriber application serving several teams, each authorised to track a different set of publications. Sharing a single callback and shared secret without tenant binding can mix deliveries across authorisation boundaries. Store each subscription with its tenant identity, expected topic and hub; use separate secrets or securely scoped lookup records where warranted. A received payload must not select its own privileged destination based only on untrusted text.
Suppose a callback receives a notification claiming topic A while the server has active subscriptions for topics A and B. The application must reconcile it against its own saved subscription state and authenticate as configured before queueing it for A’s permitted workers. The presence of an advertised self URL is useful context, but it is not alone an access-control decision. If the mapping is ambiguous, quarantine rather than guessing.
Maintain narrow permissions for downstream actions. A publication watcher might be allowed to summarise new public papers but not automatically send personal emails, edit a school database or change tuition schedules. A transport notification should activate only the tasks explicitly authorised for that topic.
At-least-once delivery and idempotent consumers
A hub may retry a delivery when the callback times out, loses its response or returns a failure. The application might therefore see the same update twice. An agent that interprets each delivery as a unique publication can generate duplicate summaries, send repeated notifications or create conflicting database records. Treat duplicate receipt as an expected condition instead of an exceptional conspiracy.
Choose a deduplication key appropriate to the feed format and publisher guarantees. A stable entry identifier plus a content version may work for some Atom feeds; another application may use a canonical topic URL and a carefully computed body hash. A bare timestamp or title is often insufficient because corrections can reuse titles or dates. Record the exact deduplication strategy and whether later edits should trigger reprocessing.
Make side effects idempotent. Before creating a reader-facing item, check whether its stable source-version key already exists. Where supported, use unique constraints or conditional writes rather than a read-then-create sequence vulnerable to concurrent workers. Preserve a path for legitimate corrections: a new version of an existing article is not necessarily a duplicate event.
Recovering when the callback crashes
Suppose the callback verifies the HMAC, inserts a delivery into a database and then crashes before returning HTTP 2xx. The hub may retry. If the insert has a unique stable key, the second arrival can locate the existing record and acknowledge it without repeating a newsletter or content publication. If the service instead sends an email before saving state, a crash can cause duplicate emails with no reliable record of the first send.
Another failure order is just as damaging: the callback sends 2xx before persisting the message, then the process crashes. The hub believes delivery succeeded but the subscriber has no durable record. The practical pattern is to persist a small authenticated delivery envelope first, acknowledge next, and process asynchronously. Keep the persistence transaction short and bounded so incoming requests do not exhaust a shared worker pool.
Not every deployment needs a heavyweight message broker. A relational table with unique keys and an outbox worker may suffice at small scale. The essential properties are an explicit boundary for durable acceptance, a visible retry mechanism, and a reconciliation procedure when either side disagrees about what was received.
When the subscription expires unexpectedly
A dashboard can appear healthy because the callback route still answers HTTP requests even though its subscription quietly expired yesterday. A reliable agent tracks the expiry timestamp and last successful verification for every topic. If the remaining lease is shorter than a configured safety margin, the watcher is at risk and should re-request subscription. If no successful verification occurs by expiry, stop claiming that push monitoring is current.
The operational remedy is not to invent missed events. Fetch the current topic through an authorised normal read, compare its entries or version with the last reconciled position and record any gaps. Then retry or migrate subscription based on verified discovery information. If older events are no longer present in a rolling feed, say that the historical gap cannot be fully reconstructed from that source alone.
Store both the time of last notification and time of last successful independent reconciliation. A quiet feed might legitimately have no updates for months, so notification silence is not by itself evidence of failure. Conversely, an active callback can receive traffic unrelated to the subscription. Health checks need subscription-specific evidence.
Moving safely when the publisher changes hubs
Publishers may advertise a new hub over time. An agent that pins a particular hub forever can lose updates, while one that blindly trusts a new hub URL can leak subscription identifiers or secrets to an attacker. Re-fetch and validate the canonical topic’s discovery information under the same network and permission policy used initially. Record the old and new hub, and explain the transition in operational logs.
An orderly migration can overlap coverage while the new subscription verifies and the old subscription remains active, depending on the publisher and hub behaviour. Overlap means duplicate notifications may arrive through two routes, so deduplication must survive the migration. Once new coverage is verified and reconciliation is complete, retire the obsolete subscription rather than leaving invisible watchers running indefinitely.
Never transfer a shared secret to a new destination solely because a payload claims a new hub. Generate or provision a new secret according to the subscriber’s security policy, update only approved endpoints and ensure that the callback’s pending-intent record expects the new arrangement. Authentication and discovery must not become circular trust claims.
Rate limits, callback pressure and backoff
WebSub reduces the need for polling but does not remove load management. A popular feed can change quickly, and a hub may deliver multiple notifications during an update burst. Limit request-body size, concurrent callback handlers, parser complexity, queue depth and downstream processing rate. A service that accepts unlimited XML bodies because they came through a subscription endpoint still exposes itself to resource exhaustion.
When an authenticated delivery cannot be persisted because storage is unavailable, returning an error may trigger hub retries subject to its own limits. Do not assume the hub retries forever. Design exponential backoff with jitter for client-initiated renewals, keep idempotence across retries, and distinguish permanent configuration failures from transient outages. No fixed retry count is correct for every operator.
For planning, if thirty-six nominal notifications in a day each trigger three downstream jobs, there may be 108 job attempts before any retries. Add a 10% replay overhead in an illustrative capacity calculation and the total becomes about 119 attempts, not 108. This is a sizing example, not a standard guarantee. Systems should measure their actual retry distribution.
Separate freshness, coverage and correctness
Freshness asks how quickly the agent notices an update. Coverage asks what share of relevant updates it ultimately captures. Correctness asks whether it parses and interprets those updates accurately. A push system can be excellent at freshness but poor at coverage if leases expire or inbox records are lost. A crawler that polls slowly may offer complete periodic snapshots without near-real-time awareness. One metric does not establish all three.
Define freshness as time from a publisher-visible change to a durable local record, where both timestamps are available and comparable. Define coverage over a known reference set of published changes, not just notifications received; counting only deliveries makes unseen missed events disappear from the denominator. Define processing accuracy using a human-reviewed or otherwise justified sample with explicit error categories.
An educational feed watcher should also distinguish source-update timeliness from student-facing notification timeliness. Editorial checks, curriculum relevance classification and tutor review can add legitimate delays. Do not shorten those checks merely to advertise subsecond delivery if the downstream message could mislead readers.
A monitoring calculation with honest denominators
Imagine a trial over one full day with 40 actual publisher changes documented by an independent source-side log. The subscriber receives 42 delivery POSTs, of which four are verified duplicate versions and two represent updates already observed through another hub. There are therefore 36 unique source changes represented among deliveries. If four of the 40 source changes were not captured, event coverage is 36 divided by 40, or 90%. Counting the 42 POSTs as 42 successes would produce the meaningless value 105%.
Now suppose 32 of those 36 represented changes were available in the local inbox within five minutes of source publication. Five-minute observed freshness coverage over all source changes is 32 divided by 40, or 80%. Over only captured changes it is 32 divided by 36, or about 88.9%. Both can be meaningful, but they answer different questions. State the denominator before comparing systems.
This example deliberately assumes the source-side log is complete, clocks are aligned and one unique version can be identified for each change. In practice those assumptions may be unavailable. Report the uncertainty or reconcile against publisher snapshots rather than fabricating certainty.
A practical school information agent
A school operations team may want a permitted agent to monitor updates from a public authority’s published feed and prepare a daily note for staff. The first decision is whether the source actually advertises WebSub and whether its terms permit this use. If not, the application should use a documented alternative such as conditional polling, a supported API or manual checks; it must not pretend every website provides a usable hub.
For a compliant source, create a scoped watcher with a canonical topic, verified hub, callback identity and renewal plan. On delivery, authenticate the body, store it, parse the publication entries and compare them with the last known version. A classifier may label an update as relevant to Primary Mathematics, Secondary English or parent administration, but a human should validate consequential interpretations and deadlines before distribution.
A provenance panel can show source URL, publication timestamp, local receipt timestamp, content version, citation and review status. This makes a machine-generated summary auditable. WebSub supplies a transport path for new bytes; it does not supply a guarantee that the summary is complete, that the source text is current at read time or that the publisher has not corrected the document.
A test plan that catches real failures
Start with a local test hub or controlled fixture that emits a valid subscription challenge. Confirm that the callback accepts only a matching pending mode and topic, and that it echoes the exact challenge in a safe response type. Try unknown topics, wrong modes, oversized challenges, unexpected encodings, redirects and stale requests. The correct negative behaviours matter as much as the happy path.
Then test signed delivery with fixed body bytes and a known secret. Alter one byte to confirm that verification rejects the content. Reorder JSON properties or change XML whitespace only in a separate test so developers see why signatures must cover raw bytes. Check handling for valid signatures with unknown subscriptions, for invalid signatures that receive HTTP 2xx but are locally discarded, and for missing signatures when the subscription expected authenticated delivery.
Finally simulate a crash after durable insertion but before acknowledgment, a hub retry, duplicate content through overlapping subscriptions, lease expiry, renewal failure and hub migration. Record whether the system creates one reader-facing item per intended source version. Tests should inspect persisted records, not merely assert that a callback endpoint returned an HTTP status.
Privacy and organisational responsibility
Subscriptions can expose what topics an organisation follows, and callbacks expose network endpoints that attackers may probe. Use least-privilege identities, avoid embedding student information in callback URLs and keep subscription secrets out of query parameters where possible. A public RSS or Atom topic may be harmless, but a closed feed can contain sensitive content; treat the actual source’s permissions as part of the subscription design.
Do not store full payloads forever solely because a hub can send them. Set retention according to educational purpose, compliance requirements and the need for audit. A durable inbox can hold a hash and limited metadata after the necessary content is safely processed or expired. Keep operational logs useful without capturing private API credentials, secrets, full student records or needless personally identifiable information.
Governance must also cover the AI layer after ingestion. If a model creates an inaccurate summary, that is not a WebSub transport failure. Make correction, provenance and human escalation paths visible. The agent should know when to stop, mark uncertain or seek review rather than silently treating every delivered document as true.
Changed-context transfer exercise with solution
A team migrates from twelve low-volume public feeds to 1,200 topics, each with an independently granted one-day lease. To renew each after eighteen hours, the average renewal rate is 1,200 divided by 18 renewals per hour, or roughly 66.7 renewals per hour; multiplied by 24 this is about 1,600 renewals per day. Real scheduling should spread them with jitter. The nominal rate is not 1,200 per day because every lease is renewed after three quarters of a day.
Now suppose the callback still responds, but no renewal verification has succeeded for thirty hours. Can the dashboard claim up-to-date push coverage because no error alerts appeared? No. Each one-day lease has likely expired unless a later verified subscription replaced it; inspect the saved leases. Perform normal read-based reconciliation and report the gap. The visible HTTP health check did not certify subscription state.
Next suppose a previously signed payload is replayed with unchanged bytes. Its HMAC can still validate. The proper defence is idempotent source-version processing, appropriate staleness policy and subscription binding—not guessing that HMAC includes replay detection. The transfer lesson is that trust in transport bytes and trust in new information are separate decisions.
Mistakes to avoid and how to repair them
A common mistake is acknowledging a notification before any durable storage. Repair it by persisting a small verified envelope and acknowledging receipt after that succeeds. Another is using the hub’s initial POST response as evidence of active subscription; repair it by tracking the subsequent challenge and granted lease. A third is accepting a challenge without matching an outstanding local intent; repair it with explicit pending-state validation and safe response construction.
Other mistakes include passing untrusted feed text into a powerful agent tool without permission checks, using a signature to justify trusting all HTTP headers, assuming the hub retries forever, and describing a quiet feed as proof of a healthy lease. Each has a different repair: scoped authorisation, transport-boundary checks, bounded durable retries and independent subscription health evidence.
A subtler mistake is changing the callback URL in a deployment without renewing subscriptions. The subscription key includes that URL, so what looks like a routine infrastructure change can break deliveries. Review callback address, TLS certificate, firewall rules, secret configuration and pending challenge handling as one migration plan.
What the protocol does not provide
WebSub is not an event-sourcing database, a distributed transaction coordinator, a global exactly-once delivery system or an artificial intelligence model. It does not guarantee that a publisher retains every historical edit, that the hub will retry forever, or that every feed conforms perfectly to the expected content format. A subscriber cannot recover a vanished historical update merely by reconnecting.
The protocol also does not rank educational importance. An AI agent that receives an update about a school event must still check dates, locale, affected population and source credibility before writing a message for parents. A machine-generated summary should link to its origin and make uncertainty visible when the source is incomplete.
Push subscriptions can be excellent for reducing discovery delay. Pair them with periodic snapshots or source-version reconciliation when missed updates would matter. Reliable systems are built from overlapping controls, not a single protocol flag labelled real time.
Frequently asked questions
Does WebSub mean an AI agent has become superintelligent? No. It is a web notification protocol used by ordinary software. The title belongs to a series about engineering components relevant to more capable future systems, not a claim that ASI exists today.
Does every RSS feed support WebSub? No. The publisher must advertise usable topic and hub relationships, and the hub must actually accept and serve subscriptions. If the source lacks these, use another authorised retrieval mechanism.
Why does the hub ask the callback to echo a challenge? To verify that the callback endpoint intended to subscribe or unsubscribe to the particular topic. Blindly reflecting every challenge defeats this protection.
Does a signed delivery guarantee the facts are correct? No. It authenticates payload bytes under a shared-secret assumption. Publishers and downstream analysis may still be wrong.
Why might one update trigger two callbacks? Retries, hub overlap, subscription migration and similar delivery conditions can duplicate content. Consumers should use stable source-version keys and idempotent writes.
Can callbacks return a success response before summarisation finishes? Yes, when the content was durably received; the protocol success indicates receipt, not completion of downstream processing.
What happens after lease expiry? The subscriber should not claim active push coverage. Renew when possible, reconcile the source directly and document any gap.
Must an agent trust Link headers in incoming deliveries as its subscription identity? No. The standard cautions that those headers describe topic metadata, not a unique subscriber-specific identity.
Does HMAC stop old valid messages from being replayed? Not by itself. Deduplication and contextual replay controls are separate.
Can a family or tutor use this idea without building servers? They can understand the principle, but operating a conformant subscriber needs an accessible callback and a secure stateful service. Hosted integrations may hide those details, but should be evaluated for provenance and retention.
Primary references and related reader pathways
The normative protocol source is the World Wide Web Consortium’s WebSub Recommendation at https://www.w3.org/TR/websub/ , updated on 2 June 2026. Its sections on discovery, intent verification, content distribution, authentication and security are the source for the transport-level distinctions in this article. The reference URL points to the W3C’s living latest published Recommendation and should be checked for later revisions.
For the security mechanism behind signed requests, the IETF HMAC specification is RFC 2104 at https://www.rfc-editor.org/rfc/rfc2104 . General HTTP response and request semantics are documented in RFC 9110 at https://www.rfc-editor.org/rfc/rfc9110 . Those standards do not replace the WebSub-specific rules; they provide context for cryptographic authentication and HTTP behaviour.
Follow adjacent engineering ideas separately: streaming record framing handles incremental bytes rather than feed subscriptions; conditional JSON patching handles updating stored state; replay-safe API authentication handles different token threats. These are complementary mechanisms, not reasons to duplicate the WebSub owner article.
Primary specifications: W3C WebSub Recommendation (updated 2 June 2026); RFC 2104: HMAC; RFC 9110: HTTP Semantics.
Continue with eduKateSG guides on Agent NDJSON Streams — Record Framing, Partial Lines and Safe Replay, Agent JSON Merge Patch — Null Deletes, Array Replacement and Safe Preconditions, and Agent DPoP Tokens — Signed Proofs, Nonces and Replay-Safe APIs.