#[fluffy]okay I’m running it with verbose debugging right now from a console instead of systemd, so I should be able to see all logs as they happen. could you run the thing now?
#GWGI was debating yesterday what I could do to demo that the token was usable.
#[fluffy]okay this is interesting, I’m getting an apparently valid redemption from you, but your endpoint is returning 400 after it does the redemption
#[fluffy]also there’s an obvious annoying deadlock condition on the Publ server which could happen if there’s too many requests happening in parallel, so, that’s fun.
#[fluffy]someday I need to look into moving publ over to asyncio
#[fluffy]but that’s an *entirely* whole other thing in python 😕
#[fluffy]oh wait never mind, that’s why I put ticket requests into a separate threadpool, so it doesn’t lock render threads.
#[fluffy]sometimes I’m smart enough to think ahead on these things 😛
#GWG[fluffy]: It is. I forgot to tell it to return something on success.
#[fluffy]On the initial ticket request I discover the ticket endpoint, and if that’s successful return a 202 and enqueue the ticket grant, if it fails you get a 400
#[fluffy]On the “automatically send a ticket if someone logs in” flow it just enqueues the ticket grant (since it already knows the endpoint) and lets the rest of the login flow happen normally
#GWGThat isn't what the ticket endpoint should return.
#GWGGoing to add this. Not sure if there should be a response body. "When a ticket is sent, the ticket endpoint MUST return an HTTP 200 OK code."
[schmarty] joined the channel
#[fluffy]I’d say maybe “When a ticket is successfully received, ”
#[fluffy]becuase like, failures could still happen. If the ticket endpoint fails to redeem the ticket from the token endpoint, for example
#[fluffy]and if the ticket endpoint is going to asynchronously make the token request it should return a 202
#[fluffy]in an ideal world all of these things would be async
capjamesg and jamietanna joined the channel
#jamietannamy POC returns synchronously (with the exchanged token endpoint response) but I wonder if maybe an HTTP 204 No Content makes more sense
#jamietannaI wonder if the caller doesn't need to know anything about whether the ticket endpoint accepted it correctly - they'll either see a ticket being redeemed, or they won't, so can go from there
#jamietannait also has the opportunity of hiding, to maybe bad actors, whether tickets were redeemed - as it may allow them to discover lengths of `ticket`s, etc - but not sure how much of a problem that could actually be
#[snarfed]conclusions: 1) caching webmention endpoints by domain is technically non-compliant but a huge efficiency/scaling win in practice. 90+% of bridgy’s wm endpoint discovery is currently cached
#[snarfed]2) webmention sending itself is a bit all over the place. mostly 201 vs 200, but often dependent on which user(s) are currently receiving most of them
#[snarfed]3) twitter is by far the biggest silo by # of wms. instagram and mastodon occasionally show up, but only very occasionally
#GWG[snarfed]: Re caching..that would be a great thing to start a discussion on
#[snarfed]I’m not at all looking to standardize the caching, I don’t know that we have many other wm senders at scale dealing with this. seems too early or incomplete to try to come up with any protocol or standard
#[snarfed]another way to put that is, if a site said “don’t cache my wm endpoint,” or “only cache it for 5s,” I doubt I’d make Bridgy obey that
#sknebelbridgy is also special in that it is something the webmention receiver signs up for
#sknebelso it having non-standard expectations is fine
#GWGI'm just really thinking about a parameter on the link
#[snarfed]sure. my points were unrelated to the specific form of that expiration/caching hint though
#LoqiA resumé or curriculum vitae (CV) is a document that represents a person's background and skills, commonly used to secure employment https://indieweb.org/resume
#jamietannado it GWG! I had fun doing mine, especially so I could get it up to date :)
#[fluffy]h-resume feels aspirational rather than practical.
#[fluffy]Given most hiring processes still want a word doc
#GWG[fluffy]: If I am doing it,. might as well shoot for the moon
#[fluffy]Like if the intention is for an indieweb replacement for monster/indeed/Glassdooretc that requires indieweb-savvy hiring processes that are then heavily biased towards members of a very specific technical community
capjamesg joined the channel
#GWGI figured that I want the page to look better, so I have to add new css, so why not some extra classes
#[fluffy]Sure, I mean, might as well add the mf2 if you’re building the HTML in the first place
#[fluffy]I’m just saying that it seems very unlikely that it’ll ever be consumed in any way other than a “look at this” demo
#[fluffy]someday I’ll get around to adding h-resume to my resume but it’s been a low priority, what with not even wanting to be employed in the first place
#[fluffy]also unlike most of my site, the resume is all handwritten HTML
#[fluffy]I mean if I wanted to be really fancy I could build it out as a series of nested Publ templates but, ugh, no
#GWGWelcome to the Indieweb, where our dreams are limited by time