Building a conversation platform — Part 8

Sharing content

7 min readAug 30, 2016

In the previous part we explored different ways to extend the core graph model, to incorporate some basic platform features. Specifically, we looked at so-called user actions — arrows in the graph, pointing from users to other nodes, and representing features like impressions, likes, ignores etc.

We haven’t mentioned shares yet, for a good reason. Sharing a block feels like a user action too. Pocket recommendations for example are mere signals of engagement, meant to be seen by all the followers of a Pocket user. But true content sharing is not a simple user action, and adding this feature does not even require extending the core model. Real shares may resemble signals of engagement, namely recommendations, but they also have a specific target audience attached. And that is something very hard to represent by a single arrow pointing from a user.

Obviously, the most basic form of sharing content with someone, or with some group of people, is sharing the permalink of that content with them. If blocks have permalink (which is ideally the case), then sharing that is sharing a block. This form of sharing could be called off-platform sharing, and is somewhat irrelevant in a modeling discussion.

Sharing content is about assigning audience to it. Our model already assigns audience through audience arrows:

Figure 1: author representing the source of sharing, and audience the target

Platforms tend to correlate the act of authoring content with the act of sharing it with some audience. When I publish this post on Medium, I also share it with my followers at the same time. Publishing content means the creation of a triangle between user, block and group. The author arrow also represents the source of sharing, the sharer, while the audience arrow the target of it.

We mentioned earlier that some platforms require the user to be a member of a group, to be able to assign that group as audience, and some don’t. Chats and blogs do, and the example on Figure 1 happens to illustrate such a scenario. But it’s not necessary.

So is sharing really just creating an audience arrow? What is sharing when the sharer is different from the author? In this case, sharing a block cannot just be pointing another audience arrow to it, as that would not capture the sharer. It cannot be the creation of another such triangle either, as that would assign another author to the block. How could we decouple the assignment of audience from authorship?

We might be tempted to introduce a new node type, that indirectly connected a group with a block, and, at the same time, could also be connected to the sharer. But that would require, beside a new node type, two new arrow types too, which is way more complexity than we need. Instead, we can just use block nodes for this purpose, as they connect to other block nodes, they have audience, that represents the target of a share, and they have an author, that represents a sharer. So sharing is nothing more, than prepending a node to another node. The author of the prepended node is the sharer, and its audience is the group that the block is shared to. The union of all audiences upstream is the effective audience of the block — the group of people that can discover it.

We have vaguely suggested earlier that audience arrows point to root nodes, conversation starters. Prepending a node to a conversation starter turns the starter into a reply, and introduces a new starter, with a new audience arrow. But we must keep the original one too. So the actual principle in general is — without any reference to roots or starters — that audience arrows can point to any block, and a block’s effective audience are any groups linked to it by audience arrows, plus all groups linked to its ancestors.

Figure 2: Block 1 shares Block 2 to Group 1, that shares Block 3 to Group 2

Thinking of sharing in this way is somewhat restrictive. First, users can only share content by also adding some comment or remark to the share. Unless we allow empty blocks, that can be prepended to other blocks. This is, by the way, what Facebook seems to be doing: it allows “bare” shares by allowing empty status updates. The second restriction is that content can only be shared with groups, but not with individual users. But that is a core feature of our model in general: readers are always represented by groups, that can have followers.

Notice how sharing mirrors replying, and how symmetric these basic platform features are in a graph model of conversations:

Figure 3: replying is appending, sharing is prepending

We have only discussed sharing individual blocks so far. But users may also want to share an angle (a block together with a specific next arrow), or a story, or a post. These aren’t actual abstractions of our graph model, but still do have meaning. As we suggested earlier, a story is a specific route in the graph, while a post is an entire subgraph of block nodes and next arrows. A story, in this sense, is also such a subgraph, but a linear one, without any branches. If there was a way to encode subgraphs, then this could be used to share these.

While the actual method of encoding a subgraph is not really in the scope of a modeling discussion, it is worth to mention, that one trivial way to encode a route is specifying the starting point, and adding directions to it, like instructions: “start here, turn right at this junction, and then turn left at that junction, and you arrived at your destination”. But instead of left and right, we could use index numbers, given there is a natural ordering of outgoing next arrows at every block (e.g. by creation time). So that would mean an encoding like “start at block X, then take the third next arrow, then the fourth, then the first, then the second, and you arrived”. It’s easy to see how this can be extended to encode entire subgraphs.

Such an encoding could be used in url’s, for off-platform sharing, as the trivial case of sharing posts. Opening this url would display the encoded route, with all its blocks. But there is another, more interesting method too.

We have never mentioned yet how an actual implementation of this graph model could look like, and there are endless possibilities of course. But no matter what the actual implementation is exactly, it is very likely that it has some way of indicating connecting blocks at any given block — options, where the reader can proceed to. So naturally, the question is how this list of options is sorted and filtered, if at all. This is where an encoding of a subgraph (a post) can play a role. If we made the encoded subgraph the metadata of audience arrows, then this could be used to prioritize, or highlight connections, when the reader navigates the content graph.

Figure 4: audience of Block 1 encodes the highlighted route

In the example of Figure 4, a reader who follows Group 1, sees Block 3 prioritized over Block 2 at Block 1, and similarly Block 6 over Block 4 and Block 5 at Block 3 etc, as the audience arrow between Group 1 and Block 1 encodes a route that chooses the second, the third and then the first connecting block subsequently, resulting in the route (story) of

Block 1 --[next]--> Block 3 --[next]--> Block 6 --[next]--> Block 8

Obviously questions like what would a reader see, who follows Group 2 instead, need to be answered. It might be, that a follower of Group 2 sees both the above and the

Block 3 --[next]--> Block 4 --[next]--> Block 7 --[next]--> Block 12

route (the one encoded by the audience arrow between Group 2 and Block 2) highlighted. Or only the latter. We meant this method of sharing posts more as a thought experiment, so let’s not get into the details and subtleties of sharing entire routes and subgraphs any further. I leave it to the reader to think about this.

Let’s rather continue the exploration of how the core model can be enriched with new features and applications, in the next part.

Building a conversation platform — Part 8

Sharing content

Written by Mikolaj Szabó