[keithjgrant]cweiske I think I used Babel for some async/await... That may have gotten moved out into the micropub-helper lib, though. I should do an audit to see if I can cut that now
www.svenknebel.deedited /Main_Page (+56) "/* Upcoming Homebrew Website Club meetups */ add SF manually (didn't have p-location, thus not captured by script)" (view diff)
schmartyrecently aaronpk brought up the issue of determining whether a post with a mix of video/photo urls is a "multiphoto" post, a video with a poster image, ...
schmartymega-plumbing-alert - i am thinking about this more in terms of how to encode this info when creating or editing a post with micropub and less in terms of how to markup and consume this info once it's in a post.
schmartysknebel, zegnat: thanks! next up i need to think about how far to go with it. for example, poster makes sense for a video, but a video could also have multiple caption/subtitle tracks associated, each with their own info (url, language, name).
ZegnatYou’d almost consider an h-video at that point, as it becomes a collection of video sources, text sources, audio sources. But it is hard to hit the right spot between granularity and actual useful data.
schmartyi am thinking about this for /Screech. it currently supports uploading a single audio file and will extract file size, duration, and ID3 data which are sent as custom properties.
schmartyi want to add micropub media endpoint support, which would put it very close to supporting multiple media files per post. at that point, the custom attributes on the post make less sense.
ZegnatIt might make sense to send it along. Though if I am implementing a micropub endpoint for audio files I wouldn’t *trust* the size and duration from the client. So I would still check them myself if I needed that data.
sknebelif one treats a micropub client as trusted (and generally that's the case I think), doing stuff like that in the client also has benefits. e.g. the server doesn't need complex code to parse audio/video files for their metadata
schmartysknebel: that was my thinking when i built it into screech. i knew the browser would have access to the file and i trust my micropub client to send accurate information to the server, so the micropub server can simple store it.
ZegnatIt is the case if you yourself have written both the client and the endpoint. But for an open ecosystem? Or say an endpoint you wrote for WordPress blogs? I wouldn’t want to trust the incoming request too much.
ZegnatWe aren’t really there yet, with current implementations, anyway. But if you are thinking about documenting metadata in a spec like (even just normative / encouraging) I would think about the security aspect.
schmartyfor properties that can't be derived from the file itself (e.g. the existence of poster image or separate captioning tracks), perhaps the nested object makes sense.
schmartypersonally i think i will move or duplicate some of the other metadata-handling onto the endpoint side, since what is desired and how to store it are going to be site-depended.
ZegnatYou need some way to say “resource A is linked to resource B by way of X”. In this case A would be a video and B an image, X describing the poster relation.
[grantcodes]Ahh the end of a busy week of indieweb dev; wrote a custom token endpoint, wrote a custom micropub and media endpoint, updated my micropub library, updated my micropub chatbot and rebuilt the together reader prototype