I've wanted to have domains as identity for years, so I'm thrilled to see someone actually doing it. I want to use a domain validated identity for everything; social networks, package repositories, code signing, etc..
I hope this idea catches on. I think a more decentralized approach to identity combined with 3rd party attestations or filters could change the way the internet works.
Imagine what could be built if everyone used domains as handles / identities. Social networks could go hands off for moderation and allow plugable moderation engines that rely on domains for identity, trust, reputation, etc..
I'm convinced that domain validated identities and attestation could usher in a revolution for reputation and trust. Are there any more projects doing similar things?
I personally don’t want to use a domain name for everything. I want all my identities to be unique, I want an infinite number of them, that I can change between multiple ones per service and that they’re not connected to each other unless I specifically say so, and they should be fully free and permission less for me to create.
Public/private keys have or enable all those properties.
While there a many problems with how domains work today as a public goods system, domain names as identities is infinitely better than what we have now, but I think we can have it much better and domain names are one step in that self-sovereign ownership.
I think you missed the part when the original username was a subdomain of bluesky. There will be a great many anonymous registration services I'm sure. And things like afraid.org make that number of possible domains you can use anonymously a truly massive number.
The problem with pub/priv keys as user identities is discoverability and validation. How do I find your key? How do I prove this key is actually yours? Sure they are anonymous, but that isn't a desirable property if you are an established public figure.
Most of us are not established public figures and many of us, I’m sure, want to keep it that way.
With keys, validation can happen in several ways: attestation by reputable orgs, reputation systems, off-band, 2FA, “Hi, I’m John”, etc etc. Discovery is also highly context dependent in that it can and should happen “in the app/system” (=whatever the context of the use case is, eg. you know me by pubkey 123, the tax office knows me by pubkey xyz).
“anonymous registration services” from the perspective of self-sovereign identity is by definition not anonymous :)
To be clear, I understand the desire for truly anonymous services. But after two decades of experimenting and thinking of this problem. I don't think it is possible for an truly anonymous solution that is also ergonomic to use.
Things like briar exist, and for you use cases, existing tools might be enough. Briar is fantastic for communicating with people you know and willing to jump through some hoops be part of a community that is anonymous, secure, and provides lots of ways of making introductions and posts.
But there are reasons why Meta, Twitter, Linkedin and the like are well above any anonymous solution in terms of users.
- Identity (including pseudo identity of anonymous users) is established.
- Spam. There is ungodly amount of spammers out there, as email has shown. If you have played with nostr or scuttlebutt you would also see just how horrible the spam is.
- Account recovery, people are bad with passwords and storing secrets. Very bad. And even the most secure people can get exploited.
- Hosting your data is problematic. Who hosts data which may be illegal? When illegal data is flagged, how does it get purged? Merely being the transit for data is protected in the US, but physically hosting that data is not.
- The vast majority of people are unable to run a persistent service for their identity and content. Even if they are willing, they lack the means. You end up targeting a very small subset of people who are willing, able, and capable of running a service. And that service requires care and feeding. You might end up with millions of vulnerable instances.
- Scalability. No one has come remotely close to solving how one of these solutions would scale to billions of users. Or even tens of millions. DHTs become painfully slow and bloated. Even if a solution did start catching on, it would quickly then fail because the user experience would crater as it gains popularity.
I have become convinced that making an ergonomic briar is impossible without making some concessions.
Complaining that a new and unproven tool's chosen concessions are bad inhibits experimentation.
The problem with infinite, easy to create identities leads to a well researched attack, known as a Sybil[1] attack.
If there isn't some type of cost or friction to creating identities, you will have a lot of bad behavior, full stop. This has been shown time and time again, so it's basically a non-starter. I don't want to be part of any social network that has this feature (infinite identities), its going to eventually turn to shit or require intense moderation (or both!)
I think this is true if the system is global or there’s model where Sybil resistance is “here everyone, have an access to write to the database”. In a system like HN there’s value in Sybil resistance. On your Twitter feed, almost none.
So I disagree this is a non-starter, because we didn’t find a solution in the past, but rather an ideal place to start and a great space to discover new Sybil resistance mechanisms (which we have over the recent years).
Domain based identity also enables attestation which could be use to artificially add even more friction. Plus, since it's not constrained to a single platform, you could have 3rd parties that assess trust and reputation.
> I've wanted to have domains as identity for years, so I'm thrilled to see someone actually doing it.
on a tangentially related note: Go "package management" is based on domain identity (although most people just use github.com), yet for some reason people seem to prefer to defer to a centralized registry and praise "good package managers" like cargo.
Yeah. I've used that enough to learn how it works. I think the biggest issue is that it's not the default and most people take the easiest path which is using GitHub, etc.. There's a neat project that can help generate some of the web resources needed to use vanity imports:
The pattern repeats fractally in everything. Since you mention Github - it happens to be by far the widely-used, centralized repository hosting, and promoter of pull-request based workflows - for a version control system whose whole entire point is for you to not do that. I mean, the "D" in "DVCS" doesn't stand for "has no manual file-level locking".
people lose domains by forgetting to renew all the time. major corporations do it. do you want people to be compromised/have their identity stolen because they forgot to pay 7.99 to ICANN?
Forgetting to renew a domain is much harder than it used to be [1]. ICANN rules require 2 reminders prior to expiration and 2 notifications after expiration. They also require a 30 day minimum RGP (redemption grace period) where DNS doesn't resolve and you can still recover your domain.
If anything, I think having a domain tied to multiple services that break when the domain expires will help people notice so they can redeem within the grace period.
Impersonation via an expired domain might be an issue, but that's already a problem we have to deal with and I don't see how it could get significantly worse, especially since services could put up warnings when domains move between accounts.
yes, I prefer this to being kicked out because my child needed medical care and I followed the doctor's advice. Or my device vendor considers the device 'too old'. Or any other arbitrary reason.
Where I live domain contracts auto-renew. And have reclaim processes.
The doctor's advice is probably the father who got booted out of the entire Google system because he sent the pediatrician a photo of his son that the AI classified as CSAM, and Google refused to reinstate access to his data despite a ton of media outrage.
It’s not like ICANN is guaranteed to not kick you out for “hosting illegal child pornography and advocating organized violence”. It will happen once enough individuals starts relying on DNS.
ICANN isn't in control over DNS because thats some platform they own but because they are a public institution and managing DNS is their mandate. Consequently, they don't get to nuke your domain and then tell you to pound sand.
ICANN also cannot boot your domain directly - they only control the root zone and delegate responsibilities. Maybe for gTLDs they have some say but if you get a ccTLD then the only one who can kick you off is the corresponding country - and if it is your country then that greatly improves your chances of pursuing legal action if your domain is taken away without due process.
The Doctor's advice I don't get the reference¹, but for deprecating a device this could be a concern if your phone or similar device suddenly stops working² and that is required to prove who you are.
--
[1] perhaps searching for some officially, erm, unsupported medication resulting in getting blocked by a service that list closely enough linked to an identity provider that the ID account is locked also? — seems a stretch
[2] or is lost/stolen – a potential problem with any physical security token or virtual token if you only have it associated with a single device
examples are numerous. There was this father who sent the doctor photos of a medical problem of his child and the trustee of the digital identity locked his account. With all his digital life, payment channels, communication, you name it. Even the police asking the trustee to unlock was of no avail. https://www.nytimes.com/2022/08/21/technology/google-surveil...
Or there is this munich company whose employee visited it's parents and immediately the company github account got locked. Parents happened to live in Iran.
That's not a problem. I don't mean that in the sense that it doesn't happen. Rather that the market succeeds despite it. People forget to pay fines, mortgages, taxes -- the system has rails to put most back on the correct path. And the failure isn't permadeath. Your domain expires and life goes on.
There are also protective mechanisms to prevent your domain from expiring. You can pay a balance in advance. Pay for "renewal insurance", etc. As more people use the system, it will grow even more safety rails.
Replace 'domain' with 'identity' and you have a very scary proposition. This is just another form of 'code is law' and doomed for all the same reasons. Bugs and exploits become severe threats to your wealth and well being. As much as we hate to depend on institutions and 'other people', depending on computers program is inherently worse.
If you use your domain for email, you already have this problem.
This problem isn't new at all.
Would you rather have a situation of ownership with responsibility or no ownership at all?
The "free" alternative is a crypto like identity, and there's zero restitution if you lose your key. People will struggle even more with this. At least with domains there is a legal framework if you're paid up.
This was a big fad from around, and then rapidly died, as most users simply didn't care. Instead we got attempts at e.g. OpenID and similar, which rapidly converged on a handful of large identity providers who ended up dominating.
A large problem to encourage and retain a truly decentralised nature is usability. It must be as simple as allowing a site to authenticate you with Google or Facebook, as most users don't care enough to be willing to do more than that, including finding somewhere they trust to register something new.
I always liked the idea of OpenID, but you're right, it was far too complex for the average person. I was enthusiastic about it, but never got around to using it because it wasn't simple enough.
I think the kind of approach used here is a bit better than OpenID in terms of separating authentication and identity. You have a permanent account on the service for authentication and the identity (your domain) is more of a pointer / shortcut. That strikes a good balance in terms of letting the service provider dictate authentication policies without usurping your identity people recognize.
Unfortunately I don't think any of the big tech companies would get onboard with an idea like this. They're all racing / competing to control identity right now. Although I've always thought the idea would fit well with Twitter.
I was more talking about the "domains as identity" part that preceded OpenID than OpenID itself. OpenID was if anything much worse in that respect, partly because it tried to solve the authentication problem, not just the "central place to look up information about a user" problem.
I don't having users maintain this domain bit will work very well unless it's integrated with a service provider you're already using, so you'll depend on users relying on decentralised providers already for it to work.
But note that OpenID also allows this. While I used OpenID directly on my own site for a short while, for most of the time that I used OpenID I just added a record to my site that pointed to a third party provider.
The same ability to point somewhere else also exists just fine today with WebFinger, and the Fediverse. E.g. my galaxybound.com/.well-known/webfinger endpoint [1] redirects to m.galaxybound.com, which is my Mastodon install. I could've also put in place a custom webfinger response at my main domain to point somewhere entirely different or add additional resources if I wanted. Similarly, there's nothing stopping e.g. registrars from offering custom webfinger resolution as an extra service.
Personally I'd much prefer that wins, since webfinger provides a single lookup mechanism that can return any number of different types of records for different services without each of them having to invent their own mechanism. This includes using it to discover the OpenID Connect provider for a given user (request /.well-known/webfinger with the "rel" url parameter set to url encoded "http://openid.net/specs/connect/1.0/issuer", and "resource" set to the relevant account URI; setting the "rel" parameter is optional - including it is just a hint that's the only setting you need/want) so you an use it both to indicate authentication preference and to provide arbitrary pointers about your identity.
Well, this is the challenge, because most people don't care. So anyone who wants effective decentralisation rather than just the possibility of decentralisation need to solve that challenge.
If you're willing to consider PGP, there's also https://wiki.gnupg.org/WKD which provides a much neater mechanism for domain owners to publish pub keys that can be used for identity verification too.
Also somewhat intersecting with that space is https://keyoxide.org/ which can provide proofs of that identity across different services.
Currently, a domain can only be a brand and cannot be a true identity. There are methods to get free domain names [1], domain names without identity validation [2], etc. So, a domain is nothing but a method of verifying internet presence.
The reason I say I think domains make a great identity is that I don't think it's important for identities to be verified. I even think there's room for 100% anonymous blockchain domains.
The value is in the way the domain owner participates online and what kind of reputation they build. There are many old-school communities where I recognize the handles of extremely knowledgeable, friendly, helpful people and I have no idea what their real names are.
Imagine if the well earned reputations of high quality participants were transferable across online communities by using a domain as global handle.
A domain can expire and be used by a different party. A different person can maintain a website. There are many ways a domain's admin can change. Domains are not guaranteed to be unique even if they are in some cases considered anonymous.
An idea to help with this would be a new resource record type, with an opaque value that changes only when the domain changes hands (yes, it is up to the registrar to decide when to change the value).
The resource records would live underneath registry.arpa, which has delegations that correspond to delegations at the DNS root; so to find out if example.com has changed, you can query:
$ delv example.com.registry.arpa OWNER
example.com.registry.arpa. 3660 IN OWNER "MEpnFkIk4sKW_oLPEl-R7WxFSAnWvgZnLYmRtn-3BkY"
You could put other stuff in there too, such as the start-date of the current registration... this is starting to sound like whois but structured and machine readable. Why on earth did that never take off!
An interesting related thing is the approach adopted by iSCSI, which constructs iSCSI Qualified Name (IQN)s by qualifying the domain name with the dates of registration.
So iqn.2003-05.com.example is a different identity to iqn.2021-01.com.example.
1. Domains are guaranteed to be unique. We have global registrars and global DNS, its not possible to have duplicate domains..
2. Don't utilize a domain that is shared by lots of people. There is also lots of DNS tricks (TXT records) to "pin" a user to a domain or whatever. If the domain is shared (for example a company website), you just add a TXT record denoting what private key is allowed to do things. Heck you could setup fine grained permissions per key via txt records.
2. Yes they can expire and that situation is detectable. How is this any different than twitter or another service allowing re-use of a deleted username?
Of course domain names are unique... As long as BGP routes aren't poisoned or a million other issues. However, the issue mentioned in this thread isn't whether company ABC has abc.com but that 10 people at ABC can administer abc.com.
Twitter allowing reuse of deleted usernames is completely different than an existing domain that is used as a identity credential to represent different people over time.
This thread is not about whether domains can represent properties on the Internet but whether domains are valid for identification purposes of people as login credentials. They aren't valid, because a domain doesn't uniquely represent a person.
I think we should make some new TLDs that come with some validation guarantees. Ie john-doe.nation.citizen is always a person who has an Id with the same “John Doe” issued by some government. The registrar is responsible for validating that. Once issues the domain is never revoked- it’s yours forever, even after death. Maybe you subscribe to something for extra features, but the core identity can’t be recycled.
People don’t always want really strong ID like that though. So make other TLDs for other categories and give them different validation rules. Like .human could have some kind of biometric ID but no name. .blob could be a free for all, whatever.
But who are those for? I mean, I get what you're saying I just don't think it solves the issue. Sure,I could sign up for JoeRogan.biz and start posting using that handle, but I would also have to pay to hide the whois information.
All government agencies would have a verified .gov domain.
States have access to .gov domains
hell, My local town has a .gov domain.
States have access to domains like ca.us, schools in states have access to k12.ca.us domains.
I guess States could offer domains like, person.county.town.state.us but what a mouthful. Or maybe person.citizen.state.us but doesn't seem ideal either.
I guess you could have a verified TLD so you can have individual domains like johndoe.verified... but it takes away from the domain being linked back to my website. Sure I could set up a redirect but boy that's starting to get complicated.
I think domains are a fine barrier for entry for vanity handles. Current domain registers could offer their own verification services where they can include the verification in the whois information.
If Joerogan.biz doesn't come back with some kind of verification string inside then it's not Joe's domain. That string could be a pubkey and services could allow for either encrypted posting or including an encrypted string that verifys against the domains whois information.
Or that pubkey could be stored as a txt record in the domain.
You do realize that most names are far from unique, right? So what if someone can show that they own john-doe.nation.citizen - you still have no idea if that's the right John Doe. Wanting this identy to persist after death only means there will be even more collisions.
Why would you want your real identity tied to online persona? That doesn’t make a ton of sense.
That kind of thing is sometimes suggested as a solution to reduce online disagreements, but in fact just escalate spitballings to murders and gang wars. Not great, in my opinion.
There are no free domains without a catch. Your example happens to be "free domain, when you pay us money", which is stretching the definition of free.
I do not understand this. They say repeatedly “free” on the first link you posted but all the links I checked required payment up front and an increased fee for renewal. I’m not certain by what definition that counts as “free”. Maybe it’s free for them after the ad redirect they tried to hide between the registrar link?
Domain registration happens through an established registrar who collects fees. There are no free-as-in-beer top level domains that I’m aware of.
I would love to be wrong, because I own more than a couple domains myself.
You need to be careful, because they are enticing with free and then trying to charge. Free subdomains are easier to obtain, but there are some domains in "off-TLDs" that can be obtained. The list of those changes over time.
Honestly, though, I wouldn't use those for an actual business. The conversation was about how to subvert using domains as identification.
> USD $10 per year might sound like a lot, but how about USD $1 per top-level domain for the first year?! If you manage to gain any sort of traffic in that year, the domain will practically pay for itself!
> Since mid-January 2023, all Freenom-based domains (.tk, .ml, .ga, .cf, .gq) are down and not available
> .free launch dates will be forthcoming.
That’s one weird website with possibly some free subdomains.
Well, that's to some degree affected by the contents of this other article that came on the home page of HN the very next day. [1]
That article describes Facebook having brought suit against freenom for giving out free domains, because they were primarily used by criminals. There will be another free domain provider. There always is. But, this also makes the point that the number and impact of these free domains is huge. Spammers use them to spam, and this is one reason why domains should not be considered to have any gravitas as an auth mechanism for identity.
From that article:
Freenom is the domain name registry service provider for
five so-called “country code top level domains”
(ccTLDs), including .cf for the Central African
Republic; .ga for Gabon; .gq for Equatorial Guinea;
.ml for Mali; and .tk for Tokelau.
Freenom has always waived the registration fees for
domains in these country-code domains, presumably as a
way to encourage users to pay for related services, such
as registering a .com or .net domain, for which Freenom
does charge a fee.
On March 3, 2023, social media giant Meta sued Freenom
in a Northern California court, alleging cybersquatting
violations and trademark infringement. The lawsuit also
seeks information about the identities of 20 different
“John Does” — Freenom customers that Meta says have been
particularly active in phishing attacks against
Facebook, Instagram, and WhatsApp users.
and
“The five ccTLDs to which Freenom provides its services
are the TLDs of choice for cybercriminals because
Freenom provides free domain name registration services
and shields its customers’ identity, even after being
presented with evidence that the domain names are being
used for illegal purposes,” the complaint charges. “Even
after receiving notices of infringement or phishing by
its customers, Freenom continues to license new
infringing domain names to those same customers.”
This discussion is about whether domain names can serve as identity not about me proving I can create a domain on the Internet.
However, here is a free subdomain I've done for you. I created http://hnretroid.mooo.com/, added an A record, and pointed it at 209.216.230.240, which is news.ycombinator.com.
You can also look at the article that appeared on the home page here at HN the very next day after this discussion you and I had. The article talks about Facebook suing one of these registrars for giving out free domain names to criminals, even after being shown that their customers were performing criminal activities with the domains. [1]
There will be another free domain service. There always has and always will be, unfortunately. There always will be something to fill that void. In the same way that legitimate actors write legitimate apps, criminals have their own ecosystems on which they rely for their income.
Of course not. You are confusing a domain as it normally used with the context of this conversation, where I pointed out that domains are insufficient, because they cannot be used as personal identification.
no, what does it take and mean to identify someone. In general and on the internet. How do you build trust? A domain is no worse than trusting any arbitrary billion dollar enterprise.
No. It's both different and worse, because you are trusting more parties for auth as well as degrading the trustworthiness in the actual integrity of the credential management by spreading it across the entire network stack in addition to trusting the same billion $ enterprise, anyway.
This was essentially the intent behind the .tel tld—using dns as an identity metadata database. Circa 2008, they did a bunch of podcasts and interviews about uses for the domains, like encryptions schemes for secure messages using keys posted to an individual’s .tel.
I interviewed with .tel around then, and declined an offer after it was clear their plans were wildly unrealistic.
The "identity metadata" bit had already been pushed by multiple registrars for years at that point, as it doesn't require the cooperation of a registry to allow it, and largely gotten abandoned because of lack of user interest.
We are talking orders of magnitude difference. Plus this is a much more solvable problem than what I mentioned: domains getting held hostage and then going to auction.
Nostr has beein doing this with Nip05 for a little over a year now. They just use a json file in the .well-known directory of the domain that contains your public key.
I have one of those. When everyone was changing their Twitter (display) names to *.eth I thought there might be a chance Twitter would use ENS for domain validated identities, so I grabbed one that matches a good .com I own.
The ENS stuff is cool, but I hope it doesn’t catch on unless they come up with a way to coexist with ICANN. I think multiple DNS roots would be a net negative no matter what.
ENS has DNS import via TXT Record verification proof, so the entire DNS tree can coexist in ENS trustlessly as long as future ENS-only TLDs are chosen wisely (seems simple: just use 0x80+ Unicode.) For example, try resolving my domain, "raffy.antistupid.com" in ENS.
I believe, the ENS registry only contains "eth" as an rogue node (also "[0-9a-f]{40}.addr.reverse" is used for wallet names). Recently, ".art" started offering tokenized names, where you get both DNS and ENS.
>Imagine what could be built if everyone used domains as handles / identities. Social networks could go hands off for moderation and allow plugable moderation engines that rely on domains for identity, trust, reputation, etc..
Imagine we let people build communities that self moderate instead of imposing a way to moderate and censor.
> Social networks could go hands off for moderation and allow plugable moderation engines that rely on domains for identity, trust, reputation
Every time this has been tried, it's failed miserably, as it should. People need to be able to post anonymously. Otherwise it's too easy to target the messenger, rather than the message. Think journalists, hackers, abuse victims, political dissidents, whistleblowers. Yes, this makes moderation harder. Sorry but that's life.
If the social networks don't moderate, or let you opt out of their moderation, and you can opt in to whatever moderation system you want, how would that be any worse than trusting big tech to moderate fairly?
>Think journalists, hackers, abuse victims, political dissidents, whistleblowers.
The vast vast majority of people are not those things. Even if you wanted to be anonymous to other people you could still prove your identity to a service and the service could keep that identity hidden.
For anyone that's serious about wanting or needing to anonymously post a public message, I would strongly recommend against this advice.
Part of the strength of your anonymity is based on the cost for anyone trying to figure you out. Centralizing your trust in a service that promises to keep your identity hidden is begging for trouble.
The service doesn't have to be malicious and can genuinely make every effort to keep your identity hidden. Trusting services like that creates choke points where it may not have been viable to attack the service for one identity but for hundreds its worth it.
Theres no such thing as flawless anonymity and you can't escape having some number of trusted parties, but you want to keep that list as low as possible.
Domain names as handles are a cool idea, and you can already do a variant of them in the "fediverse" either by hosting your own instance of a service or by configuring a WebFinger alias (which is what I do).
I'm less convinced by DIDs[1], which is what Bluesky seems to run on: I've yet to see an explanation for why the DID standard exists, given that it effectively punts all semantics (including basic things like cryptographic verification) onto unstandardized "methods" in an uncontrolled global namespace.
We use DIDs to avoid NIHing everything (we already NIHed enough) but weren't pleased with any of the DID methods available, and are currently using did:web for self-hosters and then a registry for non-self-hosters that we're running (did:plc) which we hope to spin out to a non-profit consortium. If something else with the right properties comes along then we'll adopt it, but you're right about how much variance can exist between the did methods due to the light spec and we don't expect to support a lot of them.
> If something else with the right properties comes along then we'll adopt it
Have you looked at DID-SIOP?[0] It's based on the "Self-Issued OpenID Provider" extension[1] to OpenID Connect, to make it easier for existing OIDC relying parties to support those identities.
There's also a verification feature in a Mastodon user's profile, where you can put a custom html anchor (involving something like 'a rel="me"') in the footer of your website. Then you earn a checkmark, with green highlighting for your website when people look at your Mastodon profile.
Why are we watching bluesky build fediverse features slowly in public? Every time they post something it's like ok, another feature on some closed private "also ran" network no one will care about with any mass-adoption possibility for years.... It's just DOA.
Mastodon was around for years with no attn and only got handed this miraculous situation and mass migration opportunity but it just got lucky basically. And it's not even it. This isn't happening again for Bluesky any time soon.
I think the original plan was for Twitter to adopt AT Protocol so it would instantly have 100M+ users. That aside, with a better onboarding flow they might be able to lap Mastodon.
Breaking the walled garden would cost them. E.g wouldnt it mean allowing people to interact with twitter without using the official apps, meaning losing ad revenue? (Obviously why third-party apps were banned)
I had not heard this before (not that i am super up on this kind of thing) is this a feature that was announced recently or before the change in ownership?
I wouldn't think Twitter was ever likely to adopt something that will allow it's users to move away and easily keep their followers.
Mastodon hosts an interesting set of communities in its own right, and its growth is good, but it really doesn’t seem to be in any serious way a replacement for what makes (made?) Twitter great and important.
- people know that domains are read from right to left, so that they know that president.whitehouse.gov.usofa.com is not a domain in the whitehouse.gov range (this example is bloated, but domain.com vs. $DOMAIN.com.$DOMAIN-social.net is a common pattern for fraud attempts I get)
- people outside the US know it's .gov, not .com (rarely true?)
Compared to a flat namespace, it's really helpful, even if some people don't know the rules. How many people have names like RealPerson or PersonOfficial on Twitter?
Although I agree, it's not perfect. Is there a better approach they should do instead?
The lookup of whitehouse.gov (is that the same was house gov, where dotcom was a porn site?) should hopefully be a company name.
So perhaps we could use organisations from the DNS system?
Or flip the DNS name, write out which geographical or organizational topology applies to every aspect of it on mouseover/touch, to make it readable left-to-right in the case of english etc.
And we could combine this, as proposed before, adding the information looked up from DNS for non-private accounts to every domain that is used in browsers or social media.
The again, people bought a probably mafia owned companies stock because it looked like the software Zoom was the same as the name of that stock, which was an error.
So there is no alternative except for trusting in the word of someone, that identity is what you think it is.
But no, i do not think that GNUnet or how ever the HTTPS alternative for trust is called would be a better alternative to prevent fraudulent accounts.
Another random idea:
Social media could be kind of a reversed "obligatory imprint", i.e, having a natural person's or company's name as your acccount should mean that they should have a postbox for inquiries. Normally, pseudonymous content is required in germany to have an imprint refering to a legal entity. Reverse, because you claimed to be a legal entity, so be liable for that here. Enforcement could be done via ".well-known" addresses on hosts that serve the actual imprint sites? Or with more effort, by sending codes to physical postboxes, that need to be matched for every company or organisation.
Tl;DR:
Further research into UX and thread models is in order, IMHO.
Yeah there definitely would be attacks where they use long fake domains if the site decides to hide the domain once it gets past a certain point
e.g president.whitehouse.gov.us[hover to reveal the rest]
But if it's always fully displayed then it's not really an issue. People could make fake accounts anyway under the current system. If you can't tell @elonmusklet93902398098 isn't really elon musk then I don't know what you expect to fix that.
The important point of this feature is that you know tim.wang.com is really an employee of wang.com and not just a rando. You know he really comes from that address so you could follow all the wang subdomains and know only real wangers will be followed.
> The web. Email. RSS feeds. XMPP chats. What all these technologies had in common is they allowed people to freely interact and create content, without a single intermediary.
Thanks for explaining the invite only situation. This sounds like the sort of thing I'd like to try out, so I hit "join" and got to the job application page. Spent some time looking for the sign up process.
It’s not a new problem, but it definitely feels like an endless battle of specifications and implementations.
Most recently I’ve settled on using https://micro.blog/ but I wouldn’t be surprised if I change my mind again within the year as new competitors crop up.
So, an email address? Unless that is the point you are making of course (as I type this I realise how slow I might be being!).
Alternately if they want to stick to the domain structure: user.domain.tld (I've not checked to see if that is already supported).
The problem with both of those though is that you are then less in control of your identity – the domain owner has the power to stuff you over if you are just a user of it. Because of this issue for you as the user, it means that the identity is not as trustworthy to the service because the domain owner can take control of it themselves or reassign it.
> The problem with both of those though is that you are then less in control of your identity – the domain owner has the power to stuff you over if you are just a user of it.
I don't think this is true. When you control the domain then you control email and subdomain address spaces. In the context of the given example, there's no difference in control between dholms.xyz and dan@dholms.xyz or dan.dholms.xyz when the same person registered or created all of them.
> when the same person registered or created all of them
Exactly. How does the service trusting that the address or subdomain as identity know that they refer to the person that created them?
I have surname.tld, I create dave@surname.tld for me and wayne@surname.tld for my brother. If Wayne annoyed me and I was a dick about it I could revoke the name or reconfigure it in order to act in his name maliciously. The same for sub-domains. How does a service wanting to trust the address as ID know which of us has that control? My identity is more strongly linked to my token (address/sub-domain) than Wayne's but there is no way to infer this from the identifying tokens themselves.
Of course a hack at domain registrar level could stiff it all over, so even only using top-level domains isn't perfect, but there is definitely a difference in the level of identity stability guarantee between domain and sub-domain or email address. (So the is a difference between dholms.xyz, and dan@dholms.xyz or dan.dholms.xyz)
Registrars and PKI CAs should be the same orgs (can't do only one) and each domain registration should come with a certificate. How is this not a thing? Only a valid CA for a valid TLD registrar should issue certs for a domain name, not arbitrary CAs. So much could have been avoided with this.
If you're gonna tie your identity to it. PKI is very important. EV pki cert gives me more confidence in the authenticity of your account.
How many people do you think I can fool with trump-white-house.trust (or many other cheaper/easier TLDs)?
This totally justifies my decision to purchase a domain that’s “myna.me” so I will be able to authoritatively claim “@myna.me” without worrying about jumping in and grabbing my “handle” early.
Bluesky identities are portable by design, so you can modify your identity without moving servers or you can move servers without losing your identity/content/followers.
we don't like fediverse because its a bad soultion, federation combines the negatives of centralization (censorship) and decentralization (disparat userbases with few users ).
Censorship seems like a non-problem on mastodon. If you are using someone else's server, and you break their rules, you'll lose your account. Just try another server. If you run your own server you make the rules. Other servers and users may block/mute your server but some may not. If everyone blocks your server and no one else joins your server, then maybe no one wants to hear you. You are not entitled to force people to listen to you.
you don't see how that doesn't compare to twitter in terms of functionality?
the great thing of twitter is that you have a unified userbase that can interact and discourse on a single platform, if every 10 people have their own walled off server this is more like a groupchat than twitter
The censorship model is mostly the same, right? If you don't self-host, your host can censor your communication and refuse to relay or peer certain messages.
Seems like a direct implementation of how Nostr handles verification. Nip-05 describes how it's done and is successfully implemented in most Nostr clients:
Curious how it would handle domain ownership changes.
Obviously the account would still have standard credentials but once the new domain owner proves ownership does the old handle get reverted to something else so the handle can be used by the new owner or is that account name forever squatted?
Every account gets identified by a DID which is long-lived but not human readable. Records use them instead of domains for links/follows/etc. That's how domain-name changes or debindings avoid causing issues.
Yep. The DID is kind of like an internal UUID, so we don't have to show it to them often. The three cases off the top of my head where you'll care
1. You're setting your own domain handle, in which case you're putting it in your dns record. In this case, it'll just be that string you're sticking in the TXT record.
2. You're migrating hosts. We haven't implemented this flow yet, and since the DID will be referenced in your data export you may not even be aware of it in this case.
The case I found more worrisome is you follow someone, they then start using a new domain, and now it seems you're following a different handle (IDK if handles are immutable in Twitter, maybe they are not?).
Maybe BlueSky could offer a registrar that would do steps 1 & 2 for you transparently upon domain purchase.
Ah sure, that could be confusing -- though I believe Twitter allows you to change your handle as well. We could probably try to let people know when a handle changes, but we'll wait to see if it causes a problem before we get into it.
If there is not a mapping to some sort of immutable handle, i imagine some sort of announcement in the timeline(example.com has changed their handle to example.xyz) and a history in their profile (handle = example.com 2017 to 2020-01-01. example.xyz 2020-01-01 to now) would cover it
Ideally you could use the domain as a (vanity) pointer to an immutable handle and when someone follows the domain they'd actually be following an immutable identity that's a combination of the domain + immutable handle which reference each other.
example.com <--> ryan29-abcdef
I was trying to explain how I'd do it for a package repo a few months back.
You can change your handle on Twitter, but it's not recommended if you have any "follow me on Twitter @soAndSo" links out in the wild, because it opens people to handle squatters taking your old handle.
So what, exactly, happens the moment a person’s domain is unavailable, or is transferred to a new owner? Does the account show up as the non-human-readable ID until the account owner can verify the ID with another domain? Or what?
Services will cache the mapping and probably give the old mapping until the cache gets updated. On a failed mapping, I suppose it'll fall back to the DID like you say unless we cook up a better answer.
Note: DNS already has a cache invalidation mechanism in the TTL of the DNS record. I think you’d be well advised to simply use that; i.e. just look up the domain every time, and let the DNS TTL be your caching mechanism for domain lookups.
(You’d also probably better make sure your DNS resolver uses DNSSEC validation, and that your DNS resolving code path requests it by default.)
I was more curious about what happens to the previous owners handle when a domain switches hand. Is the old handle force reset to something else? What if they haven't logged in to change it but the new owner of the domain is setting up that handle?
This looks very interesting. I just had an idea for something along similar lines today when thinking about how we can be resilient against the coming wave of AI-generated spam.
But I definitely think that the protocol itself must be open for it to be viable.
What’s the difference between blue sky’s at protocol and the SOLID POD project? They both seem to do the same thing, but AT protocol is narrower in that its more focused on storing social media related data.
Besides what you said, Bluesky is happening (there is an iOS app that works that is in beta) and Solid is not happening (there are no interesting apps).
Using domain names as handles seems like a great idea... for those whose names are easily represented by Latin-1.
Does this mean that either homograph attacks or punycode are going to make it into Bluesky? Or is this another protocol that's built around English and nothing else?
That's a really good idea. You can't cheat it in the same way as you can cheat twitter (get the tick as Mark Cornly and then rename yourself to Elon Musk)
Wakeup call: literally no one cares about the "protocol." Zoomers will still use TikTok & Instagram, millennials will still use Instagram & Twitter, boomers will still use Facebook.
Bluesky is the classic solution looking for a problem.
Yep, none of these decentralized platforms will take off unless they offer something truly unique. They're way too focused on the implementation details right now. From the front page of Mastodon:
> These posts from this and other servers in the decentralized network are gaining traction on this server right now.
I mean, what the hell does that even mean to a layperson?
I hope this idea catches on. I think a more decentralized approach to identity combined with 3rd party attestations or filters could change the way the internet works.
Imagine what could be built if everyone used domains as handles / identities. Social networks could go hands off for moderation and allow plugable moderation engines that rely on domains for identity, trust, reputation, etc..
I'm convinced that domain validated identities and attestation could usher in a revolution for reputation and trust. Are there any more projects doing similar things?