app.bsky.dislike

[manunamz]

It seems the bluesky protocol is aiming to cover behaviors that can reasonably be presumed to exist in any social media app as they are currently designed. While not ubiquitous in the absolute sense, 'dislike' is common and useful.

This is a request to add app.bsky.dislike to the base bsky lexicon records library -- similar to bluesky's existing like record type.

This could also be added in related constructs. For example, AppBskyGetHomeFeedFeedItem in the docs contains likeCount: number; -- so dislikeCount: number; could be added in parallel.

Happy to do a PR if so desired.

Thank you for your attention! 🙏

Edit: Or there could be an upvote/downvote mechanism alongside like.

[mikestaub]

Meta-question: what is the governance process for adding/modifying the schemas?

[pfrazee]

Ahhh the great downvote debate! Happy to discuss it, but not sure at this stage whether we'll include it as a core bsky.app schema, an optional bsky.app schema, or leave it as something outside of bsky.app. It's ultimately a UX question, and the pros & cons are both valid.

Meta-question: what is the governance process for adding/modifying the schemas?

Schemas are published under a domain name. Here we're discussing the bsky.app schemas for instance, which -- due to the reverse dns -- look like app.bsky.dislike in this case.

Broadly speaking, this means that anybody can create a new set of schemas (a new "lexicon") under a domain they control, and that whoever controls the domain controls those schemas. It's up to each of them to establish how they govern it. In some ways, it's safe to say that a lexicon has a strong equivalence to an application on the Web, as it establishes the collective nouns and verbs of a usecase.

At this stage for bsky.app, it's the same governance as the rest of the protocol at this stage: the bluesky pbllc governs it with the help of outside feedback. We expect to need a separate standards body in the future once the protocol stabilizes, but for now we want to be able to move quickly.

[jdlewin]

Being able to watch different domains implement additional schema elements over time may be precisely the sort of signal a standards body will need to make effective decisions.

+1 for moving quickly

On Oct 21, 2022, at 12:27, Paul Frazee @.***> wrote:

Broadly speaking, this means that anybody can create a new set of schemas (a new "lexicon") under a domain they control, and that whoever controls the domain controls those schemas. It's up to each of them to establish how they govern it.

[manunamz]

@pfrazee 👀

...not sure at this stage whether we'll include it as a core bsky.app schema, an optional bsky.app schema, or leave it as something outside of bsky.app. It's ultimately a UX question, and the pros & cons are both valid.

I hear you -- makes sense. Being so new means there is much to figure out.

Here are two cents: I had assumed (perhaps wrongly so) that the bsky domain was going to act as a base lexicon current/future platforms could start from -- with the option to add custom records per their unique use cases. But say a "forum"-style site (stackoverflow, stack exchange, hacker news, reddit, youtube, etc., etc.) wanted to migrate to atproto. If they wanted to start from the bsky lexicon to keep it simple, they would be missing the downvote feature and thereby require the addition of custom lexicon records -- for one record.

Since the lexicon system is so flexible, perhaps this will be a moot point. It's just something to consider if the bsky domain lexicon is meant to be a base to build from.

~

Ahhh the great downvote debate!

I am indifferent to whichever pony wins, so long as there were no horses harmed in the making of this race. 🐎

Is there canonical reading where I can educate myself on this?

---

@mikestaub -- good question. @jdlewin -- good point.

[pfrazee]

I had assumed (perhaps wrongly so) that the bsky domain was going to act as a base lexicon current/future platforms could start from

Yeah this aspect is not totally clear yet, and the question is about how software expresses the use of schemas and their intentions. (I have a tweet thread on this.)

At the moment it's simpler to view the bsky lexicon as a cohesive set of schemas which represent a single application -- that is, if you are using app.bsky.post, then you can expect other software using app.bsky.post to also use app.bsky.like. This makes it simple to evaluate whether you support the bsky lexicon, and to evaluate what other apps expect you to do.

What we're going to discover as time goes on is: how do we make this a more fluid system? Will it be...

1. Lexicons can define schemas that are basically optional (as you're suggesting)?
2. Lexicons can mix in other lexicons?
3. You create entirely separate lexicons and view them as distinct applications?

We're designing for 1 & 2 to happen, but we need to actually see how those things work. What happens, for instance, when an app adds the "dislike" button but every other app doesn't recognize the dislike record it produces? You've got users pressing dislike and thinking they're being heard, when in fact they're shouting into the void. It's an intention mismatch. Schemas are ultimately protocol; they depend on shared consensus.

What I'm hoping will emerge are really good tools for making 1 & 2 work, and we have a couple ideas. We're just focusing on getting a base vocabulary to work first.