ryan29

> Email infra is cheap; email reputation management is not.

In that Reddit comment linked in that article the person says they were spending $325k on self-managed infrastructure and the same thing would cost them nearly $4 million on SES.

It's unlikely they're ignoring reputation management with their self-managed stuff, so that's included in the cost, right? What kind of value added reputation management would something like SES be providing that's worth +$3.65 million per year?

What's the real threshold where the costs makes the system unattractive to bad actors? It's definitely nowhere close to millions of dollars in my opinion. I would say the entrenched players like the status quo because it gives them astronomical margins, so they act in an anti-competitive manner that ensures we never get anything better.

Overpaying by thousands, hundreds of thousands, or even millions of dollars per year for email reputation management seems like a terrible deal to me. Maybe someone can break it down for me and explain what kind of value you're getting for the 10-100x increase in costs. Is it anything beyond a pay-to-play scheme that's the result of tacit collusion?

I know everyone says it's not practical to run your own mail server, but I wonder if it's something I should have another look at. Even though this article says the cost of SES is 12:1 vs self managed infrastructure, and it's likely that SES is on the cheaper side of things, it's not really about the cost for me, it's about the loss of control.

I don't like having the potential for changes I can't control. It almost feels like I need two of everything just to be safe.

I wish some of the up-and-coming auth systems (ex: logto.io) would have some kind of tiered fallback for transactional email. For example, I have self hosted mail that's tier 1 (use first), AWS SES as tier 2 (use for failover), and Postmark as tier 3 (use as a last resort).

The reason I list Postmark last is because there is a point where price becomes a factor for me. If Postmark is 10x SES for 50k messages, and SES is 12x self managed infrastructure, that's 120x costs (12,000% markup), right? I feel like that's so expensive I might have gotten it wrong, so please correct me if I did.

If you don't have a lot of projects, it may be better to transfer them into a newly registered organization because that doesn't require a temporary drop of the namespace. Either way, you'll break the redirect, but that's better than being vulnerable to impersonation IMO.

The same problem exists, but has less of an impact on other platforms as well. For example, switching to a domain based handle on Bluesky will make your old handle available for re-registration. That makes you vulnerable to impersonation via the old handle.

I wonder if some of these platforms could allow aliases, so, using the example in the article, switching from 'MyOrganization' to 'NewOrganization' lets you keep 'MyOrganization' as a permanent alias. Obviously that would invite namespace squatting, but I think you could solve that by charging a one time fee for an alias. If you're renaming an organization it's likely worth $50+ to keep the old namespace.

Ideally, everything should move to domains as namespaces IMO. I'd rather maintain a single domain vs (hopefully) matching namespaces across a dozen different platforms.

> I think that "quality" will be really, really hard to objectively measure in the near future as the whole world of digital information becomes tainted with applied statistical models which can do a reasonably good job of predicting what people perceive to be high-quality reasoning, answers, content.

That's the scariest thing I've heard today. Lol.

Even now, I think the proper use of grammar and spelling alongside assertive language has a lot of people fooled into thinking LLMs are actually intelligent. It's hard to explain to people how the LLMs know everything and understand nothing.

I've been bullish on the idea of using domains as identity for a long time. I think by using them as a universal ID you could build reputation and trust across the internet and that helps everyone a lot when trying to assess the reliability of information. If you add in attestations for factual info it gets even more interesting. Ex: GitHub attests user @john.example.com has 1000 commits to the XYZ project. Suddenly you have a more reliable way of ranking John's comments about XYZ as a topic, regardless of where they show up (as long as those identities are validated somehow).

If you look at that as "ranking people" and judge it in the context of being a valuable piece of input for LLMs/AIs, the big push for "better" identity systems like "Passwordless" start to look like a hell of a coincidence. My cynical side wonders if we'll see a push for validated (via government ID) identity systems. Something as simple as a "real human from Canada" tag would provide immense value for AI training (and marketing).

