Live data from Hacker News

Why I’m betting on Nostr

hivemind.vc

81–90 of 166 posts

Re: Why I’m betting on Nostr

#81
post #58

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…

It did some BTC begging and got a bunch of Sats sent to me via the Lightning network. All in all I made "money" from participating. Then the porn took over.

Why should money be involved when interacting with friends on the internet? I don't think I get it at all.

Re: Why I’m betting on Nostr

#82

Earlier quoted context omitted.

Crypto scammers are the new discount viagra. Nostr and services like it have a place but they are not going to replace services that have meaningful anti-spam.

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.

Re: Why I’m betting on Nostr

#83

Earlier quoted context omitted.

This isn't an elevator pitch, it's a standup line. I understand your excitement, but your elevator pitch fails to tell me why I should even look at it.

Sorry I’ll have ChatGPT write it next time.

Perhaps try and make it compelling to a prospective user next time?

Re: Why I’m betting on Nostr

#84
post #15

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 re…

> First, I want a replication strategy.

> 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

Re: Why I’m betting on Nostr

#85
post #28

Earlier quoted context omitted.

> 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 an…

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?

Re: Why I’m betting on Nostr

#86
post #41
post #28

Earlier quoted context omitted.

> 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 an…

> 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 ha…

> 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?

Re: Why I’m betting on Nostr

#87

Earlier quoted context omitted.

I don't get it. Either I validate who I am when I log in to Twitter, or I validate who I am when I set up my "Nostr" identity?

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

#88
post #33
post #15

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 re…

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 d…

> Hey, author of https://damus.io here (ios twitter-like nostr client)

Haha, like Nostradamus, very clever name!

Re: Why I’m betting on Nostr

#89

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 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 unicode, and every single programming language, storage solution and client library has been unicode-aware for at least a decade now"?

Re: Why I’m betting on Nostr

#90

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 int…

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 h…

> 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.

Do you have the document?

Post reply on HN