I tried Nostr for awhile, and I appreciate that they're picking up where Scuttlebot left off. There are a few things that bug me about it that I wish they'd fix, or that some future protocol will solve.
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.
Hey, author of https://damus.io here (ios twitter-like nostr client)
> 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.
> > 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.
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.
Zaps just put a signed nostr note inside a lightning invoice so that clients can show that a specific user send some amount of money to some note or profile. clients request lightning invoices via lnurl (an http lightning specification). You could do the same thing for any other fiat or crypto system if you want to, but nostr was mainly build by bitcoiners which is why there is lots of bitcoin tech integrated, but its completely optional.
How do you request your Zaps balance to send it somewhere else (like to a Bitcoin wallet)? Maybe this is a Lightning thing and not a Nostr thing.
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.
There is no "zaps balance". Zaps are just receipts of lightning payments.
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:
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.
Ok, this makes sense. I must have been using a client that had 'Zap' icons and because I didn't have a Zap balance I just assumed the buttons didn't work because I had no balance.
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.
IPFS is so heavy and unperformant, just not a lot of bang for your buck when paying for a host. As far as I can tell it owes its success to VC funded blockchain startups subsidizing hosts with 8:1 payouts for hosting other peoples' stuff
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
I like the idea of anonymity, and have done implementations of anonymous services - ones that are public and live now. I wouldn't do it for money unless i was somehow indemnified against fault and damages. In my measured opinion, it is too risky to allow unfettered anonymous uploads, even strictly financially.
If you use bitcoin you can make services that provide value and get paid for those online without any identity involved.
That's the main value. That said it's a bit complicated to use bitcoin in a truly anonymous way without connecting identity to it at any point.
(not the OP:) Sure I could host your content without knowing who you are, the issue is hiding my own identity when I'm found to be hosting illicit content, this issue is then multiplied when I'm taking payment and trying to offramp those funds to pay my bills.
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)
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.
We have the same idea, a sha256 is all you need to construct a magnet link and start peering, my suggestion is for a nostr client to support this use case and webtorrent to replace the hash with the embedded file on the front end. not to make any change to the protocol.
so long it remains as standardized hash. The problem with torrent hashes is that it remains specific to torrents. Most common scenario are volunteers setting up large storage space that indexes all files according to SHA256 where anyone can regenerate those hashes again easily if needed.
Isnt IPFS effectively the same thing as trackerless torrents? i.e. its a DHT for registration and lookup of distributed resources where segments can be downloaded from multiple sources in parallel.
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.
So I've been building of one of the nostr web clients ( https://satellite.earth ) full time since December last year - I agree partially with all these points and will try to add something from my perspective of being perhaps a bit too close to this.
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 checked out a community that on the tin is about learning coding and found Trumpers, bigots and antivaxxers. It reminded me of pro free speech fork of Reddit. It wasn't a bad idea AT ALL on the face of it but in practice its front page was never without a racial slur and no decent people stayed long.
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.
Social media is crawling with the bigoted anti-reality Trumper crowd. There are plenty here as well.
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.
> 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.
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.
> nostr is stateless it’s just a streaming protocol for 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.
Some relays try to store messages for as long as possible (aside from cleaning up some really large spammy ones), some others keep a certain number of messages.
There are some relays that have no storage at all, they only relay messages between connected clients and then discard the messages.
In other words, Nostr can't do almost anything that matters.
> 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.
The number of users is almost irrelevant in the context of Nostr because many clients generate a new ID. These aren't email-verified/phone-verified users -- this is literally just a new key/ID being generated.
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.
That was my experience as well, just constant crypto spam and all the other kinds of posts or tags are very inactive.
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.
It is always fascinating reading VC hit pieces like these to see just how many leaps of faith they must make and bags of salt they must eat to justify their investments the way they do. With the benefit of hindsight, Sequoia waxing lyrical about world's first trillioniare remains the best example among them all.
And even then most of the discussion are very shallow compared to crypto twitter. I can't understand why. I would've thought since it's early adopters, discussion inside a tightly knit group would be more meaningful... alas
I guessing this is because you are used to an algorithm that is constantly showing you the most liked content. average day to day discussions between humans can be pretty shallow, nostr feels more like shooting the shit with your friends instead pumping rage bait and dopamine into you brain 24/7
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.
Meaningful ant-spam is resource heavy operation. Maybe if AI models are portable/accessible enough to run on a small system - we'd reduce the amount of manual work required...
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.
Anti-spam is one of those things that get very overblown when a lot of it can be quite easily solved. Simple bayesian spam filtering annihilates most spam.
> Talk to anyone who tried running their own private mailserver
I run a mailserver and spam is actually not a big issue for me at all. Blocking hosts with no rDNS, residential IPs and no dkim already blocks all the spammers who simply scan all the IP addresses and rspamd kills the rest. Granted, I don't post my email publicly on linkedin or other but I get no spam in my inbox.
Sorry, it's not. Modern spam filtering requires a lot of training data. Most spam that I would get - would easily bypass any small scale spam filtering operation.
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.
Correct user counts need to have a web-of-trust applied if you want an accurate count of "real followers", but I suspect that's the same on X as well.
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 true anybody (or bot) can spin up new identites so the count of pubkeys doesn't say much.
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.
For all the talk about nostr, I recently discovered it's actually a tenth of the size of mastodon[0].
The hype-to-actual-activity is through the rough with this one.
Getting an account setup is unfortunately a challenge.
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.
i never hear of nostr before and i use mastodon for while, and twitter debacle was critical, 200000 active users is lots of people from this type of non comercial céntric products.
edit: i check few nostr people and the public is quite different between the two platforms, that doesn't invalidate what i say but explain my lack of engagement in the platform
Yeah, Nostr is quite new compared to Mastodon. The clients became usable just this year. I posted my first note on Nostr in Dec 2021 and that was literally just days after the first web client allowed posting. Mastodon has been there at least since 2016.
as a dev and nostr user, here’s my elevator pitch:
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.
> events are signed using pki so it’s easy to know who sent the event and it’s authentic.
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 problem is that network architecture of Nostr is different from Twitter (and from Mastodon, for that matter). One of the core ideas of the Nostr protocol is getting rid of the idea of "logging in" or "creating an account" on any given relay, and as such it needs some way to reliably identify which posts were made by a particular user.
That's where PKI comes into play: it's not layered on top of a login system, it's a complete replacement.
IMO it would be mobility. It's true that a logged in account can also offer validation but that identity is kept and stored on the provider's database whom in turn can withdraw consent to use that. There is some mobility on Mastodon but it still requires cooperation from the instance administrator.
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.
> how many people are publishing events (tweets) that are inauthentic?
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.
They are ignoring the problem of how do you know the other person's public key. And you don't. That's why people post their public keys on their own websites or on X or whatever - basically, a third-party THEY trust and believe you can trust as well, so yeah, this doesn't remove trust on a third-party as that's impossible.
For any signed message, there is only ONE public key that could have generated that signature. You either know that key, or you don't. The network can either deliver or help you discover the key, or not. That's way different from trusting a third party to not lie to you about authenticity or the source of the message.
How does that work in the context of the whole system where I need to link a key pair to a person? If I know you in real life we can check key fingerprints or something (GPG suggests statistically nobody will) but otherwise I have to trust a third-party who says that the Bob I want to talk to has keys X, Y, and Z.
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.
Nostr is quite open for what options people use to become more trustable. People can pay couple thousand sats to get a verification, or as you say Nostr can also do the same with shifting to web of existing sources of identity.
E.g. it is well known that this Jack is CEO of Strike (strike.me) and so any nostr client can verify that https://snort.social/p/jack@strike.me is trustable, because it serves his public key here: https://strike.me/.well-known/nostr.json
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.
Your system is so poorly secured there is no value in tampering with the message: I can just say I'm you and tweet.
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.
I love the programmatic payments. what's the key rollover story? social key recovery? IMO these are table stakes for PKI to reach the general public. There's a technology called KERI (key event receipt infrastructure) that I'm bullish on, has to do with signing new keys with the old, with witnesses, with configurable threshold cryptography (m-of-n key reconstruction)
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.
> listen for a type of event, do something, emit another.
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.
> 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.
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.
I don't think there's a trivial amount of computation people would want to perform that would cost too much for bots to advertise. I don't think people would be willing to wait 20 minutes on their phone to post a comment on a website. Assuming it's SHA256 like Bitcoin, from this video [1] a Samsung S22 Ultra does 400Kh/s. On a 6700 XT, the hashrate is 24 MH/s, that is like 50 times faster, or 24 seconds per post. If they use an ASIC it shoots up to the TH level. That's milliseconds. The service would need to be unusable on a phone unless people leased servers to validate their posts on, leading to costs for each post.
Hmm. I hadn't considered that. In my defense, I'm actually not a crypto guy at all, and so I hadn't given much thought to the actual dynamics. And now that I think about it, I don't think I've seen many relays actually implement that particular protocol extension, and this is probably why.
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.
> I think it's a direction for social media that hasn't been tried yet on a wide scale.
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?
The network is a collection of relays and relays are free to permit - or reject - what they want. You can’t saturate a protocol. You can saturate a given relay (server).
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.
You are implying there is a singular network. There are a collection of relays on the internet. Each relay has it’s own business rules and may or may not accept your events. Each client may support some type of events.
Explain to me how you trivially saturate this protocol. That’s like saying you can trivially saturate TCP/IP by broadcasting packets.
IIUC, the nostr communication protocol stands on its own, which should allow you to “bring your own payments” to the mix, or even engage without hooking up any payments till you see a compelling need?
From a theoretical standpoint, this answer could get very long, but the real answer boils down to the creator of the protocol prefers bitcoin.
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.
Proof of work also depends on capital, compute isn't free. In fact, it is already incredibly centralized in the Bitcoin blockchain because there's like 3 big players which have already attacked the Bitcoin Cash blockchain. The only reason these huge pools haven't attacked the Bitcoin blockchain is because they have a financial stake on the price being high, which is also the same incentive proof of stake depends on.
Ethereum’s recent move to Proof of Stake undermines the their ability to be decentralized and permission-less. If a validator adds a blacklisted transaction, they will be slashed [0].
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.
No, your link shows that a majority of validators will not include certain transactions in a block. While problematic in itself, there is nothing around slashing other validators who do so, on their allotted blocks.
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.
I think someone did some monero focused client and relay implementation. Go on and create your own nostr eth implementation. Maybe even try to submit a NIP for this.
> I believe that open and permissionless systems inevitably win over closed competitors because open systems can marshal the collective resources of many more contributors than any individual business can employ.
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.
nostr being an offshoot of crypto/bitcoin tech influences the protocol in important ways, like everything crypto/bitcoin you need to read documentation to understand the terminology being used and you need to 'invest' in the culture, which is bitcoin evangelist culture w/ all the baggage.
I tried it for a bit, and for both content and tech, tying it to Bitcoin seems like -- perhaps not a deal-killer, but mostly pointless and trying to hard.
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.
That is how it is presented; I'm aware that you can probably use it without owning any Bitcoin, but again -- even the Twitter guy is touting that being the point of it.
I was playing around with it a few months ago and set up a relay for fun (https://blog.notmyhostna.me/posts/taking-a-look-at-nostr/). I found it to be a very nice starting point if you want to follow how a protocol is being developed as it's all very transparent, simple and easy to follow here:
I'd like to point out that the apparent "crypto dominance" is mostly due to that group's propensity to be early-adopters of new technology. The apparent crypto spam is actually a good opportunity to squash the bot issue early. Even people "in crypto" hate bots spamming the newest shitcoin.
So while that may put some people off, there is non-crypto related communication, and the "crypto dominance" will decrease over time.
> 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. This is still a very new technology ...
That seems like an area that needs work before the other 90% of the world can use Nostr securely.
Why is an article from December 2022 on the front page of HN?
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).
Nostr's very cool tech and I'm excited to see where it ends up. But I'm not sure it'll make for good social networks/apps that I'll care about. ActivityPub and Matrix get flak on the account portability issue and it's a valid one but it (and their design in general) provide a pressure on their communities to be very "cozy-web"[0] despite the few leviathan instances. Nostr's more than flexible (almost under-specified) that you can build your cozy spaces on top of it but I'm convinced its design allows it to be a real decentralized contender for the big social and I fear that's where its custodians are headed. It won't be long before we see Nostr service providers that replace all the core functionalities of Twitter like a good algorithm and moderation[1].
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.
I had looked at nostr before, and I had some criticisms of it:
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.)
> 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.
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"?
1. I concur. But it's no big deal.
2. Nothing prevents this, but it would be specified as a sister protocol. I haven't seen it specified, but I know that relays are doing it.
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.
4. I can't even comment on this one.
5. Optional chaining is possible and has been proposed.
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.
> 2. Nothing prevents this, but it would be specified as a sister protocol. I haven't seen it specified, but I know that relays are doing it.
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.
I like the concept of Nostr. The technology is not too bad (there's that small issue that you can't change your key so if it ever gets exposed you're done).
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.
My experience with the Nostr atmosphere has been faaar worse than Mastodon.
Data-loss and my timeline being flooded with spam from Crypto fans is prime examples.
People are increasingly aware of the value of free speech and dangers of letting any centralized platform decide what is and is not acceptable to say
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.
Hey everyone, author of the original essay here. Glad to see so much interest in Nostr!
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!
> I believe this idea could integrate with Block’s vision for Web 5, which to the best of my understanding, also anchors Decentralized Identifiers (DIDs) into the Bitcoin blockchain.
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.
No. That's just strawmanning a terrible implementation.
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.
All the degenerate token-fueled web3 hype of 2021 sold a bunch of dreams about decentralization and owning your social graph to unsuspecting retail and then delivered nothing but rugpulls and bankruptcy letters.
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.
To be fair to the Web3 hustlers, they never cared one iota that every 'decentralized app' was either a coin exchange, NFT marketplace or some hideous Pay to Earn abomination passing itself off as a 'game'. They pointed at every one of these snake oil machines and said "here's proof that it's being adopted".
The relationship to Bitcoin makes me nervous, though. I don't understand it, but even the mention of it makes me want to write off the whole protocol because i'm just that averse to crypto, and tried of seeing repeated crypto grifts.
Bitcoin and nostr are completely separate protocols, but they just so happen to have a level of interoperability. You can use either system without ever touching (or caring) about the other.
two things. first, the more you try to convince me about the best thing after sliced bread, the more I doubt it's even a bread. second, anything related to crypto currency should be held in doubt (in the highest order) until proven otherwise.
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™.
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.