No matter what, I think AI is going to cause changes in the way online identity and reputation work. I think if it evolves into some kind of system with domains as identity it'll be decentralized and provide long term benefit. I think if we see something with verified IDs controlled by the current big tech companies it could devolve into something disappointing or even detrimental for the average user.

> There are exceptions, obviously. There are true experts who wander the virtual halls of StackOverflow and dole out wisdom.

This is what makes SO valuable for me. Every year it seems like "trust but verify" requires a little more emphasis on the verify part, so it's extremely valuable when I run into a true expert where I know I can take their input at face value and rely on it.

I think the winners of the AI gold rush will be the ones that figure out how to help users assess the trust they should be putting in the information being surfaced. The problem I see with the current ChatGPT, etc. systems is that they seem to treat visibility and popularity as credibility and expertise when that's not the case. In my experience, the real experts don't say anything unless they can add to the conversation and there's never a lack of low quality information from uninformed participants.

For example, via ChatGPT...

Q: How do I protect against the scrub of death with ZFS?

A: The term "scrub of death" is commonly used to refer to a situation in ZFS where a data scrub operation can lead to catastrophic data loss due to undetected errors or issues. While ZFS is designed to provide data integrity and protection, it is still important to take certain precautions to minimize the risk of encountering such a situation. Here are some steps you can take to protect against the scrub of death with ZFS:

Except it's not a real thing [1]. For bonus fun, read the comment right after Ahrens'.

I don't understand why SO doesn't lean into that. Anyone can train an LLM on the raw data, but SO has the information needed to do a better job of ranking the quality of the inputs, so wouldn't they be able to build an LLM that's significantly better than anyone else with the same raw data? Understanding the quality and reliability of an answer is far more important to me than getting an answer.

What's more frustrating than getting an answer on a programming question and taking hours to figure out that it was complete BS and doesn't work as described?

I don't know much about LLMs, but, if I were SO, I'd be figuring out how to lock down the ranking information as quickly as possible because that's where the value is. The ranking and acceptance of answers, alongside tags, overall user rank, participation frequency, etc. should mean that SO has a significant advantage when it comes to ranking and weighting the input data, right?

I want the input from subject matter experts to count the most and SO has the best data set to provide that. I don't see the point of locking down the content when the real value is in the ranking. It's odd that SO doesn't see that considering the entire network is modelled on that idea. Maybe they do and there are bigger changes coming down the pipe.

I think the real debates are going to come in the future if SO releases a paid LLM product that's trained on community contributed content and rankings.

1. https://arstechnica.com/civis/threads/ars-walkthrough-using-...

> None of the contributors (apart from the employee ones, I suppose) ever got paid any currency other than high-fives in the form of rep, medals, the gamified stuff, moderation rights, and at certain rep levels some swag in the form of t-shirts and the usual.

I would love to see some kind of identity and reputation system where the "high-fives in the form of rep" could follow people across communities. It may not feel like much compensation if you've contributed over 2500 answers, but having reputation gained in your area of expertise grant you a high level of trust to interact in other communities could be valuable, at least in my opinion.

Assuming they're making this move to protect against AI / LLMs, I think SO is in an impossible situation here. When all the ChatGPT hype started, one of my first questions was "what happens to the incentive for contributors and creators?" Why would I want to contribute on a platform if I know an AI model is going to come in, take my contribution, and regurgitate it back to the masses in a way that I can't control?

Even if I get some attribution from the AI/LLM, do I even want it? If the LLM is blending content from multiple sources, which changes the context and presentation I put effort into, is the quality going to be high enough to match what I strive to achieve for myself when I'm trying to build a reputation as a high quality contributor? What if the AI is hallucinating objectively poor quality content and giving me partial attribution?

So, for me, part of the social contract with SO is that I provide answers, but I get to control the entire interaction; the context, the presentation (mark up), defending criticism in the comments, etc.. In addition to that, since the entire conversation happens inline, I can be corrected by someone even more knowledgeable than me and use that feedback for self improvement.

I think AI is going to be disruptive and the whole idea, for me anyway, behind disruption is that you break an existing system and then everyone is free to take a shot at claiming part of the new gold rush that occurs while trying to build the replacement. The problem with AI is that it's going to break a lot of services that do a good job of serving the community and shouldn't be broken. SO is a great example of a healthy community that doesn't need disruption, but the massive amount of high quality, curated content is going to make them a prime target for LLM training.

Personally I think the only solution is for "noai" variants of popular open source licenses so contributors have the ability to make it clear they don't want to contribute to AI/LLM companies. If SO had an option to flag contributions as CC-BY-SA-NOAI, I'd enable it on my stuff going forward.

I've read parts of the docs, but I guess it'll take a bit to see how it works in practice. The docs [1] list some of my concerns as "What Sigstore Doesn't Guarantee".

That same doc also says:

> Fulcio was designed to avoid revocation by issuing short-lived certificates instead. When signing, the user only needs to know that the artifact was signed while the certificate was valid.

The part I don't get is what happens when someone's OIDC account gets compromised and used to sign artifacts? How do the compromised signatures get un-trusted? Even better, what happens if the artifact repository is using OIDC and developers use the same "log in with GitHub" account for the package repo and Sigstore? Isn't that about the same as not even having signatures at that point?

As for the Fulcio stuff, I don't really get the point of some of it TBH.

> Fulcio assumes that a valid OIDC token from a trusted provider is sufficient “proof of ownership” of the associated identity.

Most OIDC providers are going to have an email or SMS based account recovery process, so, at that point, you're more or less trusting those as proof of identity. I feel like history has proven that's not adequate for protecting anything of value.

Then there's the post-failure, auditability of the logs.

> As a result, users can detect any mis-issued certificates, either due to the CA acting maliciously or a compromised OIDC identity provider. Combined with Rekor's signature transparency, artifacts signed with compromised accounts can be identified (auditability).

I don't want to be notified about failures that I can audit after the fact. I want to be notified before a cert is issued for my identity.

From what I've read the Fulcio certs can have validity measured in minutes. To me, it would make more sense to publish a CSR on the CTLog for X days, allow an identity owner to request rejection within that time period (by proving identity), and finally issue the cert if no one objects. It would require longer lived certificates, but it would let me monitor the log to make sure no one is requesting certs for any of my identities. If I see something unexpected it probably means I have a compromised account and at least I get X days to remediate the damage and request the CSR get rejected (assuming I regain control of my account).

If you have something you can audit, you get warned about damage in progress. If you have something you can preempt you can prevent the damage all together. I'd pick the latter if given the option.

I also want to get a better understanding of the OIDC tokens and how they're issued.

> When running something like cosign sign, users will complete an OIDC flow and authenticate via an identity provider (GitHub, Google, etc.) to prove they are the owner of their account.

I bet that doesn't happen every time an artifact needs to be signed. People are going to want to automate signing via CI and, I assume (maybe badly), that's going to mean long(er)-lived OIDC auth tokens authorizing short-lived signing certs. If that's right, I worry about token hijacking.

But there's a solution for that!

> Similarly, automated systems (like GitHub Actions) can use Workload Identity or SPIFFE Verifiable Identity Documents (SVIDs) to authenticate themselves via OIDC.

That sounds like another extra party that can act on my behalf and adds even more complexity. I need to read more about how it works, but common sense would say that if artifacts can be signed without me taking any action, they can be signed without my consent, right?

It seems like a lot of complexity to me, but I've never used it, so I guess I'll have to give it a try. Usually a lot of things that seem illogical on the surface start to make more sense with a better understanding of how everything works, so hopefully I'm just lacking perspective for now and it ends up being an amazing system that topples the current code signing industry (which I really dislike).

1. https://docs.sigstore.dev/security/#what-sigstore-doesnt-gua...

Couldn't you say those same things about the current providers for code signing certificates?

