[HN Gopher] A new form of verification on Bluesky
___________________________________________________________________
A new form of verification on Bluesky
Author : ink_13
Score : 176 points
Date : 2025-04-21 16:16 UTC (6 hours ago)
(HTM) web link (bsky.social)
(TXT) w3m dump (bsky.social)
| greyface- wrote:
| > Bluesky's moderation team reviews each verification to ensure
| authenticity.
|
| How is this compatible with Bluesky's internal cultural vision of
| "The company is a future adversary"[1][2][3]? With Twitter, we've
| seen what happens with the bluecheck feature when there's a
| corporate power struggle.
|
| [1]: https://news.ycombinator.com/item?id=35012757 [2]:
| https://bsky.app/profile/pfrazee.com/post/3jypidwokmu2m [3]:
| https://www.newyorker.com/magazine/2025/04/14/blueskys-quest...
| hombre_fatal wrote:
| I don't see how it's incompatible.
|
| The problem with Twitter (before the whole blue check system
| was gutted into meaninglessness) was that not enough
| verification badges were handed out. It's not exactly a
| dangerous situation.
|
| Bluesky's idea of verified orgs granting verification badges to
| its own org members would be an example of a much more robust
| and hands off system than what Twitter had.
|
| The dangerous scenario is what happened to Twitter after the
| Elon takeover: verification becomes meaningless overnight while
| users still give the same gravity to verification badges which
| causes a huge impersonation problem. But that possibility is
| not a reason to have zero verification.
| righthand wrote:
| What's stopping me from making an org that hands out
| verifications to anyone?
| d4mi3n wrote:
| Presumably a contractual agreement with BlueSky. Trust
| needs to stem from somewhere, so you're either looking at a
| web-of-trust model where somebody (BlueSky or BlueSky
| clients) makes decisions on what sign-offs to trust, or you
| trust BlueSky to perform due diligence on partner orgs that
| provide this service and to hold them accountable when that
| trust is breached.
|
| The WoT model works but as GPG has shown it requires your
| end users (people? BlueSky client developers?) to manage
| who they trust as an authority on anything.
| godelski wrote:
| Your profile says you're a security engineer, so I'm
| hoping you can help me understand.
|
| What was the problem with the current DNS system? I
| definitely think there could be improvements like
| displaying domain instead of TLD but still.
|
| And why not move into a system like multiparty keys? Keys
| assigned by domain holder, need to be signed, and
| verified accounts must login with a private key that
| validates. That way you don't just get that the account
| is validated but the post is too. Yeah, this would
| require more technical expertise to do but the
| organizations we're usually most concerned about would
| have no problem with that. Besides, tooling gets easier
| when there's meaningful pushes to make it available to
| general audiences
| verdverm wrote:
| There was once Handshake, but they failed mainly because
| they didn't want to work along side the current system,
| they wanted to replace it completely with a blockchain.
| It's actually one of the good use case IMHO, but their
| leadership didn't want to play nice with what we already
| have so transition could happen smoothly
| d4mi3n wrote:
| What is appropriate here really depends on what
| properties BlueSky wants to assert about it's ecosystem.
|
| > What was the problem with the current DNS system? I
| definitely think there could be improvements like
| displaying domain instead of TLD but still.
|
| As commenters earlier in this thread have noted, one
| property BlueSky claims it wants to develop/maintain is
| resistance against BlueSky itself becoming an adversarial
| party--say in the event it is bought out by an eccentric
| multi-billionaire who may take steps to discredit certain
| parties or reduce their reach or reputation.
|
| I don't think the current DNS verification methodology
| helps or hurts in a _BlueSky is hostile_ scenario. I
| think the only issues with the current DNS username
| verification system as I understand it are the same
| issues with any DNS based verification system in that
| vanilla DNS was not a protocol designed to be resistant
| to adversarial use and as a result there are many ways
| for people to tamper with DNS records, DNS queries, and
| confuse systems that incorrectly trust DNS records to be
| trustworthy or well-formed. DNS cache poisoning is a
| thing. Domain takeovers have and will continue to happen.
|
| Now, if we're talking about what technologies are
| suitable for username verification in a word where
| BlueSky is adversarial, we have a very different
| conversation. I think the scope of such a scenario
| extends a lot further than usernames. If your primary
| interface into the AT Protocol feed is the BlueSky
| website or the official BlueSky application, you are
| trusting BlueSky to validate usernames. An adversarial
| BlueSky could easily decide if your interface marks
| someone as trusted or untrusted without your knowledge.
|
| The only way I could think to avoid this would be to use
| a different interface to the global feed, but then you
| run into new problems that are more difficult to avoid:
| the fact that most BlueSky users don't host their own
| data (though this is doable with
| https://atproto.com/guides/self-hosting). BlueSky also
| manages the global feed, so barring a competitive global
| index, you'll still be consuming a feed curated by
| BlueSky's AT Protocol services and implementation.
|
| I'd close this by saying I am _not_ an expert in the AT
| Protocol, BlueSky's systems, or this space in general.
| This is a very fast and loose risk assessment I made
| after reviewing the AT Protocol and a bit of research on
| how BlueSky says it provides it's services. My current
| assessment is that if the community wants to be robust
| against BlueSky becoming adversarial, there needs to be a
| lot more support for self-hosting of PSPs and similar
| data stores, alternative global indexes, and likely also
| independent governance of the AT Protocol itself.
| godelski wrote:
| Thanks for the insights and disclosure. While maybe not a
| expert in the AT Protocol, certainly you are closer to
| the issue than myself and presumably most users.
|
| Were you given the ability to make a trustless or more
| decentralized system is there some route you would
| pursue? Maybe ignoring the AT protocol so I (and others?)
| can get a better sense of how such systems might be
| employed to ensure that an arbitrary organization can
| build defenses against themselves becoming adversaries
| (seems like a fairly useful mindset in general).
| d4mi3n wrote:
| > Maybe ignoring the AT protocol so I (and others?) can
| get a better sense of how such systems might be employed
| to ensure that an arbitrary organization can build
| defenses against themselves becoming adversaries (seems
| like a fairly useful mindset in general).
|
| There are ways to do this, but being trustless in the
| context of a social network is a thorny problem I'm not
| sure I can provide an answer to. The whole purpose of
| such networks is to enable communication with people you
| may not necessarily know (or trust). Furthermore, you
| implicitly trust the medium in which you use to
| communicate (BlueSky, Twitter, SMS, Zoom, etc.).
|
| There are ways to make things difficult for a service
| provider; you see many of them in high security contexts.
| For example, when storing data on AWS GovCloud or
| similar, you have the option have AWS use user or company
| provided encryption that they do not have control over.
| Should AWS be compromised in some way, they would still
| need to have your cryptographic keys in order to access
| unencrypted data (https://docs.aws.amazon.com/AmazonS3/la
| test/userguide/Server...).
|
| Another approach is message signing. An example of that
| is PGP signing of emails or files. You can use these
| cryptographic signatures to verify a message (email) or
| binary blob (file) has not been tampered with.
|
| Another common approach, which you have alluded to, is
| some kind of multi-party scheme. Many cryptographic
| blockchains are good examples of this: You need a
| majority of parties in such schemes to agree on something
| for it to be considered valid or true.
|
| A combination of these things can be used to make it more
| difficult for a service provider to be compromised or act
| against their user's interests. Sadly, this does not make
| it _impossible_ for them to do so. A user or customer who
| doesn't want to tolerate the worst case scenarios here
| still needs to make their own back ups, decide what
| entities to trust, and ensure they have robust procedures
| for doing things like trusting new entities or managing
| cryptographic material.
|
| I'll also note that there are in fact live examples of
| such systems if you look for them. See IPFS for one such
| example: https://ipfs.tech/
| derefr wrote:
| Bluesky's moderators, apparently.
|
| > For example, the New York Times can now issue blue checks
| to its journalists directly in the app. Bluesky's
| moderation team reviews each verification to ensure
| authenticity.
| dymk wrote:
| That sounds in conflict with "The company is a future
| adversary"
| steveklabnik wrote:
| It's no more than any client only showing the information
| it wants to; anyone can verify anyone else, without
| permission from the company. Any client can surface this
| information in any way they'd like, without permission
| from the company.
| verdverm wrote:
| Nothing, however AppViews like Bluesky decide which
| verifiers they trust. An AppView could also allow for user
| choice, like how algos and moderation work.
| steveklabnik wrote:
| deer.social already allows users to set a preference to
| turn off all verification badges, for example.
|
| EDIT: so does bksy.app, actually.
| steveklabnik wrote:
| Nothing: anyone can hand out verifications to anyone they'd
| like.
|
| Now, how those are _displayed_ is up to the display
| software. BlueSky themselves get to decide who gets a blue
| check based on verification records, but if you wrote your
| own software, you could do whatever you 'd like. There's a
| bsky fork that already has an account option to let you
| hide blue checks in your own view.
| FlyingSnake wrote:
| If anyone can hand out verifications to anyone they like
| then we're back to square one. Why do we need these "Blue
| Checks"? It feels like BlueSky is trying to reclaim the
| lost clout for some of their influential users.
| steveklabnik wrote:
| It's in line with the protocol design. If only BlueSky
| themselves could verify, that'd be too centralized.
|
| Mind you, just because anyone can create a verification
| record doesn't mean that the default client shows them.
|
| > Why do we need these "Blue Checks"?
|
| Normie users care about this sort of feature.
| FlyingSnake wrote:
| > Normie users care about this sort of feature.
|
| That's a really weak argument because normie users want
| TikTokified social media with a clout based caste system.
| I thought BlueSky had a different goal in mind.
| steveklabnik wrote:
| Bluesky cares about both audiences.
| TiredOfLife wrote:
| The problem with Twitter (before the whole blue check system
| was gutted into meaninglessness) was that verification badges
| were merit and nepotism and not identity based
| mattl wrote:
| That's not true though. They were for journalists and
| public figures.
| comeonbro wrote:
| Here is probably the most well-known instance of Pre-Musk
| Twitter removing blue checks from the accounts of public
| figures for reasons other than the account not being who
| it claims to be:
|
| https://techcrunch.com/2017/11/15/twitter-removes-
| verified-c...
|
| Not pictured: innumerable other accounts which were never
| granted a blue check in the first place, despite being
| the easily verifiable real accounts of journalists and
| public figures.
|
| It was de facto a caste system of political favor and
| connections.
| dijit wrote:
| Nearly everyone I interacted with on Twitter (pre-Musk)
| got their verification badge by essentially _being in the
| San Francisco tech community_.
|
| No matter how prominent someone might be on this side of
| the Atlantic, it never mattered, meanwhile mid-managers
| and coders at no-name startups had blue checks because, I
| mean, they knew _someone_ at Twitter- and who else is
| verifying people? I don't really fault them for verifying
| people they personally knew.
|
| But it meant that you had a situation where (and no
| offence meant to them) "nobodies" (as in, non-promenant
| figures) were "in the club" with heads of state,
| companies and heads of industry.
|
| So there was a definite whiff of nepotism, because it was
| a de-facto status symbol.
| albedoa wrote:
| Yep, same with "journalists". Publication companies were
| given a fast-track process that basically allowed them to
| hand out verifications to anyone who ever had a byline
| with them. The most reliable way to get verified was to
| sell some words to an online news website. It didn't
| matter how notable you or the publication were.
|
| When GP says "that's not true though" I can't even tell
| which part he is talking about. This is fairly recent and
| well-documented stuff.
| fortran77 wrote:
| The problem I had with twitter was the check was supposed to
| mean one thing and one thing only: that the person was who he
| or she claimed to be.
|
| What twitter starting doing was removing blue checks from
| people who were causing problems for the platform (but not
| behaving bad enough to kick off). This made no sense because
| people still needed to know if a person was who he claimed to
| be (e.g., Milo Yiannopoulos) even if the person was
| controversial or problematic or just plain nasty.
|
| Blue Checks weren't "gutted". Now they just mean something
| else -- you're a premium subscriber.
| wyclif wrote:
| This is absolutely correct--I remember quite clearly how it
| all went down. When Twitter first rolled out verification,
| it was supposed to ensure that the person you were
| following or interacting with was the person they claimed
| to be.
| burningChrome wrote:
| This was also because there were so many people setting
| up fake accounts using real celebs. The most famous of
| which was probably the Dave Chapelle, Kat Williams story
| that Chapelle tells where a fake Chapelle account was
| feuding with a fake Kat Williams account.
|
| https://www.youtube.com/watch?v=7_Egh9mW5y4
| NelsonMinar wrote:
| The problem is that X (formerly Twitter) is _still_ calling
| blue checks "verified". Even though nothing about the
| account is verified. It's deliberately misleading.
| ein0p wrote:
| Why is it "meaningless overnight" on Twitter? Twitter knows
| who you are if you're paying them montly. Ergo, you are
| "verified".
| tedunangst wrote:
| What happens when the government of Turkey objects to your
| verification?
| wmf wrote:
| Coming soon from Bluesky: per-country verification.
| yellowapple wrote:
| That'd certainly be a neat feature: national/regional/local
| governments running their own verifier accounts and
| providing Bluesky/ATproto verification to their residents.
| shrink wrote:
| I built handles.net[1] to make it easy for organisations to
| manage their member's handles, I think that using domain names
| for identity is neat and valuable, I have a vested interest in
| its success as a paradigm but... domain name "verification" is
| not the right solution today for non-technical people. I shared
| this sentiment a few months ago[2] and I have only become more
| confident in that assessment since.
|
| The approach they've taken ("trusted verifiers") is an approach
| aligned with their values, as it is an extension of the labelling
| concept that is already well established in the ecosystem. As an
| idealist, it is a shame that they gave up, I think they could
| have had an impact on shifting how non-technical people view
| domain names and understand digital identity... but as a
| pragmatist, this is the right choice. Bluesky has to pick their
| battles, and this isn't a hill to die on.
|
| [1] https://handles.net [2]
| https://news.ycombinator.com/item?id=42749786
| adityavinodh wrote:
| Yeah my initial reaction was not too positive. There's
| something weird to me about simply delegating verification to a
| third party organization. I'd prefer a more pure solution.
| Maybe we don't have a solution yet that is simple enough for
| widespread adoption. The domain based identity does seem a bit
| too complicated for the average user.
| yellowapple wrote:
| > The approach they've taken ("trusted verifiers") is an
| approach aligned with their values, as it is an extension of
| the labelling concept that is already well established in the
| ecosystem.
|
| That just leaves me wondering why they bothered with a new
| separate system instead of just using the existing label
| system. A "verified by bsky.social" or "verified by nyt.com" or
| whatever label would do the job perfectly well, no?
| steveklabnik wrote:
| I would have liked to have seen a justification for this as
| well. One thing about labels is that they can apply on a per-
| post granularity as well as a per-account granularity, but
| verification is purely account-level. Another is that they
| have slightly different semantics, you can lose your blue
| check if you change your handle or display name, but labels
| stay the same no matter what. That's probably the real
| justification for making it its own feature.
| yellowapple wrote:
| Both of those things sound like all the more reason why
| labels should've been the preferred approach here:
|
| > they can apply on a per-post granularity as well as a
| per-account granularity
|
| I might want my verification to apply on a per-post
| granularity. For example: if I'm speaking on behalf of my
| employer, then my post should reflect that, whereas my
| usual shitposting and pet projects probably should _not_
| reflect that. Currently the only solution there is to have
| entirely separate accounts (which might not be unreasonable
| even with post-level verification, but still).
|
| I'm also left wondering about the temporal aspects of
| verification. My employer might verify me as one of their
| employees _now_ , but not necessarily a year from now. Per-
| post verification would reflect that I was authorized to
| speak on my employer's behalf at the time I made posts to
| that effect, without retroactively implying that for posts
| I made before I worked for that employer, and without that
| verification needing revoked for those posts after I stop
| working for that employer.
|
| This is all admittedly a long ways off from what Bluesky
| probably intends with its new verification feature, but I
| guess what I'm getting at is that if labels can already do
| per-account _and_ per-post granularity then having a second
| kind of label that 's only per-account and doesn't offer
| anything that normal labels can't already do doesn't seem
| all that valuable.
|
| > you can lose your blue check if you change your handle or
| display name, but labels stay the same no matter what.
|
| That seems reasonable (but IMO questionably necessary) for
| handle changes, but rather unreasonable for display name
| changes.
| mpalmer wrote:
| Bluesky remains the single best example of how decentralization
| works best as components of the architecture, not its raison
| d'etre.
| pessimizer wrote:
| No, it's the best example of how after you take a bunch of VC
| money you won't ever give up an iota of control or ability to
| rugpull, no matter what the original purpose of your
| organization was.
| mpalmer wrote:
| True to your name if nothing else.
|
| Bewildering to me that seemingly any move in the right
| direction for social media is criticized with even more
| venom. How exhausting it must be to be stuck in such a frame
| of mind.
|
| Showing users that these ideas work is a win, it doesn't
| matter what Bluesky does in the future.
| 9283409232 wrote:
| I'm glad BlueSky is trying to innovate in this space but
| there is reason to be pessimistic. Eventually VCs want a
| return on investment and Bluesky doesn't actually make
| money as far as I know.
| ChrisArchitect wrote:
| _< checks Twitter development timeline>_ Yep, right on schedule.
|
| Fine with this albeit very 'manual'...but not clear if any other
| choice. I do really like the domain username scheme and if
| anything this news just draws more attention to that because
| there's sooo many organizations/news outlets etc not taking
| advantage.
| yellowapple wrote:
| The lack of domain-based verification among organizations is
| indeed bewildering. Surely these orgs have IT departments,
| right? Even the most junior of help desk techs should be able
| to figure out how to create a TXT record and paste in the
| gobbledegook that Bluesky provides to link that to an account.
|
| If these orgs _don 't_ have IT departments, then, well, pay me
| $20 and I'll do it for you.
| preciousoo wrote:
| Why not let users pick their own Trusted Verifiers?
| benwilber0 wrote:
| I'm guessing because users will just "verify" themselves, and
| then the whole thing is meaningless.
| steveklabnik wrote:
| In the current system, anyone can verify anyone else.
| preciousoo wrote:
| Users can then choose to subscribe or unsubscribe from a
| Trusted Verifier, if one starts to act in an unsavory manner.
| That a Verifier exists doesn't mean people have to use it
| steveklabnik wrote:
| That's absolutely possible for them to pivot to in the future.
| We'll see.
| paxys wrote:
| I like the idea of a trust hierarchy. Bluesky verifies NYT, then
| NYT verifies all their journalists. Makes the entire process a
| lot more scalable.
| Robotbeat wrote:
| NYT journalists as a privileged class... With actions like
| this, Bluesky is not exactly beating the allegations.
| 9283409232 wrote:
| I actually don't know what you are talking about.
| muglug wrote:
| NYT journalists _are_ in a different class from random
| Bluesky users -- if they spread unfounded conspiracy theories
| on their corporate-approved account, they can be fired from
| their jobs.
|
| Put another way, a Bluesky post saying "BREAKING: Trump dies
| from natural causes" from an employed NYT journo carries a
| different salience than the same post from a random Bluesky
| user.
| Applejinx wrote:
| Correct. I'd like the example of NYT as a verifying authority
| better if I trusted the Times more than I trusted some of
| their journalists (blessed few, mind you).
|
| I think it's pretty hilarious that the Times, of all people,
| count as 'trusted'. It makes me automatically distrust
| BlueSky verification, which doesn't sound like the intention.
| enneff wrote:
| It's not that you need to trust the New York Times as a
| whole, it's that you can trust that account is linked to
| that organisation. A verification tick does not imply
| endorsement, just that they are who they say they are.
| Applejinx wrote:
| That would be nice, I guess. In normie world a blue tick
| is supposed to mean 'vouched for and trustworthy, also
| high status so you should maybe show deference'. You can
| say it means whatever you want, but then watch how people
| fight for these things and argue about/rebel against
| them.
|
| In practical terms, no, they are status markers.
| trompetenaccoun wrote:
| The blog post is unclear on if they will only be allowed to
| verify accounts as being part of NYT or if they will be allowed
| to give out blue checks to anyone in general. It sounds like
| it's the latter. If not it shouldn't be a blue check at all, it
| should just inform users that the account is associated with
| NYT.
|
| News organizations have in recent years started selling so-
| called "contributor" positions. Anyone with enough money can be
| a journalist and influence public opinion. And NYT and similar
| outlets are not trustworthy sources either way, they sneak edit
| articles when they get caught spreading misinformation but
| regularly don't disclose what was actually changed. Basically
| rewriting their reporting as the narrative changes.
| steveklabnik wrote:
| > The blog post is unclear on if they will only be allowed to
| verify accounts as being part of NYT or if they will be
| allowed to give out blue checks to anyone in general.
|
| On a technical level, any account can "verify" any other
| account.
|
| On a practical level, blue checks are shown only if that
| verification comes from someone BlueSky trusts. Right now,
| that's bsky.app and nytimes.com.
| throwaway642012 wrote:
| That's very interesting. Does It mean NYTimes can also
| provide a Blue Check to someone from BBC, Reuters or even
| from a completely different org?
| steveklabnik wrote:
| At the protocol level, any account can verify any other
| account. If you have one, you can verify anyone you'd
| like right now. The NYT can verify any account, even ones
| from those organizations, or not even from a news
| organization.
|
| The only difference is that Bluesky won't show a blue
| check for just any verification, only ones from accounts
| they trust. That's a social relationship, not a technical
| one, and so I'm sure if the NYT decided to go rogue,
| Bluesky would have them not be an input into the blue
| check any more.
| pityJuke wrote:
| Good! I've been using a third-party labeller (which is a great
| hack), but making it more user friendly and official is a great
| thing.
|
| I'm a proponent of verification only for "important people". Yes,
| the definition of important is funny, and people may feel
| slighted by it: but I've yet to find a system that helps me
| identify high quality sources so immediately on a social media
| platform.
| jchw wrote:
| I think the best way to look at things is to look at platforms
| that don't and have really never had issues with verification
| to begin with. An oddly good example is YouTube, which has a
| verification feature that's so uneventful and drama-free I
| reckon a lot of people hardly even notice it. Even fairly small
| scale musicians and creators, at least relatively speaking, can
| have verification symbols. (Of course, there can be issues with
| e.g. account takeovers and people changing their name/icon to
| try to fool you, but that's not really a problem with the
| verification process itself.)
|
| The trouble with what platforms like Twitter did was by trying
| to stick to some definition of important, they took what should
| be a mundane "yep, this is the person it looks like" icon and
| made it into a status symbol that everyone wanted. Twitter had
| a hard time defining the boundaries: Shouldn't they verify
| their most influential users even if they're not real world
| celebrities or public figures? What happens if someone who is
| verified says something that they don't like? How do you
| prevent corruption when you give other organizations special
| privileges for verification?
|
| For Twitter and Instagram verification, people were bribing
| employees and getting verification just because they joined an
| organization (like an eSports team or a news organization.)
| This was not a good status quo.
|
| Bluesky is probably headed towards the same problem if they try
| to be the bearer of who's important. Obviously, you can't
| verify any Joe Schmoe, but honestly you can just set a
| reasonable threshold based on their status in the platform for
| as to whether or not they should be eligible to get
| verification. When you do stuff like say "You should be able to
| be verified _because_ you work for NYT ", that's just weird.
| Being a journalist doesn't magically make you important, or
| mean that your posts will be worthy of greater consideration,
| yet that's what you're setting people up for when you make
| verification into a big ordeal like this, and it's the reason
| why Twitter would unverify people for e.g. having an opinion
| too far outside the Overton window. And using in-platform
| metrics to determine eligibility seems reasonable anyways... If
| you have like 10 followers, your verification status is utterly
| meaningless anyways.
|
| I think if they want to solve the problem for journalists they
| should've verified the organizations and then made this
| separate from verifying individuals. Then accounts under that
| domain could just have some sort of special badge. This
| especially makes sense because otherwise you could literally
| just have your personal account become verified by having a
| couple month stint at the NYT or something, which is non-
| sensical.
| throwawa14223 wrote:
| This seems like an anti-feature. The appeal of Bluesky is exactly
| the lack of a Twitter like central authority.
| arghandugh wrote:
| The opposite. It's Twitter before Twitter was turned into a
| campaign of degenerate malignancy, with several escape hatches
| built-in.
| throwawa14223 wrote:
| Twitter was awful before Musk and is awful in a different way
| now. Emulating old awful is not good just because new awful
| is different.
| pessimizer wrote:
| If you were one of the people making twitter awful before
| Musk, you'd prefer a service that was old awful, rather
| than new awful. They just want the Shah back.
| staunton wrote:
| > They just want the Shah back.
|
| Is that a reference to something? Haven't heard that
| phrase before.
| AlexandrB wrote:
| I'm guessing it's a reference to the last shah of Iran:
| https://en.wikipedia.org/wiki/Mohammad_Reza_Pahlavi
| senderista wrote:
| You mean the kind of central authority that can censor accounts
| at the behest of a despotic government? Bluesky is not
| decentralized in any meaningful sense.
|
| https://www.turkishminute.com/2025/04/17/bluesky-restrict-ac...
| throwawa14223 wrote:
| I was misinformed about Bluesky. Thank you
| joshuaturner wrote:
| My understanding of that situation was that they could either
| remove that content from being accessible on Bluesky (the
| client) or have the site blocked entirely.
|
| They landed on country-specific moderation, which is all
| publicly accessible and documented, allowing countries to
| label specific posts/contents and have them hidden in the
| country. Again, this is only on the Bluesky client; other
| clients can ignore the 'hide' label if they choose.
|
| This is an article that details it pretty well and links to a
| few tools that allow you to view everything hidden by any
| country moderation team: https://fediversereport.com/bluesky-
| censorship-and-country-b...
| senderista wrote:
| What are these "other clients"?
| steveklabnik wrote:
| You have pure clients like https://deck.blue/
|
| And then "soft forks" like https://deer.social/
| ajb wrote:
| Not convinced by this.
|
| We need a way to reflect that human "social trust" is born
| distributed, and centralising trust subverts it. But here, while
| they introduce third party verifiers, rather than individuals
| deciding which verifiers to trust, bsky is going to bless some.
| So this is just centralised trust with delegation.
| TheJoeMan wrote:
| Are there any good examples of a working "vouch" system? I
| vouch for a few friends, they vouch others, etc. But if my
| credibility is revoked, everyone downstream of me is either
| yanked or needs a new voucher.
| jsheard wrote:
| I think the more exclusive private torrent trackers usually
| work on that basis.
| godelski wrote:
| ArXiV. Though they don't revoke papers that way
| fp64 wrote:
| A long time ago there was this "web of trust", I don't think
| it exists anymore. Was one of the big CA and you could get
| different certificates through some form of vouching, I think
| it even went as far as meeting people to show your ID and
| then they sign you or something. As it was run by a big CA,
| not really distributed but IIRC they kept their involvement
| minimal. It's been a long time but if you're curious maybe
| look into that
| duskwuff wrote:
| CACert.org, but they were never included in any major trust
| store.
| runjake wrote:
| It might have been Keybase?
|
| Keybase got acquired back in 2020 and it's popularity -- at
| least among cypherpunks, seems to have dropped off.
|
| https://keybase.io/
| jsheard wrote:
| Keybases popularity falling off a cliff isn't really
| surprising, their venture into shitcoinery already put
| them on thin ice with the anti-cryptocurrency crowd, and
| then development basically ceased overnight after the
| Zoom acquisition. I don't know why they're even bothering
| to keep the lights on, it's been five years of radio
| silence at this point.
| lgiordano_notte wrote:
| keybase had promise early on but kinda lost the plot. the
| vouching system was neat in theory but never really
| caught on outside a small circle. the crypto stuff
| definitely didn't help, and once zoom bought them it was
| basically a ghost town, no roadmap, no real dev activity,
| just inertia.
|
| feels like identity + trust systems keep coming back
| around but never quite stick. maybe too hard to balance
| usability, decentralization, and adoption all at once.
| godelski wrote:
| I feel like keybase was a good idea but needs to be
| redone. I guess there's keyoxide (any other?). What are
| people's thoughts on that?
|
| https://keyoxide.org/
| benwilber0 wrote:
| My initial thought is about GPG's "Web of Trust" system for
| trusting strangers' keys. But I don't know if that's a very
| good example since it always seemed somewhat esoteric and
| maybe not very successful in general.
| giaour wrote:
| "Working" would be a stretch, but this is how "web of trust"
| systems like PGP are supposed to function. Although I would
| say the BlueSky system sounds like it could skirt some of the
| pitfalls of web of trust because verifiers can also be
| trusted to revoke verification.
| aunetx wrote:
| There is a p2p social network (as in, people offering there
| services whatsoever) in France that does exactly this: it's
| called "Gens de confiance". It works well, although it
| creates kind of a gated community (as intended: it is mainly
| meant for upper-class social circles).
| paulsutter wrote:
| Google Pagerank
|
| Could use follows, retweets, etc instead of page links
| godelski wrote:
| I don't see what the problem was with using domains. If you're
| trying to claim you work for NYT then get a NYT verified
| account?
|
| And what ever happened to Keybase? That seemed like a good
| solution. Verify by public private key? It really seems like
| that could be extended. I mean we have things like attribute
| keys and signing keys. It seems like a solvable solution but
| just the platforms need to create a means for the private
| bodies to integrate their keys.
|
| Hell, I wish we'd have verification keys for cops and gov
| employees. So me a badge? No, show me a badge with a key I can
| scan and verify your identity. It's much harder to forge a
| badge with a valid key than it is to forge a badge that just
| looks good enough
| detectd wrote:
| > And whatever happened to Keybase?
|
| They got acquired by Zoom and promptly put Keybase into
| maintenance mode.
| mattl wrote:
| > I don't see what the problem was with using domains.
|
| DNS for your average user is too complicated. Also what
| should the domain name be for a journalist at the NYT? What
| if they leave the NYT?
| godelski wrote:
| > DNS for your average user is too complicated.
|
| The average user doesn't need verification either.
|
| In fact, I don't think I want most users verified. It then
| creates a reverse incentive where anonymous accounts are
| distrusted by default and too much trust is given to
| verification. An important part of a system with free
| speech and not governable (the point of distributed) is to
| be able to freely speak. Sometimes that means hiding your
| identity. Especially for those in countries or societies
| with particularly authoritarian rule. The best way to keep
| people quiet is to make them afraid of their neighbor.
| > what should the domain name be for a journalist at the
| NYT?
|
| AliceBob@NYT > What if they leave the NYT?
|
| AliceBob@bsky.social
|
| Everyone has the bsky.social handle, so you revert. I'd
| even be happy if optional profiles could show former
| affiliations. But it doesn't seem like a big problem. I
| mean NYT shouldn't be verifying a journalist if that
| journalist is no longer at NYT. Their new employer should.
| steveklabnik wrote:
| > If you're trying to claim you work for NYT then get a NYT
| verified account?
|
| Part of the problem here is consistent identity over time.
| People do not like changing their handles unless they want
| to. I'm steveklabnik.com now, but if I started working at the
| NYT, and had to switch to steveklabnik.nyt.com, old links
| break to my posts, etc. And what happens if I want to be
| verified by more than one org at a time? Domains (at present)
| can't do that.
| 9283409232 wrote:
| I feel like this could be solved with organizations like
| Github. Steveklabnik.com can belong to the NYT umbrella
| org. Like on Github, you can either be kicked out or leave
| the org if you wish.
| steveklabnik wrote:
| Right now, while it's possible to have a DID associated
| with multiple domains, the Bluesky app view only supports
| the first. Doing something like this _could_ work, but
| would be a larger lift.
|
| I do agree that multiple domain-based identities would be
| a nice feature though.
| godelski wrote:
| > old links break to my posts
|
| Do they? I didn't observe any breaks when I did my DNS
| verification. > People do not like changing
| their handles unless they want to
|
| I don't see it that way. On both twitter and BlueSky there
| are two handles. I'm sure there's a better term, but let's
| say "display handle" and "address handle". (On HN they're
| the same) People are paying attention to the Display Handle
| and not the address one. Most of the time the address one
| is even cut off and is partially hidden anyways.[0]
| > what happens if I want to be verified by more than one
| org at a time?
|
| First off, it doesn't seem like Bluesky's implementation
| will do this so I'm not sure why it is being brought up
| into this conversation.
|
| Second off, I agree that this is a desirable thing to have.
| It is why I was suggesting something similar to keybase
| (keyoxide?) or attribute keys. It definitely seems like
| Bluesky is intending to do something similar to the
| attribute keys but there's some details lacking and seems
| like an existing verified user needs to vet an entity prior
| to their ability to distribute keys. I'd also be quite
| happy if there was a publicly visible ledger so one could
| see former verifications (it's all visible via the firehose
| anyways, right?).
|
| [0] And there's the classic problem on typing "@" and then
| the person's name and not actually finding them because the
| search system is fucked up and is looking for the address
| handle. I've seen this on both sites, more frequently
| twitter, and even when typing the address handle directly.
| Apparently this is a harder problem than I'd have thought
| (particularly replying to someone in the thread...)
| steveklabnik wrote:
| > Do they? I didn't observe any breaks when I did my DNS
| verification.
|
| I went to one of my posts and clicked "copy link to
| post." that gives me an URL like this:
|
| https://bsky.app/profile/steveklabnik.com/post/3lndppxy7x
| c2a
|
| If I change my account to `steveklabniklol.com`, then
| this URL wouldn't work, as that url turns into
|
| https://bsky.app/profile/steveklabniklol.com/post/3lndppx
| y7x...
|
| See here for more: https://github.com/bluesky-
| social/social-app/issues/1221
|
| > People are paying attention to the Display Handle and
| not the address one
|
| I agree, and that's why people don't like changing it.
|
| > it doesn't seem like Bluesky's implementation will do
| this
|
| It does.
| yellowapple wrote:
| This seems like a perfect use case for `alsoKnownAs` being
| an array (which is already the case AFAICT). My primary
| handle (i.e. the first entry in the array) would still be
| @yellowapple.us, but with secondaries under the domains of
| affiliated orgs.
| steveklabnik wrote:
| Yep, I'd love to see it, and you're right that it is.
|
| I think that doing this raises a lot of _product_
| questions, so I 'm not shocked they haven't done it. But
| I'd like it if they would.
| verdverm wrote:
| Apps on ATProto get to decide for themselves. Another Bluesky
| client, or a completely different app, can make different
| choices. Users can then decide which interface they want to
| use. All part of the design of ATProto
| dbbk wrote:
| Ironically, Twitter's mechanism of auto-verifying anyone over
| 1M followers kind of achieves this.
| Akronymus wrote:
| IMO a system of "I vouch for these accounts" and "I trust the
| accounts these accounts vouch for, and the accounts those
| vouched for vouch for up to x levels deep" would be a workable
| solution.
| stego-tech wrote:
| They can justify it however they want to all day long, but we've
| got enough real-world examples of verification to show that its
| core use isn't about protecting users, but about authorizing
| acceptable speech on a platform and protecting advertisers.
|
| Domain verification was genuinely all the verification needed.
| This checkmark system is just a copy-paste troublemaker from
| Twitter, and we _all_ saw how well that turned out whenever a
| celebrity or billionaire 's account got hacked to shill grifto
| schemes. Training users to only look for a symbol just
| desensitizes them to the complexities of identity and sanctioned
| speech.
| pessimizer wrote:
| > Training users to only look for a symbol just desensitizes
| them to the complexities of identity and sanctioned speech.
|
| This is what their users are looking for. They don't want
| complexity, they want to know who they're supposed to listen
| to.
| derefr wrote:
| Given usernames-as-domains, is there a reason to not just
| piggyback this on the X.509 web of trust?
|
| After all, we already have an established and highly-monitored
| set of sibling "trust roots" -- we call them Certificate
| Authorities.
|
| And we already have an identity-validation system coupled onto
| X.509 FQDN-as-CN (i.e. TLS) certificates -- certificate
| validation levels.
|
| BlueSky could just:
|
| 1. require a domain username for verification;
|
| 2. require that the domain presents an Organization Validated
| (OV) cert for verification as a "public individual" (i.e. the
| kind with a "personal brand" -- which usually implies "worth
| registering as an LLC");
|
| 3. require that the domain presents an Extended Validation (EV)
| cert for verification as a corporation.
|
| ...and the whole problem of identity validation becomes
| outsourced, _and federated, and decentralized_. (Federated
| because multiple sibling CAs; decentralized because every
| computer administrator gets to decide for themselves which CAs
| their machine should trust.)
|
| ---
|
| A rebuttal might be that "EV certs can't be used for this,
| because EV certs are too expensive, take too long to get, and
| don't integrate well with automatic per-subdomain DV cert
| issuance via ACME."
|
| But (IMHO) that's not a problem to be worked around; that's a
| problem to be fixed. Why leave a broken generalized web-of-trust
| infrastructure sitting there unused?
|
| If an online casino can KYC/AML you in two minutes with a
| passport scan and a 3D camera photo, it shouldn't be impossible
| to do for OV+EV validation what we did for DV validation with
| ACME. (Ideally in such a way that you can do the interactive
| process once, receiving not a cert, but some kind of collateral;
| and then, later on, any ACME server should accept that collateral
| during an interactive domain ownership probe, to upgrade the DV
| cert it's issuing you into an OV/EV cert.)
|
| ---
|
| The other neat thing about this approach is that, in a "fat"
| native BlueSky app (i.e. not just an Electron wrapper), the app
| wouldn't have to trust _the BlueSky service_ to say who 's
| verified. The app could TLS-validate each domain username
| _itself_ , to compute the appropriate badge for that user -- just
| as a web browser does when you visit a website. And it would
| presumably use _your machine 's_ OS TLS CA store for that
| validation, just as (some) browsers do.
| giaour wrote:
| BlueSky users are already kind of doing this. Members of the US
| House and Senate tend to use their .house.gov/.senate.gov
| domains as usernames, which is a very trustworthy signal that
| the account is legitimate.
| rafram wrote:
| 1. Hello it's me your good friend Amazon S3 [1]
|
| 2. I've been programming and hosting websites for a decade+ and
| I would have _no idea_ where to start with any of the things
| that you propose they "just" require.
|
| 3. The OV requirement seems kind of hokey. There's no such
| thing as "worth registering as an LLC" -- anything can be an
| LLC. You could have an LLC that just holds your dog's assets
| and call it Internal Revenue Service (LLC), assuming someone
| else hasn't already grabbed that name in your state, and that
| would be completely valid.
|
| All of this would make it way too difficult to navigate
| verification for normal people, and I'm not convinced it would
| do anything to stop determinated bad actors.
|
| [1]: https://chaos.social/@jonty/110307532009155432
| derefr wrote:
| > 2. I've been programming and hosting websites for a decade+
| and I would have no idea where to start with any of the
| things that you propose they "just" require.
|
| That's because OV/EV certification are (currently)
| viewed/remembered mostly as "a bunch of bullshit that nobody
| sees the point in", and/or "a money-making scheme designed to
| allow big companies to throw money at the problem of looking
| 'more secure' than small companies, by showing up with a
| prettier lock icon/address bar state in web browsers" --
| ignoring the fundamental value provided by the design of the
| system, due to the pragmatics and politics of existing and
| previous (mostly previous) implementations of the design.
|
| A site presenting an EV cert used to look like e.g. this in
| Firefox: https://upload.wikimedia.org/wikipedia/commons/6/63/
| Firefox_...
|
| And this in IE/Edge: https://www.thesslstore.com/blog/wp-
| content/uploads/2010/06/...
|
| Once browsers stopped visually differentiating sites signed
| by OV/EV certificates from sites signed by DV certificates
| with the big "green for go" coloration, corporations no
| longer had any motivation to get EV certificates, so
| everybody forgot they existed. This happened a decade+ ago.
|
| (And then, in 2019, the last vestige of this distinction was
| removed, when EV certs stopped making browsers show the
| identified company name beside the lock icon:
| https://www.leaderssl.com/news/492-google-and-mozilla-
| will-s...).
|
| Because of this, nobody today is really _familiar with_ EV
| certs. But that doesn 't mean they're _hard_ or _arcane_ ;
| they're just _obscure_. And the process for getting one is
| clunky -- but it used to be that the process for getting
| regular (DV) certs was clunky, too. The EV cert process just
| hasn 't been updated with the times to match the ease of
| getting a DV cert, because nobody has cared to do so, because
| there's no demand.
|
| But neither of those things mean that EV certs aren't
| _fundamentally a good way to secure identity in a web of
| trust_. Every _code signing_ certificate is an EV cert, for
| example. And all cross-signed CA certs are EV certs. EV certs
| are still there, quietly underpinning much of X.509 's
| security model, in TLS and elsewhere.
|
| And as such, it's silly to recreate the EV validation
| ecosystem, _but worse_ , for something (identity verification
| on BlueSky) that is pretty much exactly "the green address
| bar" use-case all over again -- when we could instead just
| revive the dormant infrastructure that powered things the
| last time we cared about federated identity verification, and
| polish it up a bit for use in 2025.
|
| > All of this would make it way too difficult to navigate
| verification for normal people
|
| If they wanted, BlueSky could match what they're doing today
| by 1. setting up their own X.509 CA, and then 2. delegating
| the constrained ability to issue OV+EV certs to users from
| this CA, to named entities (like the NYT, as mentioned in the
| announcement.) Then you wouldn't have to do anything;
| everything could be handled on their end, with a BlueSky-CA-
| issued OV or EV cert just magically appearing bound to your
| BlueSky account.
|
| (And they could -- but _wouldn 't have to_ -- get this CA
| into default trust stores of client devices. The BlueSky
| webapp backend would have the BlueSky CA explicitly in its
| trust store; as would any first-party native fat clients. Any
| third-party native fat clients would need to add the CA cert
| into the app and configure their HTTP client to use it. X.509
| is not one global system; every X.509 root-of-trust creates
| its _own_ tree-of-trust, which is only a web-of-trust insofar
| as multiple roots-of-trust can [but don 't have to] cross-
| sign things.)
|
| The point here is just that with X.509, big entities who
| _BlueSky is unwilling to delegate identity-verification
| authority to_ , or who _don 't trust BlueSky_ -- or, as
| BlueSky themselves say, the existing userbase at the point
| where BlueSky itself becomes adversarial to them -- can step
| outside of this de-facto centralized trust model, by instead
| getting _an different_ X.509 CA of choice to issue EV certs
| for any entities they want identity-verified; and then
| uploading (or in the case of a native app, installing) these
| certs to bind them to their BlueSky accounts.
|
| In a bigcorp MDM domain, your EV cert allowing you to speak
| as @bigcorp_pr or whatever, would just get MDM-installed onto
| your device and you'd never even think about it. You'd just
| know that you actually can't log into that BlueSky account on
| any non-company device, despite knowing the password to the
| account, because no other device has the cert installed.
|
| > and I'm not convinced it would do anything to stop
| determinated bad actors.
|
| It does as much and as little as what BlueSky's announced
| approach -- have human moderators check identity
| verifications using their common sense -- does.
|
| That's all EV validation is, in the end: collecting a bunch
| of information and then having a human look at it and say
| "yeah, this is really who should be getting certified to say
| they own this domain" or "no, this seems to be some kind of
| domain hijacking attempt." (Or even "this domain seems
| created to typosquat a popular brand, so I'm not granting the
| cert, even if the person really does own the domain." Denying
| typosquatters EV certificates is/was an explicit feature of
| most CAs' EV processes -- although the term "typosquatting"
| hadn't been coined yet, so it was referred to as "trademark
| protection" or somesuch.)
|
| The only difference, in leaning on X.509 infrastructure to do
| this, would be that you wouldn't have to rely on "BlueSky
| moderators" as your only group of people willing to put their
| reputations on the line to assert "yeah, this is who they say
| they are; they're really in charge of this business; and this
| business is a real thing--the one you'd think of when you see
| the name." You can go out and ask any company specialized in
| "having a reputation for making identity-validation
| assertions that everyone trusts" (i.e. an X.509 CA) to do it
| for you.
| Tireings wrote:
| It could be perfect to have a basic network of trust as feature.
|
| Can't be that hard to have this
| doodlebugging wrote:
| I'm not a bluesky user yet but in reading through the post I
| discovered a problem with their implementation of the ID
| verification.
|
| They describe it as a "blue check" when in fact it is a white
| check on a blue circular background.
|
| Just nit-picking I guess but sometimes I read a passage that
| describes something and I conjure an image in my mind of what I
| would see should I open my eyes with it all laid out in front of
| me. This does not fit the image that is described in the post and
| makes we want to question the author's observational skills.
| mattl wrote:
| It's what the verification mark is typically called
| doodlebugging wrote:
| Why isn't it a blue check on a white circular background?
| That would make it a blue check. It doesn't matter to me
| since to date I am not a user, I just thought it was
| interesting that people would accept a non-truth as an ID
| verification.
| somat wrote:
| This is better than twitters nonsensical verification but still
| does not close the loop all the way. I think what is needed are a
| set of equivalency verification's. Sort of like the domain
| verification used in getting a TLS certificate.
|
| Something like bluesky user X is equivalent(has
| control) to domain A(domain verification) to
| youtube account B (youtube verification) to mastodon
| account C (mastodon verification) to D@nytimes.com (email
| verification)
|
| So logically I would expect a protocol that allows cross domain
| verification. Best I can come up with is something that works
| sort of like domain verification extended to user@domain
| verification. that is, a better engineered version of "make a
| youtube video with the string 'unique uuid code' in the comment"
| so that we can verify you own that youtube account"
|
| The problem is that some domains would have no problem standing
| up this sort of verification. The Times only benefits from
| verifying it's employees. However I can see fellow social media
| sites balking as this equivalency weakens their walls that keep
| people in.
| ammar2 wrote:
| What you're proposing is reminiscent of Keybase's account
| verification system. You make a post or equivalent on each
| platform with cryptographic proof that it's you. (e.g here's
| mine for GitHub https://gist.github.com/ammaraskar/0f2714c46f79
| 6734efff7b2dd...).
| toss2025away wrote:
| keybase.io
| thunkingdeep wrote:
| Bluesky is riddled with pornography, even with the strictest
| settings enabled. I genuinely don't feel comfortable scrolling
| any of the curated feeds in a public place except for my direct
| "Following" only feed.
|
| Not sure how big of a priority this is for the team that runs it,
| but I would probably use it 20x more if it was ran competently.
| Zak wrote:
| That hasn't been my experience with it, and I'm curious as to
| what usage pattern gets that result other than intentionally
| following accounts that post pornography. My account that
| follows and posts tech and general interest stuff gets tech
| stuff and politics in its discover feed. My account that posts
| bird photography and follows photographers gets photographs of
| animals and landscapes, and politics in its discover feed.
|
| It's politics I can't avoid there, not pornography.
| thunkingdeep wrote:
| I mostly discuss politics. I've talked about some technology
| stuff on there too, but it's easily 95% politics.
| Zak wrote:
| I should also note I have adult content set to allowed and
| all moderation categories set to warn or show, nothing set
| to hide. I can't recall seeing any porn at all outside of a
| couple searches meant to test the moderation settings.
| yellowapple wrote:
| Yeah, I can confirm that I have to go out of my way to find
| anything NSFW on any of my feeds (even while following
| multiple artists who occasionally post some risque drawings),
| whereas politics are unavoidable.
|
| Granted, I'm probably part of the problem, since I do post
| (and repost) some political stuff every once in awhile, but
| still.
| Edmond wrote:
| For folks interested in a PKI certificate based approach to
| solving verification problems:
|
| https://news.ycombinator.com/item?id=40298552#40298804
|
| Delegation similar to bluesky's "NYT org issues certs to
| journalist" is also possible and done in a far more versatile
| manner.
|
| If you have a domain and want the ability to issue certs to
| others, email me...this will just be for experimenting of course
| :)
| mhh__ wrote:
| The old blue checks were very useful as a way of knowing who was
| approved by the regime. So I sort of look forward to this, even
| if I still really struggle to even casually use bluesky.
| kristianc wrote:
| I think I've seen this movie before and it doesn't end with
| meaningful community trust. It ends with people paying for
| status, accounts impersonating others with a wink and a
| checkmark, and eventually, trust being eroded by the very signal
| designed to uphold it.
| sillysaurusx wrote:
| It's ironic that many comments are skeptical of strong
| centralized moderation, but they're posting these comments on a
| forum with perhaps the strongest and most centralized moderation
| team of the entire internet.
|
| All I'm saying is that if weak moderation has had a positive
| effect somewhere, it's worth showcasing that. Otherwise the
| evidence is decisively in favor of strong moderation.
|
| In terms of how to keep the moderation team from deteriorating,
| other platforms could learn a thing or two from HN: put someone
| competent in charge of the team, and give them lots of incentives
| to do well.
| DevOps72 wrote:
| There are a lot of users that have complained about the
| s-banning on this site. While the moderation team of this site
| seems to be well-intentioned, it does inevitably lead to a very
| strong slant. S-banning users doesn't make them or their
| viewpoints go away. They just end up happening elsewhere.
|
| Because those conversations _do_ end up happening elsewhere,
| this site is famous for leaving readers with a strongly _false_
| impression of what viewpoints are actually popular among
| whatever you would want to call this Silicon Valley hacker /
| VC scene space.
|
| The highly insidious thing about censorship is not only you
| don't know what you're not seeing but you don't know you're not
| seeing it -- you don't know what's missing.
| wmf wrote:
| HN moderation is easy mode because it's a small site and
| politics is "banned". Trying to do HN-quality moderation of
| political discourse among millions of users seems impossible.
| blotfaba wrote:
| It's giving Twitter "official teller of truth" vibes
| steveklabnik wrote:
| I got verified in the initial round of verification.
|
| On a technical level, this sort of works like a Root CA: anyone
| can verify anyone by publishing a `app.bsky.graph.verification`
| record to their PDS. Bluesky then chooses to turn those from
| trusted accounts into the blue check, similar to browsers
| bundling root CAs into the browser.
|
| * https://pdsls.dev/at://did:plc:z72i7hdynmk6r22z27h6tvur/app....
| <- bluesky verifying me. it's coming from at://bsky.app, and
| therefore, blue check
|
| * https://pdsls.dev/at://did:plc:3danwc67lo7obz2fmdg6jxcr/app....
| <- me verifiying people I know. it's coming from
| at://steveklabnik.com, and therefore, no blue check.
|
| I am not 100% sure how I feel about this feature overall, but it
| is something that a lot of users are clamoring for, and I'm glad
| it's at least "on-protcol" instead of tacked on the side somehow.
| We'll see how it goes.
| yellowapple wrote:
| I wish it'd work like labelers and other moderation features:
| with users able to choose which verifiers to use. I trust the
| NYT as far as I can throw them when it comes to verification,
| for example, whereas I'd be interested in something flagging
| Bluesky employees or contributors to a given GitHub repository
| or whatever other bizarre things people would use this for like
| they already use labels.
| steveklabnik wrote:
| What's good is that the technical design here allows them to
| pivot into that if they choose, and alternative clients can
| already do that if they wish.
| Zak wrote:
| It seems to me this feature would be much better if users could
| subscribe to verifiers the way they can labelers, perhaps with
| the official verifier subscribed by default. The current
| implementation feels centralized in a way that conflicts with
| BlueSky's stated goals.
| steveklabnik wrote:
| I'd agree that would be nice, but at least they can change
| into that in the future if they want.
|
| Hilariously, it's kind of less centralized than I expected:
| there's no "Bluesky is the web of the root of trust" here,
| only "Bluesky chooses which records convert to UI" which
| leaves the whole system open for others.
| throwaway642012 wrote:
| Do you have any insight on how was this initial batch of
| verified users selected?
|
| I'm on Bsky as well but haven't seen any such updates.
| steveklabnik wrote:
| I have no real insight. I do know that I am a big fan of
| Bluesky/atproto and post about it fairly regularly, and enjoy
| being friendly with the devs. They verified just over 200
| accounts, and most of them are news organizations and their
| employees, and the rest are programmers who regularly use the
| site and/or engage with the protocol.
|
| I think this makes sense, because 1. most people want this
| sort of feature for news and 2. the kinds of people they
| verified technically are likely to play around with it and
| see how sound it is, which is who I'd want to be kicking the
| tires.
|
| I'm not sure when they'll verify more people, but this is
| only the beginning, for sure.
| joshuaturner wrote:
| Initially I just thought they verified people working at
| Bluesky, which made enough sense, but this initial batch
| seeming so arbitrarily decided isn't a good look. It feels all
| too similar to the "I know someone at Twitter" verification in
| the SF tech community.
| FlyingSnake wrote:
| Unfortunately that's how I'm beginning to see this too, a
| sign of old school nepotism and struggle to regain lost
| status. We've seen how this unfolded for Twitter.
| steveklabnik wrote:
| Some employees aren't even verified!
|
| I hear you. I haven't investigated every account that got the
| badge, but it feels to me like they picked people who are
| both technical and engaged with the protocol, so not
| _entirely_ arbitrary. That naturally will have some
| correlation with "I know someone at bsky". I know I've seen
| accounts that I think are cooler than I am who didn't get
| verified yet! I'm sure they'll be expanding soon, which will
| dilute this sort of association.
| joshuaturner wrote:
| I can empathize with their position; I know this is
| something the community, especially the newer users coming
| from the continued rapid degradation of Twitter, are asking
| for.
|
| The concept of verification and Bluesky's original mission
| of decentralization are two very at-odds concepts, and I
| think they've bridged that pretty well and left a lot of
| options for themselves to expand it in the future. I'm just
| worried about the very visible parallels to the Twitter
| ecosystem emerging.
|
| My opinions on this will change if I join the verified
| elite, in case any bsky employees are in the thread.
| A4ET8a8uTh0_v2 wrote:
| If I was in a less charitable mood, I would categorize it as a
| misguided attempt at re-implementing previously failed ecosystem.
| But I am in charitable mood so allow me to say instead 'bold
| move. lets see if it pays off'.
| jarjoura wrote:
| If you contextualize this as a form of limiting the power and
| reach of bots, and you avoid going down the rabbit hole of speech
| and censorship, then this move is actually a very clever way of
| scaling that out.
|
| Trust is always going to be a game of cat and mouse, and this
| seems like just another move.
| FlyingSnake wrote:
| Hamartia: The tragic flaw that takes the hero to the top will
| lead its downfall.
|
| It seems to me that BlueSky is trying to rewind the clock and be
| the pre-Elon Twitter. They had a decent chance to become what
| Signal is to messaging, but looks like they are trying to be just
| another Social Media company.
|
| We're truly in the post-social media age.
| ChrisArchitect wrote:
| _" yessss FINALLY we have a caste system for professionals who
| were too stupid to figure out how to use a domain!"_
|
| haha
| rambambram wrote:
| Hey, I have this personal homepage. Available under a domain
| name. I trust myself, so I put a PNG of a blue check on it. If
| you don't trust me, I also have a blue check on my website that
| is put there by my best friend. Now you have to trust me. I guess
| I'm verified now, authenticated even.
|
| The web really was better with more pseudonyms. I don't care if
| you are you, I can read your text, judge it on it's merits
| (according to my yardstick) and I basically don't care if you or
| other people consume information that is true or false.
|
| Am I missing something?
| kmoser wrote:
| > Am I missing something?
|
| The ability to put fake blue checks on your website isn't the
| point.
|
| Bluesky (and the web at large) is slowly becoming filled with
| spam and AI-generated content. Even if you're OK with _more_
| spam (not sure why you would be but you do you), why would you
| be OK with more content generated by non-humans (the vast
| majority of which attempts to pass as human)? This just makes
| it harder to find needles of authentic human content in a
| haystack of slop.
|
| Various levels of verification make it easier to distinguish
| what's real from not real, for whatever definition of "real"
| you prefer. Without any such verification, the web just becomes
| a bigger wasteland.
| gus_massa wrote:
| Can a country verify it's president?
|
| Can a country I don't like verify it's president that I don't
| like neither?
|
| Prime minister? Members of the Senate? All citizens? Their own
| bot farm?
___________________________________________________________________
(page generated 2025-04-21 23:00 UTC)