Lemmy implements a scoring system allowing people to upvote or downvote posts. You know that since you are using Lemmy :)

Score can be used to increase or lower visibility of posts, in particular when using some sorting algorithms (active, hot, top).

This can be used to increase the visibility of good quality posts, and lower that of low quality or irrelevant posts.

Yet, from what I observe, the tool is mostly used for communities to self-administer filter bubble. Some communities seem to behave like a hive mind, massively upvoting or downvoting until either the dissident is assimilated in a very Borg way, or excommunicated.

Also, scores seem to be used often to convey cheap moral judgement, without having the need to expose oneself to criticism by providing arguments to sustain their opinion.

Overall, I think scores are more toxic than useful, and I would be in favor of hiding them by default, so that new comers are not put out by them.

What is your opinion about this? What are the advantages of having the score visible by default?

Just a clarification: the question is not "should scores exist or not?". If people find value in scores, good for them. I'm not one to dictate other people preferences. :)

A excellent book for all vegan activists to improve their strategy, their communication and their actual impact on animal rights, and well-being.

cross-posted from: https://lemmy.ml/post/171118

> On the account that "we are better equipped", Go will now ignore the order of the CipherSuite option, starting with Go 1.18, due this month. > > The [sorting logic](https://github.com/golang/go/commit/9d0819b27ca248f9949e7cf6bf7cb9fe7cf574e8#diff-fa1ebabc009bcc9a9f27168612adf5b4d56f9f40d613a62f86830861acb85803R215-R270 > ) is detailed in the code. > > Several choices seem strange to me: > * "SHA-256 variants of the CBC ciphersuites don't implement any Lucky13 countermeasures." leading to CBC-SHA1 being favored over CBC-SHA256. > * "AES comes before ChaCha20", on the account that AES-NI is faster. They use heuristics to determine whether both ends support AES-NI and whether to prefer ChaCha20 over AES. > * "AES-128 comes before AES-256", on the account that AES-256 is slower. > > The static nature of the sorting algorithm also leads to security conundrums such as the fact that updating the Go library and recompiling programs will be required if a vulnerability is found in an algorithm implementation (e.g. Lucky13 for the CBC-SHA256 Go implementation); you won't be able to just reduce its priority by updating a config file. > > What's your take on this? Can you explain some of the choices that feel strange to me?

On the account that "we are better equipped", Go will now ignore the order of the CipherSuite option, starting with Go 1.18, due this month.

The sorting logic is detailed in the code.

Several choices seem strange to me:

• "SHA-256 variants of the CBC ciphersuites don't implement any Lucky13 countermeasures." leading to CBC-SHA1 being favored over CBC-SHA256.
• "AES comes before ChaCha20", on the account that AES-NI is faster. They use heuristics to determine whether both ends support AES-NI and whether to prefer ChaCha20 over AES.
• "AES-128 comes before AES-256", on the account that AES-256 is slower.

The static nature of the sorting algorithm also leads to security conundrums such as the fact that updating the Go library and recompiling programs will be required if a vulnerability is found in an algorithm implementation (e.g. Lucky13 for the CBC-SHA256 Go implementation); you won't be able to just reduce its priority by updating a config file.

What's your take on this? Can you explain some of the choices that feel strange to me?

Edit: the Github issue of the proposal