Aaron Parecki

@akalsey It was quite an exercise in removing the dependency on a shared DB backend!

@pdxleif okay

@aallan I can't wait until e-ink tech gets better and solves that #iPad #Kindle

@wirres.net That's strange because my site and pin13.net have no trouble parsing your page. If you have a reproducible test case you could file a bug on the PHP parser though so I can try to fix it. https://github.com/indieweb/php-mf2

@wirres.net The post on your site needs to link to the Instagram copy with `u-syndication` and then Bridgy can find it! See: http://indiewebcamp.com/rel-syndication

@TechWraith yikes! I got lucky! All of mine survived. No backups though?

@TechWraith ouch! a casualty of last night's Fremont outage?

@ansate I play this game with @indiewebcat all the time

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