Eddie Hinkle

🐛 New issue for issues by microdotblog

Adding support for cross-site replies

This issue is for an in-development idea of being able to get a reply post into the micro.blog system when the post is created on an external site.

This issue was raised by @aaronpk in the micro.blog slack:

When I see a post on micro.blog that was originally posted on someone's site, clicking the timestamp jumps me to their site. Then when I reply from Quill posting to my site, micro.blog never sees that reply. Due to the fact that i don't explicitly syndicate to micro.blog (in that it is pulling from my feed as opposed to twitter where I have to also send it to twitter) I'm not actually sure what the right solution here is So in the mean time I've been copying my reply by hand and pasting it into the micro.blog UI, so it's two steps to reply to those posts

I have also experienced the same issue.

There was a short brainstorming session on the micro.blog slack. The outcome was the following possibilities and drawbacks:

1. Replies via Webmention

One way to get replies into the micro.blog system is the idea that we should send a webmention to micro.blog with the source post being the reply. Micro.blog could then parse the reply post and when it finds a mf2 in-reply-to markup, if the url being replied to is in the micro.blog system, it would be considered a reply. One problem is how the external site knows to send a webmention to micro.blog. One possibility is if the original post (the one that is being replied TO) contains a u-syndication link to the micro.blog version of the post. However, one issue is since the original post gets to micro.blog via feed parsing, there is no obvious easy way to send the u-syndication value to the original post.

2. Micropub Syndication

Another option is when the reply post is written and published on the external site, the external site could send the reply post via Micropub syndication. This has been seen in use by silo.pub in order to syndicate to twitter, facebook and GitHub. The difference being that instead of needing to use a third party service, this Micropub Syndication would be built into the micro.blog service. Because Micropub already has a way to indicate the post url you are replying to and to even return the URL of the accepted post, this seems like a pretty good option. The downfall is the user has to intentionally select micro.blog as a "Syndication Target" when they are authoring the reply.

3. Add reply mf2 markup into feed content

If one put mf2 markup for a reply post (u-in-reply-to on the href of the original post) inside of the content of JSON Feed or RSS, micro.blog could check for that mf2 while parsing the feed and integrate the reply into it's system. One challenge with this is that some people rather than building their own feed, use external feed services to parse things such as an h-feed and automatically generate the JSON Feed or RSS. This means, the JSON Feed or RSS services would have to include u-in-reply-to mf2 markup in EVERY post that contains it.

4. Extend JSON Feed with "reply"

This option would be extending the JSON Feed spec with an option "in-reply-to" attribute, that tells the feed reader that this JSON item is a reply to an original post. This would still need to be adopted by both micro.blog, anyone creating a JSON Feed as well as the h-feed to JSON Feed services, however it doesn't require adding anything new into the "content_html" section of JSON Feed. This would however, require that anyone using RSS upgrade to JSON Feed in order to syndicate replies.

5. Add h-feed parsing support to micro.blog

Instead of trying to add replies in to other feed types, it could be that micro.blog accepts h-feed as a feed possibility to use for micro.blog import. If this was the case, you could require people who want to syndicate replies to use h-feed which has built in support for "reply" posts.

6. Combination of 4 and 5

If you want to get as far reach as possible, you could merge both options 4 and 5 by extending the JSON Feed spec with a "reply" attribute but also adding support for parsing h-feeds. This would enable anyone with JSON Feed or h-feed to syndicate a reply into micro.blog

43.73 ℉Frederick, Marylandindieweb
posted using quill.p3k.io

Replies

Thanks for writing this up!
My pleasure. I figured with all the pros, cons and challenges it would be good to have a nice reference place to keep everything together
Stepping back a bit, I think we should look at the end goal from the users perspective. This seems to be a problem primarily when both people have their own website and their content is automatically pulled into micro.blog from their own feeds. With that in mind, the best solution is one which will require the least amount of behavior change as well as technical change on behalf of both people. This likely means micro.blog will have to do some additional work, but that seems appropriate since in this situation micro.blog is acting as an aggregator between two independent websites. The way micro.blog can best facilitate this kind of interaction would be to match up the replies itself, and not require any additional steps for the user replying. Since micro.blog is already consuming a feed from my site, if it encounters any posts in that feed with an in-reply-to url, micro.blog should check whether that url is one of its own, or whether it's indexed as a canonical url from someone's site that it has also previously pulled in. Then it can match up the conversation thread. If there is no match, then a perfectly acceptable first version would be to just ignore the post and not pull it in to micro.blog at all. This way neither the person replying nor the person being replied to need to fiddle with any markup or make additional feeds or make decisions about syndicating at each post. I believe JSONFeed has the concept of an in-reply-to url, but Atom/RSS do not. This means this feature will only work with JSONFeeds, but I think that is an acceptable compromise. Of course if micro.blog started consuming h-entrys that would also work but that's a different conversation.
Please note: This site is in an active redesign. Some things might be a little off 🧐