Earlier quoted context omitted.
You generate a public/private key pair. When you want to send a message (tweet), you sign it with your private key and broadcast it to relay(s). The messages contain your pubkey so others know who sent it. Your messages are signed so others know they came from you.
How is trusting a third party to deliver you the authentic public keys isn't "trusting a third party"?
Why I’m betting on Nostr
91–100 of 166 posts
Re: Why I’m betting on Nostr
#92I 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 int…
> 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 unico…
Re: Why I’m betting on Nostr
#93Earlier quoted context omitted.
You generate a public/private key pair. When you want to send a message (tweet), you sign it with your private key and broadcast it to relay(s). The messages contain your pubkey so others know who sent it. Your messages are signed so others know they came from you.
How is this any different from sending an event from an account you authenticated from (like an e-mail, or a Twitter account)?
Re: Why I’m betting on Nostr
#94> 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.
Re: Why I’m betting on Nostr
#95Earlier quoted context omitted.
> 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…
> 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 i…
Is this even possible? Won't relays throw away older messages at some point? Or are they supposed to scale infinitely?
Re: Why I’m betting on Nostr
#96I liked the punchline at the end. > 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.
Re: Why I’m betting on Nostr
#97Re: Why I’m betting on Nostr
#98Why 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).
Re: Why I’m betting on Nostr
#99Re: Why I’m betting on Nostr
#100Earlier quoted context omitted.
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 can’t saturate a protocol. You can saturate a given relay (server). 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.