Bring back likeable comments

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.

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?

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?"

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

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?"

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'.

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.

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.

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.

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

@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.

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?

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

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.

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?

Feel free to do it !

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 0.0.3.0 milestone. Can any project admin on GitHub proceed or is this a stupid idea?

Why has it to be in 0.0.3.0?

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. 0.0.3.0 and 0.1.0.0. Feel free to create 0.0.4.0 if you think it's better in that milestone.

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

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...

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.

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.