LoqiPost Type Discovery specifies an algorithm for determining the type of a post by what properties it has and potentially what value(s) they have, which helps avoid the need for explicit post types that are being abandoned by modern post creation UIs https://indiewebcamp.com/post-type-discovery
[kevinmarks]I'm saying that if you use u-photo, post type discovery will decide it is a photo post ie the photo is the primary content. If the photo is just supportive and text is primary, use u-featured
kylewm[shaners]: I sympathize. u-featured feels a bit like a kludge to make up for not having explicit post types, but I think it's worth making the distinction even if we did have explicit post types. Sharing a photo is pretty different semantically than including a vaguely related header image at the top of an article.
tantekshaners, to make your use of u-photo for the poster image work (even if/when you switched it to use u-featured), we may need to add fall back u-* parsing to <video> elements to /microformats2-parsing
tantekshaners re: "some memory of u-featured being fairly contentious and not universally agreed upon" - pretty sure we resolved all the debates/issues around it and reached a pretty good broad consensus. if you remember a specific issue with it, and we haven't documented it, please bring it and we'll refigure it out if have to!
tantekshaners, re: "feel like u-featured is adding additional vocabulary that u-photo already covers" - I was concerned about this initially too, however it's become pretty clear that capturing that author intent of "primary" vs. "supportive" content is important for more easily disambiguating, and provides a nice hook for the concept of image summaries for pages/posts of any kind that authors have been taught to publish by OGP,
tantekdespite the DRY violation, this would be a better way to mark that up though: <video class="u-featured" poster="image.jpg"><source class="u-video" src="file.mp4"/><img class="u-photo" src="image.jpg" alt="A video with a fallback image"/></video>
tantek!tell ben_thatmustbeme check out how shaners marks up his video posts with <video><source>, and consider doing the same. right now your video posts are not expressing the u-video URL since it is not on the same element as the URL: https://indiewebcamp.com/video#Ben_Roberts
kylewmmaybe like, you could publish a really simple list of hcards that just have a nickname and url. and when you query the nickname cache service, you give it your list and it fills in the blanks (avatar, social media urls, etc.)
bearI always thought a name cache would always be local and it would learn of new sources by the webmentions or micropubs it processes -- it would follow links and do a discovery of the other person's cache
tantekkylewm: also I think "using micropub" is at least semi-automated, I've always thought of "manual POSSE" as meaning using the UI of the silo directly to create a new post that is a copy of your original post.
tanteknow thinking of expanding my image+URL auto-linking to video+image+URL to make it easier to paste video URL, poster URL, permalink URL and have it all auto-combine into a <video> element with poster, source src, and fallback link inside to the permalink
kousu_xmppI found python-social-auth for Flask, which lets me consume a bunch of identity servers, but it's a nuisance to set up each OAuth backend. At first glance, IndieAuth sort of looks like I could use it instead of PSA, except it forces all of my subscribers to have a website and put up their Web Sign In links.
snarfedkousu_xmpp: honestly setting up the oauth apps for each silo is way way less work than actually writing the code for each api. python-social-auth has done the vast majority of the work for you :P
KartikPrabhutantek: I would object to this wording "Also, video posts should be your video, something you recorded, or animated yourself." in the case of a response-context. If I reply to a video post I would like to have a h-cite>u-video in the reply-context