Aaron Parecki

@leoville.net oh good, it looks like it worked! :-D

@kenichi_pdx @donpdonp @pdxmele This is super cool! See: https://twitter.com/pkoonce/status/446135974813130754

@julien51 I certainly didn't mean to come across that way! The reason I haven't contributed to PuSH until now is because I still had a lot of catching up to do myself, making better publishing and consuming tools for myself. Now that I'm actively publishing short notes on my site, and reading others' posts in my reader that supports PuSH, it's suddenly extremely relevant! I hope the takeaway would be that there is now a renewed interest in PuSH which should help make it better and be adopted by more people!

This really is just pointing back to the question of what is the original goal of this spec. If the goal is to describe a way for consumers to subscribe to content, then yes, publisher->hub is not needed as part of the spec. Since that's what @julien51 described, then it sounds like the best course of action is to document the publisher->hub interaction separately, with the goal being to make it possible for publishers to use generic hubs.

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.