[manton]gRegor: The Ruby gem. Actually looks like I’m on an older version, but quickly skimming the commit history I don’t think anything with this has changed. An exception is being thrown when using `URI`… e.g. `URI("mailto:asdfasdf")` will fail. Fix seems straightforward to catch the error and just ignore those URLs, but I haven’t looked closely.
Loqi[preview] [Shaun Harrison] What is the correct way to validate a user delete request in ActivityPub?Mastodon signs it with the key of the user being deleted, and when you request the key, it returns 410 so it's not really clear to me how you'd validate that signature.#activity...
[tantek]speaking of caching, I'm curious what's the latest "best practice" for caching webmention endpoints, either from a particular URL or for a whole domain? Like I believe Bridgy does some degree of caching / inference of wm endpoints it has discovered, and AFAIK such behavior is beyond (outside the bounds of) the Webmention spec
[tantek]I am particularly curious in the context of "large" systems that may want to "turn on" sending Webmentions, but would require them to do potentially LOTS of Webmention discovery traffic, perhaps repeatedly on the same URLs / domains for heavily "shared" links/domains
[tantek]Two part question really: what are current Webmention senders doing in terms of caching discovered wm endpoints (either page or domain level caching or both) ?
[tantek]and second: is there a way to indicate in your Webmention link rel that that discovery may be cached by the discoverer for some amount of time, like a week or a month?
[tantek]and 2a: is there a way to indicate in your Webmention link rel that that discovery may also be re-used for OTHER permalinks (or your entire domain), and cached as such, for some amount of time?
[tantek]^ obviously both of these questions could be applied to link rel discovery methods in general, however, Webmention is a good specific example of link discovery which has numerous implementations of varying scales that we can learn from
[tantek]yes absolutely. you might edit the contents of a blog post in minutes certainly over hours. whereas it's very unlikely the wm endpoint for that blog post will change in minutes or hours.
[tantek]some rel values, like "stylesheet" the consuming code has always already retrieved the source HTML, so there's no need for such a caching directive
[tantek]step 1 retrieve HTML, step 2 link rel discovery in that HTML to find a URL, step 3 process that URL. we are talking about step 2. http status codes, cache headers are about step 3
Loqi[preview] [[tantek]] yes absolutely. you might edit the contents of a blog post in minutes certainly over hours. whereas it's very unlikely the wm endpoint for that blog post will change in minutes or hours.
btremIf your page changes in minutes, and you expect a ua to retrieve a new copy (using e.g. cache-control: max-age: 120 etc.), is there a large cost to looking at the rel attributes again?
[tantek]also I don't believe you can meaningfully use that for the *existence* of the endpoint which is the problem we are trying to solve here, vs. the *results* of using the endpoint (which is what HTTP caching applies to)
sknebelpotentially one could have a pattern to rerun discovery for a cached value if the endpoint starts to return errors, but that would mean the endpoint would need to stop working once it isnt responsible anymore. which means it'll go wrong in practice
sknebelquestion of the scope of caching is also fun. per-page? - limited use, but ok for things like bridgy probably. per-domain? likely to cause issues as soon as setup get a bit unique
[snarfed]wish I could hang out for more of this conversation! sadly I'm afk for most of the day. all this ^ sounds reasonable so far. my one concern is, whatever mechanism we end up with, it may only see a small amount of adoption, like anything opt-in
aaronpkif we end up with something like `<link rel="webmention" href="..." cache="30d">` i would be happy to add that with some reasonable default value to the webmention.io setup docs
aaronpkultimately a webmention sender might decide to ignore the hint anyway, like bridgy might want to set its own minimum caching time to avoid someone saying only cache this for 1 minute or something
[tantek][snarfed] agreed that we need to solve this even only for link rel discovery consuming code, without requiring a new mechanism for link rel discovery publishers
[tantek]is there an existing cache time string format we can re-use for the attribute value rather than make up something new? e.g. the "type" attribute on link/a uses the same (or a subset of?) HTTP Content-Type
[tantek]oof I had forgotten we asked for / proposed duration in HTML <time> as an option, and lacking anything better I'm fairly certain I would have referenced re-using iCal there
[tantek]as in, yes you may cache this discovery for a week, vs you may re-use this discovery on other posts on this domain, or domain home page (or both) for a week
aaronpki suppose the way to avoid the opt in problem is to instead recommend some default behavior for senders, and then if a publisher knows the default is wrong for some reason, can use the cache indicator to suggest an alternative
aaronpklike if I know that bridgy (and most others) are caching a webmention endpoint for my whole domain for 24 hours, and I have a particular page where I want to use a separate special endpoint, I could add an attribute that says "actually don't use this endpoint for the rest of the domain"
[tantek]so even if a sender does use your default wm endpoint for a "particular page", you can redirect it serverside to the special endpoint as a repair action
aaronpki forget the status code but one of them is meant for that, where the HTTP client is supposed to re-send the post body parameters to the new url
aaronpkrather than the browser behavior which is to make a GET to the redirected-to location (like after you submit a form you get redirected somewhere)
aaronpkone problem with not having my own posting interface in my site is i have to first figure out how to represent things in microformats in order to make a micropub request to my site 😂
[schmarty]I would also love to work up something for "animated GIFs" which are now best-practiced as videos with varying degrees of autoplay and loop counts allowed, and image fallbacks (and don't forget alt text)
[tantek]aaronpk, [schmarty] the answer to "how do I post a new type of thing" is the same as it ever was. Use the closest existing "generic" type for it and a hashtag, get experience publishing it, and then if there are multiple people doing so (with a consuming code use-case) we can figure out markup for interop
[tantek]if your goal is (primarily) your own implementation, using a hashtag to "subtype" should be sufficient for your code to detect and alter presentation accordingly
[schmarty]that approach is interesting for something like a "gif" - but also any video with a poster image or image fallback. i'd send `u-video` and `u-photo` (with `alt` on the `u-photo`?)
[schmarty]aaronpk: i am interested in an mf2 client for posting panoramic images so i am happy to chat about it and maybe slap something together. i've been enjoying my recent ports of my bayside.pub micropub clients to PHP and i think micropubkit is near a good place to make it quick.
LoqiIt looks like we don't have a page for "micropubkit" yet. Would you like to create it? (Or just say "micropubkit is ____", a sentence describing the term)
Loqi[preview] [pixelfed] We are working on OIDC support, and exploring IndieAuth!The Sign-in with Mastodon feature uses Mastodon specific APIs and is a temporary measure until we get OIDC in place and other platforms support it!#pixelfed #oidc #indieauth
[schmarty]aaronpk: it's my attempt to package up PHP controllers and middleware common to micropub (and indieauth) clients. i tend to hack on it locally and it's not packaged at all so it's a secret to everyone. https://git.schmarty.net/schmarty/MicropubKit
LoqiIt looks like we don't have a page for "silorider" yet. Would you like to create it? (Or just say "silorider is ____", a sentence describing the term)
[manton] gRegor: The Ruby gem. Actually looks like I’m on an older version, but quickly skimming the commit history I don’t think anything with this has changed. An exception is being thrown when using `URI`… e.g. `URI("mailto:asdfasdf")` will fail. Fix seems straightforward to catch the error and just ignore those URLs, but I haven’t looked closely.
[tantek] speaking of caching, I'm curious what's the latest "best practice" for caching webmention endpoints, either from a particular URL or for a whole domain? Like I believe Bridgy does some degree of caching / inference of wm endpoints it has discovered, and AFAIK such behavior is beyond (outside the bounds of) the Webmention spec
aaronpk oh right, i should have remembered that, because there's a specific note to not use that in OAuth https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-15.html#name-307-redirect
[schmarty] aaronpk my "previous work" https://indieweb.org/User:Martymcgui.re#Pano_micropub_client
Loqi It looks like we don't have a page for "micropubkit" yet. Would you like to create it? (Or just say "micropubkit is ____", a sentence describing the term)
[KevinMarks] There were at least a couple of variations - panoramic/spherical and cubic iirc
voxpelli We spoke of IndieAuth and the Fediverse a few days ago, triggered by Pixelfed, now they posted: https://mastodon.social/@pixelfed/110731182392091206