@PinoBatch↩️ Currently it's a protocol (microformats2 and Webmention over HTTPS). It needs indexing and recommendation ("Related" stuff) to make a complete platform, as one job of a platform is to surface thoughts written by other users. (twitter.com/_/status/1083152671786369024)
jeremycherfasWell, that's a drag. The Comments plugin on Grav seems to have vanished all previous comments. None in backups either. I'm somewhat peeved.
aaronpkyeah I need to look at that too! that might be enough of a reason for me to stick with overcast instead of using overcast and castro half the time right now which is really annoying
[schmarty]my site is very pull-based when it comes to responses. e.g. i would expect a listen-of property to be a URL, and the build process would look up the details of that URL.
[schmarty]my endpoint already needs to look for nested h-cards in tags, so maybe i will generalize that. i'm really tempted to model how X-Ray turns everything into a URL and then includes a "refs" property w/ the nested info.
jeremycherfasI know no Python, but your script is useful and informative. I'm guessing I could try to use it as the basis for a PHP version, maybe sending to Grav rather than Known.
aaronpkbecause right now the photo property is treated as a poster image for the video, so it's not clear how to represent a post with both a photo and a video
aaronpkoh hm, so like if you have a list of media where the order is important and is a mix of photos and videos, then you don't use the "photo" and "video" property in h-entry at all?
sknebelhm. might be necessary. but what I remember was more along the lines of having an object instead of an url in the video property, and that object has the video url, the poster url, potentially an author, ...
sknebelno good idea right now, especially none that parses neutrally (no specific features in the parsers, does something useful for existing implementations)
sknebelalthough if you add objects you still end up with objects in the u-video then too... but at least it could have a reasonable "value". not sure how many consumers can handle that though (they should in a way, but it's an easy enough shortcut to take...)
[tantek]At some pong you’re trying to pack too much into one h-entry and should really be using a collection post, especially with mixing media and caring about ordering etc
ZegnatIt does lists examples that people have already published though, which may be more telling than any markup brainstorming (ie: how have people actually done it)
aaronpkone of the goals of the jf2 format was to have values not change type all the time, so i'm hesitant to switch the `photo` values to objects when there is alt text
[eddie]if you don't want it to change from the photo url, I think the second most intuitive (to me) would be to store info about the photo url in the refs array by the photo url
aaronpk[eddie]: i'm thinking a new property "meta" next to "refs", which uses the URL as the key and the value is an object, and for now I will only include "alt", so e.g.:
aaronpkthe one thing is that, like refs, it's a property that exists in the same namespace as the microformats vocabulary properties, so that means this can never represent a mf2 property called "meta"
[davidmead]ok. this is weird [aaronpk] . I disabled a plugin (InstagramShim 0.1) and I got 2 photos in OYG to post to my site. The third and fourth fail.
[eddie]ahhhh that makes sense. As you said though, that's probably a safe bet, anything on an actual h-entry called meta would probably be ambiguous and have a better descriptor.
aaronpkspeaking of headers, I seem to be getting different CDN URLs depending on whether I fetch from my browser or from curl, but these are both from my laptop
[schmarty]aaronpk, eddie: interesting choice to have X-Ray pass along "meta"! i have a bunch of "filemeta" stuff from the early days of my jekyll site when i wanted to indicate caption files for videos, whether a photo was a 360 panorama, etc. kind of excited to see some movement on this for jf2.
[schmarty]it's an interesting difference of pattern, though. e.g. ownyourgram sends person-tags as nested h-cards in the tags array, and the mf2 spec calls for a nested object in the photo array when alt text is present.
[schmarty]i'll need to find and re-send one to check it out, but back in the day i had to write special handling on my micropub endpoint to deal with the nested objects.
snarfedmaybe useful sometimes, particularly for visually imparied people, but personally i plan to omit them in granary, since i'd rather draw a clear bright line between user-provided and auto-generated
[kevinmarks], eli_oat, snarfed and [tantek] joined the channel
[kevinmarks]Given that we are changing mf2 parsing to nest alt text, making jf2 match seems reasonable, though by default that would create a "children" property in jf2
Zegnatmf2 is pretty consistent to, basically whenwver you run into an object that you didn't expect you can use the object's "value" property to get it's string value instead.
[tantek]have you figured out a methodology to evolve jf2 that doesn't involve one-off design decisions for every new feature? or is that going to be just the way jf2 operates moving forward?
[tantek]not really a unique thing, as we considered the lang implications simultaneously so we came up with an approach, both re-using a pattern from e-* properties, and more broadly handling a class of features, rather than just a one-off
aaronpkthere's been some talk about helping out apps by providing things like dimensions of images or duration of audio files, so the same place that alt text lives can also hold those