getindiekit
Add support for enriched posts
The current micropub implementation is bare or minimal. It would be helpful if the micropub server would query the source url (the page I reply to or like) and add the h-entry details as extra (nested) yaml header. So instead of
like-of: https://example.org/blog/hello-world
it would post something like
like-of:
url: https://example.org/blog/hello-world
name: Hello World
author: John Appleseed
This could then be used in my Hugo templates to parse and show richer interactions.
https://github.com/microformats/microformat-node https://github.com/microformats/php-mf2
Adding to what metrbil stated in their example, dt-published as well from the source page would be lovely. I am very interested in this, as this reduces friction for an average user in adopting the IndieWeb.
Edit: @paulrobertlloyd , I've read your code on the older IndieKit extensively and I do not think I'll be able to contribute something to your standards, but I'm happy to have a chat about any issues and talk to the IndieWeb community as well, in case there are roadblocks to this. I could maybe push out a draft for you to refactor as well -- but once again, I doubt it will live up to your code quality! 😊
I started looking at this this week. Think the approach I’ll take is to update mf2tojf2 to optionally populate the reference property for each property that includes a URL (expect url). I can then make this an option within Indiekit.
Sorry, I have no prior experience with the jf2 spec. This is probably my cue to go do some more reading. :-)
Have spiked support for this feature in https://github.com/getindiekit/indiekit/tree/147-enrich-posts. It can be enabled with the following setting:
indiekit.set('publication.enrichPosts', true);
(Appreciate lack of documentation makes this practically impossible to test at the moment. Documentation is next on my list).
However, this is the sort of output this feature generates currently. Would this work @metbril @hirusi?
---
date: 2020-08-31T22:12:53.545Z
title: A note I recently posted
bookmark-of: https://paulrobertlloyd.com/notes/1598906215/
references:
https://paulrobertlloyd.com/notes/1598906215/:
url: https://paulrobertlloyd.com/notes/1598906215/
type: entry
published: 2020-08-31T21:36:55.552+01:00
content:
html: <p>Watched the Eurovision film, with predictable consequences. 🎶 <em>I’m
in double trouble tonight…</em></p>
text: Watched the Eurovision film, with predictable consequences. 🎶 I’m in
double trouble tonight…
name: Watched the Eurovision film, with predictable consequences. 🎶 I’m in
double trouble tonight…
---
Test
Currently this will output every Microformat property found at a destination URL, which includes all its content (HTML and text versions), which seems a bit much. However, seems difficult to decide what additional information about a source should or should not be included (and how you might later configure those options). While a nice idea, I’m half tempted not to pursue this.
To explain why something like this is desired or useful in the first place, consider two posts:
- The currently published implementation would yield something like: Liked https://example.com
- However, to improve the reader's experience, we would like to change it to potentially something like: Liked A story of multiple examples by Jane Doe published on 2020-09-01.
...where:
-
A story of multiple examplesis the name/title of the post and links to the post -
Jane Doewould be the author's name which would link to the author's home page as we understand from their post -
2020-09-01would be the date time of the post, separate from when we acted on this (by liking/reposting etc.)
A correctly marked up h-entry will also carry a nested h-card for the author's info. Would the references include these properties?
Regarding content.html and content.text properties, my understanding is that they would be very welcome. Although IndieWeb makes it optional, it is recommended. This would apply to any kind of post.
Regarding what properties to include in general, I am unsure of what the correct way here is.
I also brought this up in the IndieWeb IRC yesterday, and this was the response:
hirusi (@whitelights:matrix.org)
Would anyone be able to weigh in here on what properties should be included by a Micropub server? https://github.com/getindiekit/indiekit/issues/147#issuecomment-684484035
jacky
hey hirusi
I just checked that ticket out and it's something I'm wrangling in my micropub server as well
the approach mentioned (that using a 'references' field') might be the best bet
it keeps things a bit DRY when you have multiple posts referencing the same field (like how I'm a chronic like and repost kind of post)
hirusi (@whitelights:matrix.org)
yeah but what all properties do you include and which ones do you leave out? it seems kind of obvious to suggest that published should be included, but why? what's the guiding principle here?
also, hey jacky 👋
I'm taking published just as a quick example above ^
[grantcodes]
Why not just store the full parsed microformats? Then you can choose to show whatever you want.
jacky
^ I do that (specifically the HTML tbh) and then use whatever I need
[tantek]
^ this [grantcodes]++
@hirusi Ah nice, seems like I may be on the right track here, then. Thanks for enquiring!