Nostr notes by

I bet you Archery ranges had more visitors this week than they ...

2026-07-25T04:58:49+02:00

I bet you Archery ranges had more visitors this week than they ever had since hunger games.

GN #Nostr ...

2026-07-25T03:00:28+02:00

GN #Nostr

I'm making everyone read this. Do it now. We need to talk ...

2026-07-25T04:12:26+02:00

In reply to naddr1qq…0e66
_________________________

I'm making everyone read this. Do it now. We need to talk more about this.

quoting
naddr1qv…7dqh

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:

The link is permanent, as it sits in the IdP (identity provider)'s logs from the moment of login.

The link is irreversible, because the IdP will not delete it just because the user stops using the feature.

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.¹

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.²

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.³

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.⁴

The Beginner Reality

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

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.

Set a weak PIN. The "weeks of compute" protection shrinks to seconds.

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

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.

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.

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.

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.

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"

😹😹😹 i m d e a d #nevent1q…f06n

2026-07-25T03:19:58+02:00

😹😹😹

i m d e a d

quoting
nevent1q…f06n
To be fair, Bitchat was two weeks away from a nuclear weapon.

are he and SNEAKO still fighting?

2026-07-25T02:57:33+02:00

In reply to nevent1q…vht9
_________________________

are he and SNEAKO still fighting?

Appreciate what you got brother. It's always greener on the ...

2026-07-25T02:52:15+02:00

In reply to nevent1q…r5lr
_________________________

Appreciate what you got brother. It's always greener on the other side you think?

Will definitely add it to our translation wishlist once we finish ...

2026-07-25T01:37:02+02:00

In reply to nevent1q…84er
_________________________

Will definitely add it to our translation wishlist once we finish fixing the website Arabic wording.

did Fuentes seriously say that? @npub1473…g6c5 go wip your boy

2026-07-25T00:57:56+02:00

In reply to nevent1q…rd9q
_________________________

did Fuentes seriously say that?

teepolitics (npub1473…g6c5) go wip your boy

No, but if someone wants to translate it, feel free to do so.

2026-07-25T00:51:21+02:00

In reply to nevent1q…fqea
_________________________

No, but if someone wants to translate it, feel free to do so.

another dev complaining about user feedback #grownostr 🙄 ...

2026-07-25T00:41:31+02:00

another dev complaining about user feedback #grownostr 🙄

quoting
nevent1q…wlfp
Serious? Are you going to keep complaining here instead of building a client that pleases you?

Godspeed 🙏🏽

2026-07-25T00:35:00+02:00

In reply to nevent1q…d5my
_________________________

Godspeed 🙏🏽

A great read. #naddr1qq…gp85

2026-07-25T00:32:39+02:00

A great read.

quoting
naddr1qq…gp85

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:

The link is permanent, as it sits in the IdP (identity provider)'s logs from the moment of login.

The link is irreversible, because the IdP will not delete it just because the user stops using the feature.

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.¹

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.²

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.³

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.⁴

The Beginner Reality

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

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.

Set a weak PIN. The "weeks of compute" protection shrinks to seconds.

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

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.

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.

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.

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.

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"

Alp this is a great piece. Do you write Arabic? If so we d love ...

2026-07-25T00:32:08+02:00

In reply to naddr1qq…gp85
_________________________

Alp this is a great piece. Do you write Arabic? If so we d love to put it on the new nostrarabia.com website. Lemme know

Seriously man, I didn't come here to dump some more data off ...

2026-07-25T00:11:59+02:00

Seriously man, I didn't come here to dump some more data off at Google and the likes again. You devs are completely losing it, gotta be honest and say that at this point.

quoting
nevent1q…rhe6
I really can't imagine someone who is moving from one home to another would want to put their waste bin full pf trash in the moving van with them and bring it along.

Th Sahabah mostly all left their entire homes and even businesses behind when they made hijra. Why should our digital hijra be any different?
naddr1qq…gp85

That's exactly what he said, if you can read.

2026-07-24T23:04:08+02:00

In reply to nevent1q…8awf
_________________________

That's exactly what he said, if you can read.

I really can't imagine someone who is moving from one home to ...

2026-07-24T22:55:17+02:00

I really can't imagine someone who is moving from one home to another would want to put their waste bin full pf trash in the moving van with them and bring it along.

