Aaron Parecki

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?

One thing to note is these are all properties of the h-entry vocabulary, whereas other kinds of posts support totally different properties. Things like h-event or h-review where they are completely different things. Continuing down this path it would make sense to scope these properties to note that they are part of the h-entry vocabulary.

The other question is how many of the supported properties would need to be defined? If not all of them, (e.g. photo, category, published) why these ones in particular?

Is it because these correspond with post types? If that's the case, then maybe this should be somehow tied to the Post Type Discovery spec which spells out what properties map to what kinds of posts.

In that case, it may make more sense to have the server advertise which of these post types it supports, and then clients would look at the spec to know which properties to send to create those posts.

Nope, wasn't intending to hold things up, just wanted to put that there for the record.

I agree with the current proposal of having p-* and e-* and h-* stop the implied name.

I (and likely others) use xray.p3k.io as a service, so I will have to consider what to do in that case. It doesn't return the Microformats JSON, it converts it to its jf2 format first. I may just return an empty string for name if there is no mf2 name property.

No, that's not what I meant.

Only the order of the channel IDs specified will be changed

In your example 1, c has moved as well, even though only d and b were given.

To move a channel up or down...

This is equivalent to swapping two adjacent items.

I didn't give an example of setting the order of three items because I couldn't think of a UI where it would make sense, but it is still possible.

The nice thing about this approach is that the same update logic works for all the use cases, and doesn't matter how many items are in the list, and is atomic.

The before and after values are meant to represent pages of data, not necessarily individual records. In my case, the after value refers to an item that isn't in the current page. I could return a string for _id that looks more like the before and after strings, but that's just an implementation detail of my server. Alternately I may switch my before/after strings to look more like the current _id value. Either way, this difference doesn't seem important to the client.