Proposed extension: Preview

[jamietanna]

I use a staging Micropub server to be able to preview posts before I publish them to my live site, as a way to test things out. However, it'd be nice to have this as an ability to simply have the expected Microformats2 JSON / site-specific internal representation returned to the client, so they can manually inspect it looks OK.

[jalcine]

Might be a duplicate / form of #26

[jamietanna]

So I'm thinking of this being a slightly different flow to #26 - this would be before it's published anywhere (even as a draft) and instead just be the Micropub server saying "this is what I would save"

[manton]

It's similar enough to #26 that maybe the solution is similar for both? I have that need too. Micro.blog has a "Preview" button for seeing what Markdown is going to look like, and it would be nice if that was routed through Micropub.

[grantcodes]

Kind of a cool idea, but I think this is already more or less possible with the existing api.

The way I'd do it would by saving as a draft to the server then querying the returned location for the mf2 json again. You could then delete the post if it is really just meant to be a preview.

I don't know if there was something I was missing which would make this way of doing it impractical? Server support obviously isn't going to be great, and you'd want to use something like #8 to make sure drafts are supported to prevent accidental publishing.

[sebsel]

This came up in a discussion between @tantek and me at IndieWebCamp Düsseldorf 2022.

Basicly: Tantek does not use Micropub, but he has a certain flow in which he posts his posts.

First, he sends the post to the server (step 1: save / publish). Then his posting interface shows a screen with all the discovered webmention endpoints + a Twitter preview. Pushing a button will then send those webmentions and publish to Twitter (step 2: mention+syndicate / share).

This is a bit out-of-the-box for what you can currently do with Micropub (it interupts the flow of pressing 'publish' and then seeing your post on the site), but it felt related. Tantek can do this in such an out-of-the-box way because he made this flow before the box of Micropub existed.

I personally would want a flow more like it, I think. Especially the feedback of the endpoints that are found and the Webmentions that are going to be send out. It might be something for another extension though, but I wanted to capture this usecase.

[vikanezrimaya]

Here's how I imagine it would look like in terms of request and response!

Proposed example request:

{
  "action": "preview",
  "object": {
    "type": ["h-entry"],
    "properties": {
      "content": ["Hello aaronparecki.com!"]
    }
  }
}

Proposed example reply:

{
  // MF2-JSON object processed by server - as it would appear on the website if posted immediately
  "object": {
    "type": ["h-entry"],
    "properties": {
      // Note: content was transformed to HTML by server-side normalization
      "content": [{
        "html": "<p>Hello <a href=\"https://aaronparecki.com/\">aaronparecki.com</a>!</p>",
        "value": "Hello aaronparecki.com!"
      }],
      "author": ["https://fireburn.ru/"],
      "channel": ["https://fireburn.ru/feeds/main"]
      // Note: no dt-published and no u-uid since those are time-specific and were not generated
      // If a future spec suggests the object be saved as draft, u-uid would point to the saved draft
    }
  },
  // Specifies which URLs will receive webmentions about this post if it were to be posted as is.
  "webmentions": ["https://aaronparecki.com/"],
  // Specifies syndication targets which would receive copies of this post.
  // If a string - uses UIDs of syndication endpoints as seen in ?q=config/syndicate-to
  // If an object - roughly represents the content that will be sent to the service
  // (e.g. summary for a silo intended for posting short notes)
  // Is intended to highlight potential autosuggested syndication targets based on tags
  // (currently not implemented in Kittybox - if it becomes a feature, it will be optional and highly configurable)
  // and show previews whenever the post is truncated on syndication
  "syndicate-to": [
    "https://news.indieweb.org/en",
    { "uid": "https://shortnotesilo.com/", "content": "Hello @aaronpk!" }
  ]
}

[vikanezrimaya]

Currently I don't want to prioritize implementing extensions, but if I will develop a full-featured client for Micropub (which I plan on doing after I fix that annoying bug with my backend) I would probably want this functionality to exist as described by @sebsel.

In this case, I would probably combine this with a draft, in which case a request will simply look like posting something with "post-status": ["draft"] in properties, and this would be returned (with a u-uid but no dt-published) as a body of 201 Created, the Location header being set as u-uid of the newly saved draft post.

[jalcine]

I'm torn on this because I still think having the draft scope does a lot of what's needed here. It also provides a URL that can be used to render the content (I see no omission of that in the spec at https://indieweb.org/Micropub-extensions#Post_Status, it hints at the potential use of capacity URls to help guard them as well).

Regarding the "push to deploy/post", this sounds like an Micropub client implementation detail that wouldn't necessarily have to be baked into the spec. In fact, a suggestion of such a flow can be written on the Wiki about this. I know that I don't precisely check for this in my setup, but this issue brought it up.**

(Originally published at: https://jacky.wtf/2022/5/4E/4ErOoZHuWr9Uy-9gdeabKai6)