@flancian↩️ Nice! Webmentions is another thing I really need to take a look at this weekend, do you have a personally recommended URL to ramp up on them perhaps / source for your site? (twitter.com/_/status/1344557912740540417)
jeremycherfas!tell aaronpk Just started getting an error from Telelgraph `cURL error 23: Unrecognized content encoding type. libcurl understands deflate, gzip content encodings. (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)` but as far as I know nothing at my site has changed. Not sure how to troubleshoot this.
Zegnatjeremycherfas: when are you seeing that error? Is it when you try to login to Telegraph or when you try to send out webmentions? And if the latter, does it happen when it checks your site or when it goes out to check the site you are sending to?
Zegnatalso, jeremycherfas, I just read your latest blog post on understanding JS, and you are spot on :) That function does not neccessarily need a return statement at all. The only reason it is there is so you could put in a check to see if it ran or not, but the example code never checks for that.
ZegnatI can curl that domain without any problems. Though with that said, I do think it is returning an invalid content type. The content-type header is set to `none`, which is not a valid value.
jeremycherfas"This option will change the header to Content-Encoding: identity allowing gzip to be more reliably set by the webserver although this usually breaks the out-of-process onShutDown() capability."
jeremycherfasHow important is it to have an integrity check when you are loading a script from your own domain? I noticed that Zegnat does it, so I guess it is good practice.
ZegnatThe idea of subresource integrity (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) is that you know the dependency has not changed from the one you were originally using. If your site is not on HTTPS, it could protect from MITM rewrites of resources (like when public WiFi networks try to insert their own ads/scripts) by not letting a rewritten resource load. Of course if they wanted to, they could at that
Zegnatpoint also rewrite the integrity hash so it does not make a targetted attack impossible. If your site is HTTPS and you believe to have already secured it against MITM rewrites, the only party you are protecting against is yourself.
ZegnatIt might still have value. E.g. maybe you host Chartist yourself and do not want to accidentally update it. Having the hash means you will instantly notice when the dependency was updated and you have to take a second action to confirm the update (change the hashes) or rollback to a previous matching version. But that is super marginal as far as value goes.
[Raphael_Luckom]Question for people who've done indieauth. I found a list of _oauth_ libraries for Node: https://oauth.net/code/nodejs/ . Reading the indieauth docs though, it seems like I wouldn't really get any benefit out of starting with an oauth lib vs just implementing indieauth myself. Does that sound right, or are there enough reusable parts of standard oauth2 libs that makes it worth reusing them? I'm thinking that I'll need both client and
[Raphael_Luckom]I suppose that it might be better to use an existing library for generating tokens, but I'm not sure that's a point in favor of an oauth library vs a more basic token library
vilhalmerserver was pretty easy imo, mine is only ~400 lines of go and a good chunk of that is not indieauth but the communication with the thing I use to actually authorize logins
ZegnatIf you want a client, you might be able to get there with default OAuth libraries. This year's IndieAuth spec update has focussed a lot on being more like default OAuth
ZegnatDefault OAuth just does not have discovery steps. So it does not know how to find the authorization and token endpoint by itself. It usually does not need to do this because OAuth providers provide these URLs to implementers for hard coding (e.g. Twitter only has the 1 URL). So you will end up having to implement that part of the IndieAuth spec yourself.
ZegnatWe would also be very interested in hearing how people fare using standard OAuth libs. One of the reasons the `me` parameter was made optional in IndieAuth was in response to a ticket that said using OAuth libs was impossible as long as we required it.
[Raphael_Luckom]cool, that helps. I bookmarked mindee, selfauth, and mintoken as auth server, auth endpoint, and token endpoint. If I can use an ots oauth client lib, I think that's pretty much everything I could possibly need. I saw the note about combining auth and token endpoints if you need both
ZegnatYes. Things are easier when they are combined. Mintoken is the only separate token endpoint we know of besides tokens.indieauth.com, so integrated ones are the way to go
[Raphael_Luckom][Zegnat] I've been feeling grumpy today, but I'm finding it calming to port your implementations to node. It's fun to look up the php builtins you're using and compare / translate them to the node equivalents. I like the `hash_hmac` method better than what I have to do with `crypto` in node.
[chrisaldrich], pikseladam, hoschi-it, jamietanna, pikselaxam, gRegorLove and sp1ff joined the channel; nickodd left the channel