It’s a different level of sensitive. At the end of the day, it’s application-layer & recoverable. DID operations can result in irrecoverable full-account compromise. For comparison, “deleting all of your Bluesky posts” is a sensitive operation, but is still captured in in “just write a record” scopes.
I generally agree, but I just don’t think we can treat it as a prerequisite for this community/groups work.
I don’t see the issues that it causes. Many things in atproto have a more generic protocol representation and a more particular, userland, application-specific representation.
Labelers & labels are a generic atproto concept. This is represented by the service in the DID document. They’re also used in a particular manner in the context of the Bluesky application and thus have a Bluesky lexicon declaration. Both are necessary in this case. It prevents Bluesky from bogarting what a labeler can be used for by forcing its application-specific labeler semantics down into the protocol layer.
My expectation is that this was something we could collaborate with Lexicon Community on holding. If either Lexicon Community or the working group around this thinks that’s not a fitting organization for it, then we can discuss other options to house it: Bluesky or a new organizational structure. Good topic for conversation!
I’m not sure I like enforcing application semantics like this in an account-wide, cross-protocol manner. I think DIDs can be “modal”, in that they might be a group in one context, a publication in another, and an actor in another.
For instance, a Bluesky labeler can still be a normal Leaflet user. In the context of Bluesky, the labeler record causes it’s profile to render as a labeler. Other applications (like Leaflet for instance), can then determine if they want to treat it like a labeler (because of the Bluesky record) or as a normal user.
I actually don’t think you can standardize on this one at the protocol level. It really does strike me as an application semantic. I expect some groups/communities will want to keep the list private, others will have various tiers & roles, others may have time-limited permissions or permissions that inherit from another signal like a vouch or payment receipt. Maybe in some sense, these can all be discussed as “membership”, but it’s a bit lossy.
To be clear, I actually like the communities/groups standard that we’re working on having a clear notion of membership! I just think that’s a userland thing & isn’t a given at the protocol level.