It almost sounds like a trade of one subpar solution for another. What do I get as a consumer trying to verify an identity? The way I see it:

    Current:  This code was signed by someone that gives Sectigo $500 / year.
    Sigstore: This code was signed by someone that also has a Google account.

Neither does much in terms of identity or trust. Maybe that's not the point and the idea for Sigstore is to provide the equivalent of a long term (ie: lifetime) key by tying the identity to a well known account, but that doesn't feel like an awesome solution for me as a developer.

The saying "not your keys, not your crypto" seems to apply here, but it's more like "not your keys, not your identity". Google or Microsoft (via GitHub) own my identity and they can take it away, right?

I don't know a ton about Sigstore, so maybe these are all unjustified concerns, but, to me, it seems like it's convenient for key management, but I don't understand how it adds much value. The way I see it, when I consume a package the only guarantee I get is something along the lines of "this package was published by example456@gmail.com" and it's guaranteed by OIDC, signing, etc..

That OIDC identity can still be compromised and, even if the numbers get reduced, we'll still have to deal with fake accounts and bad actors. Look at the volume of spam accounts on YouTube. For me, that doesn't inspire confidence in letting companies like Google become the arbiters of identity for the entire development community.

What if I get banned for no reason? Can I bootstrap back into the system using an alternate provider? How do I communicate that change to everyone consuming my packages?

I feel like there's a chance a system like Sigstore could devolve into the same kind of verification system we have with the current code signing vendors, but even worse because of the massive scale and minimal revenue. We could end up sending government ID to Google and Microsoft just to have accounts unlocked. Even though I think they're all terrible, the current code signing vendors at least have humans you can deal with.

I think a domain is a better way of bootstrapping identity. It's a globally unique ID, so it improves discoverability and reduces confusion / impersonation. I know it's not the same as code signing in terms of protecting the supply chain, and agree that code signing is more important, but I'd rather have a code signing system that treats my domain as my identity compared to one that uses an account from one of the big tech companies.

Would you rather see "this code was signed by tailscale.com" or "this code was signed by tailscale@gmail.com"? I know the domain is owned by the organization I'm expecting. I have no idea who owns the GMail handle and I don't see how being guaranteed they signed some code gains me anything, regardless of how fancy the whole system is. I guess once I trust them I know it's the same person signing packages, as long as their Google account hasn't been compromised.

Like I said, I don't know enough about Sigstore, so hopefully someone can explain to me how it isn't just a more convoluted way of owning a long-lived signing key, but with the downside of having it gated / controlled by someone else via OIDC.

> I never use oauth (like to create a new account / password for everything).

Me too. I have 672. Lots are for accounts I set up for nieces/nephews, etc., so those don’t really count. I bet 100 are stale as well I’ll clean them up one day. Lol.

No. I would use domain as a vanity pointer and a permanent account as the source of truth that clients use to download packages. You have to assume the domain can be dropped and re-registered by a bad actor, so a permanent account with proper package signing is really the only way to ensure you're not getting packages that are the result of an account takeover.

All a domain based namespace really does is help to get rid of impersonation and the confusion causes by squatting and mismatched namespaces everywhere. I think it helps in evaluating trustworthiness the first time you add a package to a project, but you still need package locking and signing to ensure you're only getting packages from the person or organization you've trusted.

> Again: namespacing isn't the problem (or a totalizing solution) here.

The current system works better for impersonators and squatters than it does for me as a legitimate participant, so, in my opinion, that's at least part of the problem. Domain validated namespaces go a long way towards solving that.

> it effectively gatekeeps the entire packaging ecosystem on the ability to purchase and maintain a domain name

There's no reason there can't be a default namespace similar to what Bluesky did. By default you get @example.bsky.social and can optionally switch to a custom domain. The main thing that Bluesky got wrong is they recycle your original handle when you switch to a custom domain and I think it should be (optionally) kept as an alias to prevent impersonation.

> assumes trust in a namespace (DNS) that was never really designed to be authenticated

It's trusted enough for MS365, Google Workspace, ACME (protocol), and basically everything on the internet at this point. PyPI.org is using a domain validated SSL certificate and (AFAIK) distributes unsigned packages. I view that as about the same amount of risk as using domain validation for namespaces.

> or a source of stable, permanent identifiers (domains change hands all the times, including for hostile reasons).

Domains changing ownership can be handled reasonably well by treating the domain as a mutable pointer to an immutable namespace. The immutable namespace would be the source of truth that would be trusted by clients and would point back to the domain so they reference each other. If either pointer changes the client can warn the user and let them decide how to handle it. By using the immutable namespace after following the mutable (domain) pointer once, you eliminate a lot of the value of stealing a domain to take over a namespace. If you flag domains that have recently started pointing to a different immutable namespace (ie: a new domain or owner), it acts as a cautionary warning so users know they shouldn't be blindly trusting the namespace.

Dealing with banned domains would likely be a pain point, but I don't think banning an account changes much in terms of human factors involved. On the domain side of things I'd probably maintain a public list of permanently banned domains, at least to start with, and see what problems that creates before trying to find solutions. Non-negotiable, permanent banning might even be ok.

For me personally, domain validated namespaces would be a huge improvement. I'm sick of the gold rush and having to chase my handle on every platform. Even if I get it, I'm still indistinguishable from a bad actor on most platforms because I have very little activity and nothing popular.

At least with domain verified namespaces someone who doesn't know me can go from pypi.org/@example.com to github.com/@example.com or example.com and be nearly guaranteed it's me (ignoring domain hijacking). That makes it easier to make a judgment call on whether or not to trust me because most of my activity will show up at, or be linked to from, those places.

Plus, as a package becomes more popular, the recognizably of the owner's handle also grows. With a single, domain validated namespace, that's only one definitive thing for people to have to recognize which cuts down on the cognitive load of trying to figure out if mismatched namespaces are legitimate or someone trying to engineer an attack.

I think the current system for namespaces is a big chunk of the problem because it's non-authoritative in the context of knowing who owns a namespace. By switching to domain validated namespaces a lot of that ambiguity disappears because you know that example.com, pypi.org/@example.com, github.com/@example.com, twitter.com/@example.com, etc. are all the same person or organization. That means that as soon as you know you can trust them on one of those platforms, you can trust them everywhere else because, as long as the UI flags new domain pointers to combat domain hijacking, you've basically removed impersonation and squatting as a potential threat.

So, maybe it's not perfect, but, in my opinion, it adds enough value that it's worth considering as an option. I think it's great on Bluesky because I find it so much easier to determine whether or not people are legitimately who they say they are and not some prankster or impersonator. For example, I'm following @tailscale.com on Bluesky and I know it's them.

I think domain verified namespaces would make a difference. If I own example.com, it makes sense for my namespace to be @example.com (pypi.org/@example.com/project).

If all namespaces were domain based it would reduce impersonation and confusion while making it much easier to assess trustworthiness. If I can definitively associate a namespace across GitHub, PyPi, the internet, I can get a much better idea of whether or not I should trust someone.

I also think that could evolve into some type of attestations about money already being spent. I call it collateral attestation.

For example, if I use GitHub Sponsors to donate to a project, GitHub could attest to that. If I donate $50 to the PyPi project, they get an attestation that someone donated $50 to them and I get an attestation that I donated $50 to someone.

Even if it's only domain validated namespaces, at least that's something that costs a little bit of money every year and it scales without a lot of human intervention compared to most other ideas.

There are a couple things i don’t like about this trend.

First, I have idle accounts for brand protection. I really dislike being forced to participate in the handle registration gold rush to begin with. Now I’ll have to set aside a day every few months to log in to all of them. It’s not a huge deal, but it’s annoying.

Second, if idle email accounts become available for re-registration it might expose some users to account takeovers if they own accounts with email addresses they’ve forgotten about. And, what about people forwarding from accounts they never log into directly? I wouldn’t consider those inactive. Does Google?

