maxwelljoslynI accidentally webmentioned last week's HWC page instead of today's. When I fixed my u-in-reply link and re-sent webmention to last week HWC page, got an error back saying "no link to this page in the source"
aaronpkit's weird because you have to do stuff before webmention verification unlike normal where you don't trust anything about the external input until you validate the link is there
jonnybarnes, nickodd, [jeremycherfas], geoffo, cweiske and [James_Gallaghe] joined the channel
[tb]Hey [jgarber] / [jacky] any chance you guys could review my PR to omniauth-indieauth? I think it's ready now that I've fully UAT'd it with my demo app, and I'd love to get it merged so I can move on to adding PKCE and token retrieval to it (I purposely kept this PR at authentication only feature parity with what was already in the gem) https://github.com/aaronpk/omniauth-indieauth/pull/6 (cc: [aaronpk])
[James_Gallaghe]What is the accepted content of a the anchor text in an `in-reply-to` tag? I see some people use @ mentions whereas others state the name of the person to which they are replying.
LoqiIt looks like we don't have a page for "accepted content of a the anchor text in an `in-reply-to` tag" yet. Would you like to create it? (Or just say "accepted content of a the anchor text in an `in-reply-to` tag is ____", a sentence describing the term)
[tantek]so part of the challenge is re-adjusting the perspective / asking of questions to be from the user's perspective first (what user-visible thing are you working on?) and then working downward from there, rather than from the markup perspective ('in-reply-to') and trying to reason upward from there
[snarfed]GWG definitely not, largely due to scaling. the silos generally don’t give you any way to “subscribe” to arbitrary changes like that, so bridgy would have to regularly poll all 1.7M interactions that it’s ever sent a wm for. that’s not really feasible
[snarfed]it would also add an implicit promise that bridgy stores all of the wms it’s ever sent. it actually does right now (shhh), but i don’t plan fully commit to that as part of the product
maxwelljoslynWrestling with ingesting Micropubs right now. The fact that "post content" can show up in one of many parts of the JSON is getting on my nerves. For application code, I think I'll end up with something to read JSON into conveniently-shaped Python objects
maxwelljoslynBut planning to stick to JSON for storage so I don't disturb the differences between "content" "content[html]" and "content" : [{"html"} ...]
[chrisaldrich], jonnybarnes, KartikPrabhu and [schmarty] joined the channel; nickodd left the channel
sknebel(well, not hugo, but dynamic code, but similar storage principle. although I keep a copy of the originally submitted content so I can modify it automatically if I want
[schmarty]i try to keep it minimal but there are a handful of things to deal with. for example hugo requires that "title" be a string while in micropub JSON it's an array. i map "category" to "tags" because that system in hugo better matches how i use tags. i also have special handling for tags with nested structure (e.g. ownyourswarm sends tags with nested h-card data) but hugo only understands string tags.
[tb]I have a somewhat normalized relational schema that I transform into right now but I'm about to move away from that in favor of something more like what [schmarty] said
maxwelljoslynSeems like there's no avoiding a hairy map/unmap step, it's just a question of whether to do that when storing the payload, or when retrieiving it for rendering, etc. I'm leaning toward the latter for now; seems that would make it easier to implement micropub update/edit features. and tb, thanks for reminding me that I should ensure my conversion from form encoding to JSON matches the equialent MF2. Still learning about the different request