[fluffy]well I mean, any side effect that’s happening will have already happened, and the output you’re getting is by definition the same as the output that you got last time
mblaneyI've seen pages with today's date in them and it updates every day... other than that they stay the same, so you can't rely on hashes if you want to know if the main content has changed.
[fluffy]So I fail to see a case where it’s a bad thing for there to be automatic assignment and 304ing based on the content hash. Unless you mean that this behavior also prevents you from setting your own ETag.
GWG!tell [manton] Reached out to my podcast app and one of the WordPress plugins I use re supporting JSONFeed. One gave me a generic... we'll forward to the dev team, the WordPress plugin support told me that I needed to send my request somewhere and the developer would respond about integrating with the JSONFeed plugin
ZegnatWant to drop a request-for-comment in here wrt https://github.com/indieweb/indieauth/pull/56. [dmitshur] raised a good point on whether the (confusing) redirect stuff is even needed if the client is supposed to refetch to establish `me` anyway.
[manton]@GWG By the way, unrelated… I’m rewriting some Micropub code and testing with WordPress, and getting a 403 from q=config in WordPress. Any tips for troubleshooting? Bearer token and URL look fine. (“/index.php?rest_route=/micropub/1.0/endpoint&q=config”)
[manton]@GWG I’m not sure, because usually my code defaults to XML-RPC for WordPress. I disabled XML-RPC so I can use WordPress as a better place to test IndieAuth/Micropub.
sknebeldoes the route thing work like that with WP? or does the "&q=config" need to be encoded into the route for WP to accept it - which would be a WP bug?
[manton]I tried changing my permalinks, which appears to change the endpoint to /wp-json/micropub/1.0/endpoint. Same problem, so I don’t think it’s encoding.
[manton]@GWG Would it help if I created a WP user for you on this blog? It’s just for testing so doesn’t matter if anything breaks. https://test.manton.org/
sknebelZegnat: that's an interesting one. I wonder if there is any case where the endpoint would want to have a URL along the path as a suggestion? Otherwise I don't think its needed anymore, and even that seems kinda contrived
ZegnatThe client could store the entire redirect path, that way if the returned `me` value is anywhere within the redirect path you do not need to request again. But that is just the default redirect path and would not include any keeping track of types of redirects / "canonical profile URL"
[tantek]petermolnar, in the past there has been a proposed "license" property for microformats that would apply to all the information in that specific microformat. e.g. in an h-entry, a u-license to a Creative Commons license URL would apply to all the other property values like summary, content, photo, video etc.
Zegnatsknebel: probably not. All the auth endpoint cares about is what `me` the user is likely to have entered, incase of multi-url-users (e.g. the micro.blog case).
[tantek]I'm like wait, you don't need all that, all you need is a rel=license attribute on the *existing a href link to the CC license that you're already encouraging*
[tantek]hah! tl;dr on the Google proposal: they've picked up the "license" property (per object) *exactly* as it was previously discussed in microformats years ago
ZegnatI cannot get ahead of the work assignment, the work assignment will be to implement whatever Google says, because nobody cares about the meta data and everyone cares about what Google thinks of them *shrug*
sknebelI think one problem with weather is that its somewhat tricky to make data from random stations really usable for forecasts etc. although that doesn't explain lack of pure community projects like there are for other measurements, i.e. air quality, radioactivity, ...
sknebelthat could also be a use case for a h-media like wrapper object around photos/videos/..., since they're the most likely to have a different licenses