There's a good chance it would be considered a "bad faith" complaint. It's called reverse domain name hijacking [1] and is specifically addressed in the UDRP.

If you lose the dispute, you'll never buy the domain for a reasonable price after that, so it's a really risky move.

https://en.wikipedia.org/wiki/Reverse_domain_hijacking

> You can't register the trademark until after you've been engaging in commerce with it.

Is that US? I'm in Canada. I think we can register before commercial use [1]:

> Another of your responsibilities as the owner of a trademark is to use the trademark in Canada. If you do not use it, the registration could be expunged from the Register of Trademarks by the Registrar. The Registrar could start summary expungement proceedings, after three years beginning on the day on which a trademark is registered

To me, that sounds like you have to use it within 3 years of registering and I didn't see anything requiring commercial use prior to registration in the linked info.

We also have a ~3 year backlog for applications and I don't know if the trademark ends up registered with the filing date or the issuance date. It's the kind of thing that's complicated enough that I wouldn't want to risk screwing it up, so I'm waiting until I can pay someone that knows what they're doing.

TLDR; It's complicated and expensive, especially compared to the simplicity of pulling out a credit card and registering a dozen TLDs. Lol.

1. https://ised-isde.canada.ca/site/canadian-intellectual-prope...

I was trying to decide this a few years ago when I found the best .com I'll ever own. It's only 8 characters and I was able to get matching social media handles everywhere but Twitter.

My main concern was that someone with more money than me could come along, start using it, trademark it, and make it unusable for me. I've been thinking about trying to trademark it, but it's expensive and complicated, especially if I can't get a trademark personally and transfer it to a business in the future

In the meantime I decided it was worth the money to buy every decent TLD as a way of discouraging someone else from trying to use the same name. It's not cheap, but it's cheap in the context of what people like the OP pay for a decent .com.

I pay about $200 / year in total to renew about a dozen matching domains. I can hold onto those for 20 years and it'll still cost less than the asking price of a half decent .com.

Think of the .net and .org as a $3 month expense for brand protection. I'm from Canada where .com and .ca are used pretty equally. I remember about 10 years ago when a local computer store only registered one of them and ended up with an unhappy customer redirecting the other to a porn site. Would you pay $3 / month to avoid dealing with that?

I just want the option of using my domain name as a verified handle everywhere. I’m so tired of having to participate in the gold rush to grab my handle for brand protection, especially on platforms I barely use.

> Any minute now the average user is going to realise that Dropbox is useless, you can just use ftp

I really don’t understand the harm in having more options. Would you say we should never consider anything but Dropbox because it works fine for the average user? What about someone with >250k files which tends to be what all of those sync platforms recommend as the max number of files you should try to keep in sync?

> Because outside of HN users, people do not want domains as handles and the feature is actively dangerous.

HN is frequently ahead of the curve in terms of trends, so it’s not shocking if most people don’t understand the value until they see someone else getting that value out of a new strategy.

In terms of it being dangerous, I don’t agree. I think having everyone associate me, my brand, my business, etc. with my domain name reduces the risk of being de-platformed because anyone that wants to can easily find me via my universal handle (aka domain) regardless of the platform. I’ll gladly take on the risk of having to remember to renew my domain name as a trade off for the added protections I get via the dispute resolution processes for domains.

> What happens when you forget to renew your domain? The bot that grabs it gets to take over your account or handle?

No. Expired domains have a well defined post-expiration lifecycle that makes it difficult to lose a domain unintentionally . If you don’t notice everything you use being broken for a month, it can’t be that important, right? Yeah, you’d lose the handle, but the account ID is typically immutable and used as a source of truth, so it wouldn’t give a new domain owner the ability to hijack your account.

Every time I see one of these roll out with dots allowed in the username [1], I wonder what they’re thinking. YouTube just made that (IMO) mistake with their new handles and now Discord is doing the same.

