Bring back likeable comments

(Dennis Schubert) #1

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:

Note: This discussion was imported from Loomio. Click here to view the original discussion.


(Dennis Schubert) #2

Proposal: Bring back likeable comments Dropdown

Outcome: Okay. That’s a clear “yes”. But there are things with higher priorities right now… :slight_smile:


  • Yes: 12
  • Abstain: 2
  • No: 1
  • Block: 0

Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.


(goob) #3

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) #4

I used the term “likeable” because we had a little attribute called “acts_as_likeable”. But you are right, it’s a bit funny. :slight_smile:


(raven24) #5

just for reference:
… 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) #6

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) #7

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) #8

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 :stuck_out_tongue:


(Jonne Haß) #9

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) #10

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) #11

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) #12

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


(Rasmus Fuhse) #13

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) #14

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


(raven24) #15

@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) #16

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) #17

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


(Sean Tilley) #18

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]) #19

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) #20

Feel free to do it !