Aaron Parecki

This has been discussed a bit more on the IndieWeb wiki: https://indieweb.org/RelMeAuth#Consolidated_identities_do_not_carry_inherent_trust

This is a question for the RelMeAuth spec, which indieauth.com implements. I like the idea, it's just a matter of figuring out the best rel value now.

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 do think it should be a preference, tho maybe hidden by default is okay. The trick is once the channels without new content are hidden, you have to have a way to quickly show them again in case you want to be able to look at old content again.

As for the posts: Slack, IRC clients, as well as Twitter, show all the posts, not just the unread ones. I don't think I personally would use the "show only new posts" feature except in certain cases such as when I suspect there might be some old unread posts that have been buried somehow. I prefer to have some visual indicator about whether a post has been read rather than hiding it completely. In either case, you'd need a quick way to toggle between showing all posts vs showing unread posts.

My IRC client also does this and it's great

@waxpancake did essentially this for himself, and made it public: http://belong.io