I think it’s a mistake because using validated domains as handles makes sense to me. Even if it’s not a requirement, giving businesses and large influencers the option of using a domain as a handle has benefits. Reducing impersonation is one of those benefits and, subjectively, Discord is frequently a component in impersonation scams.

Even if you don’t want domains as handles right now, why wouldn’t you keep the option available by forbidding dots in usernames, especially since Bluesky is getting a lot of hype and they’re using domains as handles? If Bluesky catches on, impersonation using handles that look like domains will become an issue for platforms like YouTube and Discord because they aren’t paying enough attention.

Or is in intentional? Domain validated handles are amazing for small businesses trying to create a consistent experience (across services) for their users, so maybe that’s the whole point. Allowing bad actors to impersonate domains reduces the value of domains which makes users more dependent on platform based verification solutions that don’t double as an advertisement for your website (that you control).

What are the upsides to allowing dots in a username or handle? I don’t see any that outweigh the downsides.

1. https://support.discord.com/hc/en-us/articles/12620128861463...

I’ve been thinking about this a bit more. What happens if the server operator bans a DID? Does that ban the DID across the whole network via federation? What if I run my own server? Does that make me un-bannable?

Is there even such a thing as DID bans or is everything handled via moderation and filtering? I’m guessing impersonation would still be an issue even if domain based handles solve most of the impersonation problem.

So the domain is a mutable pointer to an immutable DID? That’s pretty much how I’d do it too [1]. Very cool!

1. https://news.ycombinator.com/item?id=32755618

I always try to distinguish between decentralization of infrastructure and decentralization of control. I think the former is very difficult to achieve, but that’s ok because the latter is by far the more important of the two.

As long as I can (technically) take my domain based handle and move to another host I’ll be thrilled. I also hope it’s not a fad because I think it’s a huge win for users, especially small businesses.

I wonder how they handle dropped domains that are re-registered.

I would like to see this done using domain validated identities. It might not work for everything, but, if I can prove I own a domain, it's a globally unique handle that can be used to build online reputation and trust.

It would also make is possible for larger companies to attest to purchases made and / or the quality of participation within their community. Imagine a scenario where I donate $50 to an open source project using GitHub Sponsors with my domain as the identity and GitHub attests to me spending that $50.

Over time, it would be possible to demonstrate a significant "investment" in your domain validated identity and it would be done by spending money online like you normally would without any additional cost. The attestation that you spent the money is simply a side effect of something you're already doing, but it's a really good indicator (over time) that you're a normal participant.

At the very least, I think having a domain as a globally usable handle would help to reduce impersonation which is a serious, difficult to solve problem right now.

I think there are potential alternatives that could evolve.

My preferred solution would be domain validated identities with long lived, global reputation alongside some type of attestation. For example, if I have a GitHub account with 'example.com' as a verified domain, GitHub could attest 'example.com seems to be a real user or organization that behaves well'. It would be similar to the web of trust concept in GPG, but technology is to the point where it could actually be built in a way that makes it usable. Money that you're spending, or the way you interact in well known communities, could have the side effect of bolstering your reputation everywhere.

My most feared solution would be a similar system of attestation, but using Passkey since it would solidify the role of the current big tech companies as the arbiters of everything online. For example:

    You look like a bot.  How do you want to prove you're human?
        Microsoft
        Google
        Apple
        Facebook

Those companies, as Passkey providers, would, for all intents and purposes, be your 'anchor identity' online and they'd be in a good position to attest to you behaving like a normal, non nefarious participant.

I think Apple would be the company that could sell that kind of change to normal users. It could be done in a way that's anonymous because all you really need is an attestation that says 'Apple certifies this user is in good standing'. Apple is very good at selling those kinds of changes as being privacy focused and I think their user base would go for it if it were framed as 'good people' (aka Apple device owners) getting a superior experience that isn't available to the 'bad people' (aka bots, bad actors, and outliers).

If it worked, Google would follow with Android. Anyone else large enough for their opinion of you to count (Microsoft, Facebook, etc.) could probably compete, but it doesn't work for startups or small, less known providers.

