#bridgy 2016-09-29

2016-09-29 UTC
snarfed joined the channel
#
aaronpk
does bridgy cache webmention endpoints per URL or per domain?
#
snarfed
domain
#
aaronpk
hm this may throw a wrench into my plans
#
snarfed
known issue/deviation from spec
#
aaronpk
I am scheming something that will result in having a different webmention endpoint on my home page. The rest will be the same as it is now.
#
snarfed
aaronpk: yeah, we talked about this a while back with your expiring endpoints
#
aaronpk
well I did come to the conclusion that expiring endpoints aren't useful.
#
aaronpk
this is different though
#
snarfed
heh ok
#
snarfed
https://github.com/snarfed/bridgy/issues/528 is related, but probably not enough for your new use case
#
aaronpk
yeah this will be a regular thing
#
snarfed
i could probably make the caching smarter by caching found endpoints per url, but not found endpoints per domain
#
snarfed
still not compliant, but...meh
#
aaronpk
could probably make an exception for caching the home page endpoint separately from everything else on the domain too
#
aaronpk
if all goes according to my plans, a separate home page webmention endpoint will be a common thing :)
#
snarfed
ooh a new wm.io!
#
snarfed
filing a bridgy issue
#
snarfed
aaronpk: huh btw per-line fragment links link to the wrong date, e.g. https://chat.indieweb.org/bridgy/2016-09-28 , maybe because UTC?
#
aaronpk
yeah :/
#
aaronpk
(this is also related to private webmentions if you hadn't figured that out yet)
#
snarfed
oh btw wm spec editor aaronpk, guidance on discovery caching would be a great addition! :P
#
aaronpk
ah we talked about that last week! we realized that respecting HTTP caching headers would be a good start
#
snarfed
sure! the interesting q is whether to cache across pages, though, which headers don't specify easily
#
aaronpk
yeah. there's a way to specify that with an OPTIONS request, but we didn't like the idea of adding another request
snarfed and snarfed1 joined the channel