Aaron Parecki

There's no point in adopting a spec that doesn't actually tell you what to do, other than to have the official stamp of approval of that spec. Right now, any number of completely incompatible implementations of can call themselves OAuth 2.0, but is that really a success? Is that really what we're shooting for?

At a minimum, I would like the PuSH spec to define *one* way publishers can notify hubs, (`hub.mode=publish&hub.topic=x`) and in order for a hub to be PuSH-compliant it MUST support *at least* that way. Hubs should be welcome to support additional methods, such as the two ways already implemented by two different hubs. (multiple topic URLs https://indiewebcamp.com/how-to-push#Multiple_topic_URLs) by adding additional `hub.url` parameters, and wildcard topic URLs https://indiewebcamp.com/how-to-push#Wildcards)

Frankly, not having the publisher->hub payload in the 0.4 spec feels like a failure of a spec, similar to how OAuth 2.0 core is considered a failure. Having a separate spec for the publisher->hub payload also points to a failure, which is exactly what OAuth 2.0 is doing now.

There's nothing wrong with allowing hubs to offer more functionality for publishers, but there absolutely needs to be a common payload. Being able to change hubs by simply changing the hub URL advertised in the link header is critical to a successful standard.