Adding support for cross-site replies #75
Comments
|
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 |
|
Hey, just checking in to see if you’ve had a chance to think about these options at all. I feel like 2 is the most elegant, however for mass-adoption, I think 6 (the combination of 4 and 5) is probably the most wide-reaching option. I don’t think it’s a huge stretch to have someone who wants to host their own replies to update to JSON Feed or h-feed. (Originally published at: https://eddiehinkle.com/2018/02/26/9/reply/) |
|
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. |
|
I am willing to and will add support to add the input from my WordPress post kinds plugin using the jsonfeed filter in the WordPress json plugin |
|
We should revisit this. Thanks @EdwardHinkle for the post about how you're using Webmention. To add to what @aaronpk said earlier this year, it seems like |
|
Essentially if Micro.blog noticed an |
|
It sounds like this has been mostly implemented?
|
|
I think there is still a piece missing. I think this is missing the piece where a micro.blog user can have a reply in their feed and that reply gets put into their timeline. The link above is where if a webmention from a non-micro.blog user hits the endpoint, it will be entered as a reply from a specific domain. |
|
@EdwardHinkle So those replies are going into the Mentions and Conversations (or maybe just the latter?) feeds but not the main Timeline? |
|
@simon-woods Yeah I believe they will show up both in mentions and conversations, because a webmention automatically gets a @-mention added to the beginning of a reply if it doesn’t exist. They might show up in your main timeline if they are a reply to your post. I’m not sure if the timeline is a fully integrated stream or not? But yeah for everyone else they would only ever see those replies in the conversation view because they can’t follow that arbitrary domain that the reply came from. |
|
Closing this since Micro.blog's Webmention support has improved a lot since then. Thanks everyone. |
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:
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
(Originally published at: https://eddiehinkle.com/2018/02/14/5/reply/)
The text was updated successfully, but these errors were encountered: