Now that the reblog apocalypse has been avoided for now - let’s talk a little about the use case of “I want a reblog within the chain to get the quote unquote appropriate recognition it deserves”.
This got me thinking about a reply from tumblr staff about the usage of the reblog graph. Honestly, I would love to know what is being used behind the scenes to generate this app (is this just React.js/Vis.js that queries the underlying relational databases with a limit clause and eventually after someone presses “get more nodes” it eventually breaks their browser? I digress).
In any case, let’s talk about the “requirements” that I saw come back from my dash regarding the issues with the now rolled-back reblog update. Of course, this is based on a super small sample size and does not encompass the breath and depth of what has been brought up to the staff. But just for funsies:
The original poster (OP) should be able to receive “metrics” (number of reblogs) of their post.
The original poster (OP) should be able to receive all comments / tags from reblogs of their post.
The current block mechanism is a non-negotiable. A blocked user should not be able to reblog or comment on a post by an OP that has blocked them.
Under the cut, let’s answer the question, what can we do with reblog graph and can it address the “reblog chain” use case the staff wants “solve”? Short answer is yes. And we can solve this fairly simply with the very limited information that I have.
I’m going to make some assumptions here:
The information is stored within relational databases and possibly a graph database (though I have doubts, because a graph database would be incredibly expensive if they managed to do this per post/per reblog if we’re talking about any of our major graph database providers)
A reblogger wants to be notified or know their influence in the chain, where influence is the number of reblogs or likes on their specific post.
A reblog is always considered a separate node, so the situation where A -> B -> C -> B will never occur, because a node with an id of B will only occur 1x and only 1x.
The blocking mechanism will prevent a reblog node from occurring in the first place and thus, we won’t have that within the graph.
Short answer, yes. You can do this in a graph and this can and possibly may be used to answer this “reblog chain”. And I think this can be done fairly easily while maintaining the current reblog/like utility. This could be a fairly straight forward query to write a graph query language like OpenCypher/Gremlin.
Your graph query would look something like this:
Given the root node, you want to count each child node, where the edge between the root and the child node is considered a reblog. Now, per child node, you want to count each edge that each child node has to another child node, and this would be recursive until you hit the end.
The root node would have the total combined value of all edges in the graph
A child node would only have the total counts of all of its children.
Let’s take an example:
Original Post A
|-Reblog B
|-Reblog E
|- Reblog G
|-Reblog C
|- Reblog D
|- Reblog F
In this scenario: we would get the following:
OP Post: 6 reblogs
Reblog B: 2
Reblog C: 2
Reblog E: 1
Reblog D/F/G: 0
Now, in terms of user experience and where would they put it? I’m sure they can get those requirements pretty quickly From all the feedback forms that they got :)
All this to say, the reblog graph definitely fits this use case for aggregation and for lineage and chaining. Give users the option if they want to see this on their reblogs via a dropdown or something.
as someone who works with graph viz on a daily basis, the reblog graph is cool, but should not be considered a replacement for the current reblog utility.
At the core of it, Graph visualizations and databases are meant to help uncover relationships such as the potential influence of a particular reblog or help discover at which point did a post become viral. It could also be used as a discovery mechanism (e.g, I like this particular post, what other similar posts should be suggested? How many of my mutuals reblogged a similar post?) But, for the average user and the utility to assess the notes and comments of a post or subsequent reblogs? this is not the right use case and place for it.
Common challenges I hope has already been tested is the possibility for “dense nodes”. These are posts with thousands potentially millions of reblogs, which isn’t uncommon for heritage posts. Will this affect the latency of the users’s browser? I did see that they also cap the number of nodes shown on the graph, which is a necessary requirement for visualization/latency reasons. However, does this break some of the utility of a graph visualization or graph in the first place if not everything can be shown?
I admit, I don’t have the full use case, persona docs, behind this, any unit tests, data points, etc etc to make an informed comment about how the reblog graph was developed and why it was chosen for it’s purpose, but from experience? There are a heck of a lot better databases for designing a blog (e.g., Key-Value stores). A graph database and visualization for retrieving notes/tags is not one of them.
If there’s anything that I’ve learned from my work life is that graph databases/viz are really neat. But for the average use case and the average person (even those in tech), Graph databases are a really hard sell when there are so many simpler options.
