You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The existing DNS-as-username verification scheme is decent for verifying that a user corresponds to a well-known web-based entity. Eg @nytimes.com is probably the New York Times that you expect it to be. However, it would be nice to verify that someone is a "member" of an entity - eg I think a lot of folks are hoping for something like the old twitter verification where nytimes journalists would probably get a blue check on the basis of their employment. Now one possibility is that nytimes should give a @user.nytimes.com DNS entry and while this has the advantage that it scales by delegating the verification to the nytimes webmaster, there are a lot of problems with that (if someone joins/leaves nytimes employment they need to change their username, if someone writes for more than one outlet then they can be verified at one of them, etc).
I'm proposing another solution, where user corresponding to an organizationm eg @nytimes.com can publish a list of their members (just like this one they already made https://bsky.app/profile/nytimes.com/lists/3lbl2hyzmfy2u ) and in addition to subscribing to that list as a feed, like i could do nowm, what if as another option I could choose to subscribe to the list to get a label (eg the nytimes favicon) against nytimes members. (They could publish multiple lists eg editors/columnists/guest contributors so I could choose to subscribe to only some and/or give them variant icons). This way, say @jamellebouie.net could keep his current username, but also show up in my feed with the nytimes favicon (and if slate also joined bluesky, published a list of their contributors and I subscribed to that, then I could see both the nytimes and slate favicon for him (at least until last year while he was still working for slate)).
I think this is a much more elegant and scalable solution for delegated verification, and it doesn't require any new atproto elements since user lists already exist and are already in use for this exact semantics, its just app UX to allow displaying them this way.
Show up in feed something like this:
Some example UX to subscribe to the label (although could need some extra UX to allow choosing a specific icon, not just one given to the list by its creator).
This is basically the same ask to #3135 but focussing on the verification use-case.
As a possible follow up to handle the "I want all mainstream media journalists to have a blue check" use case, there could be a new lexicon for "lists of lists" so I could subscribe to "USA mainstream journalists" from someone I trust (could be bsky moderation team) (which list contains links to eg https://bsky.app/profile/nytimes.com/lists/3lbl2hyzmfy2u and https://bsky.app/profile/latimes.com/lists/3lau5j6rij523 etc) or I can subscribe to a different list of "members of serious robotics labs" etc - this doesn't have to be for journalists only).
Attachments
No response
Describe Alternatives
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Describe the Feature
The existing DNS-as-username verification scheme is decent for verifying that a user corresponds to a well-known web-based entity. Eg @nytimes.com is probably the New York Times that you expect it to be. However, it would be nice to verify that someone is a "member" of an entity - eg I think a lot of folks are hoping for something like the old twitter verification where nytimes journalists would probably get a blue check on the basis of their employment. Now one possibility is that nytimes should give a @user.nytimes.com DNS entry and while this has the advantage that it scales by delegating the verification to the nytimes webmaster, there are a lot of problems with that (if someone joins/leaves nytimes employment they need to change their username, if someone writes for more than one outlet then they can be verified at one of them, etc).
I'm proposing another solution, where user corresponding to an organizationm eg @nytimes.com can publish a list of their members (just like this one they already made https://bsky.app/profile/nytimes.com/lists/3lbl2hyzmfy2u ) and in addition to subscribing to that list as a feed, like i could do nowm, what if as another option I could choose to subscribe to the list to get a label (eg the nytimes favicon) against nytimes members. (They could publish multiple lists eg editors/columnists/guest contributors so I could choose to subscribe to only some and/or give them variant icons). This way, say @jamellebouie.net could keep his current username, but also show up in my feed with the nytimes favicon (and if slate also joined bluesky, published a list of their contributors and I subscribed to that, then I could see both the nytimes and slate favicon for him (at least until last year while he was still working for slate)).
I think this is a much more elegant and scalable solution for delegated verification, and it doesn't require any new atproto elements since user lists already exist and are already in use for this exact semantics, its just app UX to allow displaying them this way.
Show up in feed something like this:
Some example UX to subscribe to the label (although could need some extra UX to allow choosing a specific icon, not just one given to the list by its creator).
This is basically the same ask to #3135 but focussing on the verification use-case.
As a possible follow up to handle the "I want all mainstream media journalists to have a blue check" use case, there could be a new lexicon for "lists of lists" so I could subscribe to "USA mainstream journalists" from someone I trust (could be bsky moderation team) (which list contains links to eg https://bsky.app/profile/nytimes.com/lists/3lbl2hyzmfy2u and https://bsky.app/profile/latimes.com/lists/3lau5j6rij523 etc) or I can subscribe to a different list of "members of serious robotics labs" etc - this doesn't have to be for journalists only).
Attachments
No response
Describe Alternatives
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: