Aaron Parecki

@obensource Cool, I will shoot for 5pm then! I need either a 1/4" or RCA output of the audio.

@obensource What's the plan for tomorrow? I need some time to set up, what time are you getting there?

@calum_ryan Oh that's awesome! They look great!

@calum_ryan That looks great! Where'd you get the weather icons from?

It would be amazing if Granary supported PuSH. That would allow Granary to be smart about how it polls the underlying data sources (since each may have their own varying rate limits) instead of relying on the Granary consumer to implement smart polling. Ideally a Granary consumer could subscribe to updates at the PuSH hub and be notified when a feed has new content.

Just for clarification since some people seem to be unclear, this issue is specifically about whether to allow/recommend HEAD requests when making the HTTP request to verify that a webmention source URL does in fact link to the target URL.

This is *not* about the HTTP request used to discover the webmention endpoint in the first place. There are definitely obvious benefits to doing a HEAD request first when discovering the endpoint, since the webmention endpoint may be advertised in the HTTP header, which means that the sender can avoid making a GET request at all.

When verifying the link back, the receiver is going to have to make a GET request eventually, in order to check the document body for the link. The question is whether we should recommend that a receiver first make a HEAD request to the source URL before making the GET request.

It's true that not all webmention targets are HTML documents. Because of this, I think it's reasonable to clarify the text, changing

> The sender MUST fetch the target URL (and follow redirects [FETCH]) and check for an HTTP Link header [RFC5988] with a rel value of `webmention`, or an HTML `<link>` or `<a>` element with a rel value of `webmention`.

to

> The sender MUST fetch the target URL (and follow redirects [FETCH]) and check for an HTTP Link header [RFC5988] with a rel value of `webmention`, and if the content-type of the target URL is HTML, the sender MUST also check for an HTML `<link>` or `<a>` element with a rel value of `webmention`.

Requiring all senders to check for the HTTP `Link` header provides the largest opportunity for interop among implementations, since it's possible to publish a Link header regardless of content type.

If you have specific examples of wanting to advertise a webmention endpoint in a non-HTML document, please document them and suggest a (as you said) "standards-compliant way" of advertising the endpoint in the document.

I'm just going to point back to what @sandhawke said:

> Abandoning your early adopters before establishing a new user base means you have nobody.

The time to suggest a 100% breaking change to the spec has long passed. There is already a lot of written and deployed code that sends webmentions using form-encoded syntax. It's not a matter of simply making a "tiny" change to switch to JSON, since it will affect senders as well as receivers, some of which are using libraries on both sides, not to mention the fact that this software is deployed quite widely and in places where a single person can't even mandate that it be updated. Such is the situation when a spec gets widely implemented.