Nostr notes by

If you don't understand the problem you don't understand ...

2026-07-22T07:40:57Z

If you don't understand the problem you don't understand the solution.
A peer to peer electronic cash system
#bitcoin

must read for all devs (and wannabes) #naddr1qq…gp85

2026-07-22T04:49:18Z

must read for all devs (and wannabes)

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"

This bro intelligent ⬇️ #nevent1q…g8ar

2026-07-22T04:20:18Z

This bro intelligent ⬇️

quoting
nevent1q…g8ar
Buzz is GAY AF

Why do I HAVE to have an Anthropic or OpenAI account that I sign in with an email in order to even see the program?

This is antithetical to nostr and using openapi keys or an openweight model

Say no to Big Tech integrations in Nostr apps. #naddr1qv…ey6g

2026-07-22T04:18:30Z

In reply to naddr1qq…r4mq
_________________________

Say no to Big Tech integrations in Nostr apps.

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"

@npub1we8…qhcl

2026-07-22T03:29:51Z

In reply to nevent1q…3cet
_________________________

Kawaii-Muslim (npub1we8…qhcl)

The Japanese learning about anti-Riba money ...

2026-07-22T03:26:54Z

The Japanese learning about anti-Riba money

No, that's not the question 🙂. The how is it.

2026-07-22T03:22:43Z

In reply to nevent1q…jm6x
_________________________

No, that's not the question 🙂. The how is it.

Stupid people do stupid things even if they have access to ...

2026-07-22T03:08:31Z

In reply to nevent1q…casa
_________________________

Stupid people do stupid things even if they have access to intelligent machines.

What's the point of an AI subscription if you don't use ...

2026-07-22T03:06:10Z

What's the point of an AI subscription if you don't use it to check out a new hyped app, and instead just chase after every new release like a fanboy without thinking, just because it's announced by the right names?

buzz

2026-07-22T02:59:45Z

In reply to nevent1q…lmpt
_________________________

buzz

looked at it this morning. hella buggy

2026-07-22T01:35:24Z

In reply to nevent1q…t7vq
_________________________

looked at it this morning. hella buggy

Nostr event nevent1qqsp6fj8f5cz2deq3qr64mljgxxyllrepn0l609lpa2fh0swqd5hdpgpg3mhxue69uhhyetvv9ujumn0wd68yctjv93xjcfwvdhk6tmfde6x2mn58fex2mrp0yhxummnw3exzunpvf5kztnrdakj7mrfd4sj6an9wf6x27qzyzug2xsxmlte6j8uxffrfg27nfr2x2sfs25z8d2vm7p9zjumzg96zydmunp

2026-07-22T01:32:43Z

In reply to nevent1q…gknf
_________________________

https://github.com/bitcoin/bitcoin/pull/35558#issuecomment-5040544280

am i missing something is Buzz basically the same thing as ...

2026-07-22T01:31:36Z

am i missing something is Buzz basically the same thing as Budabit?

liking this much better than Nostrord. hoping it gets opensourced ...

2026-07-22T01:10:14Z

liking this much better than Nostrord. hoping it gets opensourced

quoting
nevent1q…0t97
#Lotus is a great place to start Nostr. You can explore and will already find common patterns you know from Google or other services like "Calendly".

Onboarding is straight forward.

Thank you markusturm (nprofile…6fz4) for spreading the word

nevent1q…dtjf

Tonight: my first attempt at a Bitcoin Core PR.

2026-07-21T23:57:48Z

Tonight: my first attempt at a Bitcoin Core PR.

Oh really? Well then...

2026-07-21T23:09:41Z

In reply to nevent1q…q9ku
_________________________

Oh really? Well then...

I have nothing against the project. I used it back when it was ...

2026-07-21T23:07:33Z

In reply to nevent1q…v2zm
_________________________

I have nothing against the project. I used it back when it was called Sprout.

We love new things. I just find our community a little cute.

i'm not that tech savy yet. let me get the home server setup ...

2026-07-21T23:07:52Z

In reply to nevent1q…edgy
_________________________

i'm not that tech savy yet. let me get the home server setup first. my main reason for Notesnook was to get off Google Docs and bc Obsidian was too complex for me over a year ago. getting a more efficient set up come next.

Notesnook is a muslim dev team btw.

i have sync confirgured between macOS, iOS, GraphenOS, and Linux ...

2026-07-21T22:13:59Z

In reply to nevent1q…8egq
_________________________

i have sync confirgured between macOS, iOS, GraphenOS, and Linux (Mint currently, want to switch to something better soon).

The thing is, since it's all text and md files, syncing is ...

2026-07-21T22:17:03Z

In reply to nevent1q…4nvn
_________________________

The thing is, since it's all text and md files, syncing is really easy to do independent of any app with a script that uses Unison. That's how I sync all my machines now without going through a third party server.

absolutely love Notesnook! been using them for over a year now

2026-07-21T22:11:46Z

In reply to nevent1q…nsu5
_________________________

absolutely love Notesnook! been using them for over a year now

Always something to complain about... 🙂

2026-07-21T21:51:14Z

In reply to nevent1q…kc8k
_________________________

Always something to complain about... 🙂

Sounds great. I have the exact same setup. Should give it a try.

2026-07-21T21:30:06Z

In reply to nevent1q…kqpv
_________________________

Sounds great. I have the exact same setup. Should give it a try.

How is it better than Obsidian?

2026-07-21T21:17:08Z

In reply to nevent1q…4d7k
_________________________

