[chrisaldrich]tantek, it was Jacob Hall who had asked about publicly showing aggregator "content" from someone else's site at the HWC last week. Not sure if he's in chat though.
[eddie][scojjac] my pleasure. Also, great sleuthing! One can use an http(s) Url or a custom app scheme, but in practice either through IndieAuth best practice or Apple’s OAuth 2 implementation (I don’t remember which), essentially made the case that it was best to redirect to the server and have that redirect back to the custom scheme. So both are being used
Loqipayment in the context of the indieweb refers to a feature on an indie web site that provides a way for the visitor to that website to pay (currency, gift card credit, etc.) the person represented by that indie web site https://indieweb.org/rel-payment
anon_jasrjfbq and [Forest_Johnson] joined the channel
[Forest_Johnson]Yes, it was a mixture of old code from before async/await was widely supported, example code that uses `.then()`, and just general laziness and familiarity with JS promise `.then()` API
[Forest_Johnson]Part of me prefers `.then()` too because it doesn't `throw` and rip all the way up the stack until it hits `try` . I guess its technically the same thing since I think the new standard is gonna be that rejected unhandled promises will completely blow up the app
[Forest_Johnson]failing silently and halting both very poor compared to compile time error 🙂 that's why I like golang where you have to explicitly state that you want to ignore an error, otherwise its a compile time error
[Forest_Johnson]Yeah, but I appreciate the effort they made to push "truely exceptional" errors into their place and prefer to simply return a "result" whether success or failure, rather than blowing the stack
[Forest_Johnson]yeah... or at the request-scope or even more granular level. I ended up doing that once for a relatively complex go app, having the thing log panics without crashing was very helpful to debug
Ruxtonyeah I have a few 24/7 API's connected to hospital result processing, they have things like that. It's more important they're online and doing their thing.
LoqiIt looks like we don't have a page for "410 Gone can be 302 Found" yet. Would you like to create it? (Or just say "410 Gone can be 302 Found is ____", a sentence describing the term)
oodani_, kiero_, leo60228-, deltab_, rhiaro_, treora_, strugee, cjav_dev, [chrisaldrich], really2, [scojjac], shoesNsocks, gRegorLove and [tantek] joined the channel
anon_jasrjfbqI want both humans and non-humans to be able to parse the payment data. And I also don't want each participant to host an app or anything for their wallet.
[chrisaldrich]Somehow I always find recipes feel more daunting when they say "make a portion of X, see recipe on page Y". It always makes the process feel like twice as much work somehow.
[chrisaldrich]Jeremy Cherfas, I'm just saying that it makes them feel like more work. I also hate books that don't do it. Usually the sub-recipes are far more important things to know than what's in the main recipe. Like IndieWeb, cooking is really all about having a strong foundation of multiple /building-blocks
petermolnaraaronpk: if you provide binaries for everything, most probably yes, but even if they have to compile it, it's usually painless with go. Emphasis on usually.