Th Sahabah mostly all left their entire homes and even businesses behind when they made hijra. Why should our digital hijra be any different?

quoting
naddr1qq…gp85

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:

The link is permanent, as it sits in the IdP (identity provider)'s logs from the moment of login.

The link is irreversible, because the IdP will not delete it just because the user stops using the feature.

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.¹

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.²

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.³

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.⁴

The Beginner Reality

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

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.

Set a weak PIN. The "weeks of compute" protection shrinks to seconds.

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

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.

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.

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.

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.

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"

🤮 yeah no thanks. i'd rather build something that can save ...

2026-07-24T22:46:58+02:00

In reply to nevent1q…7t9j
_________________________

🤮 yeah no thanks. i'd rather build something that can save normies from that and not bring baggage with them.

Ok, as long as you don't Google or Apple login to attract ...

2026-07-24T22:44:38+02:00

In reply to nevent1q…zl39
_________________________

Ok, as long as you don't Google or Apple login to attract some normies ... 😜

that has to be the objective. Trump wants to go out with a bang ...

2026-07-24T22:37:11+02:00

In reply to nevent1q…82w0
_________________________

that has to be the objective. Trump wants to go out with a bang so probably going to be a hot weekend and the allies will be on their own afterward

ok. i'm not super familiar with amethyst. been a few months ...

2026-07-24T22:34:57+02:00

In reply to nevent1q…uv28
_________________________

ok. i'm not super familiar with amethyst. been a few months now since i've used that client and never tested DMs there.

since you're on android you can use a dedicated nostr messaging client like 0xchat. NoorNote has also been solid on the DM front.

feel free to DM me and i can try to troubleshoot more with you

i can make you a new one, soon...

2026-07-24T22:34:19+02:00

In reply to nevent1q…jmhs
_________________________

i can make you a new one, soon...

Well, if you do that with Claude, you'll get reported to the ...

2026-07-24T22:17:46+02:00

In reply to nevent1q…hkmh
_________________________

Well, if you do that with Claude, you'll get reported to the local authorities. 🙂

Yea sucks. Closing my NoorNote support group there.

2026-07-24T21:38:18+02:00

In reply to nevent1q…jsvk
_________________________

Yea sucks. Closing my NoorNote support group there.

but yes, everything sucks and muslims are as much to blame for it ...

2026-07-24T20:48:40+02:00

In reply to nevent1q…d77a
_________________________

but yes, everything sucks and muslims are as much to blame for it sucking as the reat

those are genuinely more ambiguous as both Russia and GAE were ...

2026-07-24T20:47:43+02:00

In reply to nevent1q…rg6j
_________________________

those are genuinely more ambiguous as both Russia and GAE were financing both sides in those conflicts.

Transparency should be enforced at the funding layer, without ...

2026-07-24T20:24:01+02:00

In reply to nevent1q…xyge
_________________________

Transparency should be enforced at the funding layer, without giving funders control over Bitcoin. Ideally tracked by a transparent ledger like your proposal.
Each member should publicly disclose its pledged and disbursed amounts, recipients, selection rationale, conflicts of interest, milestones, and the work produced: research, code, reviews, tests, repositories and, where relevant, BIPs.
Recipients should publish periodic progress reports, while independent technical reviewers and the wider community verify delivery over time.
But funding must never be mistaken for consensus. Supporting a developer or proposal does not buy protocol influence. BIPs remain proposals; adoption ultimately belongs to Bitcoin’s users.
The standard should be simple: trace every dollar to verifiable work, independently audit the process, and never confuse sponsorship with authority.

@npub175n…g6w0 Joogle login infection spreading.

2026-07-24T20:22:17+02:00

In reply to nevent1q…fcm2
_________________________

alp (npub175n…g6w0) Joogle login infection spreading.

exactly my point - the arab autocrats have doubled down on their ...

2026-07-24T20:16:05+02:00

In reply to nevent1q…05v2
_________________________

exactly my point - the arab autocrats have doubled down on their support for the kufar and absolute evil. that's btoh a theological and political situation.

fiat has always been the threat though. i imagine we actually ...

2026-07-24T19:40:49+02:00

In reply to nevent1q…ls3q
_________________________