How is it better than Obsidian?

Nostr event nevent1qqs02rej8e977kvxzvfy92dn5rtq9dml79ax28lshxzcmqwhu5wppwqpg3mhxue69uhhyetvv9ujumn0wd68yctjv93xjcfwvdhk6tmfde6x2mn58fex2mrp0yhxummnw3exzunpvf5kztnrdakj7mrfd4sj6an9wf6x27qzyzug2xsxmlte6j8uxffrfg27nfr2x2sfs25z8d2vm7p9zjumzg96ze8zjhz

2026-07-21T20:40:12Z

In reply to nevent1q…aglk
_________________________

Why is it a scam? Don’t subscribe, it’s really that easy. The ...

2026-07-21T20:32:04Z

In reply to nevent1q…prm5
_________________________

Why is it a scam? Don’t subscribe, it’s really that easy.

The prices are more about supporting the developers rather than gaining access to features.

This…. Looks…. Disgusting 🤢

2026-07-21T20:29:37Z

In reply to nevent1q…tdfg
_________________________

This…. Looks…. Disgusting 🤢

Welcome 🙏 We have things here called follow packs. It’s like ...

2026-07-21T20:29:07Z

In reply to nevent1q…02um
_________________________

Welcome 🙏
We have things here called follow packs. It’s like a big list of people with similar interest. You can open a pack and follow folks you think are interesting or follow the whole pack and unfollow as needed.

What client are you using?

Wow. This looks amazing.

2026-07-21T20:24:14Z

In reply to nevent1q…vgk6
_________________________

Wow. This looks amazing.

You are not seeing the Buzz? 😂

2026-07-21T20:04:27Z

In reply to nevent1q…apmg
_________________________

You are not seeing the Buzz? 😂

It’s funny how an entire community can be moved with one note. ...

2026-07-21T20:01:05Z

It’s funny how an entire community can be moved with one note.

You people are bored as fuck. 😂

quantity over quality. yeah, no thanks. when you consider working ...

2026-07-21T19:10:47Z

quantity over quality. yeah, no thanks. when you consider working with the network a waste of time you ultimately put yourself in oposition to the protocol.

wisp cult is way more annoying than BCHnostr imo.

quoting
nevent1q…gx57
Just make the best UX you can and try to get users, its a waste of time to constantly discuss how to interoperate.

If you get a ton of users you win the discussion and become the standard by default without saying a word

Evil in disguise

2026-07-21T19:07:59Z

In reply to nevent1q…wypd
_________________________

Evil in disguise

Nothing says “public safety” like secretly watching the ...

2026-07-21T19:06:04Z

In reply to nevent1q…wq7t
_________________________

Nothing says “public safety” like secretly watching the public without asking the public.

and i'm now hearing Iran just hit their embassy in Bahrain

2026-07-21T18:53:16Z

In reply to nevent1q…qudn
_________________________

and i'm now hearing Iran just hit their embassy in Bahrain

Ah ok

2026-07-21T18:28:28Z

In reply to nevent1q…3ftk
_________________________

Ah ok

Yes and yes.

2026-07-21T18:22:37Z

In reply to nevent1q…c3la
_________________________

Yes and yes.

France is using children as the warrant to abolish anonymous ...

2026-07-21T18:24:08Z

In reply to nevent1q…5ujn
_________________________

France is using children as the warrant to abolish anonymous speech for everyone.

BIP-110 is right about Bitcoin’s purpose. Core is right about ...

2026-07-21T17:41:03Z

BIP-110 is right about Bitcoin’s purpose.

Core is right about Bitcoin’s mechanics.

Ethos matters. Physics settles.

classic nostr dev response to user feedback 🤣 #nevent1q…zxks

2026-07-21T17:28:09Z

classic nostr dev response to user feedback 🤣

quoting
nevent1q…zxks
Go fuck yourself.

No, people are asking about how to manage keys, where to create ...

2026-07-21T17:12:55Z

In reply to nevent1q…dmmc
_________________________

No, people are asking about how to manage keys, where to create accounts, early bitcoiners type of questions.

SAIF: 1 Balaji: 0 #nevent1q…qw6j

2026-07-21T16:55:08Z

SAIF: 1
Balaji: 0

quoting
nevent1q…qw6j
we will win

https://www.nst.com.my/news/nation/2026/07/1494102/updated-johor-govt-shuts-down-network-school-effective-july-22-watch

Morning anarko hv a good one

2026-07-21T14:30:52Z

In reply to nevent1q…pstj
_________________________

Morning anarko hv a good one

🙏🏽

2026-07-21T14:30:30Z

In reply to nevent1q…gnjl
_________________________

🙏🏽

Fair. Keep up the great work man.

2026-07-21T12:30:12Z

In reply to nevent1q…dylc
_________________________

Fair. Keep up the great work man.

Yalla natrak

2026-07-21T12:27:46Z

In reply to nevent1q…l7nl
_________________________

Yalla natrak

What are you gonna do about it?

2026-07-21T12:17:31Z

In reply to nevent1q…4eks
_________________________

What are you gonna do about it?

That's pretty much it

2026-07-21T12:07:50Z

In reply to nevent1q…teqh
_________________________

That's pretty much it

When are you link a wallet here? :)

2026-07-21T12:02:03Z

In reply to nevent1q…28w6
_________________________

When are you link a wallet here? :)

Hey suzzy

2026-07-21T12:01:16Z

In reply to nevent1q…04s5
_________________________

Hey suzzy