Just implemented mp-destination on my site! I can connect multiple Micropub or Twitter accounts to my site to be able to post to other accounts from Micropub clients when I'm logged in as me. This is the first step of turning Monocle into more of a Tweetdeck-like experience!
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 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?
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 Sounds great! I can implement it at any time on Micro.blog, although first I wonder if anyone has feedback on the JSON key names.
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.