Jonathan Yee
https://github.com/jonyeezs
•
Feb 21
Nicolás Álvarez
https://twitter.com/nicolas09F9
•
Feb 21
EdwardHinkle
https://github.com/EdwardHinkle
•
Feb 20
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.
manton
https://github.com/manton
•
Feb 20
@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?
snarfed
https://github.com/snarfed
•
Feb 20
...also, of course, i've now realized that while this mf2py feature is great, it doesn't actually quite fix this issue, since this is on the consuming side, where i don't control the parser.
@aaronpk, depending on your usage, you might consider asking granary for format=mf2-json instead of format=html, since that won't have this problem! i'm guessing you reported this on behalf of someone else who's seeing granary html output in a feed reader, though, so you don't have that luxury either.
adding blank p-name is totally reasonable. will do.
manton
https://github.com/manton
•
Feb 20
@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.
kaa
https://micro.blog/kaa
•
permalink
@aaronpk WAAAAAY to much work. @replies should just be an option that gets published on your site somewhere automatically. Feature request.
adrianizq
https://micro.blog/adrianizq
•
permalink
@aaronpk I added the webmentions plug in on my WP site. Just not exactly sure how to use it. Can you link an example?
adrianizq
https://micro.blog/adrianizq
•
permalink
@aaronpk I’m a complete noob. How do I do this???
mdhughes
https://micro.blog/mdhughes
•
permalink
@manton Which makes replies problematic, since they're only hosted on m.b right now. I need a way to have my replies end up on my site, permanently.
Zegnat
https://github.com/Zegnat
•
Feb 16
It doesn’t return the Microformats JSON, it converts it to its jf2 format first.
It might be worth opening an issue on jf2 to see if they want to keep an explicit name property. Their “author” syntax says it “consists of a name” and more, but that’s not marked as a MUST. For a jf2feed on the other hand name is a SHOULD.
The real question is, do you see any reasons for postponing this change because of your use of a mf2 parser as a service? I think not?
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.
Zegnat
https://github.com/Zegnat
•
Feb 16
Documenting from yesterday’s chat, because nobody could remember this and I can’t find it elsewhere:
So I think the (as of now) latest proposed spec change would be:
p-name MUST NOT be implied if there are any explicit p-* or e-* properties, or any nested microformats.Currently all mf2 items have a name property, because of implied name. If we change this, some code using the parsers could fail if it assumes a name is present.
Here too I will just document an answer given in chat, this time by @aaronpk:
may just mean it has to be released as a major version number [of the parsers]
Assuming something like semver is being used, any major version bump should signify possible API changes to the user. I too don’t think that would be an issue.
There might be an issue if someone is using parsers-as-a-service, e.g. always getting their mf2 parser output from php.microformats.io. But I don’t think anyone ever advertised their online parsers as a service?
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.
jsorge
https://micro.blog/jsorge
•
permalink
@aaronpk @brentsimmons Thank you! Why would anyone put more than one feed on a page?