In my opinion, as soon as authentication moves to something like domains or digital signatures where 3rd party attestations become simple, we could see a lot of new ideas that focus on reputation and related solutions / services.

This is something I said, but didn't explain well in the thread about Bluesky using domains as handles. You did a much better job of explaining it in your article. Being able to adjust the moderation rules to fit specific scenarios is useful.

I also think the use of domains could have a significant impact on the quality of online discourse because building a good reputation on a domain and having that transferable anywhere on the internet is a lot more valuable than a handle that's only usable within the silo of a single company.

Sub-domains add another layer where the owner of the top level domain has incentive to make sure they're not bringing bad actors onto the network because moderation could be enacted against the base domain, not just individual sub-domains.

Domain based attestation could also drive significant change. Imagine a system where spending money at a reputable company gave you a digital token / receipt that you could attribute to a domain (aka identity) as a way to attest to that domain being a good participant.

The attestation wouldn't cost anything beyond what you're already spending, but it's valuable because it demonstrates you're spending real money somewhere and attributing it to an identity. That doesn't scale well for bad actors running millions of bots because someone like me might have thousands of dollars of spending per year that I can attribute to my reputation or the reputation of someone I've had a good interaction with and bots can't throw that kind of money away. IE: It's a good indicator that a domain / identity isn't a bot, spammer, jerk, etc..

> I don’t understand how this is going to take off if no one is going to make money from this.

I'd pay something for it. The way the author describes it I would have a 'Small-World' server. I'd be willing to pay $5-10 per month to connect that to a 'Big-World' server. After that I'd expect the costs to scale with the size of my 'Small-World' server. As long as that's based on resource consumption rather than some kind of per-user scheme I think it would work fairly well.

The biggest issue for me would be setting up and maintaining a server. I don't really want to do that and a hosted service for it probably skews towards costs that are more than I'd be willing to pay just to be connected to the network.

How do the gold checkmarks for companies work? Are there requirements for follower count, etc.?

I wouldn't pay $8 / month for Twitter Blue, but I'd be willing to pay something for a domain validated checkmark similar to the Bluesky feature that was on here a few weeks ago [1]. I pay $10-20 / year for domains, so something like $20 / year seems reasonable for me to verify my namespace, especially if it helps reduce impersonators, squatters, and bots.

That's not to say I'd never pay $8 per month either. If my Twitter account starts getting used for feedback from users / customers I'd be willing to pay more than $8 / month, especially if it came with tooling that helped me manage everything.

As of now, my Twitter account is unused because I wasn't able to get the handle that matches my domain name. I own 'example.com' and use 'example' everywhere except Twitter. I have 'exampletech' at Twitter which is objectively worse than 'example'. However, if given the choice between having 'example' or 'example.com' as a verified handle, I'd rather have 'example.com'. The verification could be automated and I'd pay for it.

1. https://news.ycombinator.com/item?id=35050335

In that thread someone points out a fake channel:

    youtube.com / @LinusTechTips2.0

It's a shame YouTube allowed dots in handle names considering the problems creators have with impersonation. Those should be reserved for domain validated handles similar to the BlueSky post a couple weeks ago [1].

As it is, I don't think there's a way to create aliases, so it's not even possible to proactively protect yourself from impersonation by grabbing all the attractive handles that would be used by bad actors.

For example, what stops me from creating @LinusTechTips.com as a handle? That looks very official to a lot of people and high value domains are recognized by a lot of normal users. I know it would get banned eventually, but that's after the creator complains and it seems a bit unfair to ask creators to police their brand while YouTube leaves the door wide open for bad actors.

In the case of a channel like LTT, if they're using @LinusTechTips as a handle I think it would be pragmatic for them to be able to ask Youtube to forbid all other @LinusTechTips* handles. That's their brand, everyone knows it's them, they've earned it, and platforms should be doing more to work with them to reduce impersonation. I say that in the context of all popular creators, not just LTT.

1. https://news.ycombinator.com/item?id=35050335