#microformats 2026-02-25

2026-02-25 UTC
plantroon, simoneti, gRegorLove_, [tw2113], oaktownchop, DREADBEEF, glacier and glacier1 joined the channel
#
glacier Hello did something happen to the other #indieweb channels on IRC? I can't find them on Libera.chat
#
[tantek] What happens when you click / tap that channel name in your message?
#
glacier Nothing happens
glacier joined the channel
#
glacier I can't find them on the list search either
#
glacier huh, oddly if I manually wrote slash join #indieweb it works
#
[tantek] Yep, they're unlisted to mitigate bot/spammer auto discovery via /list etc
#
[tantek] Join #indieweb-meta for more on that topic
#
glacier Oh thanks, that makes sense.
ancarda joined the channel
#
glacier It might help to put a message on the https://indieweb.org/discuss page to say so because at first I wondered if the channels had been removed
discountzen joined the channel
#
[tantek] There are already direct joint links there I believe. What would be the point of noting anything more? No need to /list when there are links you can directly click
#
[tantek] direct join* links
#
glacier oh I'm using waterfox and I don't really have a protocol to join IRC links via it so it just came up with an error
#
glacier hence looking in /list
#
glacier some users (like me) might expect to be able to find the channels via /list since they used to be findable that way
#
[tantek] probably worth an FAQ
#
[tantek] added. take a look glacier and see how this reads to you: https://indieweb.org/discuss#Why_are_indieweb_channels_missing_on_Libera_list_search
[KevinMarks], gRegorLove_, barnaby, IWSlackGateway, Saphire, btrem, [manton], mandaris, gRegorLove__, [Jo], [capjamesg], [Murray], [aciccarello] and GWG joined the channel
#
btrem Apropos of our discussion around read only feeds for events and contacts: there's a `h-card` brainstorming page on the mf wiki. It says brainstorming should be around vcard, since h-card is a port of vcard. But maybe it makes sense to brainstorm there for a read-only `h-card` feed? Or should it be elsewhere? Or nowhere?
#
btrem Oh, and separately I could begin a brainstorming section around a feed of `h-event`s, too. Or not.
#
[tantek] might depend on the level? like if it's purely property vocabulary, brainstorming in the context of the upstream vocabulary makes sense. if it's something beyond the property names, then maybe on the h-card level?
#
gRegor I think brainstorming pages are mostly historical. If it's proposing new properties we usually use github issues
#
[tantek] brainstorming is more open ended yeah
#
[tantek] for specific change proposals like new properties github issues are the way to go
#
btrem I guess I'm asking more like is there any point in gathering examples if they exist, or at least documenting the need.
#
gRegor I feel like there's a github issue for feeds of any h-*
#
btrem I sort of forgot about github issues.
#
gRegor https://github.com/microformats/h-feed/issues/3
#
Loqi [preview] [dshanske] #3 Do Not Restrict H-Feed to Only Contain H-Entry
#
GWG You rang?
#
btrem Yes. I remember reading that issue. I might have even commented on it, But I can't be sure.
#
gRegor In practice, I think the indieweb wiki has examples of h-feed of h-card, and h-feed of h-events. I have both
#
gRegor Loqi preview rang, GWG :)
#
btrem I don't have any h-feed of h-card. But I do have an h-feed that has more than just h-entry.
#
gRegor and yep, looks like you commented :)
#
btrem Huh. My brain still stores and retrieves things. How about that?
#
btrem Well, I'm inclined to gather information on this, unless you think it's a waste of time. I mean, it's not like I'm dying to file issues. But I have done a fair bit of STFW (and CTFS). :-D
#
btrem Any takers on that last initialism?
#
gRegor I'm not sure what either initialism means haha
#
gRegor Adding information to that issue would be great! I was just consider we should probably consolidate the examples from the earlier https://github.com/microformats/h-entry/issues/16 into that h-feed one, probably close the h-entry one
#
btrem Cursing the @#$!@ standards!
#
btrem Hmm. Thinking out loud here for a moment. Suppose there's an `h-feed` which contains `h-entry`s and one `h-card`. Does that imply that the `h-card` is the author? I seem to recall that it does but I can't be sure.
#
gRegor h-feed.author property does that, not a child h-card iirc. https://indieweb.org/authorship-spec#Algorithm
#
btrem That /appears/ to be determining authorship of an h-entry, including h-entry in an h-feed. What about author of the h-feed itself?
#
gRegor Sorry, clarifying: `h-feed` with a `p-author h-card` property is the author of the feed.
#
gRegor Without the `p-author` property, the `h-card` would just be a child element, like a feed of contacts
#
gRegor *child microformat
#
btrem Excellent. One less thing to worry about.
#
btrem One example demonstrating the need: https://learn.microsoft.com/en-us/answers/questions/4533257/read-only-contact-group If you're not busy, read the answer. It's really, um, revealing.
#
btrem https://github.com/microformats/h-entry/issues/16#issuecomment-3962096631
#
Loqi [preview] [btrem] There appears to be no read-only subscribe-able address book format, only CardDAV, which is both overkill and difficult to implement. Consider these Reddit posts: - https://learn.microsoft.com/en-us/answers/questions/4533257/read-only-contact-group -...
#
[tantek] btrem, yeah an h-feed of h-cards would be reasonable for that
#
btrem And an h-feed of h-events could be a readonly calendar.
#
btrem I feel like the next step is to figure out how email apps/clients manage address books, internally. And how calendar apps manage events, internally. Then maybe we can figure out how to bridge one to the other. Am I thinking about this correctly?
#
[tantek] That's certainly a reasonable approach. Iā€™m not sure there is any one "correct" approach but rather a variety of different possible paths
#
aaronpk i never realized h-feed was limited to containing h-entry
#
aaronpk "email a word file" is wow
#
gRegor Yeah, the spec says it but I'm not sure how often it's enforced in practice. I ran into an edge case in Monocle where a feed had h-entry and h-cite, and it showed all of them, even if the h-cite was kind of a mistake (it was meant to be inside an h-entry)
#
btrem aaronpk: wow indeed.
#
capjamesg btrem I agree re: the utility of a h-feed of h-entry
#
gRegor Which is kind of a feature, not a bug. I was briefly confused because I didn't recognize the name/url in Monocle :)
#
btrem gRegor: sorry, I commented in the wrong repo. :-( Is it bad form to delete that comment? That'd be the cleanest way to put it where it belongs without repeating it all.
#
gRegor no worries. I think that's fine if you want to repost it. I was going to manually copy comments over later.
#
btrem As I pressed the "comment" button, I was thinking, wait, issue 16? I thought it was 3?
#
[tantek] yeah I think it would be fine to generalize to composite h-feeds, with heterogeneous children
#
btrem slaps forehead
#
gRegor And may not need additional properties to identify the type of feed. A consumer looking for h-feed of h-cards could ignore any other h-* in the feed, and warn if it found no h-cards.
#
btrem Or warn if it found other h-types, if so-configured.
barnaby joined the channel
#
btrem [tantek]: yes, doubtful that there's one approach. That will be part of the climb.
#
btrem I sent an email to my nephew, who happens to work for Yahoo building their iOS email app, hoping to get some information on how they do it. Probably he'll reply "no idea" and that'll be that. But hope springs eternal.
#
[aciccarello] I need to see if I have any h-recipes in my h-feed
#
[aciccarello] I may have left them h-entry on the feed page
#
btrem I definitely have h-recipes in my h-feeds.
#
[tantek] I use h-recipes to make things for my h-feeds šŸ™‚