הצטרף ל-Nostr
2026-07-22 04:57:39 UTC

FreedomTech on Nostr: Never use OAuth to sign into a Nostr app. Not even once. This article explains why. ...


Never use OAuth to sign into a Nostr app. Not even once. This article explains why.

OAuth means signing in using your Google account, Facebook account, Apple, etc.
quoting

The pattern you are about to read is not new. It is the classic co-opting pattern that has played out repeatedly over the past 30 years, with Linux servers ending up as AWS plantations, XMPP suffocated by centralized messengers, Email dominated by a handful of providers, and Mastodon instances consolidating under corporate operators. The damage does not require a grand conspiracy. It requires one small compromise, then another, then a generation that grows up thinking the result is normal.

What is new is that the same pattern is now arriving in Nostr, and the first clients with OAuth login have already shipped.

The Core Issue: A Bridge Between Pseudonymity and KYC

Nostr was built as an explicit counter-model to KYC (Know Your Customer) platforms. No phone number, no email, no identity check. You generate a key pair, you are in. Your npub (public key) reveals nothing about who you are as a person. For most Nostr users, this is not a side effect. It is the entire point. They moved away from Twitter, Facebook, and Google precisely to stop leaving personally traceable footprints.

A Google or Apple account is, by definition, a KYC'd identity. You cannot create one without a phone number, and in most cases you also hand over a real name, a payment method, and years of behavior. The moment a Nostr user binds their npub to such an account, three things become true at once:

  1. The link is permanent, as it sits in the IdP (identity provider)'s logs from the moment of login.
  2. The link is irreversible, because the IdP will not delete it just because the user stops using the feature.
  3. The link is correlatable, as no extra work is required and it happens in the normal data pipeline.

This is not about whether Google or Apple read your Nostr messages. It is about whether the wall between your anonymous Nostr identity and your real-world KYC'd identity holds. With every OAuth button in a Nostr client, that wall gets a hole punched through it. The hole does not close.

The damage does not require Phase 2, 3, or 4 of anything. In the moment a Nostr user performs their first OAuth login in a Nostr client, the link is established. Everything after that is merely a question of who uses that link, and for what purpose.

This is not Phase 1 of a process. This is the taboo break itself.

What Is Already Happening

The taboo is already broken. The first Nostr clients have started shipping OAuth login buttons ("Continue with Google", "Continue with Apple") on their splash screens. The convenient, familiar path is placed first visually. Beginners take the top button. That is not a guess. That is how UX works.

What happens next is not hypothetical. It is the direct, foreseeable consequence of routing a Nostr identity through a data broker's account.

What the IdP learns, even without ever seeing the nsec (the Nostr private key):

  • "This real-name account uses a Nostr client." The OAuth access runs on the client's OAuth client ID. The IdP knows for certain: this Google or Apple account, with real name, email, phone number, payment data, and years of behavior, uses a Nostr client. This entry is permanent in the account's security settings.
  • Activity patterns over time. Every authenticated call (backup upload, sync, restore, listing) is timestamped and tied to the account. The IdP sees when the user signs in, switches devices, and how often.
  • IP and rough location. Every call to the IdP's servers carries the user's IP address, timestamp, and OAuth token.
  • File metadata. Any data the client stores in the IdP's cloud (Drive, iCloud) is hidden from the user's UI, not from the IdP's servers. File existence, size, and timestamps are fully visible.
  • Cross-service enrichment. "Is a Nostr user, active at these times, from this IP" can plausibly be correlated with the IdP's existing identity graph, including contacts, location history, searches, and device telemetry. The IdPs have not publicly documented such a correlation, but it is well within their demonstrated data-handling capabilities and consistent with their published Privacy Policies.1

The PIN problem:

Clients that store the encrypted nsec in the IdP's cloud typically protect it with a 4 to 8 digit numeric PIN stretched via PBKDF2. A 4-digit PIN gives only about 13 bits of entropy, and even an 8-digit PIN reaches just 27 bits. In theory, the slow key derivation gives an attacker "weeks of compute" after compromising the IdP account. In practice, beginners choose 1234 or their birth year, and it cracks in seconds.

