Skip to content
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

Query for supported vocabulary #1

Closed
aaronpk opened this issue Feb 20, 2018 · 23 comments
Closed

Query for supported vocabulary #1

aaronpk opened this issue Feb 20, 2018 · 23 comments

Comments

@aaronpk
Copy link
Member

@aaronpk aaronpk commented Feb 20, 2018

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

@aaronpk aaronpk added this to Current Issues in Query for Supported Vocabulary Feb 20, 2018
@manton
Copy link

@manton manton commented Feb 20, 2018

@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
Copy link
Member Author

@aaronpk aaronpk commented Feb 20, 2018

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
Copy link

@EdwardHinkle EdwardHinkle commented Feb 20, 2018

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
Copy link

@manton manton commented Feb 20, 2018

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
Copy link

@EdwardHinkle EdwardHinkle commented Feb 20, 2018

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
Copy link
Member Author

@aaronpk aaronpk commented Feb 20, 2018

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

@manton
Copy link

@manton manton commented Feb 20, 2018

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

@aaronpk
Copy link
Member Author

@aaronpk aaronpk commented Aug 9, 2018

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
Copy link

@EdwardHinkle EdwardHinkle commented Aug 9, 2018

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
Copy link

@swentel swentel commented Sep 19, 2018

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

@dshanske
Copy link
Member

@dshanske dshanske commented Nov 27, 2018

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
Copy link
Member

@dshanske dshanske commented Nov 27, 2018

Would that be 'properties' in the config query?

@dshanske
Copy link
Member

@dshanske dshanske commented Nov 27, 2018

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

@dshanske
Copy link
Member

@dshanske dshanske commented Jun 28, 2020

This is now stable.

@dshanske dshanske closed this Jun 28, 2020
@jamietanna
Copy link

@jamietanna jamietanna commented Jul 11, 2020

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
Copy link

@manton manton commented Jul 11, 2020

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
Copy link

@jamietanna jamietanna commented Jul 11, 2020

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
Copy link

@manton manton commented Jul 11, 2020

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
Copy link

@jamietanna jamietanna commented Jul 11, 2020

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
Copy link

@manton manton commented Jul 11, 2020

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

@jamietanna
Copy link

@jamietanna jamietanna commented Sep 20, 2020

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
Copy link

@manton manton commented Sep 21, 2020

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
Copy link

@jamietanna jamietanna commented Sep 24, 2020

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/)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants