Likes got replaced by Upvotes/Downvotes

[deanpress]

Edit There has been extensive discussion about this topic in the Matrix and I think the core team is on the same wavelength with the concerns described below, though the direction remains unclear.

I noticed that likes in the protocol were recently replaced with upvotes/downvotes. This could completely change the purpose and direction of the protocol in a way that makes it no longer viable as a decentralized Twitter-like network.

Tldr: imagine every tweet you make also becomes a Reddit thread, and every reply also shows up in a Reddit comment section.

Upvotes and downvotes will make ATP more fit for reddit-esque discussion boards rather than timeline-based social networking/microblogging. Visually representing a voting score would cause malicious interactions and sheep-like behavior (i.e. downvoting a post just because it's trending towards a negative score).

In the matrix channel there was a reply saying it's up to the client application to work with downvotes if they choose. The problem with this is it would cause a discrepancy with how likes/votes are displayed per client (i.e. one shows the upvoteCount as Likes while another shows a positive or negative score based on total upvotes and downvotes accumulated) thus cause constant confusion.

People will make troll replies/downvotes when they see a post that has a lot of downvotes already, jump on opportunities to bury a post, or simply bot peoples' posts with downvotes, and meanwhile it's possible that the author (on their platform) doesn't see the downvotes (only "likes" i.e. upvotes), causing a sea of confusion in the post's replies. It could also actively demotivate people from wanting to post on ATP because they're scared of getting negative scores on their timelines.

Imagine you make a post and see a bunch of likes on your client of choice (because you prefer posting on a platform with Likes rather than downvotes), but on another platform your posts are also indexed, with downvotes counted. One platform shows "100 likes" and the other platform shows "-123 votes" and people start replying "lol everybody disagrees with your opinion" and/or posting screenshots of negative scores. You wouldn't understand what's happening ("why is my score x on client A but y on client B?"), leaving you confused and simultaneously on the receiving end of controversial replies and negative voting behavior.

It could also cause competitors to constantly try to manipulate other parties' posts' exposure with botted downvotes, trying to influence public opinion and create a negative connotation about their competition.

I'm not saying upvotes + downvotes are inherently bad for all types of platforms. It works for e.g. Reddit, but replacing Likes with Upvotes/Downvotes on a social networking standard/protocol will cause an extreme shift of direction for the protocol and I would no longer consider it as a decentralized version of Twitter-like networking.

This decision will likely cause the content and manner of communication on ATP to have more properties of a Reddit front page + comment section rather than a Twitter timeline/replies section. The respective purposes of posts/clients/indexers that count upvotes exclusively (as "likes") and ones that use an Upvotes/Downvotes scheme are so incredibly different that they might as well belong to two different protocols.

[erlend-sh]

There has been extensive discussion about this topic in the Matrix and I think the core team is on the same wavelength with the concerns described below.

Does that mean this is being revisited? I certainly hope so, as I fully agree that downvotes are the wrong design for this protocol.

https://medium.com/the-physics-arxiv-blog/data-mining-reveals-how-the-down-vote-leads-to-a-vicious-circle-of-negative-feedback-aad9d49da238

“Not only do authors of negatively-evaluated content contribute more, but also their future posts are of lower quality, and are perceived by the community as such,” they say. And it gets worse: “These authors are more likely to subsequently evaluate their fellow users negatively, percolating these effects through the community.”

https://meta.discourse.org/t/what-are-likes/30803

From @coding-horror, co-founder of StackOverflow and Discourse:

systems of fact, data, and science can benefit from downvotes, because statements can be scientifically proven to a reasonable degree.

systems of opinion do not benefit from downvotes and are in fact materially and seriously harmed by them, because nobody can prove an opinion. Empathy is the order of the day in opinion systems.

[deanpress]

@erlend-sh Very nice quotes. 100% agree.

Based on the Matrix conversation on this topic it seems that some team members do agree that it needs to at least be considered to have a separation between "likes" and "upvotes/downvotes" (which imo would complicate the protocol as it separates posts into 2 distinct categories), but what the final decision will be remains unclear.

I would personally opt for excluding upvotes/downvotes entirely as imo it has no place in timeline-based microblogging social networking and it might shift the protocol into something that it's not supposed to be (instead of decentralized Twitter we get Reddit). There's a reason why the world's most successful social networks with the biggest research departments have not implemented it into their products.

I do understand the issue of needing a decentralized way to separate high-quality posts from spam within the protocol, which I think would be better served with a multi-step "report" system rather than an inviting "downvote" aka "f- this post" feature.

[whyrusleeping]

Note that likes/upboats/downvotes/etc arent “in the protocol”. They are a particular type of interaction defined by a particular lexicon. The downvotes you see in the repo are defined in the app.bsky lexicon, which is a twitter-like system built on the AT protocol. One lexicon including downvotes doesnt mean everything using atproto has downvotes.

[mikestaub]

Using user interaction to detect spam posts is a failure mode and should be considered an edge case.

I think the app lexicon using simple upvote or downvotes is prudent as it allows other app lexicons to extend the schema with more contextual "reactions" that can be mapped to the simpler Bluesky ones if the client doesn't support them.

For example, if Facebook adopts the protocol, their app.facebook.feed.getVotes schema would have 7 possible values. When viewing a user's post from their UI I would see all 7, when I view it from the Bluesky app the team could decide how to present it.

1. condense the reactions into simple upvote/downvotes
2. render the post with a custom Facebook-specific component
3. gracefully fallback to only render the common properties and show a UI warning that not all fields are supported

[pierce403]

A few things. First off, a network with only "likes" quickly devolves into a pure popularity contest where everyone becomes obsessed with getting attention at whatever cost (including self-harm etc). Some form of negative feedback is required to keep bad behavior in check. I also feel like a pure up/down mechanic quickly becomes "this re-enforces my existing beliefs" vs "this challenges my existing beliefs" for 90%+ of users. This leads to polarization and tribalism.

I worked on a system once using the labels "awesome", "hilarious", "enlightening", "solidarity", "scammy", "poopy", and "hateful". This means that when you wake up in the morning and want some inspiring content, you can bump up the scoring on "enlightening" label to +2 or +3. Or if you need a good laugh, you can crank up the value of the "hilarious label".

Furthermore, assuming labels are signed and published globally, you have the ability to identify users who found interesting, and funny things etc before you found them, meaning you can find users with a high affinity for the kind of content you appreciate, follow them, and increase the quality in your timeline. This also quickly lets you quickly identify and filter out users who are insincerely promoting content, via bots or paid promotions etc. There's an unlimited amount of interesting things you can do with this data to improve the quality of your timeline, and importantly, this can all happen client-side so you don't need to rely on any centralized entities for content moderation. Of course you would also expect the popular clients to have some sane defaults built in.

In the Element chat, we also discussed the idea of opening up labeling to all existing emojis, which would be interesting. It would enable a wide range of emotional responses, and build some interesting and complex social norms. This could get wild to deal with purely on the client side, so to reduce the noise, clients might decide to only consume labels that are signed by accounts within two or three hops of the user's existing social graph.

Of course, since it's all client-side, you could create a client that ignores everything except the "heart" emoji to represent likes, or a client that only sees "thumbs-up" and "thumbs-down" to create a more Reddit-like experience. Give people a simple UX to start with, and let them turn the knobs towards what gets them the timeline that they want to see.

The problem with this is it would cause a discrepancy with how likes/votes are displayed per client (i.e. one shows the upvoteCount as Likes while another shows a positive or negative score based on total upvotes and downvotes accumulated) thus cause constant confusion.

Subjective vs objective scoring is absolutely a feature that should be embraced for systems like this IMO :-)

[deanpress]

Of course, since it's all client-side, you could create a client that ignores everything except the "heart" emoji to represent likes, or a client that only sees "thumbs-up" and "thumbs-down" to create a more Reddit-like experience. Give people a simple UX to start with, and let them turn the knobs towards what gets them the timeline that they want to see.

I can see this working if the Post attribute contains the list of permitted reactions (e.g. allowedReactions: ["♥"] set by the client), so the same post is not automatically displayed on a client that allows e.g. upvotes/downvotes, and instead the post is only visible to clients that handle the same type of engagement (and are only "reactable" with the emojis that were configured in the post data). This does cause extra complexity like what emojis represent "Likes"? Will some emojis even represent the same thing for each client?

[deanpress]

@whyrusleeping: One lexicon including downvotes doesnt mean everything using atproto has downvotes.

Does atproto expect different atp clients to implement their own unique lexicons for posts and interactions? Doesn't that beat the advertised purpose of the protocol, where content and accounts follow a standard so it can be handled equally across different clients?

If likes/votes aren't a part of atproto at all, then clients would need to change the back-end logic of their atp server, build their own modules on top of atproto to allow the type of engagement that they want, and then if other clients don't have the same implementation, then engagement like Likes won't be shared between those clients, effectively isolating/centralizing post engagement in the protocol.

Furthermore, if bsky is part of atproto's spec with its own subjective voting system, and it shouldn't be considered a part of the protocol itself and clients are expected to integrate their own style of post engagement logic, doesn't that give an unfair competitive advantage to bluesky, where every bluesky post is indexed/processed by every client that integrates atproto, but custom back-end work (importing/applying logic for different lexicons) needs to be done by every single client that wants to properly handle posts from other clients?

I don't see a reason why the engagement action should be a DYI part of the protocol, which would break content apart into groups of "which client integrated which engagement lexicon logic".

[mikestaub]

I think the meta-issue this discussion is hinting at is that we should be developing 2 clients simultaneously. That way as we develop the lexicons it will be more concrete how the crossposting works and integration issues will surface early. It's easier to go from 2-n than 1-2 generally.

I know resources are tight, but the 2nd client may be a good first way to engage the open-source contributors? Or the 2nd client can be very simple and similar to the bsky lexicon. Perhaps a lexicon that could eventually evolve into a reddit clone?

[danfinlay]

Hi all, I’ll just throw in a few cents:
Likes are nice, downvotes have benefits, but my favorite right now is an open ended react system. These systems let people define new reacts and add them freely to any post, and agree with any outstanding react. Slack and Discord are both good examples of this, and if you could support that, it seems like you’d have a maximally flexible approach.

[deanpress]

@danfinlay I agree with a variation of this approach as discussed earlier - one where the client decides what reactions to allow on a post. This way a decentralized Reddit app can simply only allow 👍 and 👎, and a decentralized Twitter can allow ❤, and a decentralized Facebook could have a whole plethora of reactions per post.

This way, clients and indexers can still interact and sync with each other easily without the need to maintain separate lexicons (synchronize by allowed reaction types), and a user on a decentralized Twitter will not have any "downvote anxiety" on posting as they know the type of allowed reactions on their post beforehand.

