Nostr has created quite the hype in the last few months. A lot of people are migrating over to the new platform. @leve39 took the opportunity to write up a very detailed thread on the risks associated with using Nostr for your identity.
𧡠1) Nostr is π, but there are limitations and serious risks associated with using Nostr for your identity. Let's take a closer look at what the issues are, why it needs to be solved and why using Nostr for identity can increase the risk of security vulnerabilities and attacks.
2) The ability to robustly secure oneβs identity is critical to functioning societies. Without proof of identity, individuals cannot access banking services, gain employment, or receive voting rights. Solving decentralized identity is crucial for individual sovereignty.
3) There are 1.1 billion people who are not able to formally prove their identity β the majority of which live in Africa and Asia. For any decentralized social media protocol to be fully inclusive, worldwide, it must be able to robustly support identity for the unidentified.
4) Currently, most online federated identities are controlled by centralized and permissioned entities, such as Facebook. Google, Mozilla, Apple and Twitter. Users can easily find themselves deplatformed by these companies, for a variety of reasons.
5) @jack has a bounty for a trusted Nostr-based GitHub. Nostr keys are being considered as a way to manage online identities. However, as we will see, using Nostr keys for identity can introduce significant security vulnerabilities and risks for users. bountsr.org/code/2023/01/1β¦
6) The Nostr protocol provides users with a public and a private key. The userβs identity is tied to this public key, as opposed to a username. Much like your Bitcoin, if you lose or leak your private key your Nostr identity is gone.
7) The average Bitcoin holder might be able to recover from a loss of some funds. However, losing oneβs identity can be far more catastrophic β particularly if that identity is used for oneβs career, unlocks access to other applications or signing powers.
8) Recently, @BTCGandalf accidentally shared his private Nostr key on Twitter, instead of his public key. It was an easy mistake that anyone could have made and is indicative of UX issues with the protocol. This gave everyone control of his Nostr account and his Nostr identity.
9) To solve the issue, @BTCGandalf had to go back to Twitter, disavow his Nostr identity, and announce a new Nostr key as his new identity. He plans to tie his identity to DNS records. However, if his DNS were to expire or be seized, his identity would be permanently captured.
10) Nostr is a communications protocol, not an identity protocol. As such, it does not solve identity at the protocol level. Thus, it is in Nostr usersβ best interest to have maximum interoperability with existing standardized decentralized identity protocols.
11) Nostr handles identity "out of band" β meaning that your identity within the protocol entirely relies on external identities. Nostr simply points to centralized or seizable sources of identity and everyone presumes that those sources are trustworthy and accurate.
12) For example, when @jack first joined Nostr, he put his public key on Cash.app, which allowed anyone to see it was him. However, this approach is permissioned. If a user doesn't own the domain hosting their identifier, it can be easily deplatformed.
13) For the 1.1 billion people who are not able to formally prove their identity, purchasing a personal domain isn't an option. And even if they could, they are unlikely to be able to maintain a domain.
14) Domains are also easily blocked or taken down, especially in authoritarian countries, making them unreliable for identity verification. This has led to concepts such as "unstoppable domains" which many browsers still refuse to recognize.
15) Furthermore, an attacker can create imposter identities and use those identities to falsely "verify" captured Nostr identities. Without a standardized method of attestations that users, browsers and machines alike can quickly and easily verify, confusion and fraud ensues.
16) Ironically, Nostr dev @jb55 recently lost his Twitter account. If his Nostr key was compromised his imposter would have full control over his Nostr identity and could point his βProof Linkβ to a new Twitter account and claim it was his.
17) If Nostr cannot be reliably used to manage oneβs identity, then it will not be a reliable way to communicate in low-income countries and may even be considered an anti-pattern by vendors that are working to integrate with more robust decentralized identity protocols.
18) Nostr private keys are almost invariably managed by users without a secure enclave, making those keys easy to mismanage. Even if it were easy to encode Nostr keys into a secure enclave, users would not be able to revoke their keys in the event of theft or loss of devices.
19) This is because there is no way to do what is known as "key rolling" on Nostr β a best practice for security. That is, when a key or device becomes compromised or retired, you can't revoke it and keep using your identity. Imagine the following scenarioβ¦
20) Let's say you use Nostr keys to manage a photo album service. 20 years in, an attacker gets access to your keys. With Nostr, you are powerless and can't block the attacker's access. In that sense, Nostr is a protocol for the benefit of relays, not users.
21) Without regular key rotation and revocation, an attacker could gain access to your Nostr identity, along with any authorized accounts, and spy on you indefinitely without your knowledge. Itβs good practice to regularly roll and revoke keys, but Nostr doesnβt permit this.
22) The good news is that some (imperfect) solutions have been proposed to solve some of these issues in Nostr. For more details, read @brian_trollzβs excellent analysis here: bitcoinmagazine.com/technical/solvβ¦
23) Nostr uses a secp256k1βa secure and widely used curve (including for Bitcoin)β to create secure digital signatures and other cryptographic operations. However, it is not performant for all applications.
24) Zero Knowledge Proofs (ZKPs) enable a party to selectively prove data (like your age) without revealing private detailsβproviding a higher degree of privacy and security for personal data. Services with high volume ZKPs will prefer more performant βpairing-friendlyβ curves.
25) For example, GitHub recommends using curves that provide a high level of security and efficiency to implement and use. Curve25519 and Ed25519 are recommended, and are well-suited for use in systems like GitHub where performance is important.
26) Some applications need additional features and capabilities that are not available with secp256k1. Tying one's identity to secp256k1 may limit usersβ ability to integrate with other systems and networks, creating potential interoperability issues for users.
27) If a service requires a more performant elliptic curve at scale, Nostr would lack interoperability with that service. One way to solve these issues would be to use an identity βdocumentβ that could robustly list, rotate, revoke and manage keys. Hold onto that thought.
28) Nostr is a lightweight technology and much like the concerns of the Blocksize Wars its creators understandably want to keep it lightweight. However, the current practice of verifying "out of band" comes with real risks for identity that must either be acknowledged or fixed.
29) Nostr users might not be aware, but a comprehensive decentralized identity solution was developed over the last few years and was recently standardized by @w3c, the main international standards organization for the World Wide Web, founded in 1994 and led by Tim Berners-Lee.
30) Last year, Berners-Lee promoted Decentralized Identifiers (DIDs) as a new technology-agnostic web standard which permits users to inexpensively own trusted pseudonymous digital identities, without having to rely on centralized protocols.
31) DIDs were formally objected by Mozilla, which used bogus environmental fear mongering over Proof of Work, to try to deny DIDs from being accepted as a standard. This was despite the fact that PoW didn't even appear in the standard. bitcoinmagazine.com/culture/mozillβ¦
32) This article, written before DIDs were accepted as a web standard, explains how DIDs work and how they make online trust and the entire Internet better for everyone, including users who lack reliable identity. bitcoinmagazine.com/technical/didsβ¦
33) DIDs are decentralized documents that can receive attestations β with a web standard known as Verifiable Credentials (VCs) β from the DIDs of trusted third parties, who in turn have attestations from other trusted third parties with verifiable DIDs β creating a Web of Trust.
34) This unique combination of DIDs and attestations of Verifiable Credentials (VCs) allows even pseudonymous identities to become verified and trustworthy within a standards-based Web of Trust. Implementation of this standard could stop bots in their tracks, at virtually no cost
35) In 2001, Berners-Lee described a future where computers can perform authorized tasks and trust is instantly ascertained to unlock enormous amounts of productivity. For example, an AI assistant quickly matches your loved one with a medical specialist and secures an appointment
36) When web standards are combined, DIDs + VCs help bring about Berners-Lee's vision for the "Semantic Web", where the true power of the Internet is unleashed when humans + machines are able to both seamlessly and instantly trust identities with standard verifiable signatures.
37) Without standards, emails wouldn't be sent and web pages wouldn't be readable. If you want to natively and agnostically verify identity, as @ImperviousAi browser and @get_zion does, you need web standards
-justin- @justinrezvani
38) When Nostr devs were presented with the standardized solutions, they downplayed issues, openly mocked devs and solutions, and declared war. This is not the behavior one would expect of a welcoming social protocol that should want increased interoperability.
39) Instead of considering that decentralized identity was a complex problem that requires a robust solution, they decided to hurl insults and dismiss the prior work that solved the very problem that Nostr fails to solve.
Daniel Ιrrr @csuwildcat
40) Nostr devs complained that the standard was too verbose. This isnβt a valid complaint. Even the simplest internet standards are extremely verbose. For example, the spec for MIME types, which identify document types on the web, is extremely verbose.
41) Implementing support for DIDs in Nostr would solve these issues, improve interoperability and would not be all that difficult to implement. Here is one proposal.
42) More recently, a @TBD54566975 engineer proposed a thought experiment for DIDs on Nostr. However, the method falls well short of the security and features of other DID methods. But, it might be the best option, given Nostr's architecture.
43) Nostr devs appear to be anti-web standards, believing their limited protocol, which lacks identity assurances, will become a standard for social media. However, no browser will natively support half-baked solutions that impart risks and vulnerabilities on its users.
44) Amazingly, Nostr devs have not only declared war on web standards, but actually promote intentionally fragmenting and sandboxing web applications. fiatjaf.com/130cfaed.html This would essentially make it impossible for collaborative ideas like the Semantic Web to flourish.
45) Nostr devs actually *want* a fragmented anti-social architecture for the web β one that mocks interoperability and expects the mainstream to follow an imperfect approach to identity that would put users at risk if it were widely adopted.
46) While Nostr devs may have personal reasons to dislike the mainstream web and standards bodies in general, intentionally restricting interoperability through robust web standards is a recipe for obsolescence, vulnerabilities and risks.
47) If Nostr devs acknowledge their protocolβs limitations and attempt to build their own identity system to allow users to manage their keys, they will be re-inventing existing web standards, years after those web standards were vetted by major browser vendors.
48) Ultimately we need decentralized protocols to succeed. However, if Nostr chooses to roll its own proprietary solutions for identity, it will be intentionally deviating from approaches that have already undergone intense scrutiny from organizations that make the web usable.
49) Nostr folks do have a valid point that the new web standards currently lack widespread usage, and are generally in silos. However, this is no excuse for the fact that if key features for identity remain flawed or missing from Nostr it will only cause major problems for users.
50) Lack of rapid widespread adoption is always disappointing for people trying to implement new web standards. However, Using OpenID Connect Verifiable Presentations, there are over 70 major corporations who are interoperable today.
51) Groups like the identity.foundation are developing the foundational components of an open, standards-based, decentralized identity ecosystem for all people, organizations, apps, and devices.
52) And each quarter, more and more projects and user agents are beginning to support decentralized identity web standards, including @TBD54566975, @bluesky, @get_zion and others. And this, in turn, is spreading adoption.
53) Interoperability requires collaboration, not fragmentation. Nostr devs will ultimately need to decide if they are building a protocol that supports and benefits the needs of users from all backgrounds, worldwide, or if they are engineering Nostr to mainly benefit relays.
54) If Nostr chooses to shun interoperability and ignore standards-based solutions, it will not be serving the invisible and unidentified in the way #Bitcoin serves the unbanked. Relying on βout of bandβ centralized identities is simply not an option for much of the world.
55) The world needs interoperable decentralized protocols that support all users. If you believe Nostr is the future of decentralized social media, then you should make every effort to improve its interoperability with existing protocols and standards.
56) Addendum: DIDs aren't merely a document for attestations from others. DIDs are a relatively simple DNS-like JSON document for keys, endpoints and schemas that can be fully managed by the user. This allows users to manage enormous amounts of interoperable potential.
57) Once you have a protocol that has DNS-like documents, it unlocks the Semantic Web. This is essentially what "Web5" is. Front-end clients can lookup DIDs containing standard schemas advertising endpoints and attestations. Web5 = marketing term for the Semantic Web.
58) Reread the TDB.dex white paper and you'll see it's not really a decentralized exchange. The same protocol could just as well be an eBay, with no backend, for exchanging anything through the Semantic Web.
59) Which means that DIDs unlock something way bigger than just social media. If Nostr wants to sequester itself from from the rest of the upcoming Semantic Web, so be it. You simply don't get access to the Semantic Web without interoperability.
60) Ultimately Nostr devs will solve all these issues if they want to support features that are required for mainstream adoption. When they solve them theyβll arrive at the same complexity as DIDs without the benefits of interoperability, years after the fact.
Daniel Ιrrr @csuwildcat
61) Meanwhile the Enterprise products that make the web usable wonβt invest in protocols that are constantly shifting under their feet and scrambling to figure these things out. They are incentivized to invest in protocols thatβve undergone intense scrutiny from standards bodies.
»»»»»» Twitter | Youtube | Citadel21.com | Crypto News | Cryptoqed ««««««