Complete Conversations

Earlier today I asked a question on App.Net that sparked a conversation that I think was misinterpreted as me bypassing even more of the system1 to allow people to view and interact with posts from people that have blocked them, or they themselves have blocked. While it would be a trivial matter to simply show all posts from all accounts regardless of whether blocks are in place to prevent such a thing or not, this is really not my intention. My question has more to do with completeness than anything else. The next few updates to Nice.Social will be attacking some of the more complex issues that people have been asking for, one of which is a different conversation view that will allow for a TreeView-style layout. Doing so will not be ridiculously difficult so long as conversations are complete entities. It’s when they are incomplete that the code needs to get tricky and begin making assumptions.

Allow me to illustrate.

conversation_a

In the image above, we can see a very basic type of conversation. @person_a starts it off, and @person_b replies. Eventually we see others join in the conversation and it begins to split and evolve into three distinct conversations. This is par for the course on a social network like App.Net, but there’s a problem. @person_d has blocked @person_c from seeing their posts, and @person_c wants to see the conversation view in order to better understand the flow of the conversation. What does @person_c see?

conversation_b

If @person_d blocked @person_c, the first and third conversations will be completely disconnected despite what happened in the second conversation. These two conversations may come from the same conversation thread but, for all intents and purposes, they’re completely different conversations … even if they’re the same subject with the same ultimate root.

What I posited was whether it would be a good idea to show @person_c that the second conversation did indeed happen, as they’d see it in their home timelines, anyway, and link it accordingly.

conversation_c

The difference here is that, rather than seeing every message, we would see that the second conversation includes blocked content. Again, this could be the result of @person_d blocking @person_c or vice versa. It really doesn’t matter. The conversation between @person_a and @person_b that stemmed from @person_d’s comment will appear just as they should in a second tier, and everything would be good to go. This allows for a complete view of a conversation as best as possible. As someone who has worked with databases for over 15 years, data completeness is incredibly important to me. Broken data — especially obscured, broken data — infuriates me to no end as my mind wonders if something is wrong with systems if the human interactions are "out of alignment".

Of course there are a few ways to handle the comment from @person_d. The post can be completely eliminated from the view and a disconnected conversation can be shown, leaving the reader to wonder how a branch replying to @person_d with no discernible parent record came to exist.

Another way to resolve this issue would be to eliminate anything that came after @person_d’s post. The posts from @person_a and @person_b will continue to appear in @person_c’s timeline, but they will not be able to see it in the conversation view as an entire entity.

The third, my preferred way, would be to show that a post (or string of posts) does indeed exist, but collapsed in such a way that it’s understood the material is best ignored. Of course, if a person *really* wanted to know what those messages said, a client could be configured to collect the information without an API key and display it. This, too, would be trivial for someone to add to a personal branch of Nice.Social. Heck, this could be extended to show that posts have been deleted from the conversation, too!

As I said above, when I think about doing a proper conversation view, I think about data completeness. Hiding missing chunks of data is the default answer by many, but strikes me as overly simplistic for the types of complex discussion that can arise on the App.Net platform.

Of course there is the problem of having our posts — posts that we own according to the contract of App.Net — shown to people whom we have revoked the privilege, and this is not something that I will blatantly disregard. There will be no stupid “opt out” function necessary to ensure our posts are not easily read by people we’ve blocked from view. The goal of the exercise was really more about answering the question of completeness and information display.

I’ve said this before and I’ll say it again here. No code has been written to allow a person to access or read posts that have been denied to them. This question was raised as a thought experiment with the hopes of collecting ideas from the people who actually use the network. You are free to examine the source code for Nice to confirm what I’ve said.