The credential manager problem:

When a Nostr client creates a new account on Android or iOS, the OS may surface a system save dialog offering to store the new credential in the device's configured password manager. If the user confirms, the npub sits there in plaintext as the username, and the nsec sits as a password. The default recipient depends on the platform:

  • On Android, the default is Google Password Manager. Google Password Manager is not end-to-end encrypted by default. Google's own help page states verbatim: "This type of encryption means that you trust Google to hold the key and keep your data secure." On-device encryption is opt-in, and Google states it will roll out "over time" to everyone. Until then, the default is "standard password encryption," where Google holds the key and can decrypt on demand.2
  • On iOS, the default is iCloud Keychain, which is end-to-end encrypted for the items themselves. However, when iCloud Backup is enabled (the default), a copy of the keychain is included in the backup, and Apple's published policies confirm that iCloud content is reachable via valid legal process to the extent Apple is technically able to comply.3

In both cases, the credential is within reach of a valid legal order in the default configuration. A key that Google or Apple holds or can recover is a key within reach of a subpoena or search warrant.4

The Beginner Reality

Clients that ship OAuth login target newcomers. Beginners take the familiar button, accept every default, and without noticing:

  1. Permanently mark their fresh, supposedly pseudonymous Nostr identity as belonging to a real-name IdP account. The "uses a Nostr client" entry sits in the IdP's logs from second one.
  2. Set a weak PIN. The "weeks of compute" protection shrinks to seconds.
  3. Possibly confirm the system password dialog, leaving the npub in plaintext next to the real-name account, and the nsec as a password the IdP can technically decrypt in its default configuration.

A user who enters an existing nsec directly, without going through OAuth, is not affected by any of this. The damage is concentrated exactly on the people least able to assess it: newcomers without an existing key, taking the path of least resistance.

Picture a journalist in a country where criticizing the government is dangerous. They install a Nostr client, tap the familiar top button, accept every default, and start writing, feeling safe behind their npub. The attacker does not even need their nsec. The permanent IdP entry "this real-name account uses a Nostr client", combined with timing and IP data, is already a serious exposure. If the client also surfaced the credential save dialog and the user confirmed, the npub itself sits in plaintext next to the real name in the IdP's password manager. The government does not have to break Nostr. It goes to the IdP. What previously required infiltrating a pseudonymous network has become a single legal request to one company. None of this requires hypothetical machinery. It is the direct, foreseeable consequence of one design decision, namely routing a sovereignty tool's identity through a data broker's account.

How the Co-opting Cycle Unfolds From Here

Once the taboo break is tolerated, the following progression follows an identical dynamic that has been observed historically across multiple instances, including Linux being absorbed into cloud infrastructure, XMPP being outcompeted by centralized messengers, Email/SMTP being dominated by a handful of providers, and Mastodon instances consolidating under corporate operators. Here is how this cycle could unfold in the Nostr/Freedom Tech space if the taboo break is not stopped. If Nostr succeeds and grows, this is a likely scenario of what might happen.

Phase 1: "Optional" (Where We Stand Now)

  • OAuth login gets integrated into Nostr clients as a "convenience."
  • The argument: "It's optional, nobody is forced to use it."
  • First analytics integrations appear, "to improve UX."
  • A taboo is broken, but nobody wants to be the one who "unnecessarily alarms."

Phase 2: Normalization (around 6 to 18 months)

  • More and more clients follow suit due to conformity pressure within developer teams.
  • OAuth login users become the majority because it is simply more convenient.
  • Developers who complain get dismissed as "extremists," "purists," or "impractical idealists."
  • First sponsoring deals with Web2 companies emerge ("we support open source and freedom tech").
  • Relays begin enriching metadata, "to combat spam."

Phase 3: Infrastructure Control (around 1 to 3 years)

  • A handful of hosted Nostr services dominate the market (like Mastodon instances, but worse).
  • These services offer "free" relay hosting, identity management, push notifications.
  • The catch is that they require KYC or IdP binding "to prevent abuse", or, more subtly, they are operated by companies that already have KYC data on their users through sister products.
  • Most users rely on only one or two of these services. Decentrality exists on paper only.
  • First data partnerships with analytics firms are quietly introduced.

