Celata on Nostr: Sure. 1. "Serious scalability problems" The "O(N) Relay" problem: In Nostr, clients ...

Sure.

1. "Serious scalability problems"
The "O(N) Relay" problem: In Nostr, clients have to query multiple relays to fetch a user's feed, and publishers must push their events to multiple relays to ensure their audience sees them. As the number of users and relays grows, the network traffic and duplicate data processing scale inefficiently.

No global state consistency: Unlike blockchains (which have a shared state) or federated networks like Mastodon (which route messages to specific servers), Nostr relies on gossip. Finding and assembling a complete, chronological feed across disconnected, independent relays is highly resource-intensive for both clients and servers.

Spam and storage: Because writing to most relays is cheap or free, they are highly susceptible to spam. Mitigating this requires relays to implement aggressive filtering or paid entry, which fragments the network.

2. "Hardcoded to outdated crypto"
The Schnorr/secp256k1 lock-in: Nostr is heavily tied to Bitcoin’s cryptographic curve (secp256k1) and Schnorr signatures (NIP-01). While great for Bitcoin compatibility, this curve is not standard in the broader web cryptography ecosystem.

Lack of agility: If a vulnerability is found in secp256k1, or if quantum-resistant cryptography becomes necessary (PQC), Nostr cannot easily transition. Because the cryptographic keys are the user identities (NPUBs), changing the algorithm means everyone would have to abandon their existing identity and start over. There is no built-in mechanism for "key rotation" to a different cryptographic standard.

3. "Identity, UI, and processing (relay) are in different places... meaning you have to basically trust everything"
Fragmentation of the stack: In a typical Nostr setup, your identity (private key) is held in a browser extension (like Alby or Nos2x), your UI is a web app hosted by a third party (like Coracle or Primal), and your processing/data storage happens on third-party relays.

The trust dilemma (No non-custodial middle): Because these three layers are entirely disconnected, you face an "all-or-nothing" trust model:

Trust the UI: You have to trust that the web client isn't maliciously showing you fake data, hiding posts, or tricking you into signing a transaction you didn't intend to.

Trust the Extension: You have to trust that your key manager is securely holding your keys and not leaking them. Also your extension is not partitioned and can read all your web traffic and internal browser state even on secure sites like your bank website.

Because there is no "middle tier"—like a personal, trusted local proxy or a "light client" that cryptographically verifies the UI's behavior—you are forced to fully trust the client app to render the truth and the relays to serve it honestly.

4. "Content is a raw string that has zero content typing..."
No MIME type standards: When a Nostr event (specifically Kind 1, short text notes) is sent, the actual payload is just a raw string of text. There is no standardized metadata telling the client, "This content is HTML," "This is Markdown," or "This is a JSON object."

Inconsistent rendering: Because the data payload doesn't declare its own type, different Nostr clients will parse and display the exact same post differently. What looks like a beautifully formatted post on one client might render as raw, ugly markdown or plain text on another.

5. "...determining what to display is obsolete sniffing of file extensions and a serious security problem"
Relying on file extensions: Because there is no strict content typing, clients have to guess what a link is by "sniffing" the URL. For example, if a client sees a URL ending in .jpg, it assumes it's an image and automatically renders it.

Security risks of "sniffing": This approach is notoriously insecure and outdated:

MIME-sniffing exploits: An attacker could post a link ending in .png that actually contains malicious JavaScript or executable code. If the client's parser is naive, it might attempt to execute or process the file, leading to Cross-Site Scripting (XSS) attacks or arbitrary code execution.

IP Leaks and Tracking: Automatically loading URLs found in raw text strings to "preview" them forces the user's client to make requests to unknown third-party servers, immediately leaking the user's IP address and browser metadata to whoever hosts that link.