#dev 2016-08-01

2016-08-01 UTC
KevinMarks_, KevinMarks, tantek, mblaney, cweiske and loicm_ joined the channel
#
kongaloosh.com edited /collection (+227) "/* Kongaloosh */" (view diff)
#
cweiske domain ideas for the anonymous commenting platform: i-conclu.de, comment-para.de, reply-para.de, solicitu.de. which one should I use?
#
petermolnar I'd go for solicitu.de; the - is usually a problem for people to remember imo
tantek joined the channel
#
calumryan.com edited /events/2016-08-06-homebrew-website-club-sprint (+16) "/* Brighton */" (view diff)
tommorris joined the channel
#
cweiske aaronpk, domain ideas for the anonymous commenting platform: i-conclu.de, comment-para.de, reply-para.de, solicitu.de. any opinion??
#
cweiske s/??/?/
#
aaronpk I like "comment parade" the best but not sure about the hyphen
#
cweiske petermolnar also had the hyphen problem
#
cweiske s/problem/reservation/
#
cweiske commentpara.de
tantek joined the channel
#
@kevinmarks @fhwang @albertwenger working on it with webmention https://webmention.rocks/ - you get to control what you're site displays (twitter.com/_/status/760140748150874112)
#
KevinMarks_ Damn autocorrect
cweiske joined the channel
#
cweiske aaronpk, what do you think about letting indieauth servers return different final "me" URLs as the user entered at the beginnning of the process? (limited to the same domain)
#
cweiske that way we'd support the "give domain, return specific author url" use case that would apply to multi-user known instances
#
aaronpk cweiske: that's what it does currently
tantek and gRegorLove joined the channel
#
kevinmarks.com edited /content_addressing (+542) "/* Use in existing web standards */" (view diff)
tantek and cweiske joined the channel
#
cweiske aaronpk, indieauth.com does not seem to like when the federated indieauth server returns a different URL
#
cweiske I got a "expected $this, got $that" error last time I tried
#
aaronpk oh that could be. Quill and other apps I wrote support it.
#
aaronpk Filed: https://github.com/aaronpk/IndieAuth.com/issues/123
#
cweiske thanks
#
gRegorLove New chat logs look great!
#
aaronpk yay thanks
#
cweiske aaronpk, micropub spec 3.7.1: should the config response have a certain mime type?
#
cweiske and the format: is that example the full normative definition of the allowed properties/nesting?
#
cweiske or do you have a json schema for that somewhere
#
cweiske ?
#
aaronpk ah yep that's missing the json content type header in the example
#
aaronpk and good call, I should list out explicitly the fields in that response
#
aaronpk filed: https://github.com/w3c/Micropub/issues/40
#
GWG Afternoon
#
cweiske is there a micropub endpoint test tool that validates if an endpoint follows the spec correctly?
#
aaronpk not yet, but it will be at http://micropub.rocks
#
aaronpk it's on my list
#
GWG aaronpk, may I again point out how indispensable you are to the community?
#
aaronpk thanks, i try :)
#
GWG And how we need to recruit more helpers to take the load off.
#
cweiske http://micropub.net/draft/#servers does not specify that ?q=config is mandatory. should it be?
#
Loqi [Aaron Parecki] Micropub
#
aaronpk hm, i think that is correct. if the endpoint does not support syndication and does not have a media endpoint then there is nothing to return
#
GWG I don't support it yet, but I will. Maybe it should return nothing as opposed to an error
#
cweiske so clients have to copy with "400 bad request" responses or so
#
cweiske that should maybe noted
#
GWG Is it a bad request?
#
aaronpk noted: https://github.com/w3c/Micropub/issues/41
#
aaronpk GWG: it's more like a warning that the server might respond with something strange and to be prepared for it
#
GWG It should return 200, but an empty body
#
cweiske gwg, if the "q" parameter does not have a value that the mp endpoint expects, then it's a bad request from client side
#
GWG But how does it know what is supported without asking?
#
cweiske GWG, even ?q=config does not tell you that
#
cweiske you may support ?q=config but not ?q=syndicate-to
#
GWG I am more proposing they should be required to support queries even if they are empty.
#
cweiske I may also choose not to implement ?q=source
#
GWG Which is fine.
#
cweiske nothing tells you that
#
cweiske but ?q=config does not tell you that
#
cweiske so the client does not know if the 400 bad request it gets from the ?q=source query is a problem on his side, or simply an unimplemented feature server-side
#
GWG Yes
#
GWG Is that a problem?
#
cweiske it maybe
#
cweiske HTTP 1.1 specifies the "501 Not Implemented" status
#
cweiske the spec could require clients to reply with that status if a unknown "q" value is seen
#
aaronpk why is that better?
#
cweiske if the MP client sees a 501, it can carry on. if it sees a 400, it could automatically open a bug report for itself
#
GWG Isn't that the difference between knowing that something isn't supported and wondering if you did something wrong?
#
cweiske yes
#
GWG Conversely, if you are going to implement a lack of support for something, how much harder is support?
#
cweiske lack of support is an else branch
#
cweiske 4 LOC here on my MP endpoint
#
cweiske much easier than actually implementing ?q=source support
#
aaronpk some servers still won't implement that, so the client has to be prepared for it anyway
#
cweiske but if it's in the spec, then clients could point fingers
#
aaronpk in general, I want to make it as easy as possible to implement both ends
#
aaronpk so the fewer requirements the better, usually
#
aaronpk but if the server can do something that makes the client implementation significantly easier, then that's a good reason to require the server behavior
#
GWG I would say returning not implemented should be a recommended practice at the least
#
GWG But the client will have to handle both regardless
tantek and KevinMarks joined the channel