@yenzie↩️ Best part is that now that I have a semi-workable blog, I can return to your glorious blog entries about microformats and webmentions. ❤ (twitter.com/_/status/1282510130505031680)
nickodd, geoffo, KartikPrabhu, wagle, gRegorLove, cweiske, [tantek], vika_nezrimaya, moppy, [Murray] and [KevinMarks] joined the channel; nickodd left the channel
[KevinMarks]one thing it does have is verified historic employer emails, so it knows that I have in the past had email addresses at Apple and Google (even though I don't any more)
jmacMy reason to ask is tuning Whim's "send webmentions to everything at [given URL] that looks deserving" feature. It currently extracts all links from the first h-entry's e/p-content, and does nothing if it can't find one. I am under the impression that just using al links found under the h-entry might be more correct behavior.
[snarfed]yeah, generally you want a good reason to do anything other than "all links on the page," minus maybe header, footer, other common template links
jmacThe failure I'm envisioning: I do this with a post on my own blog, which has a "ten recent posts" sidebar, resulting in all those posts getting webmentions, which they all happily confirm and display, meaninglessly
[snarfed]right. as the site owner, you get to handle that however you want. just remember that it's technically possible for a random third party to send a wm from your home page to those posts too. unlikely though, you can probably ignore that until/if it happens the first time
jmacIs there prior art about conditionally checking for "benign cruft" webmentions like this? Stuff that is from legit sources, and not spam, but not meaningful and not worth display?
jmacMaybe I *should* skip self-wms... it'd be easy enough (and it would test Whim's blocklist feature, so hey). I kinda don't want to because I like the purely accidental "related posts" feature that self-wms otherwise create!
[schmarty]jmac: this is an interesting webmention-handling case! webmention-the-spec only requires that the source page link to the target page, but whether the target system should actually do something about that is very complicated and i would argue very under-documented.
jmacI mean the community consensus right now seems to be "If it's valid and we're not blocking the source domain, scan the source content for microformats and then display it as best we can, the end"
[manton]Thought some of y’all would be interested in this… We are working on a rewrite of our photo app Sunlit. It supports Micropub and will be completely open source. Hope to wrap up a few things and make the code public soon. https://www.manton.org/2020/07/13/sneak-peek-at.html
[tantek]Snarfed, I got a report that explicit linking of GitHub @-names in an issue, e.g. as I did in https://tantek.com/2020/191/b2/ when POSSEd to GitHub via Bridgy, does not provide any of the usual @-mention UX, e.g.: (1) disables github's normal UI for usernames and (2) more importantly, disables the notification and email filtering behavior of mentioning someone by name (my POSSE copy of that issue has been subsequently edited to remove the
[tantek]technically it's a GitHub bug (shouldn't matter *how* an author made an @-mention link, it should work the same), however it's something we could work around.
jackytbh I think GitHub's right here. It's treating plain-text as Markdown, their internal format of choice versus allowing arbitrary linkage to something else. Like with the format you've given, you could make it look like it linked to @jalcine but send it to https://github.com/totally-not-jalcine when the link's clicked since it keeps it as a link