Update like, repost, and bookmark UI based on Micropub server support

[manton]

Here's a quick proposal for returning what properties a Micropub server supports, so that a client like Indigenous could know to hide or rename the common choices in the UI. This needs to be discussed more in the IndieWeb community, but want to file this issue so that there's a place for it.

https://indieweb.org/Micropub-brainstorming#Query_for_supported_vocabulary

I'm specifically thinking of Micro.blog, which currently has no public "Like" feature, and where bookmarks are called "Favorites". Another extremely-hypothetical example would be an IndieWeb-powered Tumblr, where reposting would be named "Reblog".

[EdwardHinkle]

@manton One great things about the IndieWeb, is that the standards are often based on real-world implementations rather than theory. So after we get some feedback from people, if you want micro.blog to be the first publisher of the supported vocabulary query, I can commit to being the first consumer.

The lessons we learn from implementing it in micro.blog and Indigenous could help discover things we'd never know when keeping it at the theory level. So I definitely would be open to trying to add this soon rather than later. I think this one might require a bit of experimentation and implementation before people really want to join in.

[manton]

@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.

[aaronpk]

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.

[EdwardHinkle]

From a client perspective I’m good with either scoping the vocabulary or using reverse post-type discovery. I do feel like the reverse post-type discovery is a pretty elegant solution. I think having scoped vocabulary could cause the response and parsing to be pretty verbose. Manton do you feel like there are any specific of the two that would work best for you from a server/service side?

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

[aaronpk]

Let's move this discussion over to the micropub-extensions repo: https://github.com/indieweb/micropub-extensions/issues/1

[EdwardHinkle]

Sounds good!

[EdwardHinkle]

Note to self, micro.blog now supports a draft version of this: https://github.com/indieweb/micropub-extensions/issues/1#issuecomment-367106122

[gerwitz]

Is some version of this already in place?

I have a homebuilt endpoint, and the Indigenous share sheet is offering me Reply, Like, Repost, and Bookmark … when in fact I am only ready to receive "note" and "article" posts.

I did see a q=config query first, perhaps I answered it incorrectly?

[EdwardHinkle]

Nope, this is not active in the current beta. So nothing wrong on your side necessarily. Definitely hoping to get this in soon. Either this next build or the one after