Bring back likeable comments

DS Dennis Schubert Public Seen by 120

Some time ago, it was possible to like comments. That feature is now removed due to some reasons. What do you think about bringing it back?

-> Decision has been made: YES, bring back likeable comments.
GitHub Issue: https://github.com/diaspora/diaspora/issues/2999


Poll Created Sun 21 Oct 2012 6:04PM

Bring back likeable comments Dropdown Closed Wed 21 Nov 2012 7:07AM

by Dennis Schubert Tue 25 Apr 2017 5:15AM

Okay. That's a clear "yes". But there are things with higher priorities right now... :)


Results Option % of points Voters
Agree 80.0% 12 CB JH JR BB DU RF DS DU E T MS M
Abstain 13.3% 2 JV F
Disagree 6.7% 1 ST
Block 0.0% 0  

15 of 143 people have voted (10%)


Jonne Haß
Sun 21 Oct 2012 6:18PM

No objections, if someone wants do it… :P


Sun 21 Oct 2012 6:23PM


Jason Robinson
Sun 21 Oct 2012 6:40PM

I did likeable this feature when it was implementable


Sean Tilley
Sun 21 Oct 2012 6:45PM

I like the feature, but we'd need to figure out a more resource-friendly way of doing this, compared to our implementation in the past.


Mon 22 Oct 2012 6:38AM

I think we have more urgent things to do, but if someone has the time to do it, why not.


Brent Bartlett
Sun 4 Nov 2012 2:18AM

Libertree is another Decentralized Social Network that is written in Ruby, and does have likable comments. I know that they don't have nearly the same membership we have, but maybe it would be a good idea to check out how they implemented it?


Fri 9 Nov 2012 6:35PM

I like it and I miss it.


goob Sun 21 Oct 2012 6:07PM

Hee hee, Dennis. I can't help smiling at your title, as 'likeable' as the connotation 'pleasing', so I'd agree, yes, let's have lots of likeable comments in Diaspora and get rid of all the unlikeable ones.

As to the 'liking' facility - I personally think this is a waste of time, but clearly a lot of people use it, so agree it would be good to implement it if it's not too problematic.

I'd not make it a priority, though, until federation and so forth are solved. Although, it it's a fairly simple task, it might make a good project for a dev new to Diaspora.


Dennis Schubert Sun 21 Oct 2012 6:09PM

I used the term "likeable" because we had a little attribute called "acts_as_likeable". But you are right, it's a bit funny. :)


Florian Staudacher Sun 21 Oct 2012 6:42PM

just for reference: https://github.com/diaspora/diaspora/issues/2999
... where we also brought up the problem, that the 'likes' table is one of the biggest in the database - which will not become any better if we add stuff that can be liked.


Jason Robinson Sun 21 Oct 2012 6:43PM

Btw, Maxwell or someone who remembers why it was removed - was it due to technical issues in the code at the time, federation or just purely a design decision?


Sean Tilley Sun 21 Oct 2012 6:43PM

I seem to remember that this feature was originally taken out because it filled up the likes table in the database much faster. On a larger pod, this might cause a disproportionately large likes table, which might add some significant overhead.

While I always enjoyed comment likes as a feature, I guess what it boils down to is: "Can bigger pods handle it?", and "How can we make them federate again?"


Jason Robinson Sun 21 Oct 2012 6:47PM

Well it is clear this feature should probably not be just activated as before - if in principle people want it, maybe some fresh ideas would be necessary.

It does make me wonder though how it can make the DB so big? After all, it really only needs 4 columns - id, commentid, user, timestamp .. Or am I oversimplifying :P


Jonne Haß Sun 21 Oct 2012 8:59PM

Hm, wouldn't like that I think, I can already feel the confusion this would cause to users never looked at the config files. Like "Hey, Joe liked your comment too!" "He did what?"


goob Sun 21 Oct 2012 11:10PM

OK, so my vote would be 'implement it if someone can come up with a way to implement it which wouldn't put a load on the database of each pod'.


Rasmus Fuhse Tue 23 Oct 2012 12:02PM

Sean, what is the problem of the size of the table? The only problem I can imagine is that this data might be joined for the "my activities" stream to see what the user liked. But was that stream killing the performance on jd? And even if: you could insert the comment-likes in a different table than the thread-likes; and for the "my activities" stream you only need to count the likes on the threads.


Sean Tilley Tue 30 Oct 2012 9:29AM

