gRegorLovemicro.blog appears to not be accepting /read micropub posts because it doesn't have a 'content' property. The mp JSON has properties: summary, read-of, and read-status
gRegorLoveHeh, haven't checked my micro.blog in a while. I need to update my jsonfeed that gets pulled in there so it doesn't include Twitter @-replies.
[kevinmarks]Summary is a legitimate thing to have in a feed, atom can have summary without content. It's RSS that fails to make the distinction, using description for both. So micro.blog should support summary
ZegnatSure, but we are talking about creating entire entries via a Micropub request. So the question is: should a platform (e.g. Micro.blog) support entries (h-entry objects) that have no content.
GWGaaronpk: I just think of it every time someone talks about summaries. My Micropub endpoint fails if there is no content, summary, or it doesn't know how to render that type of post
Zegnataaronpk, I went looking, because I seemed to recall discussions about using content as sort of a plain-text-fallback for micropub’ed posts. But I didn’t find any fallback discussion at all on the wiki. Maybe my search-foo is just weak today though
Loqi[Tantek Çelik] h-entry is a simple, open format for episodic or datestamped content on the web. h-entry is often used with content intended to be syndicated, e.g. blog posts. h-entry is one of several open microformat standards suitable for embedding data in HTML.
...
ZegnatYou’d have to do that almost on a per-post-type basis to make any sense, I think, GWG. Because the properties could be so different. And once you are doing summary-creation-per-post-type implementations, you might as well implement the post type...
Loqi[gRegor Morrill] Martijn asked if I had documented the micropub request I make for read posts. I had not yet, so decided to make some quick notes while it's fresh in my mind.
Currently, it sends an h-cite object with properties: status, url, name, author, and isbn.
...
ZegnatIf you check both content and summary properties for fallbacks, GWG, that means at least your fallback stuff is already compatible with the read posts project. Shouldn’t worry too much about that.
Zegnataaronpk, I wonder where we can best document this fallback stuff. Also, just reading your reply on GitHub “fallback for when the server doesn't recognize the other properties”. Is that any property? What if I don’t understand photo posts and I get summary/photo/content sent by a client, should I then only take summary? Even though I understand `content`, but don’t know what it means in context because of the added `photo`
Zegnatmf only says “these properties were marked up by the author”. So I don’t know if fallbacks for consuming belongs in there. Especially with mf2 parsing being vocab-agnostic.
ZegnatSo you’d say something like, Core Properties: “p-summary - short entry summary that may be used to express the entire entry when other properties aren’t recognised”?
aaronpkI realized the other day that I used to be really good at writing API docs, and I think we need something more like API docs for this than the wiki is
[manton]I thought there was a discussion a while back about how Micropub clients should send "content" as a kind of ready-to-go fallback. I'd be fine with supporting "summary" too, but it seems like there's an increasing number of different situations to support for servers. Content, summary, photo, bookmark-of, JSON vs. form params, etc.
aaronpktho actually my micropub endpoint only recognizes a few specific properties, and stores the rest it gets without looking. it's the rendering part of my site that knows about the rest of them.
ZegnatI do see aaronpk’s point though that content is a pretty bad fallback. E.g. for a photo post content is more of a note-about-the-photo. It should not be used as a fallback as it probably makes no sense without the photo from u-photo present.
[manton]I can imagine. 🙂 But it's a lot if someone wants to build a bare bones server. My Micropub endpoint is much more complicated than the XML-RPC support, which seems backwards.
[manton]I essentially do only support those in Micropub. Except for bookmarks (which is experimental still) Micro.blog pretty much just thinks everything is a blog post.
aaronpknot sure how you implemented the form-vs-json bit, but on my end I have a step that converts the form-encoded request to a JSON request so I process everything as JSON really
[manton]Anyway, I'm just concerned that the minimum requirements to have a functional Micropub server keep growing. I don't really see the practical difference between summary and content.
[manton]For the book example, I can see how a indiebookclub-aware server wouldn't want to display "content" unless the user actually typed it in, though.
[manton]To be clear, I'm going to add support for "summary" so this works better, but this issue highlighted something that I've wanted to bring up for a while, that I think the core requirements to get a working Micropub client/server could be even simpler. Don't want anyone to be scared off by all the different potential parameters.
aaronpkownyourswarm has two modes, one meant for servers that are "not smart" where the location is sent in content so that it "just works" in most cases. the other mode sends a JSON payload with a much more accurate representation of the checkin
aaronpkthe functional difference between summary and content is demonstrated by a photo post that has no caption. it would be misleading to have the client generate a summary of the photo and include that in content, since then the server would have no way of knowing whether the content was something the user entered or not
aaronpkthis is why summary is useful tho. photo seems like an "obvious" one for everyone to support right now, but it wasn't obvious at the start. like remember when twitter had no way to upload photos?
aaronpkthe micropub spec offloads all the vocab stuff to microformats to avoid duplicating that work in the spec and so that it can evolve separately. but that means you can't read only the micropub spec and know what to do.
aaronpktho it would be nice if somewhere something listed the most common properties that clients and servers support so people have a baseline to go off of
ZegnatThat may be what “Core Properties” is aiming to do. Note that properties need to have some sort of implementation support out there before going from draft to core.
[manton]I don't think a "core properties" section needs to grow much at all. There could be a very limited number of things that all servers should accept: name, content, summary, photo, date, etc. Bringing all of MF2 into the discussion really complicates things. Then if a server wanted to (for example) support book reading, it could add that on as needed.
[manton]It's a slippery slope, obviously, but I think there are basic fields that make up a traditional blog post. That is what you want most of the time.
aaronpk"location" has been a core property across a bunch of different sites for a long time now tho. twitter, facebook and instagram all let you say where you were when you posted the thing
ZegnatI think it is fine to iterate those possible new properties outside of the mf wiki though, aaronpk, and then propose them for inclusion on the page when you have real-world usage. That is one of the point for being included in the vocab anyway.
[manton]A related issue with summary/content in indiebookclub: so let's say I use summary if content isn't present. No problem. But what if indiebookclub later adds support for the user typing in some text about the book, and that goes in content. If I just display content, wouldn't it lose the book information in summary? Or would summary need to be both a summary and the content the user typed in?
aaronpkeven tho ownyourswarm uses "content" for the fallback (only in form-encoded mode), it always include the venue in the content even if the user types content in the checkin
aaronpkand I should probably add the summary property to OwnYourSwarm's JSON mode, in which case I think I would include both the venue as well as the user's content
[manton]If you don't include venue in the JSON content, then I don't think there would be any fallback text used by something like Micro.blog for the venue, right?
[manton]I need to run, so I'll catch up later. But I do think these inconsistencies between form-encoded and JSON are worth thinking through and/or documenting.
ZegnatI think it is hard to figure out exactly when to fall back to summary. In the photo/content/summary case, you want to ignore content and use summary if you do not support photo. But in the photo/content/summary/location case, if you do support photo but not location, you probably only want to ignore location rather than fallback to only summary :(
ancardaQuick question about user agents: Do you set one when you make requests to people's websites? e.g. to check if a WebMention's source links to your website
ancardaThanks, I think it's probably fine to not fake Firefox's UA. If you block that bot, all that will happen is your h-card won't be fetched. The other bots might cause, e.g. likes/replies to not show up on my website
ancardaOh, Zegnat, if you do look through your server logs, you may find quite a few hits from that particular one on one day. I sort of used your website as a test bed while I ironed out some bugs. Sorry about that; your website is the only link on my website that contains an h-card (and what a glorious h-card it is!)
ZegnatI don’t really do any statistics or monitoring on that side. So I am not likely to look at my logs before they rotate again and all traces of your bot are removed ;)
ancardaI mean, it's standard on every major web server, but then again so is "Invalid Username/Password" but that's a bit of an anti-pattern everyone does because everyone else is doing it
ancarda>In addition, this site uses the LetsEncrypt Certificate Authority, which is itself DNT-compliant and does not log your browser checking the validity of this site’s HTTPS certificate.
[manton][aaronpk] By "inconsistencies" I was thinking how the behavior of clients like OwnYourSwarm might be different depending on whether something was form-encoded or JSON. Just wondering if there is an opportunity to simplify any of this in recommendations for new client/server developers.
[manton]Maybe this is a larger discussion that could happen at IndieWeb Summit. There's a certain amount of extra complexity because Micropub has 2 flavors, so anything to simplify the "basics" that a client/server needs to support would help.
aaronpkyeah I don't necessarily think this is a spec issue, but like I was saying earlier, we do need some better guides and tutorials around this to make some of the more concrete recommendations
aaronpkin spec writing it's tough to balance being extremely specific, where there is no ambiguity about anything, with being flexible enough to evolve over time to avoid having to toss out the current spec and make a v2
LoqigRegorLove: aaronpk left you a message 32 minutes ago: feature request: can you add the micropub json docs to indiebookclub.biz visible when you're logged out?
gRegorLoveI considered adding a text field for comments / notes, which would be sent as `content`. If I do add that, I'll definitely include it in the summary.
gRegorLoveMy earlier micropub work was getting ahead of itself, so the h-cite e-content it sent is a bad example. My mp endpoint didn't parse h-cite at the time so it was a workaround to post the exact HTML I wanted.
gRegorLoveaaronpk: Thinking security with mp access tokens, do you flush them periodically from Quill/Teacup? I was wondering about that for indiebookclub
aaronpkactually, since Teacup is entirely an interactive app, it should never store the token in the database in the first place. It should use some sort of temporary session storage tied to the user's browser session
aaronpkOYG/OYS are different since those post to your website without you in front of the computer, so it makes sense that those are storing the tokens
LoqiIt looks like we don't have a page for "token revocation" yet. Would you like to create it? (Or just say "token revocation is ____", a sentence describing the term)
aaronpki'd have to add some sort of persistent storage, either to store the nonce of the revoked token, or storing tokens in a database in the first place
ZegnatI also want to implement expiring tokens. But that’s a low priority, as I tend to not use clients hosted by others, so tokens rarely leave my control in the first place
Loqi[Eugen] Generally big yikes on some of the stuff here, like the docs straight out say "the process will leak memory so we periodically kill it" like what
[grantcodes] Very alpha version of my inline micropub browser extension is online now 🙂
gRegorLove micro.blog appears to not be accepting /read micropub posts because it doesn't have a 'content' property. The mp JSON has properties: summary, read-of, and read-status
[kevinmarks] Summary is a legitimate thing to have in a feed, atom can have summary without content. It's RSS that fails to make the distinction, using description for both. So micro.blog should support summary
GWG aaronpk: Speaking of summary, I couldn't convince you to address https://github.com/aaronpk/Quill/issues/93
aaronpk Zegnat: I would expect to find it on http://microformats.org/wiki/h-entry but I don't see anything there either!
Zegnat Some chat search seems to show that, most of the time, both content and summary were mentioned for fallback. (E.g. https://chat.indieweb.org/dev/2016-08-10/1470859728768000)
[manton] I thought there was a discussion a while back about how Micropub clients should send "content" as a kind of ready-to-go fallback. I'd be fine with supporting "summary" too, but it seems like there's an increasing number of different situations to support for servers. Content, summary, photo, bookmark-of, JSON vs. form params, etc.
Loqi indiebookclub is an app for posting books you are reading to your website using Micropub https://indieweb.org/indiebookclub
ancarda For example, I have `ancarda-hcard-discovery/1.0 (bot; +https://markdain.net/bots.html#hcard)` for the nightly cron that updates my hovercard cache
dgold ancarda: see my privacy policy for my thoughts on the issue: https://ascraeus.org/page/privacy/
leg --
@celeste_reign Say goodbye to DISQUS and comment SPAM: https://indieweb.org/Webmention (twitter.com/_/status/1005866204056211457)
swentel to put 'something' on https://indigenous.abode.pub/
loqi.me created /token_revocation (+126) "prompted by gRegorLove and dfn added by gRegorLove" (view diff)
tantek I saw this link go by earlier: https://mastodon.social/@Gargron/100169277500179278