-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposed extension: refreshing metadata #27
Comments
@jamietanna What would be calling it? |
This could be done by an editor when you're updating an old post from some time ago. Granted, this is also something a Microsub client could use when it detects a post that a user's interacted with has been updated. |
Couldn't this also just be a query? |
@dshanske what would you expect the query API call to look like? I'm thinking this would either be an editor when updating a post, or could be something manual/automated that allows updating posts. |
How would the response be different than |
@manton This is reply context metadata...so data about an external url that the url in source is referring to. |
Hmm. So you would be calling in to someone else's server, e.g. the Micropub endpoint for the post you are replying to, not on your own server? This seems like an odd thing for Micropub to handle instead of downloading the post HTML again for changes, which would work everywhere. |
Not quite, this is calling your own micropub server and updating any stored metadata for a given post |
Thinking about this again, it does feel like this could be something that the Micropub server does but would be invoked by some external process. Like if it’s a property ( (Originally published at: https://v2.jacky.wtf/post/4ff97a0c-93ee-4568-9480-8157940905ad) |
Sounds more like reverse-salmention, since in this case the original post somehow sends a salmention to posts that webmentioned it. I think it's out-of-spec for Salmention and I would prefer updating reply-contexts manually anyway (because sometimes they can be used for archival purposes, e.g. when the original post gets 410-d or 451-d, I wouldn't want this to automatically propagate) |
So, I've gotten to a point with my site where my locally stored context is slightly inflating my posts (like pulling in a lot of MF2-JSON just to mark it up as a like). I'm thinking about simplifying it a bit, but this does have some benefits when looking at it. I've opened a ticket on my project that takes a bit of a different approach where I wouldn't have to check for an update, as long as the remote URL has a WebSub endpoint, my Micropub server will subscribe to that and when the page's updated, it'll automatically refresh and parse it back into MF2+JSON for inline use. I wonder if such a flow could work for you, @jamietanna. Of course, this wouldn't work for sites that don't support WebSub. (Originally published at: https://jacky.wtf/2022/7/ssa6) |
I'm planning on implementing (Originally published at: https://jacky.wtf/2022/7/-QhA) |
I store certain metadata in posts (i.e. for reply-context) which is only gathered at the post's creation time, so may be out of date over time. Having the ability to refresh this would be useful.
I am thinking something like:
This would then return either a
204 No Content
if no updates are being made, or a201/202
with the response body containing either:The text was updated successfully, but these errors were encountered: