Open jalcine opened 2 years ago
I've been doing this by manually setting the published
to a time in the future, then it doesn't get made visible by my site until after that date
That's the same process for my site currently, since it acts like a Micropub client as well, it even sets an upper band when fetching posts to prevent any future ones from coming back (measure twice, cut once). I'm hoping that such a change could encourage windows of post delays. I haven't considered what it would look like to see such a post in a feed (I guess for the site owner, it could show with a hint that it's yet to be published).
(Originally published at: https://jacky.wtf/2022/4/SI/SIny43uWRCS_993GX2xy-Rsz)
After checking out /publish_delay and having a little ramble in #indieweb-dev, I'm proposing a slight consideration (two actually) for Micropub servers.
Using ISO 8601 Durations
The first idea is to allow the passing in and the relative parsing of ISO-8601 durations to fields. This would allow the ability of delayed publishing, defining an event ambiguously in the future, and even for server-related expiration on posts.
The second idea is very specific to publishing. It would be allowing a suffixed value that maps to a duration to be used. So instead of providing a
published
andpost-status
value, you could sendpost-status=published+PT3M
. The Micropub server would see this, marked it as published but compute the value ofpublished
by the current time on the server (or however it determines 'now') and adding the duration to that time. This puts it squarely in the world of publishing, and I do think that this might be simpler to implement.Being candid, I like the first option more because it expands it to other fields. But I can see the latter being more useful for clients that want to make smaller changes. Thoughts? I do plan to implement this in a few weeks.
(Originally published at: https://jacky.wtf/2022/4/ka/ka0LHRB7-z7M0MknPFd3iENk)