fiat has always been the threat though. i imagine we actually have more folks awake now than before. it's just the ones we thought were awake never actually were

exactly and the only silver lining is that in that process they ...

2026-07-24T19:38:36+02:00

In reply to nevent1q…0fcl
_________________________

exactly and the only silver lining is that in that process they are waking everyone up to have bad the fiat system is

they have to use the theology to back up their autocratic states ...

2026-07-24T19:35:03+02:00

In reply to nevent1q…v2j6
_________________________

they have to use the theology to back up their autocratic states though. otherwise we are literally in an arab/persian race war.

we are now in the sunni/shia war i've been warning about for ...

2026-07-24T19:12:34+02:00

we are now in the sunni/shia war i've been warning about for nearly 2 years 🫠

https://www.wsj.com/world/middle-east/iran-gulf-states-bahrain-kuwait-strikes-009637db

nevent1qgs0xv59y9lfw6keetc9gez94kqs0kuc7evk0nwwdn8ytesd5q8wx2sqypewlxk9e3pmcf6p4vlxnestadmyhdhsmdwl894hsvy7kaw57vnpzmp6c7h

idk. Zuck tries to hold his tongue since 2016. he's more ...

2026-07-24T18:58:02+02:00

In reply to nevent1q…rjqd
_________________________

idk. Zuck tries to hold his tongue since 2016. he's more self-conscious than Musk

that is economizing though. economizing into fiat debt. it's ...

2026-07-24T18:44:24+02:00

In reply to nevent1q…dxss
_________________________

that is economizing though. economizing into fiat debt. it's the wrong direction but it is a form of economization.

Doesn't matter if it's optional or for convenience. ...

2026-07-24T18:35:17+02:00

In reply to nevent1q…pyq7
_________________________

Doesn't matter if it's optional or for convenience. It's a psyop. You add OAuth, you endanger your users.

quoting
naddr1qv…ey6g

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:

The link is permanent, as it sits in the IdP (identity provider)'s logs from the moment of login.

The link is irreversible, because the IdP will not delete it just because the user stops using the feature.

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.¹

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.²

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.³

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.⁴

The Beginner Reality

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

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.

Set a weak PIN. The "weeks of compute" protection shrinks to seconds.

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

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.

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.

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.

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.

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"

Asain dads are awesome https://youtu.be/xKuDvRRE7Bc

2026-07-24T18:34:59+02:00

Asain dads are awesome

https://youtu.be/xKuDvRRE7Bc

messages disappeared? what client are you using?

2026-07-24T18:18:07+02:00

In reply to nevent1q…77vr
_________________________

messages disappeared? what client are you using?

Yes but only one time. Might not be maintained though.

2026-07-24T17:54:57+02:00

In reply to nevent1q…x2t0
_________________________

Yes but only one time. Might not be maintained though.

Has Zuckerberg ever said anything against Islam or Muslims in ...

2026-07-24T17:54:15+02:00

In reply to nevent1q…eu77
_________________________

Has Zuckerberg ever said anything against Islam or Muslims in general? Incited hate against us?

It has Big Tech OAuth. Read my latest article about that.

2026-07-24T17:52:11+02:00

In reply to nevent1q…yulz
_________________________

It has Big Tech OAuth. Read my latest article about that.

If Bitcoin ISNT about nodes and those who run it, then what ...

2026-07-24T17:46:21+02:00

In reply to nevent1q…r8cj
_________________________

If Bitcoin ISNT about nodes and those who run it, then what exactly makes Bitcoin any different to any other shitcoin?

Removing the importance of nodes is like removing the imporance of the Sunnah. It’s the way to deviate from the original mission statement.

We will find out just how important nodes are soo enough.

What I find most illuminating about the anti-BIP110 campaign ...

2026-07-24T17:38:10+02:00

What I find most illuminating about the anti-BIP110 campaign isn't really any of the technical arguments (although those are important), but the overall social strategy.

There was a real coalition of privacy advocates (like Samourai and Wasabi developers agreeing on something!) and certain independent developers and long-time critics of Bitcoin Knots who opposed BIP110, yet they were largely overshadowed while the campaign instead wrapped itself around Saylor, Andy, Coinbase, and other institutions in the "Bitcoin Security Consortium." From a consensus building perspective, that seems like a missed opportunity or an odd own goal. I mean if I were trying to build opposition, I'd have elevated the privacy and decentralization voices, not the institutions that many Bitcoiners are already largely skeptical of.

