An open, simple, web-scale and decentralized pubsub protocol. Anybody can play.
As opposed to more developed (and more complex) pubsub specs like Jabber Publish-Subscribe [[!XEP-0060]] this spec's base profile (the barrier-to-entry to speak it) is dead simple. The fancy bits required for high-volume publishers and subscribers are optional. The base profile is HTTP-based, as opposed to XMPP (see more on this below).
To dramatically simplify this spec in several places where we had to choose between supporting A or B, we took it upon ourselves to say "only A", rather than making it an implementation decision.
We offer this spec in hopes that it fills a need or at least advances the state of the discussion in the pubsub space. Polling is extremely wasteful and high latency. We think a decentralized pubsub layer is a fundamental, missing layer in the Internet architecture today and its existence, more than just enabling the obvious lower latency feed readers, would enable many cool applications, most of which we can't even imagine. But we're looking forward to decentralized social networking.
This document is currently a W3C TR track document. Current bugs and issues are managed in GitHub.
(This section is non-normative.)
Earlier versions of this protocol were called PubSubHubbub:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [[!RFC2119]].
WebSub describes three roles: publishers, subscribers and hubs. This section describes the conformance criteria for each role.
A conforming subscriber:
A conforming hub:
hub.callback, hub.mode and hub.topic.hub.secret parameter.X-Hub-Signature header if the subscription was made with a hub.secret as described in Authenticated Content Distribution.For this specification to exit the CR stage, there must be at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products. There is no requirement that all features be implemented by a single product. For the purposes of this criterion, we define the following terms:
A WebSub Publisher is an implementation that advertises a topic and hub URL on one or more resource URLs. The conformance criteria are described in Conformance Classes above.
A WebSub Subscriber is an implementation that discovers the hub and topic URL given a resouce URL, subscribes to updates at the hub, and accepts content distribution requests from the hub. The subscriber MAY support authenticated content distribution. The conformance criteria are described in Conformance Classes above.
A WebSub Hub is an implementation that handles subscription requests and delivers notifications to subscribers when the corresponding topic URL has been updated. Hubs MUST support subscription requests with a secret and deliver authenticated notifications when requested. Hubs MUST deliver the full contents of the topic URL in the notification, and MAY reduce the payload to a diff if the content type supports it. The conformance criteria are described in Conformance Classes above.
Each implementation must be developed by a different party and cannot share, reuse, or derive from code used by another qualifying implementation. Sections of code that have no bearing on the implementation of this specification are exempt from this requirement.
A Subscriber and Hub implementation are considered interoperable for a specific feature when the Hub takes the defined action that the Subscriber requests, the Subscriber gets the expected response from a Hub according to the feature, and the Hub sends the expected response to the Subscriber.
For the purposes of evaluating exit criteria, each of the following is considered a feature:
The discovery mechanism aims at identifying at least 2 URLs.
The protocol currently supports the following discovery mechanisms. Publishers MUST implement at least one of them:
When perfoming discovery, subscribers MUST implement all three discovery mechanisms in the following order, stopping at the first match:
Note: The Host-Meta method of discovery is currently At Risk and may be deprecated.
Subscribing to a topic URL consists of four parts that may occur immediately in sequence or have a delay.
Unsubscribing works in the same way, except with a single parameter changed to indicate the desire to unsubscribe. Also, the Hub will not validate unsubscription requests with the publisher.
Subscription is initiated by the subscriber making an HTTPS or HTTP POST [[!RFC7231]] request to the hub URL. This request MUST have a Content-Type header of application/x-www-form-urlencoded (described in Section 17.13.4 of [[!W3C.REC-html401-19991224]]) and the following parameters in its body, formatted accordingly:
Subscribers MAY also include additional HTTP [[!RFC7230]] request parameters, as well as HTTP [[!RFC7230]] Headers if they are required by the hub.
Hubs MUST ignore additional request parameters they do not understand.
Hubs MUST allow subscribers to re-request subscriptions that are already activated. Each subsequent request to a hub to subscribe or unsubscribe MUST override the previous subscription state for a specific topic URL and callback URL combination, but only once the action is verified (Section 4.3). If verification fails, the subscription state MUST be left unchanged. This is required so subscribers can renew their subscriptions before the lease seconds period is over without any interruption.
The topic and callback URLs MAY use HTTP or HTTPS [[!RFC7230]] schemes. The topic URL MUST be the one advertised by the publisher in a Self Link Header during the discovery phase. (See Section 3 ). Hubs MAY refuse subscriptions if the topic URL does not correspond to the one advertised by the publisher. The topic URL can otherwise be free-form following the URL spec [[!WHATWG-URL]]. Hubs MUST always decode non-reserved characters for these URL parameters; see section 1.2 on "Percent-encoded bytes" in [[!WHATWG-URL]].
The callback URL SHOULD be a Capability URL [[!capability-urls]] and SHOULD use HTTPS [[!RFC7230]]. The Capability URL acts as authentication from the hub to the subscriber when confirming subscriptions and delivering notifications. Additionally, the callback SHOULD be unique (not re-used for multiple hubs) and changed when subscriptions are renewed.
The callback URL MAY contain arbitrary query string parameters (e.g., ?foo=bar&red=fish). Hubs MUST preserve the query string during subscription verification by appending new parameters to the end of the list using the & (ampersand) character to join. Existing parameters with names that overlap with those used by verification requests will not be overwritten. For event notification, the callback URL will be POSTed to including any query string parameters in the URL portion of the request, not as POST body parameters.
The hub MUST respond to a subscription request with an HTTP [[!RFC7231]] 202 "Accepted" response to indicate that the request was received and will now be verified (Section 4.3 ) and validated (Section 4.2 ) by the hub. The hub SHOULD perform the verification and validation of intent as soon as possible.
If a hub finds any errors in the subscription request, an appropriate HTTP [[!RFC7231]] error response code (4xx or 5xx) MUST be returned. In the event of an error, hubs SHOULD return a description of the error in the response body as plain text, used to assist the client developer in understanding the error. This is not meant to be shown to the end user. Hubs MAY decide to reject some callback URLs or topic URLs based on their own policies (e.g., domain authorization, topic URL port numbers). However, since verification and validation of intent are asynchronous steps that logically begin after the HTTP response has been returned, the HTTP response MUST NOT depend on the process or outcome of verification or validation.
Subscriptions MAY be validated by the Hubs who may require more details to accept or refuse a subscription. The Hub MAY also check with the publisher whether the subscription should be accepted.
If (and when), the subscription is accepted, the hub MUST perform the verification of intent of the subscriber.
If (and when), the subscription is denied, the hub MUST inform the subscriber by sending an HTTP [[!RFC7231]] GET request to the subscriber's callback URL as given in the subscription request. This request has the following query string arguments appended (format described in Section 17.13.4 of [[!W3C.REC-html401-19991224]]):
Hubs may provide an additional HTTP [[!RFC7231]] Location header (as described in section 7.1.2 of Hypertext Transfer Protocol [[!RFC7231]]) to indicate that the subscriber may retry subscribing to a different hub.topic. This allows for limited distribution to specific groups or users in the context of social web applications.
The subscription MAY be denied by the hub at any point (even if it was previously accepted). The Subscriber SHOULD then consider that the subscription is not possible anymore.
In order to prevent an attacker from creating unwanted subscriptions on behalf of a subscriber (or unsubscribing desired ones), a hub must ensure that the subscriber did indeed send the subscription request.
The hub verifies a subscription request by sending an HTTP [[!RFC7231]] GET request to the subscriber's callback URL as given in the subscription request. This request has the following query string arguments appended (format described in Section 17.13.4 of [[!W3C.REC-html401-19991224]]):
The subscriber MUST confirm that the hub.topic corresponds to a pending subscription or unsubscription that it wishes to carry out. If so, the subscriber MUST respond with an HTTP success (2xx) code with a response body equal to the hub.challenge parameter. If the subscriber does not agree with the action, the subscriber MUST respond with a 404 "Not Found" response.
The hub MUST consider other server response codes (3xx, 4xx, 5xx) to mean that the verification request has failed. If the subscriber returns an HTTP [[!RFC7231]] success (2xx) but the content body does not match the hub.challenge parameter, the hub MUST also consider verification to have failed.
Hubs MAY make the hub.lease_seconds equal to the value the subscriber passed in their subscription request but MAY change the value depending on the hub's policies. To sustain a subscription, the subscriber MUST re-request the subscription on the hub before hub.lease_seconds seconds has elapsed.
Hubs MUST enfore lease expirations, and MUST NOT issue perpetual lease durations.
The spec uses GET vs POST to differentiate between the confirmation/denial of the subscription request and delivering the actual notification. While this is not considered "best practice" from a web architecture perspective, it does make implementation of the callback URL simpler. Since the POST body of the notification may be any arbitrary content type and only includes the actual content of the document, using the GET vs POST distinction to switch between handling these two modes makes implementations simpler.
The publisher MUST inform the hubs it previously designated when a topic has been updated. The hub and the publisher can agree on any mechanism, as long as the hub is eventually able send the updated payload to the subscribers.
A content distribution request is an HTTP [[!RFC7231]] POST request from hub to the subscriber's callback URL. The HTTP body of the POST request MUST include the payload of the notification. This request MUST have a Content-Type Header corresponding to the Content-Type of the topic, and SHOULD contain the full contents of the topic URL. The hub MAY reduce the payload to a diff between two consecutive versions if its format allows it.
The request MUST include at least one Link Header [[!RFC5988]] with rel=hub pointing to a Hub associated with the topic being updated. It MUST also include one Link Header [[!RFC5988]] with rel=self set to the canonical URL of the topic being updated. The Hub SHOULD combine these headers into a single Link Header [[!RFC5988]]. All these URLs are those resulting from the discovery process (Section 3). The subscriber MUST NOT use these Link headers to identify the subscription corresponding to the content distribution request, because the Link headers are metadata associated with the topic content, not with any particular subscription. A hub MAY use discovery from time to time to detect changes in a topic's canonical URL and Hub URLs. Any such changes will cause changes to the Link headers sent in subsequent content distribution requests.
The successful response from the subscriber's callback URL MUST be an HTTP [[!RFC7231]] success (2xx) code. The hub MUST consider all other subscriber response codes as failures; that means subscribers MUST NOT use HTTP redirects for moving subscriptions. Subscribers SHOULD respond to notifications as quickly as possible; their success response code SHOULD only indicate receipt of the message, not acknowledgment that it was successfully processed by the subscriber. The response body from the subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications up to self-imposed limits on the number of times and the overall time period to retry. When the failing delivery exceeds the hub's limits, the hub terminates the subscription.
If the subscriber supplied a value for hub.secret in their subscription request, the hub MUST generate an HMAC signature of the payload and include that signature in the request headers of the content distribution request. The X-Hub-Signature header's value MUST be in the form method=signature where method is one of the recognized algorithm names and signature is the, hexadecimal representation of the signature. The signature MUST be computed using the HMAC algorithm [[!RFC6151]] with the request body as the data and the hub.secret as the key.
The following algorithms are the initially registered algorithm names, based on the contents of the referenced registry at the time of publishing. [FIPS PUB 180-4]
In the future, any algorithm added to [FIPS PUB 180-4] SHOULD be supported by hubs and subscribers.
When subscribers receive a content distribution request with theX-Hub-Signature header specified, they SHOULD recompute the signature with the shared secret using the same method (provided in the X-Hub-Signature header) as the hub. If the signature does not match, subscribers MUST still return a 2xx success response to acknowledge receipt, but locally ignore the message as invalid. Using this technique along with HTTPS [[!RFC2818]] for subscription requests enables simple subscribers to receive authenticated notifications from hubs without the need for subscribers to run an HTTPS [[!RFC2818]] server.
Please note however that this signature only ensures that the payload was not forged. Since the notification also includes headers, these should not be considered as safe by the subscriber, unless of course the subscriber uses HTTPS [[!RFC2818]] callbacks.
hub.topic must be the self URL that was discoveredFrom header on subscription requests<link> tags in the HTML <head> element