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?