Why I’m betting on Nostr
hivemind.vc
hivemind.vc
First, I want a replication strategy. Nostr messages get lost in time, and many of the clients end up just blasting an entire message history at your client. Because there's no clue in the protocol how messages are related other than a timestamp this also means you can fake timestamps and write fake messages in the future or back in time. This doesn't have to be an append-only log, but you need some idea of message order to avoid wasting bandwidth to get someone's timeline and detect when a message has been posted out of order.
Second, I don't like that many Nostr clients are using the same signing key for messages as they do for lightning transactions. We don't know how many of these web Nostr clients are secretly sending your private keys back to their servers, and everyone will run from Nostr as soon as some untrustworthy dev starts emptying lightning wallets.
Third, someone needs to delete some of these NIPS. The arms race to make Nostr as complex and difficult as possible to implement is not going to do much for the ecosystem in the long run. In the beginning Nostr was simple to implement from scratch, they should get back to that!
Fourth, it needs a dedicated blob store protocol. Yah, I know IPFS isn't great but someone should come up with something that is simple and works.
Anyway best of luck to the people who are working on the project. If anything we learned more about how these protocols can work, even if Nostr isn't going to be the winner in this space in the long term.
nostr is stateless it’s just a streaming protocol for messages, there is no ordering (the same way there is no packet ordering in UDP). Looks like what you need is something built on top of it. Right now nostr relays are just that, real time message relays, they are not even supposed to store the messages.
I've brainstormed ways to solve this on top of Nostr. Perhaps I could write a program that downloads all of the history of Nostr (or perhaps just the users I'm interested in?) and then my server would sign when I received the messages and create order out of that.
Then if I get a message that claims to be from the past at some point in the future, I'd instantly be able to see that. I'd also be able to periodically ping relays and see what messages that are no longer being relayed and I'd have some curiosity about why that is happening.
I just kind of wish this was baked into the protocol. But I sailed here from the Scuttleverse. I'm open to ideas about how to do this well.
Is this even possible? Won't relays throw away older messages at some point? Or are they supposed to scale infinitely?
There are some relays that have no storage at all, they only relay messages between connected clients and then discard the messages.
I'm betting on webtorrent paired with seedboxes - your peer just has to serve whatever mp3/mp4 you're hosting to the first few clients, and as long as their browser windows are open they can help seed any viral growth, handling DDoS/hugs-of-death without issue. If there are multiple hosts in a community they can enter peering agreements and sync their seedboxes to keep media available, solving bitrot
if only I could figure out how to get paid to implement it
The financial system at large is built to discourage people transferring funds anonymously for myriad reasons, and most people aren't interested in keeping all their cash inside the black market (no exit nodes in torspeak)
from my view it's been settled for near 2 decades now, IPFS just gets more press in certain circles
They were using Gun db at some point too maybe but it's been some time since i checked, maybe it was a clone.
Just post the SHA256 hash on the note and when publishing keep sending the file to some file hosting server (as done today).
The file host will be gone one day, hopefully some other server will have the same hash.
SHA256 is not enough? Just use a tag like file:sha256:blablablabla and you now support better hashes in the future.
Nostr isn't about blockchain nor a crazy fear of losing data. It is intended for sharing notes that someone, somewhere might have interest to piece back together in a few centuries from now.
Maybe time for a NIP on this topic?
If we don't want a global scope for blob sharing maybe the relay only responds if we are friends/members of the relay.
I think the main difference is that in IPFS the content ids (equivalent to torrent hashes) support multiple encodings, etc, and peer connections are more flexible than bittorrent "nodes" in their addressing - i.e. multiple protocols/transports, etc.
> First, I want a replication strategy. Nostr messages get lost in time, and many of the clients end up just blasting an entire message history at your client. Because there's no clue in the protocol how messages are related other than a timestamp this also means you can fake timestamps and write fake messages in the future or back in time
You can do this with email or git too and it doesn't make it any less useful. I actually like the backdating feature as it allows you to copy your account to a new key.
As for replication, at damus I am working on https://github.com/damus-io/nostrdb which is intended to be a "sqlite for nostr". I plan on implementing set-reconciliation based syncing with strfry relays (using a technique called negentropy), so that replication is very efficient.
> Second, I don't like that many Nostr clients are using the same signing key for messages as they do for lightning transactions.
This is simply not true.
> Third, someone needs to delete some of these NIPS. The arms race to make Nostr as complex and difficult as possible to implement is not going to do much for the ecosystem in the long run. In the beginning Nostr was simple to implement from scratch, they should get back to that!
All nips are optional except for nip01, you can ignore them all for the most part.
> Fourth, it needs a dedicated blob store protocol. Yah, I know IPFS isn't great but someone should come up with something that is simple and works.
It does not, in the same way email or git or any text-based protocol doesn't need a dedicated blob store. These are separate concerns and they should be a separate protocol. nostr clients can of course integrate and link to any blob store it wants via new NIPs that describe this. I believe there are a few already in the nips repo.
Cheers!
> This is simply not true.
I'm sorry if I'm wrong about this one. How does it work?
I guess I assumed it was based on the private key you generated when you got started on Nostr and if that private key became compromised then the Zaps could go to whoever had the private key.
Perhaps there is a document somewhere that explains this.
The basic idea is that a lightning node will detect when the invoice with a nostr note inside is paid, and then send the receipt to nostr as a nostr note, with the original bolt11 invoice inside with the signature from the user who sent the zap.
It's all described by NIP-57, a spec I put together to support this:
https://github.com/nostr-protocol/nips/blob/master/57.md
I was working on c-lightning at the time and I thought it would be really cool to replace the "like" button with an instant bitcoin micro-payment. I think it worked out quite well! There are many sites utilizing zaps in all aspects of the protocol, such as a decentralized market for AI job requests (data vending machines), zapgoals and zap fundraisers. All built on this note type. protocol synergy!
I guess what confused me is I've used Nostr clients where everyone has a Zap button. Who is holding onto those lighting receive addresses until they specify where they want the funds to go?
Like if someone Zaps me right now, I haven't specified a place for those Zaps to go. Do I call the Damus staff and they send the total of the micropayments Zapped to me over Nostr to a Bitcoin receive address? I don't think anyone has Zapped me, I'm just trying to wrap my mind around how it works since I was wrong earlier.
Maybe I need to set aside an afternoon and read about how Lighting works, perhaps I just don't get that protocol.
then you can't be zapped
you can only be zapped if your profile has a tag in it that tells people where to send your zaps to
without that, a zap button shouldn't show up, and if it does show up, it shouldn't do anything
I didn't realize every single person who downloads a zap-supporting client had to also set up a separate app to handle the micro-transactions and host that app somewhere where it is available 24/7 in case their post gets zapped.
Haha, like Nostradamus, very clever name!
That remembers me off project.ioni.st and now iam sad.
> You can do this with email or git too and it doesn't make it any less useful.
In the sense that you can fake timestamps, you're of course correct on git and anything else beyond public blockchains.
In the other sen, git is a counter-example of what I take the author's main point to be, in that commits do have an mandated relationship and linkage that Nostr noted don't.
1) With regard to message replication/ordering, the relays are supposed to reject messages that are received with a timestamp that deviates from the server clock beyond some max delta, but it's not clear they always do this. Nostr in its current state (multiple relays hosting everything and letting clients sort it out) is optimizing for redundancy over efficiency — as the ecosystem matures I think this will get sorted out. I have one idea in particular that I think could really help, but it's beyond the scope of this comment.
2) In the very early days you had to copy/paste your key into some clients, but this is not the case anymore. There are several web extensions now that hold your key securely and expose a limited interface for clients to sign messages.
3) You're right - there are too many NIPS (that's "nostr implementation possibility" for those unaware). But fortunately the only required NIP is NIP-01 which is basically just a standard for how to sign and exchange json between clients and relays. I don't think any client implements all the NIPs. In fact, there has been a lot of talk on nostr about 'microapps' (apps that specialize in a narrow use case) and that's fine — maybe because nostr was birthed in the context of being a Twitter alternative we've been thinking that all clients need to support the whole protocol, but I don't really think it will turn out that way. Since all apps are interoperable with a shared user identity, it's possible for clients to be complementary to each other in a way that hasn't previously been incentivized.
4) Regrading blob storage — that's what NIP-94 was created for. You can in principle create a "file" message containing whatever metadata you want. This can be a torrent magnet link or IPFS cid or whatever.
For what it's worth, I've personally never had as much coding anything than I have working on nostr. There's a core group of people that are very excited about this, and it's really motivating to get immediate feedback every time I push an update. No doubt the whole thing is very messy compared to a corporate-sponsored project like (for example) Bluesky. My bias is toward ecological systems tending to win in the long term. We'll find out.
I believe Nostr is doing way better than Bluesky at achieving the goal of being a distributed social network.
If everyone cares about privacy then privacy focused places ought to be full of on average smart people having intelligent conversations. If few people feel the need to bother you end of serving largely the paranoid and the odious and this can easily be a self re-enforcing trend as bad drives out the good.
I feel like the space could use some innovation if its produce communities worth attending to without strong centralized moderation. Instead of bubbling up the top 100 things the community as a whole thinks are worth reading or the top 100 things that someone thinks I might be willing to engage with including 60 things selected because they are liable to make me angry or succeed in wasting my time why not have a personalized analysis done on MY side or on a computer I rent to pull in 10,000 things and figure out which 100 I actually want to engage with based on my own aims not advertisers.
I would probably pay for that especially if it could be plugged into a lot of common platforms to filter out the crap.
Maybe running a local spam filter on one of these decentralized platforms is the way to go. I wouldn't mind running LLMs and removing all the content from Trump crime family fans. Would be nice to detect and reject LLM-generated adtech bullshit while we are at it.
> Second, I don't like that many Nostr clients are using the same signing key for messages as they do for lightning transactions.
> Fourth, it needs a dedicated blob store protocol.
You should make some Nostr Improvement Proposals
> First, I want a replication strategy.
xx Network has message replication built in.
> Third, someone needs to delete some of these NIPS.
xx Network lets you delete messages.
> Fourth, it needs a dedicated blob store protocol.
For blobs, clients should be able to plug in to any 3rd party blob storage (e.g. Crust Network). This secondary storage is needed only for large attachments and isn't strictly required in messaging. If you think about it, you could upload large attachments anywhere and send links in messages. Look how Teams or Outlook work with One Drive.
Some web apps auto-create a new ID and join the network every time you use them.
Also, the signal to noise ratio is really bad with a lot of spam and almost all discussions related in some way to crypto.
Nostr has potential as a technology but the current demographic is basically a social network full of crypto fans.
Nostr and services like it have a place but they are not going to replace services that have meaningful anti-spam.
Talk to anyone who tried running their own private mailserver. SMTP is a decentralized open and very simple protocol - yet that doesn't address the issues that keep people away from hosting their own mailservers.
My SpamAssasin 10 years ago would flag too many legitimate emails... while allowing genuine spam. The amount of crap I would get to my personal email was so bad, that I just switched to GMail for the simplicity.
It's just not worth the effort. Like it's just not worth the effort in investing into a decentralized social network at this point.
Maybe if the spam filtering protocols were public, trainable on all of the data(which isn't going to happen on a privacy focused network, ever), objectively efficient at catching spam... and runnable on even RaspberryPi 3 - you're just going to get spammed out of existence.
This is also why I suspect people are generally nicer and happier on nostr, there is much less fighting because there is no algorithm that boosts angry and controversial threads.
not to say algorithms can't happen on nostr, there just aren't many in clients yet.
Additionally, I tried a few clients, they were a bit buggy and far from anything anyone would take seriously for more than a minute. Key portability was broken on them as well for some reason I don't even want to invest my time investigating.
These decentralised solutions need to distance themselves from cryptocurrency (or at least make it in the background rather than the center of discussion and operations) to be taken seriously.
I see Radicle[1] did that by distancing the version control software from the cryptocurrency, and I think it was a good decision.
If you're just using free relays you will get inundated with spam.
I was running an open relay for awhile and closed it up because of this.
(Lightning is the magic lubricant that makes Nostr so promising).
As one of the largest accounts on nostr I can say there aren't many "crypto" fans on the network, those are all on farcaster. Lots of bitcoiners and freedom lovers though! Maybe try following #grownostr, there is lots of non-"crypto" content, mostly gardening, homesteading, etc.
You have to curate your feed to see the things you want by following specific people. There are no algorithms that automatically tailor the feed to your interests. If you go into the "global" or "universe" feed you will see lots of crap, but that is just noise that can be filtered out by setting your global feed to only show paid relays.
It is also true that there is spam. But it is avoidable. Spam lives in the general feed and in replies. You can configure clients to ignore the general feed, only show posts of people you follow (and maybe of people they follow). If you want to meet new people, then use relays that filter spam. You have choices of how to solve this; nostr is about putting the decisions in your hands.
I have not seen any client that creates a new ID. I've always imported my key and used my same ID from day one.
But you are 100% that the community is heavily slanted towards bitcoin enthusiasts.
And tada! You have centralization... Because filtering spam is a very complex operation.
[0] https://datum.alwaysdata.net/?explorer_view=quest&quest_id=q...
Which leads to the same issue as Bitcoin, Git and other open services - costs of managing are so high, that there's going to be monopolization in the hands of the one that can attract the most resources... and even when the financial costs aren't high(hosting Git or a mailserver on your home router/server/NAS is not expensive), the time costs start to take a toll.
There's going to be a mental barrier to these things - paying $9 per month for a managed Mastodon instance is mentally way too much. I pay for Google One, to not think about storage and mail management... and get many perks with it.
everything is an event. events are signed using pki so it’s easy to know who sent the event and it’s authentic. they’re human readable json objects. events flow over websockets so it’s “real time”. you can build literally anything on this platform - listen for a type of event, do something, emit another. it can all interoperable. we started with basic twitter clones but are rapidly moving into uncharted territory - people are building music distribution apps, ai agents, and so on. and the entire ecosystem has native, programmatic payments built on bitcoin’s lightning network.
Ethereum had an unfair issuance. That means the founders kept a pool of coins for themselves and have unfair control of the network, furthered by PoS.
Ethereum is effectively a private tech company led by a CEO. They have a public roadmap.
Ultimately I think these fundamental properties of Ethereum make it inadequate as a permission-less money protocol. It works great for games and apps, but its foundations are susceptible to coercion and control - and you can’t build a permission-less protocol on that foundation.
[0] https://cointelegraph.com/news/51-of-ethereum-blocks-are-now...
This is incorrect, and your reference doesn't back the statement up.
Validators don't have to include any transaction they don't want to, just like Bitcoin mining pools don't have to either.
The link I provided shows this coercion via OFAC compliance.
Technically you can still obtain 32 ETH on the market, permissionlessly set up your own beacon-, validator- and execution clients and wait until it's your go to send out txes.
On the theoretical side, I'd argue that bitcoin PoW is the best choice because it is more resistant to malicious actors. Assuming that a solution to the botting issue requires a small proof-of-work or fee to post, on a PoW chain malicious actors would need to control a large amount of energy inflow and hash power to support their botting operation. Whereas on a PoS chain, they simply needs a large pool of capital to be staked, which would give returns that can support their operation. This means that the attack vector is larger on a PoS chain than a PoW chain. This is also why the nostr protocol itself has a proof-of-work component. It's the simplest solution to two-generals problem.
I understand your excitement, but your elevator pitch fails to tell me why I should even look at it.
Posting your pitch on a technical public forum should have a random critically minded technical person in mind.
If everything is an event, and you can send any types of events, then you can trivially saturate the network, the clients, and the relays with bogus events.
> but are rapidly moving into uncharted territory - people are building music distribution apps, ai agents, and so on.
None of this is uncharted territory. Uncharted for Nostr, maybe. But time and again anything that comes out of crypto shows that people building this stuff have literally zero knowledge of what has been there in the real world before them.
Yes, including "we send events, and listen to them". Kafka alone is 12 years old this year.
It’s uncharted in the protocol. The protocol has nothing to with crypto other than 1) it depends on cryptography and 2) there is an event type that cares about bitcoin lightning payment receipts.
Here's what I said, verbatim: "then you can trivially saturate the network, the clients, and the relays with bogus events."
What are you arguing against?
Explain to me how you trivially saturate this protocol. That’s like saying you can trivially saturate TCP/IP by broadcasting packets.
Even if they don't accept your events, you can still trivially saturate their bandwidth and processing.
> Explain to me how you trivially saturate this protocol.
Explain to me why you keep pretending I said anything about saturating the protocol
> That’s like saying you can trivially saturate TCP/IP by broadcasting packets.
And yet DDOS exists. Things like TCP tuning to avoid network congestion exist.
I agree this is a problem. However, there is at least one protocol addition (that doesn't involve cryptocurrency per se, although it shares some ideas) that tries to address this: proof-of-work requirements.
The idea is basically this: message IDs are SHA256 hashes of message contents. If you add a nonce to the message metadata, then each time you change the nonce, you'll get a different SHA256. Relays can then choose to ignore messages without a particular number of leading zeroes in the event ID. This means a client will have to do a non-trivial amount of computation to generate an event ID that a particular relay will accept.
> None of this is uncharted territory. Uncharted for Nostr, maybe. But time and again anything that comes out of crypto shows that people building this stuff have literally zero knowledge of what has been there in the real world before them.
I mean, I think it's a direction for social media that hasn't been tried yet on a wide scale. Personally, I look at it as a cool idea- I don't know if it'll actually pan out in the long run, but I think it addresses a bunch of problems with both centralized and federated social media, so it's worth seeing what can be done.
On the other hand, I think it's reasonable to note that individual relays could very well change their proof-of-work requirement over time to deal with network conditions. Because clients are expected to send events to as many relays as possible, it's not unreasonable to suppose that a client's message might very well make it through _somewhere_, even if a particular relay won't accept their message at a particular moment. Clients can always try again later.
I think it's also worth treating PoW as part of a "swiss cheese model" for managing abuse. There are layers in front of it (since the protocol uses WebSockets, all your standard DDOS protections can sit in front) as well as behind it (blacklisting or throttling pubkeys you don't know very well.)
One example that comes to mind is another protocol extension which provides a mechanism for client authentication, where a server can send a challenge string, in which case the client is expected to respond with a special event type which includes that same challenge string. Requiring a much higher proof-of-work requirement for this message type (and then accepting a lower PoW for messages sent afterwards on the same connection) is at least one idea of a scheme for mitigating spam.
---
For what it's worth, I wouldn't say I'm a True Believer at this stage of the game, but I find the whole thing pretty compelling, and at the very least it's something fun to hack on and experiment with.
What direction? Building music distribution and ai agents? Or building a social network that literally relies on trusted servers (that you're even expected to pay for) to function?
what problem does this solve? how many people are publishing events (tweets) that are inauthentic? you need to be logged in via password + 2fa on twitter to post. if somebody can post from your twitter account on your behalf, they are logged in as you. i don't see how "PKI" on top fixes that?
The messages contain your pubkey so others know who sent it. Your messages are signed so others know they came from you.
If you don’t do that, as soon as it becomes popular enough to attract scammers you’re going to have Mallory publishing keys with Bob’s name on them and a million random people who have incredible financial opportunities for you. Most of the decentralized systems shift that problem to another system like email or DNS, Facebook/Twitter/GitHub/etc. at which point it’s worth asking whether there’s still value in decentralization at that point.
The only trust a 3rd party like Twitter demands in your example is that I trust they won't impersonate my account with a message (since there's no private/public key proof)
But your system doesn't address that either. After all, what's stopping _anyone_ from just saying they're me and sending out messages?
Like 99% of decentralized usecases, this still falls down to trying to cheat the oracle problem. I actually trust Facebook and Twitter more in this situation because they can at least demand verification in the real world, they've got enough social capital that they can overcome the oracle problem in limited contexts.
You are correct - it allows consumers to know the message has not been tampered.
The downside of your trust model is permission. Facebook and Twitter may revoke your permission to use “your” identity at any time, for any reason.
Requiring ID verification for a rented online identity is a terrible trend imo. These companies are not to be trusted - they exploit users and inevitably sell your data or get breached.
A tweet is not a direct message, it's a broadcast message.
Without a centralized 3rd party mapping names to public keys, the identity of the sender can be set to whatever you want.
Your model only works for non-tweets where I'm sending to people I had communication with in the past and was able to verify a public key... at which point you're just providing E2E encryption with worse ergonomics and no new value prop.
—
You cannot cheat the oracle problem. There is no magic bullet that lets you broadcast messages with known identifies without a centralized 3rd party.
- Sharing keys in person
- Sharing keys via other channels like Twitter
- Via DNS using NIP-05
> Without a centralized 3rd party mapping names to public keys
Sharing in person doesn't work for broadcasting
Other channels require falling back to some non-decentralized system.
Again, it's the oracle problem. You can't say it's not true, that's like saying "1+1=2" is not true.
That's where PKI comes into play: it's not layered on top of a login system, it's a complete replacement.
Pretty much everyone, because Twitter doesn't provide a way to tell a tweet written by a user from a tweet written by someone that controls/works at Twitter.
On nostr if a relay or even client decides to ban you from posting you can just post from another client to another relay using the same identity.
my favorite part about that last one is the possibility of social key revocation - if you're in a community misbehaving, the same people you trust to save key fragments in case you lose your private key can conspire against you to lock you out of your account, a kind of cryptographic ban hammer.
KERI sounds interesting, I’ll read up on that. Maybe you can review that PR and share some insights?
Yeah, this is why mobile computing is owned by Apple and Google.
> Edit: Please note that I changed my Nostr public key identity. My last private key was compromised, likely from using it to log into a web client last month.
The theory is cool, it makes sense, you have your identity tied to your Bitcoin public key.
But it just seems unnecessary to focus on this particular bit of the technology, when the human relationships via something like Mastodon and federation seem to be just fine.
Then the porn took over.
Uhm, where did you see that?
Don’t like bitcoin? Cool, don’t click the button. That’s literally all there is to it.
Android also has a great client, Amethyst: https://github.com/vitorpamplona/amethyst
Gossip is a cool rust desktop client: https://github.com/mikedilger/gossip
Strfry is used by most of the large relays: https://github.com/hoytech/strfry Doug Hoyte is a wizard.
So while that may put some people off, there is non-crypto related communication, and the "crypto dominance" will decrease over time.
The same goes for NIP-52 [Calendar Events] and NIP-99 [Classified Listings]. Neither of those are "inherently baked into the network".
That seems like an area that needs work before the other 90% of the world can use Nostr securely.
Nostr has moved quite a bit since this article was written. The most obvious being that it says to try Damus from test flight (it went GA like half a year ago).
Personally, I don't want Twitter with pki. I don't want Twitter at all. I really hope Nostr keeps it cozy but hey, at least you'll get to personally choose your algorithm.
[0]: https://maggieappleton.com/cozy-web
[1]: https://primal.net has a great start
1. The serialization and canonization of JSON. Fortunately the conversion to arrays without floating point numbers avoids the problem with digitally signing the canonized JSON, but this is still messy. There are other problems with using JSON too, including inefficient binary data, restriction of which character sets you can use, lack of proper 64-bit integers, and others. I preferred a efficient binary format instead.
2. Servers cannot send messages to each other. I would allow it as an optional capability, in addition to clients sending messages to multiple servers.
3. It should not need WebSockets; plain TCP (with optional TLS; it should not be mandatory) would do. Other optional protocols can also be possible to do, e.g. HTTP POST requests, or even HTTP GET (or Gemini) to merely receive a single message by its ID. (WebSockets in binary mode could also still work.)
4. Character encoding. Unicode is too messy as well as other problems. My proposal is you can specify what code page to use, including an extended TRON code (including ISO-IR-169, Cangjie, and others). A few control codes might be used, e.g. line break, furigana, and text direction; for simplicity you might not need much more than that I suppose.
5. Lost messages. Blockchaining (i.e. each message contains the hash of the previous message) might help a bit, but still sometimes you will have lost one, or an entire account is lost without anyone else referencing them. Making this mandatory comes with many problems, but being optional also has different problems, so it is unclear.
6. Some other stuff, too (I do not remember all of them at this time).
I had tried to design a better one, but I did not know what to call it so I just reversed "nostr" to make "rtson", but that doesn't seems like very good either. (Although, maybe is not needed; NNTP is good enough anyways.)
I also started a nostr-like protocol back in November 2022 based on my gripes with it. Then I came to my senses... nobody is going to use my variant. Perfection is the enemy of the good.
Then, how are you supposed to know how to do if it is not specified?
> 3. Websockets allows pub-sub. Clients stay connected to relays and instantly get the next message when it arrives. Polling means either lots of polling or having delays.
You can remain connected even with plain TCP (or with TLS) too. But, if you only want to send or receive a single message (rather than waiting as new messages arrive), then HTTP would also do.
> I also started a nostr-like protocol back in November 2022 based on my gripes with it.
Do you have the document?
How is "your messages can be in any coding on earth" simple compared to "everything is unicode, and every single programming language, storage solution and client library has been unicode-aware for at least a decade now"?
In practice though, the only two topics covered on Nostr are a) nostr, b) bitcoin and how stupid non bitcoin believers are.
Good demo that technology is only a portion of success.
I wish, but I think this is completely wrong. Support for freedom of speech is at an all-time low and continues to drop. Frankly if it didn't already exist I don't think you could even get the postal service off the ground these days, with its completely uncensored communication.
New content moderation system for Nostr - https://news.ycombinator.com/item?id=37343373 - Aug 2023 (2 comments)
Social Media is broken. Can we fix it [with nostr]? - https://news.ycombinator.com/item?id=36698217 - July 2023 (1 comment)
How to verify your domain on Nostr and Bluesky (for micro.blog users) - https://news.ycombinator.com/item?id=36646598 - July 2023 (40 comments)
Show HN: Zapddit – a Reddit-style open-source client for nostr - https://news.ycombinator.com/item?id=36326468 - June 2023 (1 comment)
Show HN: Agora – Follow your favorite topics across Nostr, Bluesky, and Mastodon - https://news.ycombinator.com/item?id=36210443 - June 2023 (3 comments)
Nostr – Decentralized social network - https://news.ycombinator.com/item?id=35773168 - May 2023 (164 comments)
Nostr (“Notes and Other Stuff Transmitted by Relays”) – An Introduction - https://news.ycombinator.com/item?id=35690659 - April 2023 (141 comments)
Decentralized Twitter Alternatives Bluesky and Nostr Experience Growing Pains - https://news.ycombinator.com/item?id=35673764 - April 2023 (5 comments)
Jack Dorsey has set a 10 btc bounty for Nostr based alternative to GitHub - https://news.ycombinator.com/item?id=35020964 - March 2023 (127 comments)
Mostr: A Fediverse Nostr Bridge - https://news.ycombinator.com/item?id=34999118 - March 2023 (3 comments)
A decentralized social network with a chance of working - https://news.ycombinator.com/item?id=34937223 - Feb 2023 (9 comments)
Nostr, Love at First Sight - https://news.ycombinator.com/item?id=34901659 - Feb 2023 (1 comment)
Blogstack.io: blogging on nostr with lightning tips - https://news.ycombinator.com/item?id=34850871 - Feb 2023 (1 comment)
Set up a Nostr Relay server in under 5 minutes - https://news.ycombinator.com/item?id=34697020 - Feb 2023 (1 comment)
Nostr.how – A Complete Guide to Nostr - https://news.ycombinator.com/item?id=34656925 - Feb 2023 (135 comments)
What do y’all think about Nostr? - https://news.ycombinator.com/item?id=34535910 - Jan 2023 (2 comments)
Nostr: Notes and Other Stuff Transmitted by Relays - https://news.ycombinator.com/item?id=34526562 - Jan 2023 (154 comments)
Snowden on the Lightning Network on Nostr - https://news.ycombinator.com/item?id=34507443 - Jan 2023 (91 comments)
Edward Snowden Joins Nostr - https://news.ycombinator.com/item?id=34503748 - Jan 2023 (21 comments)
Move over Mastodon, here comes Nostr (and to set up your NIP-05 id) - https://news.ycombinator.com/item?id=34442708 - Jan 2023 (1 comment)
A Map of Nostr Relays - https://news.ycombinator.com/item?id=34408692 - Jan 2023 (2 comments)
Awesome Nostr - https://news.ycombinator.com/item?id=34406773 - Jan 2023 (2 comments)
Nostr Is the Decentralized Protocol That Might Replace Twitter - https://news.ycombinator.com/item?id=34174724 - Dec 2022 (5 comments)
Coracle – a web client for the Nostr protocol - https://news.ycombinator.com/item?id=34144111 - Dec 2022 (2 comments)
How to Start Using Nostr? - https://news.ycombinator.com/item?id=34090375 - Dec 2022 (1 comment)
Check Out the Nostr Protocol - https://news.ycombinator.com/item?id=34068676 - Dec 2022 (2 comments)
Jack Dorsey donates to develop decentralized social network protocol [pdf] - https://news.ycombinator.com/item?id=34002218 - Dec 2022 (9 comments)
Nostr is a stupid simple P2P protocol that works, built by builders - https://news.ycombinator.com/item?id=33746360 - Nov 2022 (128 comments)
Nostr Protocol - https://news.ycombinator.com/item?id=31717981 - June 2022 (9 comments)
Jester: Chess over Nostr - https://news.ycombinator.com/item?id=31580536 - June 2022 (1 comment)
Fiatjaf/nostr – a censorship-resistant alternative to Twitter - https://news.ycombinator.com/item?id=29749061 - Dec 2021 (138 comments)
Nostr – The final solution to Twitter censorship as an open protocol, not P2P - https://news.ycombinator.com/item?id=25104364 - Nov 2020 (6 comments)
I originally published this article in Jan '23. Since then, we've seen a lot of development around both the protocol and applications (much of which has been well documented here by jb55 and others). Twitter-like clients such as Damus and Amethyst have gotten much better and new clients like primal (primal.net) have emerged with their own takes on features like caching and algorithms. Nostr Wallet Connect made it substantially easier to connect a Lightning wallet with a Nostr client for one tap zapping, radically simplifying the payment experience for end users.
I'm personally most excited to see several early examples of applications that move beyond social media and show Nostr for what it is - a generalized data protocol. Almost any app would benefit from a persistent identity and portable data shared with other apps. Here are a few live examples:
- Long tail of edge AI services - pablof7z and several others are piloting a new construct called "data vending machines (DVMs)" which allow users to publish job requests to the nostr network and other users (or bots) to compete to fulfill those requests. We're already seeing early markets for fine tuned open source models completing services like voice-to-text transcription or image generation. Even cooler, each of these DVMs is chainable, so the output of one DVM can be the input of another. See https://vendata.io for example. This recent hackathon had a few cool dvm projects as well: https://bolt.fun/tournaments/ai4all/overview
- Music - Stemstr (stemstr.app) is a Nostr native app for creating and remixing music. Wavlake (wavlake.com) is a music streaming service with Lightning zaps, which recently integrated Nostr login.
- Text annotation - https://highlighter.com allows users to collaboratively highlight text (think rapgenius on Nostr). You can even collaboratively highlight this very thread if you like!
- Marketplaces - bids and asks are messages which can be published over Nostr, allowing multiple marketplace front ends to share a common order book or liquidity. We've already seen a few pocs for building Nostr based marketplaces such as: github.com/lnbits/nostrmarket github.com/supertestnet/superstore
- Nostr browser - an early version of Spring, a nostr browser, recently launched to experiment with hosting various microapps in one interface: github.com/nostrband/nostr-universe/
This list is just the tip of the iceberg, but hopefully it gives a good overview of Nostr's potential. I've invested in a number of these projects already and remain committed to funding many more hackers exploring Nostr in the coming months!
There's a lot of effort going on in the EU to enable international, decentralized identity that can be recognized by every country. The first thing they decided was that DIDs on the blockchain are a terrible idea. GDPR demands that personal information must be protected, but having your DID in a blockchain forever, for all to see every transaction your DID ever performs, goes completely against that. It's one of those ideas that doesn't pass even 5 minutes of light consideration when you actually understand the implications.
However, DIDs are not tied in any way to blockchains, so they're still a good idea, just the ideal implementation needs to be found yet.
There may be use cases where a DID tied to a verifiable history is a feature (particularly for organisations as opposed to individuals), but for most people having it linked to a blockchain is definitely not the way forward. Also, blockchains and associated protocols can become defunct, or dwindle in usage until a 51% takeover of the remainder is feasible, or many other things.
I imagine that in the end, a DID will be a private/public keypair wrapped in some hardware that the average person can use.
Here's another less terrible one: Public certificates of ID issuers are what's stored on-chain. Individual users have their (potentially locally generated) DIDs cross-signed by an issuer. The only data being stored on-chain is issuer certificates (and potentially further signatures and metadata around them) and this makes it possible to run the whole scheme in a more decentralized fashion.
Meanwhile, nostr built a system people actually use on top of open protocols. No tokens, no blockchains. Only notes and other stuff transmitted over relays.
even if I ignore two things above, I don't want to use any new comm. protocols. to me, what we have now is good enough™.