Whither custom self-labels? #2885
Replies: 6 comments 17 replies
-
|
One approach to this could be a generic self-labeler mod service that just re-emits all self-labels. Seems simple enough, should do the trick, and anyone could build it...? |
Beta Was this translation helpful? Give feedback.
-
|
Unrelated, @qazmlp you've clearly been interested and (very!) knowledgeable about decentralized social and ATProto and building software in general, but haven't had the free time to take on a big project...? This one seems pretty small and contained. Seems like it might fit you well? |
Beta Was this translation helpful? Give feedback.
-
|
@snarfed I have several equally 'small' ongoing projects that I'm already not getting to 😅 (Sorry.) I know it's not necessarily good form to only discuss and not publish any code, but this really is the extent I can spare of myself in the ATProto context. |
Beta Was this translation helpful? Give feedback.
-
It is a very important part of the protocol/project that it be possible (and credible) for a third party to step in and start running an appview for any app/Lexicon. More broadly, any infrastructure that any community relies on should have "adversarial interop", meaning a new provider could replace existing providers (if they can convince users to jump over, and have some realistic/sustainable funding model). We think it would also be good for there to be multiple providers for major/important/popular app modalities, but it isn't as high of a priority right now as the "credible" bit, and things like improving self-control of identity and making new app development easier (gotta prioritize!). In general I do think it is important for folks to be able to backfill labels. Note that at least the Ozone mod service allows full backfill on the subcribeLabels endpoint, so both subscribeLabels and queryLabels could be used for backfill. When Jaz said that the AppView doesn't use queryLabels, I think they were just describing how the system works today. We think queryLabels is a fairly important part of the API surface going forward (it enables a lot of use cases, introspection, etc), even if we aren't currently using it. And hopefully isn't too laborious to implement. (of course, as always, folks can experiment as they see fit; my role here is to nudge in the direction of certain norms) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the correction @bnewbold! Sorry for unintentionally spreading misinformation. 😁 One big part of what led me astray here was the question of lexicon and app "ownership." I was maybe thinking more about whether third parties could or should build appviews for lexicons/apps they don't own, beyond merely running independent instances of the reference implementation. Any nontrivial app will have nontrivial product semantics and behavior that are built into their appview. Would third party appviews be expected to try to match those semantics? Or is part of appview adversarial interop that they could offer alternative semantics? Either way could be reasonable, or maybe other ways entirely, but the answer obviously impacts what it means to "own" an app or set of lexicons, and what the ecosystem norms and expectations are. (Apologies for the tangent from the topic here, happy to move somewhere else if you know where!) |
Beta Was this translation helpful? Give feedback.
-
Definitely understood, and agreed. I only interpreted Jaz as describing the current state, not being normative. I ended up nerd sniping myself into actually building this self-labeler, it's up and running and almost working, https://bsky.app/profile/self-labeler.snarfed.org , but I don't know if I plan to go the extra mile to make it robust or long-lived or backfill-able. We'll see! |
Beta Was this translation helpful? Give feedback.
-
|
(If you're wondering whether the real reason I filed this was just so I could use the word whither, the answer is a resounding yes. English is |
Beta Was this translation helpful? Give feedback.
-
|
In the big picture, we know that the labeling system probably needs a "v2" iteration. This probably won't be breaking protocol changes, but there are a large list of lessons learned and problems that have surfaced. Unfortunately we probably aren't going to be making smaller tweaks or improvements until we do that large push. This isn't to say that composable moderation isn't a priority. Self-labels kind of fall in that bucket. As designed, self-labels are in the scope/context of the author, regardless of which labelers the viewer subscribes to. To have such labels appear consistently, we felt it was important that they be defined at the app level, not at labeler-service level. We also wanted to start with a small set of initial self-labels to start. We wanted to avoid a norm of "content warning policing", where folks are shamed or punished for not self-labeling. All those decisions might be re-visited now that we have more experience! The "badging" use-case of labels has been very popular. But also having hashtags on profiles could cover many of those use-cases? Or other forms of badging, maybe community-specific, maybe tied to social roles, maybe something like https://docs.smokesignal.events/blog/blue-badge-released/? Lots of options to consider. |
Beta Was this translation helpful? Give feedback.
-
|
I'd only be half-joking if I said I think people want forum signatures. Have you considered a sort of "micro bio" that's a little deemphasised next to the user name? This is similar to how the Mastodon app (Moshidon) on my phone displays the "Pronouns" profile field. I imagine people would want to use this for their fursona species or job title in some cases, too, like "internet goat" or "UX is my hobby". You may want to force text presentation for emoji though. |
Beta Was this translation helpful? Give feedback.
-
|
@futurGH raised a great point just now: do custom self labels not actually exist? Or more specifically, does the protocol not allow them? https://docs.bsky.app/docs/advanced-guides/moderation#global-label-values says:
Whoa! News to me. Seems kind of the opposite in spirit to the idea that clients can add arbitrary fields to records that aren't in their lexicon, and PDSes etc are required to preserve those fields, right? Even if we're now moving toward recommending sidecar records instead. ...but if this is true, then arguably I've been doing it wrong all this time by setting Phew, ok. If anyone can confirm, please do! |
Beta Was this translation helpful? Give feedback.
-
|
Somewhat related: bluesky-social/social-app#3872 However, I do not know anything about the technical details and whether self-labels would show up in the app if they're attributed to a third party labeller. |
Beta Was this translation helpful? Give feedback.
-
|
Finally found a custom self-label that's not from Bridgy Fed! |
Beta Was this translation helpful? Give feedback.
-
|
Saw a few more custom self-labels this morning, all Japanese, eg https://atproto-browser.vercel.app/at/did:plc:lmftezsq52hi53taz762s7pc/app.bsky.actor.profile/self |
Beta Was this translation helpful? Give feedback.
-
|
Currently self labels in Bluesky aren't terribly useful since they have to have a global definition to define the rules, display information, and such. It may be helpful or even necessary for custom self-labels to have an extra field referring to a separate definition record, perhaps only accepting one that explicitly allows self-labeling. (The use case for this is that I'd like for people to be able to self-label USPol posts, using my labeler's labels so that any settings a reader already has for the label apply.) |
Beta Was this translation helpful? Give feedback.
-
|
Theoretically, it would be already possible and legal in the protocol to add a labeler record to a user, since self-labels always refer to the poster as the issuer? Again, it seems less useful to me since binding custom self-labels to a labeler means each label can be configured by an end-user as they see fit. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with the usefulness of having a self-label definition record. I expect it to be added with label v2. However, it may not completely replace the self-label labeler. Simple self-labels are defined independently for each user, so viewers need to set the display style for each. For example, if a self-label labeler can provide a "semi-global label" with a common meaning, viewers can use it more conveniently. It is probably possible to include definition sharing options in the bsky self-label system itself, but it is natural for me to use the labeler as an authority for label definition. |
Beta Was this translation helpful? Give feedback.
-
Hi all! What's the current status and thinking on custom (ie non-bsky.app) self-labels? They are usable right now, granted; Bridgy Fed sets one on each profile bridged into Bluesky from the fediverse. However, unlike labels served by a mod service, it seems like there isn't a straightforward path to expose self-labels to users? https://atproto.com/specs/label#self-labels-in-records says "downstream clients" can use them. Is that the expectation right now: clients have to surface them explicitly if they want to? Any plans for bsky.app to do that? Any other thoughts?
More background in snarfed/bridgy-fed#1388 , cc @qazmlp . Thanks in advance!
Beta Was this translation helpful? Give feedback.
All reactions