The technical debate is one thing, ok, but at the social layer the anti-BIP110 side seemed to misunderstand how Bitcoiners actually form consensus, like they are socially retarded.

Let's hope for the best and plan for the worst.

2026-07-24T17:30:39+02:00

In reply to nevent1q…zufl
_________________________

Let's hope for the best and plan for the worst.

$15 million for open-source security work is welcome. The word ...

2026-07-24T17:24:10+02:00

$15 million for open-source security work is welcome. The word “consortium” is where scrutiny begins.

Bitcoin does not need institutional permission. Its developers deserve institutional funding.

Nine major firms have pledged $15 million over three years to support Bitcoin developers and security research. Each firm will choose where its money goes, while the new consortium says it will neither direct Bitcoin’s development nor support specific protocol changes.

Good.

Now publish the receipts.

Because funding does more than pay salaries. It determines which problems receive attention, which researchers gain runway and which solutions acquire institutional legitimacy.

That is influence, even without formal authority.
Bitcoin’s rules remain with the network. The research agenda must not quietly migrate toward the institutions financing it.

Disclose every commitment, recipient, conflict and result. Fund competing approaches. Separate new capital from existing promises.

Institutions may finance Bitcoin’s defence. They do not inherit a vote.

saylor (nprofile…d8n5) Blockstream (nprofile…hxm7)

looking forward to testing out your fork! ...

2026-07-24T17:15:13+02:00

In reply to nevent1q…gcka
_________________________

looking forward to testing out your fork!

nevent1qgs8eseg5zxak2hal8umuaa7laxgxjyll9uhyxp86c522shn9gj8crsqypx30vzxzph0hmarwmzefhl724h470y838d84zy3c0vq8eup9t05y42t7la

Seen a lot of folks simping for Jack's new Buzz app and ...

2026-07-24T17:00:17+02:00

Seen a lot of folks simping for Jack's new Buzz app and honestly disappointed. We've had better tools in #Budabit and #KeyChat for well over a year. And the "built on nostr" claim is really quite dangerous.

Here's notes from a code audit of their repo I ran after test-driving:

* Messaging is NOT E2E / not even NIP-17. Per Buzz's VISION doc: server-managed encryption (TLS in transit + at-rest) covers every channel, DM, and event *by design* — the server can read everything, to support enterprise eDiscovery/compliance. NIP-44 E2E is only a "future consideration" for DMs. Keypairs do identity/signing/audit, not confidentiality. Summary: email-gated access to AI features, nostr keypairs are used for internal audit trail.

* Different trust model from NIP-17. Nostr wants the relay operator *unable* to read private content; Buzz wants the server *able* to. Same Nostr foundation, opposite privacy posture. This is a different customer than your normal nostr user.

* Agent identity: each agent = its own keypair + a second signature tying it to its human owner + hash-chain audit trail; wired via the Agent Client Protocol (Claude Code, Codex, Goose). #KeyChat already landed on the same pattern: an agent is its own keypair plus a human owner who approves/vouches for it. This is a converged pattern rather than inventing anything new.

Bottom line: If you have a business that needs to do fiat reporting on AI compliance, Buzz could be useful. If you are the average nostr user who is concerned about sovereignty and privacy you should only use Buzz with a separate keypair. Or go fork it and make it more nostr friendly!

quoting
nevent1q…92y0
Is Buzz something we can use as community chat?

Thanks for sharing. Great video.

2026-07-24T16:58:14+02:00

In reply to nevent1q…x3qx
_________________________

Thanks for sharing. Great video.

will do

2026-07-24T16:39:07+02:00

In reply to nevent1q…u60q
_________________________

will do

what is this? an influencer party?

2026-07-24T16:37:03+02:00

In reply to nevent1q…7al3
_________________________

what is this? an influencer party?

sanctioned bitcoin only works if you don't have a circular ...

2026-07-24T16:34:55+02:00

In reply to nevent1q…zeyp
_________________________

sanctioned bitcoin only works if you don't have a circular economy built. i might totally disagree with the Epstein Consortium but they are economizing, albeit with paper btc. devs can fight all they want but until sovereign users are economizing their btc then its likely gg.