Building a conversation platform — Part 9

Browser

4 min readAug 31, 2016

In the previous part we discussed how sharing content is prepending a block to another, and assigning audience. Kind of like a reverse-reply. And thus how the functionality of sharing content does not require any extensions of the core model, unlike the introduction of likes or other common platform features.

While discussing platform features, we have touched on many different applications of our model, like publishing, messaging, commenting, storytelling, and various crossovers. We have even hinted at a “save for later” functionality, when bookmarks came up, and this application is something we will use as inspiration. This is a popular application, either as a specialized service, like Pocket or Instapaper, or as a feature of a publishing platform or a specific publication.

Could our model combine the steps of first saving some interesting content for reading it later, and then sharing it with friends or to a blog, and afterwards discussing it? How could we extend the core graph model so that it can integrate all these applications? Obviously, if we only consider content that is internal to our own platform, then we already have all the means to do these, and we are done here. But what about off-platform content?

We have been aiming for a model of content that is generic enough for as many use cases as possible, and it should not be impossible therefore to actually import content from other platforms and arbitrary sources, and convert it into our representation. It is easy to see how almost any content can be represented as a graph of blocks, and not only the content that has been created as such. The actual process of importing content, and breaking it up into a sequence or a graph of blocks, is not even a modeling concern, so we will not spend time discussing this. We will just assume that such a process exists.

What is rather relevant to our discussion, is that blocks representing an imported article do not (necessarily) have a corresponding user in our platform, that can be connected as an author to them. Instead there is a (unique) url that is associated with these blocks as a source. This suggests that the extension of our model, required to implement saving content for later from outside the platform, is a new node type, that we will call page, and a new arrow type source, pointing from page nodes to block nodes. With these two additions, our model can finally express all steps of a user first importing an article, then bookmarking it or any piece of it, also sharing it (or any piece of it) with groups, and then followers of these groups replying any blocks of it.

But this not only means a new application of the model. This is also a significant enhancement of the storytelling capabilities of our platform. These blocks that represent imported content, can not only be read by readers, but can be re-used in posts, articles, stories. These can be quoted individually, or can serve as building blocks of “cut & paste”, “remixer” storytelling. As we discussed earlier, stories are basically specific pathways in the graph of content. In this context, storytelling is less about writing, and more about editing, that is selecting the best route, the best traversal of the network of blocks. Being able to import any content into this network is a boost indeed.

There’s another benefit, in terms of conversations. Discussions on the same subject, which might be a quote or a tweet or an image, do not fragment. The block that represents the subject, gets re-used, re-referenced, re-connected again and again in each of these discussions, without any actual duplication. The block representing the subject holds all discussions on it together. And this creates cohesion.

But we can improve this even further. Our assumed process of importing content could also parse web links in that content, and represent them as block connections, next arrows, pointing from blocks of the imported article. Again, the actual mechanics of parsing web links is not a modeling concern, but if this process was implemented in a clever way, we could import content into our platform on the fly. We could unfold the web links of the original content into actual blocks, on-demand, as the reader reads and navigates through the graph of blocks, and arrives at such a link.

Figure 1: importing this article from New York Magazine creates a graph of blocks, all sourced from a page node

This way, we just turned the feature of importing off-platform content, into another application of the model: a browser. Depending on implementation, this augments the user experience of integrated reading, bookmarking and commenting, with browsing the web. A reader can import content, read through it, and through any other that is referenced by it, bookmark some of it, link pieces of it, creating new routes, that other readers can take, share parts of it, that others can reply to and discuss — all in one place. We unlocked the complete flow of

browse, bookmark, edit, share, discuss

and all in the framework of the same graph model.

We can see how minor additions to the model can unlock quite complex features and applications, thanks to the interplay of these new and the existing elements. Exploring ways of extending our graph model is a fruitful discussion, so we will carry on in the next part.

Building a conversation platform — Part 9

Browser

Written by Mikolaj Szabó