3rd party labeler lexicons rework

[dholms]

Rework some of the lexicons around labelers.
A few notes:

• all lexicons have been moved to the app.bsky.moderation namespace
• we refer to the services as "moderation services" or "mod services" rather than "labelers" as their functionality can and likely will include more than just labels
• only one service can be announced per did so
  • the app.bsky.moderation.service lexicon has a key type of literal:self
  • remove did property from record
  • removed getActorLabelers
  • displayName and avatar have been removed (and will just fall back to the repo's profile)
  • Open question on that^^ do we want to keep around a mod service's description or should it fall back to profile as well?
• possibly controversial one, interested in thoughts:
  • updated modServiceViewDetailed so that it returns the actual record rather than the properties recomposed onto the view
  • this is something I wish we'd done on profile views & it seems nice to get it in now on the mod service. It allows for easier extensibility etc

[bnewbold]

On re-using profile metadata: de-duping is nice, but it would also make sense to me to have all of avatar, displayName, and description on the service record. I don't have a specific example but it seems pretty feasible to me that you'd want different types of name/description in the two contexts. Feels like we could start with all-profile and add more fields though, while the other direction might be tricky.

I'm also just now realizing that, in contrast to feed gens, mod services will have a handle! That is actually pretty nice to be able to hook in to domain verification.

👍 to namespace move and calling them "service".

👍 to embedding the full record, with at-uri and cid as parallel fields.

It feels like the service record could get pretty big if there are a bunch of long-description policies. Eg, will we put our full community guidelines in there... i'm guessing not to start, we would link from description? Each policy could be a separate record. A related thing is translating policies, so having the (human) language indicated, or an array or map or something. Some mod services might be lang specific, but something like a visual nudity labeled can apply to multiple languages and would want to describe policy. This is a whole can of worms though, AFAIK we don't have a "translated text" thing to just copy. Maybe we just make the per-policy field shorted and enable/encourage linking out to an external URL for the full policy, and leave translation up to that?

[bnewbold]

From a parallel discussion: we could consider calling it app.bsky.safety instead of app.bsky.moderation. I think we've already gone down the "moderation" terminology elsewhere though (mod event, mod report) and consistency is probably most important.

[pfrazee]

Yeah this is all looking great. Two things that just came up while Eric and I were just looking at this:

1. Since we dont use the modservice declaration record to identify mods anymore, we actually won't have a unique URI for sharing in posts. Therefore the idea of an embed view with the modservice details in posts doesn't work anymore. What can work is sharing profile views as link cards. When users put the URL of a profile in there, we can suggest a link card. This is nice generally, but then for mod service users we can consider showing the relevant information there.
2. Open question: because this is now a 1:1, do we want to be including the mod declaration info in the profile views? This relates to the question above, but it's also a question for when we land on a profile. If we don't include it in the profile view, then we need to make a separate additional request for every profile we visit to discover this information.

[pfrazee]

Something else we need to do: replace all the usages of labeler with modservice or mod.