Aaron Parecki

@anomalily I choose to read this as an Onion article.

@leahthehunter :-) Some of my favorite days are spent within a block of my house too!

this one has a little too much going on.

@panic Yes!!! <3

@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.

@AmazonHelp :-D What's the timeline on the SDK? I'm really excited about integrating Alexa with more of my home automation stuff!

@AmazonHelp aww she doesn't seem to understand that! Also I'd need a wifi disco ball too... hmm...

@sciencequiche about 0.5-1 second, pretty good! And that's for 5-6 lights in a group.

although it definitely requires talking super slow, like you're talking to a non-native English speaker #echo

@timmmmyboy I agree. There's also some thoughts on how to grow here: http://indiewebcamp.com/generations It's too fragile to go from 0 to everyone immediately.

@timmmmyboy @andy_leap @benwerd Actually the "everyone contribute to my open source project" is exactly the kind of mentality that kills open/free software over and over again. Lots more on that here: http://indiewebcamp.com/monoculture

@voxpelli You should talk to @bretolius! He has Micropub for his GH Pages site. @julien51 @pfefferle

@dreev Oh yeah that too! It'll be nice to have that back.

@nitinthewiz I'm pretty sure you only need the Micropub plugin to use Quill with Wordpress. #IndieWeb

@maxogden I remember passing that quite often between PDX and Eugene. Okay how bout 45.5,-122.6?