#dev 2020-05-23

2020-05-23 UTC
geoffo and KartikPrabhu joined the channel
#
[tantek] JeremyCherfas, definitely worth getting IndieAuth+Micropub support into a feed reader to make it a social reader, whether or not it supports h-feed
geoffo, KartikPrabhu, [schmarty] and [fluffy] joined the channel
#
jacky so I've been reconsidering using more indieweb tech for my personal site
#
jacky gr, not personal but consulting site (like https://black.af)
#
jacky I do want to collect (approved) feedback from content I'd post on there but I'm like 90% certain since it's a commercial entity that'll run into some kind of potential problem (like Bridgy is safe for people to use but not for commercial entities)
#
jacky that said, I'm not torn on having to roll something like silo.pub (I can't find the sources for it online (this doesn't seem to be it? https://github.com/kylewm/silo.pub)
#
Loqi [kylewm] silo.pub: Micropub bridge for hosted blogs
#
jacky LOL so I was wondering for the _longest_ why I couldn't capture the responses from Bridgy w.r.t syndication
#
jacky finally figured it out (bridgy sends a 201 which I use to assume an async webmention)
#
jacky if it's async, I don't bother use the location info as the meaning of that for webmentions are a bit undefined
#
jacky this makes me wonder if there should be some sort of expected format for async webmention status URLs
#
jacky also TIL that webmention.io is written using Ruby!
[jeremycherfas] joined the channel
#
[jeremycherfas] [tantek] I’ve been trying gently but there is very little enthusiasm there.
#
jacky hmm actually it doesn't look like _anyone_ does legit status stuff for async webmentions
#
jacky as far as I can see
#
jacky I was certain Webmention.io did this
#
jacky what are async webmentions
#
Loqi It looks like we don't have a page for "async webmentions" yet. Would you like to create it? (Or just say "async webmentions is ____", a sentence describing the term)
#
jacky <sobs in "am I confused?">
#
jacky this might be new space then
#
jacky OH I misunderstood what status pages are okay
#
jacky interesting
#
jacky well tbh I think I'm going to drop support for it in Koype until we get some light consensus on this approach
#
jacky async webmentions will definitely speed things up (faster to write to redis than to a database)
#
jacky what are webmentions
#
Loqi Webmention is a web standard for mentions and conversations across the web, a powerful building block that is used for a growing federated network of comments, likes, reposts, and other rich interactions across the decentralized social web https://indieweb.org/webmentions
#
GWG I never finished async
#
jacky oh wait hold on
#
jacky what are async webmentions
#
Loqi It looks like we don't have a page for "async webmentions" yet. Would you like to create it? (Or just say "async webmentions is ____", a sentence describing the term)
#
jacky async webmentions is /Webmention-brainstorming#Asynchronous_status_polling
#
Loqi ok
#
jacky what are async webmentions
#
Loqi https://indieweb.org/async_webmentions
#
jacky that would have helped me so much lol
#
jacky GWG: how much of it did you get through?
#
jacky tbh my site silently dropped info about them
#
jacky I wanted to capture info about the status url and use it to determine if I need to poll for information or if there's some way to register a callback
deltab joined the channel
#
GWG jacky: I put a hook in to do them. Then I did a proof of concept to, when the webmention came in, to schedule the webmention processing in the background. So, not really very
#
jacky hm okay
#
jacky my processing happens in the background by default
#
jacky this would be yet another job
#
jacky eh tbh this is an incentive to refactor my webmention code so it can handle async webmentions and flag syndications that happen over webmentions to respond to that
#
GWG The WordPress code does synchronous by default, however it does have the ability to handle syndications over webmention, although that is an extension piece
deltab joined the channel
#
jacky like an extension to the syndication logic or to webmentions itslef?
#
GWG Well, everything is plugin based.
#
GWG The Webmention plugin doesn't do it by default.
#
GWG The syndication plugin hooks into the webmention plugin functionality
#
jacky ohh
nickodd joined the channel
#
GWG This happens a lot with the WordPress code
#
GWG The syndication code is separate, the Micropub code is separate...but each are enhanced when working together
[tantek] and deltab joined the channel
#
jacky hmm actually looking more into this
#
jacky it seems like bridgy's webmention responses aren't compliant to the spec
#
GWG Aren't they?
#
GWG I recall the discussion.
#
jacky like a 201 Created should be used when returning a status code
#
jacky hmmmm actually
#
jacky there's a little bit of ambiguity there
#
jacky b/c it does mention the possible existence of content
#
GWG Yes.
#
GWG That was what I recall discussing.
#
GWG It does not mandate nor forbid content.
#
jacky but bridgy returns the resulting URL _as_ the location which the specs reserves for the status URL
#
GWG Bridgy predates the spec
#
jacky this might be why my syndication stuff recently broke once I made it lean on my webmention logic
#
jacky fair
#
GWG Considering other things have implemented the same logic for webmention based syndication, if seems like it is an acceptable, if offbrand use.
#
jacky I don't know...
#
jacky like this is how implementation drift happens
#
jacky lemme look for the discussion
#
jacky I'm trying to avoid having 'snowflake' code as much as possible tbh
#
dansup snowflake ids are pretty useful
#
jacky nah it's not that - it's like having edge-case-y code
#
jacky is looking for the smallest patch that I can do this with
#
jacky my real goal is to make it so I can do better polling for webmentions so I can have the frontend update accordingly
#
dansup edge-case-y code defines the fediverse, hehe
#
dansup jacky: have you considered applying to NLnet for a grant to work on Koype?
#
dansup the last 4 people I recommend this to got accepted, the max is 50k euros up to 200k total per project
gRegorLove joined the channel
#
jacky hmm that's a compelling reason to apply tbh lol
#
jacky lol edgecases aren't great to have especially when they're avoidable
#
jacky I think I have a patch for this
#
jacky this = the pre-wm-spec stuff
#
jacky but I'm definitely wanting this to be brought to spec just so it's less confusing
[jeremycherfas], moppy, [arush], nekr0z, dckc, KartikPrabhu, gxt__, jeremych_, [LewisCowles], [prtksxna] and [schmarty] joined the channel
#
[schmarty] This is a good write up of how hard setting up static sites to use "easy" posting tools: http://robinrendle.com/notes/blogging-should-be-easy.html
#
[schmarty] The pain points in there, esp where it's unclear how to proceed, suggest good error handling and extra work to make suggestions or setup wizardry might go a long way.
[Murray] joined the channel
#
[Murray] Not sure I agree with Robin here. They say it should be "as easy as dragging and dropping a file", but that's already an option in Netlify. The complexity has been added by layering a whole backend tech stack (Git/GitHub, 11ty, iAWriter) that aren't necessary. Just write the page in HTML and CSS, drag the folder into Netlify, and it'll deploy. It's never been that easy. Sure, knowing HTML/CSS is still a level of complexity, but if you don't
#
[Murray] want to do that there's Squarespace, Wix, Medium, Wordpress, Tumblr... (and yeah, those are third-party silos so not ideal, but I don't think there's a middle ground where you can have zero tech know-how and still have total independence). And if you want the added value of version control, templating, CMS... then yeah, that makes it trickier to set up, but that's not new and it still feels a lot simpler than 5-10 years ago. Maybe that's just
#
[Murray] me 🤷‍♂️
#
[Murray] That said, I do agree with better error handling and documentation for setup. A lot of Jamstack services could benefit from hiring better technical writers and UX people
#
sknebel "just write the page in HTML and CSS" is then the complexity added instead
#
[Murray] True, but as I said at that point you don't have a choice but to use a fully third-party option, which is fine and much easier. I mean Netlify are getting close with their one-click install buttons, but you'll still need to understand GitHub etc. My point is I don't think there is much simpler workflows than what we have these days without trade offs and maybe that's okay (?)
swentel, nickodd, JC1, [jgmac1106], [fluffy], geoffo, betodealmeida, [jeremycherfas] and [schmarty] joined the channel
#
[schmarty] Haha, in my personal opinion it is not actually okay! 😂
[LewisCowles] joined the channel
#
[LewisCowles] what complexity does HTML & CSS add?
#
aaronpk compared to just writing text?... lots?
[KevinMarks] and [Murray] joined the channel
#
[Murray] [schmarty] Fair enough 😊 Who knows, maybe someone will come out with a solution one day and it'll just be a lightbulb moment, one of those "how did no one think of this before now?" type things and it will remove all the complexity without also being a third party solution
[snarfed] joined the channel
#
[snarfed] jacky: re yesterday on bridgy wm responses and async...HTTP 201 is the _opposite_ of async! it means the request has been fully handled and something new was created. 202 for async. it means accepted, not yet handled. https://httpstatuses.com/201 vs https://httpstatuses.com/202
KartikPrabhu joined the channel
#
[snarfed] aha, interesting, the webmention spec specifically offers 201 as an async response, along with 202, which is maybe surprising? https://webmention.net/draft/#sender-notifies-receiver . cc [aaronpk] ^^
#
aaronpk it means the webmention *request* was received, it says nothing about whether it was verified
#
aaronpk 201 is for when you want to return a link that can be followed to monitor the status of the request
#
[snarfed] hmm no, from https://httpstatuses.com/201 : "The request has been fulfilled and has resulted in *one or more new resources being created.*"
#
aaronpk right, the resource is the webmention *request*
#
aaronpk not the comment
#
[snarfed] i mean sure, you could say the status page is a new resource
#
[snarfed] seems like a stretch, but i gues
#
[snarfed] seems like 202 for async vs 201 for sync would be useful, but i guess don't feel strongly
#
aaronpk the reality is very few implementations should ever be doing synchronous processing
#
[snarfed] hah, sure. that's orthogonal though
#
aaronpk well sorta
#
[snarfed] guess i'm just saying clients shouldn't assume 201 means async, since that's definitley not how i read the HTTP 201 definition
#
aaronpk what's the actual issue here?
#
[snarfed] and we do want to at least allow sync handling, if maybe not recommend it
#
[snarfed] jacky's wm client assumed 201 meant async and it hadn't been fully handled yet (discussion last night here)
#
aaronpk looking at the logs
#
aaronpk isn't this more of an issue with bridgy's specific use of webmention?
#
[snarfed] maybe! as a publishing trigger, it's definitely weird and unusual
#
[snarfed] but also regardless i'd like clients not to assume 201 always means async
#
aaronpk agreed, in any case that doesn't sound right
#
aaronpk if anything 202 means async since it doesn't include a Location header
#
[snarfed] right!!!
#
aaronpk 201 means *something* was created. webmention intends that to mean the request was created, and bridgy uses it to mean that the POSSE copy was created.
#
[snarfed] the language in https://webmention.net/draft/#sender-notifies-receiver is maybe technically ok, but might not hurt to strengthen it a little re all this
#
[snarfed] right. honestly "request was created" still feels a bit weaselly to me, as opposed to creating something imho "real," but i'll try not to push it 😁
#
aaronpk again it was meant for status URLs, and also assuming that by default people shouldn't be processing webmentions synchronously
#
[snarfed] yeah, understood
#
[LewisCowles] [aaronpk] when were you only publishing text? because unless you're serving text-files, that's a strawman
#
aaronpk [LewisCowles]: *writing* text, like in a publishing app
#
[LewisCowles] Right, so there is complexity in the publishing app
#
[LewisCowles] like connecting the publishing app
#
[LewisCowles] etc
#
aaronpk if you consider logging in complexity then sure
#
aaronpk once it's working, the experience is pretty smooth
#
[LewisCowles] It's less detail oriented in one part, but there are more moving parts
KartikPrabhu joined the channel
#
[snarfed] hi aaronpk! re https://github.com/snarfed/bridgy/issues/946 ...
#
Loqi [mbifulco] #946 Bridgy is somehow getting incorrect URLs for webmentions of my site
#
[snarfed] yeah the comma-concatenating is standard from http://tools.ietf.org/html/rfc7230#section-3.2 , so python requests or something else probably is doing it
#
[snarfed] requests didn't result in that comma-ed location header in my manual testing just now, though
#
aaronpk oh you actually tried it with python just now? I couldn't figure out how to get that set up on my laptop enough to test it
#
[snarfed] right
#
aaronpk something funny is happening with that series of redirects though since the body of the page is returned at two points in that redirect chain
#
[snarfed] and bridgy definitely handles multiple redirects fine, lots of experience with that, so that alone shouldn't be the problem. _maybe_ the fact that it also included response body, but i kinda doubt it
#
aaronpk what's suspicious to me is that the final URL bridgy is choking on is an exact concatentation of the two two Location headers with a comma-space separator
#
[snarfed] hah yeah reminds me of a different bug i filed elsewhere yesterday. microsoft's conference video pages, eg https://mybuild.microsoft.com/sessions/23912de2-1531-4684-b85a-d57ac30af09e , actually return 404, but incude a body that renders and works totally fine
#
aaronpk ugh lol
#
[snarfed] so weird. https://github.com/ytdl-org/youtube-dl/issues/25363
#
Loqi [snarfed] #25363 Microsoft videos (eg on mybuild.microsoft.com) failing
#
[snarfed] but yeah aaronpk i agree, something is doing that header concatenation! just not sure what yet
djmoch_, djmoch, [tantek] and lahacker joined the channel; nickodd left the channel
#
petermolnar I need an nginx greybear wizard. Apparently setting the "expire" header in nginx negates fallbacks to dynamic content. This very simple config: https://pastebin.com/UYZf6aSH is supposed to go to index.php in every case if the file is missing - except it doesn't, because of the last block. Anyone knows how to do both: fall back to index.php if the file is missing AND set an expire header if it's present?
#
petermolnar *greybeard, typo, though in this specific case, bear might be able to help
#
jacky is catching up on discourse re: webmentions
geoffo and swentel joined the channel
#
sknebel petermolnar: try nesting the last block in the first?
#
sknebel or add the try_files rule to it too
#
jacky ah okay
#
jacky all of that makes sense aaronpk and [snarfed]
#
sknebel (or *a* try files rule, since you likely don't need all of of them for image urls)
#
jacky thanks for that clarification!
#
jacky will need to make another patch to consider this
#
jacky hm actually
#
jacky I understand bridgy was made pre-webmention-spec but this still means I'd have to keep an edge-case for bridgy since the returned URL isn't one for status checking
#
jacky (which isn't a problem; this is going to be moved to an external service soon)
#
jacky but it seems like bridgy should be leaning on a 200 instead of 201 since the stuff happens synchronously
#
jacky I'm tempted to treat 201 and 200 as the same
geoffo and [snarfed] joined the channel
#
[snarfed] again, based on the HTTP status code definitions, 201 does not necessarily mean anything async happened
#
[snarfed] the webmention spec lightly encourages everyone to do async, and lightly encourages 201/202 for that, but doesn't require it, and i'm not really entirely on board with that
#
aaronpk jacky: what responses are you trying to distinguish here? I'm confused where the actual problem is
#
[snarfed] async is better in some ways, but definitely more work for at least bridgy publish's usage. if you can't know inline in your wm sender whether a POSSE actually worked, you either have to wait and poll the status URL, or come back another time to check it, to see if your POSSE worked, and get the syndication URL to plug into your post
#
[snarfed] both of which are a lot more work for the site than just waiting for a somewhat longer webmention request
#
aaronpk oh yeah i don't think bridgy should switch to async at all
#
[snarfed] right. so one conclusion is that webmention is a somewhat convenient but also very awkward and nonstandard mechanism for bridgy publish
#
aaronpk it's an example of when synchronous webmention processing is useful
#
[snarfed] definitely
#
[snarfed] hence the wm spec might benefit from clearer language that async is nice but not required, and that 201 doesn't mean it was async
#
aaronpk yeah that paragraph could be improved, but the only real normative text there is "Any 2xx response code must be considered a success"
#
[snarfed] oh sure. all the normative stuff is fine. async, 201/202, etc are all non-normative
#
aaronpk the 201/202 and status URL stuff is intentionally underspecified in webmention because we didn't have enough consensus to document it at the time
#
[snarfed] sure! it just sounded like to some degree, jacky concluded from that part of the spec that 201 meant async. so i'm wondering if that could be improved
#
aaronpk ideally what i'd like to do is figure out if there's any commonalities among webmention implementation now, 3 years later, and actually tighten that part up
#
[snarfed] ooh sure! sounds like a project
#
[snarfed] fortunately you have https://webmention.rocks/
[LewisCowles] joined the channel
#
[LewisCowles] [petermolnar_] you don't need a greybeard, just add /index.php to that list instead of trying the rewrite. It forces it to fall back to /index.php if other URL's fail, which is what your rewrite does anyway.
#
[LewisCowles] location blocks fight to be top-dog. You could force CSS & JS into sub-folders and then your expire headers won't conflict
#
[LewisCowles] `try_files $uri $uri/ /index.php?$query_string;`
#
[LewisCowles] that is one I use on a basic website
#
[LewisCowles] unless you are also wanting to have the css etc files served from PHP, in which case move the `try_files` directive to also exist in that block as each location will need it's own overrides. It won't need `$uri/` for a js, css, xml or any file with an extension
#
[LewisCowles] https://pastebin.com/rSCA02X8 would let you have an index.php in your current folder as well as a root /index,php to fall back to
#
[LewisCowles] My work got merged into WeKan. I'm very happy about that
#
jacky I assumed it to be async b/c of the ability to return a 'status' URL ( something to check if it was completed )
#
jacky I've adhered to the spec now (200 = sync, 201 = sync, 202 = async)