tantek.comedited /User:Tantek.com (+139) "/* indieweb community */ archive remaining 2014/UK/Scheduling etherpad links to wiki pages and update ehterpad links to link to wiki pages instead" (view diff)
[miklb]hmm, so the 400 bad request error I was getting in Quill posting to WP micropub is gone, but the “endpoint did not return a Location Header” is still there and no photo posts, but the text does.
aaronpkso right now, the only way to support websub for non xml/html formats is via the HTTP header. maybe this issue would be better described as wanting to allow non-http-header discovery of hubs for alternative content types
[manton]On that WebSub issue, I'm not sure it's possible to have a standard discovery mechanism in JSON, because most JSON formats are completely different. Treating JSON as if it's XML would remove one of the reasons people like it: that it's simple and not overly abstracted to do everything.
Loqi[manton]: [miklb] left you a message on 2017-07-07 at 3:44am UTC: I tried disabling/blocking xmlrpc in WP but no dice on bypassing it and using micropub.
[manton]I also completely agree that HTTP headers are the best, most general way to discover endpoints. I just don't think they can be used exclusively because not everyone can control their own HTTP headers.
[manton]I was a little surprised that even WordPress.com, which should be able to use HTTP headers, advertises WebSub links in HTML <link> tags instead.
[manton]And my takeaway from that was that if WordPress doesn't use HTTP headers, what hope is there of your random Jekyll static-based site. ? Not that we should give up... But just that it's not practical to require HTTP headers.
voxpelli[manton]: totally agree with the Jekyll use case, though just like Atom defines a way to extract generic feed links, so could JSON Feed and then the only thing one would need to do would be to extract the links
voxpelli(And if some other spec also bases its discovery on link relations, which is fairly common, then it could easily/automatically support JSON Feed)
[manton]During the early discussions of JSON Feed, the idea of a more generic "links" array that mapped essentially to HTML/XML link tags was raised. The thought at the time was that it would be flexible but not as clear as direct support. So that's why the spec has feed_url, hubs, next_url, etc. instead.
sketchessQuestion: I would like to get a clarification. What difference lies between a meta tag regarding the author and the microformat regarding the author, for example? I try to accomplish a decent understanding of usage and processes of meta tags and microformats.
voxpelli[manton]: if one supports generic link relations then JSON Feed and another spec can have support for another without anyone having to support the other one specifically - neither WebSub or it would have to explicitly support the other
[manton]@voxpelli I'm not sure that's actually different than what we have today. The argument I heard in that GitHub issue was that since WebSub doesn't describe what to do about JSON, new formats can't be technically compatible with WebSub. And that would be true whether there's a field called hubs or links or something else.
voxpelliThe static site argument is a good one and ensuring new static files can be supported through an as standardized as possible mechanism would be good
aaronpkpubsubhubbub 0.4 said that the publisher MUST include an HTTP header. it also said that if a subscriber doesn't find an HTTP header, it should look for the rels using other mechanisms that are not defined.
voxpelliOn the case for link relations – we even use such extensively in our internal document format at work: https://github.com/Sydsvenskan/doc_format So even proprietary formats can make use of such decouples standards
aaronpkso what I'd like to see is a new issue on websub about the fact that the websub discovery step is missing the ability for non-HTML documents to include a discovery mechanism inside the document, whereas that was previously possible in pubsubhubbub 0.4
voxpelliWell, it wasn't really broken, because PuSH 0.4 never really allowed for anything but Link headers, it just pointed out what to do with non-compliant legacy feeds, no?
[manton]That's what I was trying to get at with my original GitHub issue, to "relax" it to allow other implementations that aren't defined in the spec. But maybe it needs to be re-worded. (I'll also review 0.4, since I'm curious about the change now.)
voxpelliYeah, the wording of the current issue became such that it suggested that the relaxing should happen by not imposing any kind of standard discovery mechanism at all
aaronpkthat's what I was saying about jumping to solutions. it frames the discussion around the particular solution rather than around the actual problem
[manton]Re-reading the issue, I'm not really sure how to rephrase it without saying the same thing. But I agree that the current issue got derailed and we should start over.
Loqi[aaronpk] What I would really like to see is a generic link rel discovery method for JSON formats in general. This would be something JSONFeed could adopt, and also something that WebSub could recommend as the discovery format for JSON documents. At least this...
[manton]One other point: the reason JSON Feed has "hubs" instead of "rels" or "links" is also because I think real-time notifications is critical to building new platforms. Burying it under an abstraction will hide it, meaning fewer people will implement it or know about it. (See Dave Winer's comment today, "What is WebSub?")
[manton]I totally get the desire to have compatibility between multiple JSON formats. But I also think some things are important enough that they can be promoted. For example, we all probably agree that "title" should be a top-level item and not a "name": "title", "value": "Hello" pair.
snarfedi think that part of the docs is actually wrong, and the current code will happily still truncate p-bridgy-twitter-content if necessary. i'll update the docs.
tantekaaronpk, pretty sure we had several issues about other websub discovery either for specific other formats (JSON(LD)) or making it somehow "extensible" so that folks could make up their own formats in the future and somehow make it work (handwave handwave)
tantek.com edited /User:Tantek.com (+139) "/* indieweb community */ archive remaining 2014/UK/Scheduling etherpad links to wiki pages and update ehterpad links to link to wiki pages instead" (view diff)
snarfed [miklb]: does quill show the HTTP headers that your site returned to the micropub request? i'm curious, since it definitely does set the Location header: https://github.com/snarfed/wordpress-micropub/blob/master/micropub.php#L229
[miklb] snarfed, no, it just shows the red error message at the top of this issue https://github.com/snarfed/wordpress-micropub/issues/69 (without the 400 Bad Request error)
voxpelli aaronpk: I guess you've seen the additional comments on https://github.com/w3c/websub/issues/107 – I find the conclusion there a bit tricky :/
jonnybarnes if http headers and html link tags disagree what should happen?
[manton] During the early discussions of JSON Feed, the idea of a more generic "links" array that mapped essentially to HTML/XML link tags was raised. The thought at the time was that it would be flexible but not as clear as direct support. So that's why the spec has feed_url, hubs, next_url, etc. instead.
aaronpk i just commented on that jsonfeed issue https://github.com/brentsimmons/JSONFeed/issues/46#issuecomment-323165723
@rubygems jekyll-webmention_io (2.6.4): This Gem includes a suite of tools for managing webmentions in Jekyll: * Tags *… https://rubygems.org/gems/jekyll-webmention_io (twitter.com/_/status/898270449896898560)
tantek maybe this is what I was remembering: https://github.com/w3c/websub/issues/84#issuecomment-277903071
Loqi It looks like we don't have a page for "micropub client" yet. Would you like to create it?