From what I understand, the problem with the size is that it can cause a significant performance overhead on larger pods. Imagine people start liking lots and lots of comments, and for the sake of the argument, let's say that they're liking these comments every single day.

Facebook and Google+ can get away with this because they have lots of servers that they're already running on top of. Libertree gets away with this because it has a comparatively smaller userbase. Friendica, similarly, is focused on smaller hubs with more people working across the network.

While this would be fine on smaller pods, the problem is that we have a lot of bigger pods up right now, and it's going to take more than elbow grease to get proper profile exporting/importing going to mitigate the huge size of pods like joindiaspora.com.


Rasmus Fuhse Tue 30 Oct 2012 11:05AM

I still think, that this is a technical problem of the implementation - not of the feature itself. Even if you have trillions of likes in your database-table, a

SELECT 1 FROM like_table WHERE comment_id = ''1234'

should still be fast enough, if you have defined an index over the primary key.


Jason Robinson Tue 30 Oct 2012 1:22PM

So, is this proposal actually about returning the old implementation or making a new one?


Florian Staudacher Fri 2 Nov 2012 10:36AM

@jason: As I understand it, this is just about getting the picture if this is even wanted.
The implementation is not part if the proposal.

@rasmus it's not just about the speed, the columns are indexed already and it's working acceptably fast.
The problem I see is storage space in combination with row count. My phpMyAdmin shows ~66,783 rows with 118.6 MiB for about a years worth of likes on my pod with < 5 users. Only the 'participations' table can top that with ~77,899 rows and 131.6 MiB.
For comparison: the 'taggings' table has ~65,239 rows and shows only 13.4 MiB.

If we allow comments to be liked without changing anything, then a post has many comments and likes, and the comments also have many likes, which would come to a geometric or exponential increase in 'like' db-rows over time.


goob Fri 2 Nov 2012 10:46AM

It seems that the general feeling (here and in my D* stream) is that comment likes should be implemented again. Would it be worth starting an issue in Github re the problem of the database size for comments, so that people can look into this and work out where the problem occurred in the old code?


Sean Tilley Sun 4 Nov 2012 9:33PM

@Brent: I can get in touch with Rekado from Libertree, he might have some suggestions.


Sean Tilley Mon 5 Nov 2012 2:29AM

f it helps any, Rekado's version of likes on comments is here.

I'm currently trying to find a commit where we still had comment likes to compare it to, but at least this is something to work from.


[deactivated account] Sun 6 Jan 2013 3:26PM

Should this be made into an issue on github? Why not then post a final link to that issue and close the discussion, since a decision has been made?


Flaburgan Sun 6 Jan 2013 4:48PM

Feel free to do it !


[deactivated account] Sun 6 Jan 2013 10:10PM

Issue already exists: https://github.com/diaspora/diaspora/issues/2999

Is there any way to finally close a discussion on loomio?

I'd like to suggest to add the existing issue to the milestone. Can any project admin on GitHub proceed or is this a stupid idea?


Jonne Haß Sun 6 Jan 2013 10:21PM

Why has it to be in


[deactivated account] Sun 6 Jan 2013 10:23PM

No specific reason. I just thought it has been decided on so let's proceed with action. Afaik, there are currently only two milestones on GH. and Feel free to create if you think it's better in that milestone.


Jonne Haß Sun 6 Jan 2013 10:25PM

I see nobody actively working on it so I'd prefer no milestone at all.


Flaburgan Sun 6 Jan 2013 11:08PM

Yeah, we put a milestone when someone works on a pull request and we can estimate the time to do it. About like in comments, nobody has time to work on it for the moment...


goob Mon 7 Jan 2013 6:48AM

It's easy to decide that it would be good for something to be done. Actually finding a way to do it (and people with time and energy to do it) is not so easy. Likeable comments had to be removed because they were putting an enormous strain on the servers of big pods. Now this may be a fairly straightforward problem to solve, or it may not be. Until the reason for this problem has been identified, and one or more people have said they'll work on it, it wouldn't be appropriate to set a milestone, certainly not an imminent one.

As always, I'm sorry I can't help with coding things.


Camil Mon 26 Jan 2015 5:51PM

Sorry for bumping this as per this new thread. Of course there always are "higher priorities", but someone might be kind enough to update the Loomio thread with what's happening on github. Someone was working on bringing the feature back, but the current status of the progress is unknown. Can someone ping the guy working on it on github? Thanks.