Query for supported vocabulary

[aaronpk]

Let's continue the discussion from https://github.com/EdwardHinkle/indigenous-ios/issues/120 over here.

[manton]

@aaronpk I'm glad you mentioned Post Type Discovery, because to me that is the part to focus on. It seems too complicated to require spelling out every property, like category or photo. If an endpoint doesn't support accepting a category on a new post, no harm done.

What can we borrow from the Post Type Discovery spec that will help here? At the very least it seems like the Microformats class names should be consistent.

In my example (https://indieweb.org/Micropub-brainstorming#Query_for_supported_vocabulary) I included what I view as the common actions from an app like Indigenous: like-of, repost-of, and bookmark-of, but bookmarks aren't actually mentioned in Post Type Discovery. I wonder if they should be, or are they not different enough from a regular post to list separately?

[aaronpk]

Interesting, I didn't actually realize bookmark wasn't in Post Type Discovery. It looks like it was mentioned under "Other Types Under Consideration" before it was moved to the W3C repo. Now the W3C note links to the Kinds of Posts section on the IndieWeb wiki for that.

The way we were adding things to the list of types in the algorithm was roughly based on how well-established the markup was in the wild. I am kind of surprised bookmarks didn't make that cut, but oh well.

The one potential confusion here is that post types are not the same as h-* types, e.g. there is no h-reply because you use the in-reply-to property on h-entry to create a reply post. I think that just means we need to be explicit about what to call this. To build on your previous example, this could be a solution:

{
  "post-types": [
    {
      "type": "note",
      "name": "Note"
    },
    {
      "type": "article",
      "name": "Blog Post"
    },
    {
      "type": "photo",
      "name": "Photo"
    },
    {
      "type": "video",
      "name": "Video"
    },
    {
      "type": "reply",
      "name": "Reply"
    },
    {
      "type": "like",
      "name": "Like"
    },
    {
      "type": "repost",
      "name": "Repost"
    },
    {
      "type": "rsvp",
      "name": "RSVP"
    },
    {
      "type": "bookmark",
      "name": "Bookmark"
    }
  ]
}

Clients should assume that if it's not in the list, then the server doesn't support it? Of course there needs to be some sensible behavior for servers that don't return this info at all.

Would it make sense to omit note from this list since that's kind of a baseline? Or keep it in the list because it allows the client to customize the name of the button still?

[EdwardHinkle]

I think if no post-types array is returned, the app should default to supporting everything. By adding a post-types array, the server is saying, “I want to improve the UI by only including support for specific post types”. At that point, that means having note in the array is important because if the user only wants to support notes, they need to have an array with just a note.

(Originally published at: https://eddiehinkle.com/2018/02/20/8/reply/)

[manton]

That looks good to me. If a server doesn't return post-types, or if it's an empty list, a client should just do whatever default behavior it thinks makes sense. For example, it should send a Like with fallback text.

As a client developer I think I'd view the list as a suggestion. As @EdwardHinkle says, it's a way to improve the UI, but if a certain app always wants to include support for creating notes regardless of what the server says, I think that's fine too. I can imagine a specialized app that is only for creating RSVPs that should still feel free to send them even if the server omits RSVP from the list.

[EdwardHinkle]

Yep, exactly. Or a specialized app like Teacup that sends ate and drank posts. Those should still go through regardless.

As you said, @manton, it's more of a suggestion but especially a suggestion for generalized Micropub application, as opposed to specialized.

[aaronpk]

That makes sense, and also fits nicely with the idea of this as an extension rather than part of the base spec.

[manton]

Added a few post types to Micro.blog's q=config if @EdwardHinkle or anyone wants to play with it.

[aaronpk]

As of a few weeks ago, Quill now supports this extension. If the server returns a list of supported vocabulary, Quill disables the links to any interfaces that use unsupported vocabularies. This should help reduce the confusion when micro.blog users use Quill, since now they won't end up on an interface that fails to make a micro.blog post.

[EdwardHinkle]

I added support for this into my website, Quill worked great! Now I have something to test Indigenous with.

I also created a section for this on the extensions page: https://indieweb.org/Micropub-extensions#Query_for_Supported_Vocabulary so it's easier to find and where it brings together all the software that supports this extension.

[swentel]

I've added support for this in the drupal indieweb module to return the supported post-types. Indigenous for Android is next.

[dshanske]

I would like to add to this proposal querying for properties like visibility in order to know whether the client should display an option for it.

[dshanske]

Would that be 'properties' in the config query?

[dshanske]

Also, would suggest config return a q array noting what expanded queries it will accept for the same reason.

[dshanske]

This is now stable.

[jamietanna]

Is there any reason that this implementation doesn't mention which properties are expected for a given post-type? If we're looking towards autogenerated Micropub clients, I would be envisioning the flow as being:

GET /q=config
{
  "post-types": [
    {
      "type": "note",
      "name": "Note",
      "properties": [
        {
          "property": "content",
          "required": true
        },
        {
          "property": "mp-syndicate-to",
          "required": false
        },
        {
          "property": "category",
          "required": false
        },
        {
          "property": "photo",
          "required": false
        },
        {
          "property": "mp-photo-alt",
          "required": false
        },
        {
          "property": "published",
          "required": false
        }
      ]
    }
  ]
}

Alternatively, to remove this from q=config, which is getting a bit big:

GET /q=post-types&post-type=note
{
  "type": "note",
  "name": "Note",
  "properties": [
    {
      "property": "content",
      "required": true
    },
    {
      "property": "mp-syndicate-to",
      "required": false
    },
    {
      "property": "category",
      "required": false
    },
    {
      "property": "photo",
      "required": false
    },
    {
      "property": "mp-photo-alt",
      "required": false
    },
    {
      "property": "published",
      "required": false
    }
  ]
}

Then, if the server supports Query for Supported Properties:

GET /q=properties
{
  ...
}

Which then allows the client to auto-generate the inputs for a given post-type.

[manton]

I like this. I wonder if it could be simplified to just the list of properties without the required field. I feel like in practice, almost everything is optional. If it was just properties: [ "name", "content", "post-status", "published ], that hardly takes up any space and it could always be included in q=config, making it more obvious and requiring fewer API calls.

[jamietanna]

I've not looked at how many other Micropub servers operate, but isn't it quite common to have certain fields as required? I.e. I'm writing this comment on Micropublish and it requires in-reply-to and content for a reply type.

Screenshot

(Originally published at: https://www.jvt.me/mf2/2020/07/x7ik3/)

[manton]

But a client that is sending a reply already knows that the reply URL will be required. I guess I'm not seeing how in practice the required would be used. It adds some complexity for both clients and servers. And what if a server declares that they require a property that isn't even supported in the client? Just speaking for the Micro.blog client, I would have to ignore most of the required properties if they didn't make sense anyway, such as requiring "name" for microblog posts.

[jamietanna]

So my angle on this is to have a client that is completely auto-populating. It's not necessarily something that will be useful for everyone, I admit (and is a slightly different interaction model than we usually use).

But I think it'd be quite nice to be able to point a Micropub client to a Micropub server, and have it render an editor for all the given post-types, with all the given properties, instead of needing to build the client with some awareness of what is required.

(Originally published at: https://www.jvt.me/mf2/2020/07/gayvo/)

[manton]

By the way, I think this discussion should be moved over to #8.

[jamietanna]

Does anyone expose this as a standalone query, too, or is it only on q=config?

(Originally published at: https://www.jvt.me/mf2/2020/09/7sdde/)

[manton]

I've only seen it implemented with q=config. It's not much data so it's convenient to have it in an API call that most clients are going to make anyway.

[jamietanna]

I've implemented this as part of the general call to q=config as well as the specific query q=post-types.

(Originally published at: https://www.jvt.me/mf2/2020/09/pe6ij/)