Micropub for WordPress now supports this.

To confirm, would this mean that you would only be able to create/read/update posts that are in the draft status, and if you wanted to promote them to published posts, you would need i.e. the create scope?

@jamietanna Correct. No matter what status you passed in, everything would be set by your site as draft.

And is there a way to determine whether a Micropub server supports drafts? I seem to think yes, but I can't find a reference in the issue tracker off the top of my head

Will look into implementing this. Tracking ticket will be https://git.jacky.wtf/indieweb/koype/issues/212

(Originally published at: https://v2.jacky.wtf/post/d38997c4-bdc4-4fe8-8940-6d843e505a20)

I've been using a separate Micropub server and then doing some manual validation of the post, but being able to do this with draft scopes may be better - although there's then the risk that a bug in my Micropub server implementation means a draft-only client could promote to the live site

@jamietanna depending on how your tests run, may be mitigated by a test case that explicitly tries to post something with a "draft" scope and asserts that it is never shown to the public.

I just implemented this on my site, it was pretty straightforward.

Now a client can ask for draft scope, or I can change a client's request for create with draft, and then all posts that client creates will be created as drafts instead of publishing them.

My internal implementation is basically: if the scope of this token contains draft, then always create the post as a draft.

I like this because it means I can be more confident in testing out random Micropub clients and not worry about them publishing posts to my website before I've had a chance to look at them.

Apps like iA Writer which already were setting post-status=draft in the Micropub request can now opt in to this draft scope during login as well.

Micropublish now supports an optional draft scope when logging in. Posts are submitted to the server with post-status=draft.

I've also implemented this in my Micropub server:

• when creating a post, and the draft scope is present, the post-status is forced to draft (even if it's set otherwise in the post)
• when updating a post, and the draft scope is present, the update is only allowed when updating a draft post, otherwise returns insufficient_scope
• delete/undelete returns insufficient_scope when the draft scope is present

(Originally published at: https://www.jvt.me/mf2/2021/02/sswpb/)

Updated the wiki... there are now 3 implementations of this on the server side, but only one on the client side. Wondering if, since this feature can be transparently supported by the server, but the client doesn't necessarily need to know about it, per @aaronpk 's implementation, if the normal client+server for stable applies?

Either way, looking at the variances in implementation... The commonalities seem to be that if you have the draft scope, all posts are forced to draft status, even if set otherwise.

The questions come at other decisions...although this could vary in implementations, worth discussing.

What happens if you request both a create and a draft scope. @jamietanna In your implementation, are you requiring the create/update scope + the draft scope? In my original thought on the matter, you would request the draft scope in lieu of create, and it would give you the ability to create draft posts only. I didn't give thought to updating and deleting.

Should you only be able to delete/update draft posts? Again, that could be an implementation detail, but it's worth discussing.

Indiekit now supports this.

I started with @jamietanna’s permission model, but adapted it slightly leading me to implement the following:

• when creating a post, and the draft scope is present, the post-status is forced to draft (even if it's set otherwise in the post)
• when updating a post, and the draft scope is present, the update is only allowed when updating a draft post, otherwise returns insufficient_scope
• when undeleting a post, and the draft scope is present, the post-status is forced to draft
• deleting a post is not affected by the draft scope; you can only delete posts if you have the delete scope

Thinking about the combination of draft and delete scopes made my head spin for a bit, but then I realised these are mutually exclusive; draft needn’t be read as indication regarding overall permissions. If a user should not have permission to delete files, they should not be granted the delete scope.

That said, I’ve yet to implement much UI around creating posts, and none around editing or deleting posts, so this may change as I start to build that out.

Here’s my consent screen:

The first 3 permissions are slightly in contradiction to each other; however selecting draft scope supersedes the first 2 (if you select create and draft you would still be able update posts, but only as described above; selecting that option would make no difference in this case).

I think this is fine...ish. I could possibly progressively enhance the form such that if you select the draft scope option, the create and update scopes get checked and disabled automatically.

indiebookclub requests draft scope now, in v0.1.2.

The new post form lets you select post-status "published" or "draft", defaulting to "published". If you have granted draft scope, it will default to "draft" instead.

I wasn't sure if the post-status=draft option should only appear when you've granted draft scope, so currently it's always available. I noticed micropublish.net does that as well, so thought it was a safe choice. I'm open to making updates to that, though. I included the note in that release post "Your Micropub server must understand the post-status property in order to handle draft posts" to hopefully make it more clear.