Phase 4: Data Monetization (around 2 to 4 years)

  • Hosted services begin selling aggregated user data, "anonymized, of course."
  • Targeted advertising gets introduced into clients, "to make the project sustainable."
  • Google/Meta offer official Nostr integrations.
  • Bitcoin payments are routed through Lightning nodes operated by Big Tech adjacent firms. Transaction graphs get tracked.
  • "Freedom Tech" becomes a marketing label, similar to how "organic" or "fair trade" are used today.

Phase 5: Protocol Co-optation (around 3 to 5 years)

  • Big Tech introduces their own NIPs (Nostr Implementation Possibilities) containing proprietary extensions (anybody remember the browser wars?).
  • These NIPs get adopted by most clients "for compatibility reasons."
  • Google/Meta/X operate their own relays that only work with their authentication.
  • The open protocol still exists, but the usable part of the network is de facto under corporate control.
  • Anyone who refuses to implement the new NIPs gets isolated from the mainstream network.

Phase 6: Split or Surrender (around 5+ years)

Two scenarios:

Scenario A: Surrender. Mainstream Nostr becomes a Google/Meta ecosystem with a "decentralized" protocol as a facade. The original ideals become a footnote on Wikipedia. The developers who saw it coming are either absorbed or marginalized.

Scenario B: Split. A purist faction breaks away and runs a parallel network with 1% of the users but with genuine freedom. They get labeled as "sectarians" and "conspiracy theorists." Big Tech uses this split to tell mainstream users: "See? That is the alternative. Do you really want to go there?"

The Underlying Pattern

Phase Mechanism Justification
Taboo break First small compromises "It's optional"
Normalization Social proof, group pressure "Everyone does it"
Infrastructure Convenience beats principle "Users want it this way"
Monetization Data becomes the product "We need to be sustainable"
Co-optation Protocol gets taken over "Compatibility"
End state Freedom as a marketing label "We are decentralized"

The Real Decision Is Now

The most dangerous phase is not Phase 6. It is Phase 1, where the taboo break happens and the community tolerates it because it is "small" and "optional." That is exactly where the decision is made whether the cycle runs its course or gets stopped.

The break is happening now, in shipping software, today. It has to be named. It has to be answered, not with denial, not with "but it's optional," not with "they're a good team", but with a counter-design that keeps Nostr users out of corporate identity graphs by default, even when the operator is well-meaning and the UX is convenient.

The question is not whether it continues. The question is whether enough developers and users name the break now and bear the consequences: leaving a mainstream client, choosing alternatives, having the uncomfortable conversation, accepting being dismissed as a "purist."

That is the price that has to be paid anew in every generation.

Sources

  1. Google Privacy Policy: "We may use the information we collect across our services and across your devices for the purposes described above." Apple Privacy Policy: Apple similarly discloses cross-service use of personal information across its ecosystem.
  2. Google Account Help, Get started with on-device encryption. Verbatim: "This type of encryption means that you trust Google to hold the key and keep your data secure." The same page documents that on-device encryption is opt-in ("Under 'On-Device Encryption,' click Set up") and that "Over time, this security measure will be set up for everyone to help protect password security." Until then, the default is "standard password encryption," where Google holds the key.
  3. Apple Legal Process Guidelines, U.S. and Apple Government Information Requests. Apple discloses that iCloud content is reachable via valid legal process to the extent Apple is technically able to comply. iCloud Backup (enabled by default on iOS) includes keychain escrow data used for account recovery.
  4. How Google handles government requests for user information. Verbatim: "Get a search warrant to compel disclosure of the content of communications, such as email messages, documents, and photos." Apple Legal Process Guidelines describes the equivalent process for iCloud content. Neither provider publishes a carve-out for stored credentials.
Author Public Key
npub1fkluklzamwpyn7w8awxzrcqe7z8mldlvthk4gz9kz3vsh6udz62s9qj48l