Nostr is essentially a compromise between p2p and traditional web architectures. It cuts with the grain of the internet by using web servers, while reducing the dependence users have on servers by using keys for identity and digital signatures for authenticating data.
The effect is that users have "credible exit" (among other things), which has been discussed for years. This doesn't really create any new "use cases", which is why the use case is often described as "whatever, it's the new internet".
What it does do is introduce a very different set of trade-offs which favor user control over platform control (with the attendant UX trade-offs (or at least a different set of UX idioms)).
The reason the focus is on social is because that represents the majority of applications that do exist, the original motivation for building the protocol, and a value proposition (censorship resistance) that lots of people can relate to.
I don't want to be mean, but this post has exactly the problem the person you're replying to was complaining about. The person you're replying to, I think, would like an explanation that reads more like "It's like Twitter, but not tied to a mega-corp, just for you and your pals". I don't know if that description actually fits Nostr though because, like the person you're replying to, I have a pretty hard time understanding what Nostr actually _is_.
My point is that question is sort of a category error. It's like asking what type of business the internet is for, or what the use case of smart phones is.
Here are a few things built on nostr, with specific use cases:
primal.net is a twitter-like client with bitcoin micropayments and long-form articles (also see coracle.social, nosotros.app, jumble.social, Amethyst, Damus, yakihonne.com and many others);
zap.stream is a twitch-like client for live streaming;
flotilla.social and chachi.chat are group chat clients;
dtan.xyz is a client for torrenting on nostr;
satlantis.io is sort of a travel ratings thing;
zap.cooking is a recipe website;
yakbak.app is for voice messages;
nutstash.app is a cashu wallet built on nostr;
cashumints.space lists cashu mints that advertise themselves on nostr.
What's neat is that all these clients can do things the way they want to, but remain interoperable, which means that new developers can create an app and immediately have access to all existing nostr users and their social graph.
>It can be used to some extent via a browser using web clients, but it's best used alongside extensions for authentication and key management
Just wonder can the key just sit in the IndexDB? And it is decrypted on the client side (when user enters password to decrypt the key) to sign a message to send to peers or relay, they can verify your identity by checking against the corresponding public key.
The question isnt a category error and deserves a direct answer.
If I follow what you're saying the answer could have been: "it's a framework/set of protocols for building a Twitter that can show all the stuff on other compatible Google+/Facebooks"
If you have a preference for this style of definition, then we could say that
Nostr is a protocol that's well suited for creating decentralized applications that need publicly verifiable identity, censorship resistance and event based communication.
For example, https://zapstore.dev/app is an Android AppStore that uses nostr to provide a decentralized way to verify the developers and remove "fake" apps.
The criticisms are either implementation dependent (not checking signatures, which defeats the entire purpose of the protocol), or based on a very early proof of concept encryption scheme which has since been superseded (by NIP 44, which was independently audited). There's nothing substantial or actionable here (any more).
The cryptography was thrown together in the very early days as a proof of concept, that reached some level of adoption because of how nostr suddenly grew at the end of 2022. The community has since largely switched to a new standard (NIP 44) which has been independently audited, although there are some popular clients that haven't yet transitioned.
I am less on HN these days, but as far as I have seen:
Telegram is still judged by its very early releases, still called "unencrypted" while it is about as encrypted as your bank transactions (they definitely aren't e2ee either).
Signal can do what they want including dabbling in crypto currency without being open about it. Signal can also have extremely "interesting" bugs (didn't it at some point send messages to random people?) and glaring security issues (relatively trivial remote code in the desktop client IIRC a few years ago).
Last I checked WhatsApp was supposedly also good since they now use good encryption despite now being owned by Facebook, sending my social graph to them and sending peoples entire backups (including chats with me) unencrypted to Google for "free" (IIRC) backup.
That said these days I am definitely looking for Telegram alternatives.
Your bank doesn't operate in Telegram's threat model! You are never concerned that your bank's servers are attacking your transactions: if you can't trust your bank, you're fucked anyways. That's precisely what's not supposed to be the case about a messaging service!
It's very unlike mastodon in that server operators have minimal control over user identities and content. Spam control is still a work in progress, but has come a long way through web of trust and more responsible relay operation. I invite you to give it another try!
Very thoughtful points. One thing about nostr is that it does tend to balkanize due to the technical architecture, allowing for different groups of people to use it in different ways (different relay policies, client features, filtering, etc). But the tradeoffs you list are real, and enforce real constraints (the biggest of which is bare keys as identifiers). Many of these constraints can be designed away, which keeps me optimistic. We've had 30 years of research and development into password management, but far less into end-user key management. Even if nostr itself has some fatal flaw, I think a lot of interesting ideas are coming out of it, just because it provides a very different set of affordances for digital spaces.
Alternatively, you could use nostr, have your users pay for the database, and get access to rich content types, an existing social graph, and application interoperability.
OP and developer here, Flotilla's not quite primetime-ready, but I saw the Revolt post and decided to proffer my own alternative. Happy to answer any questions.
It definitely has bearing on the indexeddb complaint. If I was sending proxies over fetch, I would never have noticed. But I would expect the callbacks/props thing to be pretty annoying for any app that uses portals.
The effect is that users have "credible exit" (among other things), which has been discussed for years. This doesn't really create any new "use cases", which is why the use case is often described as "whatever, it's the new internet".
What it does do is introduce a very different set of trade-offs which favor user control over platform control (with the attendant UX trade-offs (or at least a different set of UX idioms)).
The reason the focus is on social is because that represents the majority of applications that do exist, the original motivation for building the protocol, and a value proposition (censorship resistance) that lots of people can relate to.