#[tantek]You could reply saying hi thank you and that was your first MDN update and feedback & suggestions welcome!
KartikPrabhu and Asaf_Agranat[d] joined the channel
#[tantek]aaronpk have we considered adding IndieAuth login to the microformats wiki also? would there be a way to preserve existing user/pw logins while allowing new IndieAuth logins?
#[tantek]if we're able to make that work, I can think of a few more MediaWiki wikis that would likely also adopt a similar setup
#aaronpki suspect any time that was brought up in the past i said we would have to wait until the upgrade to revisit it :)
#aaronpkbut now that that's done, we can discuss :D
#[tantek]GWG, lots have been created & banned due to spam holes of the past
#[tantek]at this point it's too much work to moderate any new "public" wiki that an individual or small group would setup
#[tantek]hence the iteration on getting IndieAuth sign-in working for MediaWikis in general, and getting it adopted by more wikis (so it can become a "normal" thing for any new MediaWiki)
#aaronpkI do think if we expect it to be used by other mediawikis it makes more sense to build the whole indieauth bit into the plugin itself
#aaronpkthat would remove the setup step capjamesg[d] had to do with Vouch-Proxy
#aaronpkthe main advantage of vouch-proxy is that you can share the login across a bunch of different subdomains, which is useful for indieweb.org
#sknebel(also, it goes through indielogin and thus doesnt just do indieauth, right?)
#aaronpkbut then that also brings up the question of whether it should be just indieauth, or also support relmeauth to twitter/etc, which then adds the additional setup step of getting api keys
#aaronpkcorrect, vouch-proxy doesn't do indieauth itself, it does oauth/oidc to a single configured provider
#sknebelwhich is indielogin, which gives us indieauth and relmeauth?
#jacky> if that child element itself has a microformat ("h-*" or backcompat roots) and is a property element, add it into the array of values for that property
#jackyunless "else use the parsed property value per p-*,u-*,dt-* parsing respectively" means "use the property element as the value to be added to the property class that was found"
#jackyactually those are two separate things (which I kinda blame on the formatting of this page)
#sknebeli.e. the "is a property element, ..." implies "do this for each property"
#jackyI think I'm confused b/c of this phrase "add it into the array of values for that property "
#jackybecause in my head, that means with "u-author h-card u-url", I'd be adding it (the parsed h-card) to the 'author' and 'url' properties of its parent, which is _wrong_ to me
#sknebel(technically for each property type, but without measuring I can't tell you if thats actually faster in practice to make that distinction. the python parser does it that way, but not everything is python and I don't remember if that was done that way as a result of profiling or not)
#[tantek]jacky, there's a challenging balance in specs between precision and conciseness to prevent ambiguity. shorter and fewer words usually means fewer places for unintended "bugs" in the prose to creep in
#[tantek]specs have their own "specese" (pronounced like legalese) as a result