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
Note: This discussion was imported from Loomio. Click here to view the original discussion.
Proposal: Bring back likeable comments Dropdown
Outcome: Okay. Thatâs a clear âyesâ. But there are things with higher priorities right now⌠
Votes:
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.
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.
I used the term âlikeableâ because we had a little attribute called âacts_as_likeableâ. But you are right, itâs a bit funny.
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 
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 !