re @mikestaub I think having separate lexicons for different clients, solely for the purpose of "reaction type" would cause too many integration issues (i.e. clients have to constantly maintain/integrate other clients' lexicons)? Wouldn't something like the above work better?

[mikestaub]

@deanpress for this specific example, probably yes. But I assume the main problem Bluesky aims to solve, which is currently unsolved in the industry, is data portability between apps. If all apps are forced to use a specific lexicon then this project is basically just Mastodon with a better ID system. If that assumption is true then better to tackle the challenge early on in the development of the protocol. If apps can specify arbitrary lexicons then I predict a healthy developer ecosystem will emerge to satisfy all possible use cases, similar to https://discord.bots.gg

[deanpress]

@mikestaub 100% agree. Hence I'm concerned by the recent communications that atproto seems to be more considered by the core team as "only a data portability protocol" and bluesky is considered "a social networking standard built on top of it, and other social networks shouldn't need to integrate it".

If this concept is upheld, then if we compare ATP/bsky's ecosystem to email, ATP can be thought of as the framework for building communication protocols, rather than being an email protocol itself. Different services can communicate with each other using ATP, just as different email clients can communicate with each other using the email protocol. However, imagine Gmail is the first and dominant email provider, and many other email clients have to adapt and "copy" Gmail's exact features and logic in order to be compatible with it, since they built their own "email standard".

Similarly, Bluesky built on ATP would be the dominant social networking protocol, limiting the ability of other ATP clients to communicate with it unless they are logically identical to Bluesky (which is an issue if bluesky is restrictive with how it deals with reactions). This creates barriers to communication and reduce interoperability in the ATP ecosystem.

If Bluesky is deployed using new (non-"Twitter standard") social actions, such as a variation of upvotes and downvotes, other social networks built on ATProto will be forced to deal with 2 mediocre choices: either be a full integration of Bluesky's own social networking logic to support content portability, or build their own ATProto lexicon and lose the ability to interoperate with other clients. Neither are ideal imo.

[mikestaub]

I trust the team to make the right technical choices to avoid the pitfalls you mentioned. What I assumed was meant by "other social networks shouldn't need to integrate it" is that being at full feature parity with the bluesky app is optional for all clients. Using the ATproto is not, as that is how a user logs into any experience. If any client wants to clone all the UX of Bluesky that is not hard to do, look at all the open-source Instagram, Pinterest, etc clones on github. The barrier to entry is the data and network effect that is built around it. If the team can successfully solve the data-portability issue, it will usher in the next wave of consumer social products that will eventually displace the incumbents for the same reason that no apps can compete with wechat in china. Each new app developed on the ATproto will increase the value of all the others.

[deanpress]

What I'm gathering from this thread is that ATProto is in fact not a social networking protocol itself, but rather a protocol that provides the foundation for Bluesky to function as a social networking protocol. This is different from how ATProto is described on its website, which currently refers to it as a "social networking technology".

I think it would be more accurate to describe ATProto as an account/data portability protocol and Bluesky as the social networking protocol built on top of it.

Either way, the feedback regarding user reactions in the bsky lexicon still stands. We should continue discussing how to standardize user engagement on the bsky lexicon, as most ATP-powered social networking clients will fully integrate with it. This will help improve the user experience and allow users to interact with the platform in a consistent way.

[AaronGoldman]

@deanpress
ATProto is a way to exchange authenticated data.

For data to be authenticated we need two things an identity for the author and a way to authenticate the bytes.
at://did:plc:bv6ggog3tya2z3vxsub7hnal/app.bsky.feed.post/3jj3-lis-dvgx-23 maps to a byte array.
The data is authenticated since the root of the repo is signed by did:plc:bv6ggog3tya2z3vxsub7hnal and 3jj3-lis-dvgx-23 is in the Merkel Tree.

The Identities in ATProto are Identities in the same way as the same origin policy and authoritative domain name from https.
https://authoritative.domain.name.example/path/to/file.ext the part after :// and before the next / is the authoritative name. https:// brings in DNS for the authoritative domain names, at:// brings in the DIDs.

Since documents can contain at:// URIs and at:// URIs can point to documents they form a web. This web can be the links of a social network by having a following document with links to other authoritative DIDs. or whatever else you want to use URIs for, know the web.

[dholms]

aannddd... we're back to likes as of #658

[ShreyanJain9]

Rather than have upvoting or downvoting, why not create a separate lexicon for emoji reactions? That way, any user can react with any emoji similarly to how Nostr does it

[NetOpWibby]

Rather than have upvoting or downvoting, why not create a separate lexicon for emoji reactions?

How would this look on a post with 85 different emoji reactions (assuming texting emoji)? At some point, there has to be a limit.

Facebook and LinkedIn each have five emoji reactions to choose from, which would be a lot simpler to grok.

[incendies]

The concern is that this change could shift the purpose and direction of the protocol towards a Reddit-like discussion board rather than a Twitter-like timeline-based social networking platform.

There are several potential issues highlighted in the feedback:

Visual representation of voting scores could lead to malicious interactions and sheep-like behavior, where posts are downvoted simply because they are trending towards a negative score.

Different client applications may handle upvotes and downvote differently, leading to discrepancies in how likes/votes are displayed and causing confusion.

Troll replies and downvotes could be used to bury posts, manipulate public opinion, and create a negative connotation about competitors.

The shift towards an upvotes/downvotes scheme could fundamentally change the content and manner of communication on ATP, making it more akin to a Reddit front page with comment sections rather than a Twitter timeline with replies.

It's important to note that these concerns are based on assumptions and interpretations of the potential impact of the changes to the protocol. The actual outcome would depend on how the changes are implemented and adopted by the community. I guess we can go with emojis or something and go with likes instead of downvotes because its has the risk to get spammed.

[shaqq]

Hey folks, thanks for the thoughtful conversation here. I had a maybe naive question: have we considered secret or private downvotes, in the same way we consider mutes secret/private? I wonder if that assuages many of the concerns of the 2nd order effects of downvotes, but still allows users to indicate what content they like or don't like.

Of course, this means clients would have to make use of downvotes rather than downvotes being part of the network, which is no easy task.

[Heartade]

What we really need is, imo, a "show me less of this" button. Post writers shouldn't be able to see how much dislike their post is getting, but post readers should be able to exclude certain types of posts that trouble them.

Dealing with potentially trigerring posts written in good intention (e.g. personal accounts of violence, depression, etc) was always a problem in Twitter, and muting people or words does not work with those. I believe we could prevent such using a natural language classification system coupled with user's own 'dislike' data.

[astrojuanlu]

One could devise an algorithm that just uses dislikes/downvotes to "push away" a post from certain clusters of the network to minimize negativity. But there's evidence that negativity is the emotion that generates the most engagement online, so there could be also bad incentives to promote and encourage it. As long as downstream applications can handle reactions differently, I guess it's fine. But I echo what others have said in this thread, this needs careful and intentional design.

[shaqq]

What we really need is, imo, a "show me less of this" button. Post writers shouldn't be able to see how much dislike their post is getting, but post readers should be able to exclude certain types of posts that trouble them.

Dealing with potentially trigerring posts written in good intention (e.g. personal accounts of violence, depression, etc) was always a problem in Twitter, and muting people or words does not work with those. I believe we could prevent such using a natural language classification system coupled with user's own 'dislike' data.

Yes, exactly this. This is one aspect of TikTok I do like, which is the "secret" downvote i mentioned earlier. There's a good discussion on how the user indicate "see less" - whether it's a button as available as the like button, or if it's behind a 3-dot menu. But that's a client-side discussion, not one for the protocol.