Live data from Hacker News

Why I’m betting on Nostr

hivemind.vc

121–130 of 166 posts

Re: Why I’m betting on Nostr

#121
post #104

Earlier quoted context omitted.

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…

Would be nice to see a well secure alternative to torrent and IPFS so we can just settle and use it. Ideally encrypted and anonymous optionally too.

you can torrent over tor (well, more in theory than in practice)

from my view it's been settled for near 2 decades now, IPFS just gets more press in certain circles

Re: Why I’m betting on Nostr

#122

Earlier quoted context omitted.

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)

Re: Why I’m betting on Nostr

#123
post #89

Earlier quoted context omitted.

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

By experience. For handling multilingual text (and non-multilingual text), Unicode is worse.

How is it worse than juggling every known and unknown encoding?

Re: Why I’m betting on Nostr

#124
post #85

Earlier quoted context omitted.

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

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.

> Each relay has it’s own business rules and may or may not accept your events. Each client may support some type of events.

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.

Re: Why I’m betting on Nostr

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

Re: Why I’m betting on Nostr

#126
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…

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…

Keep it simple.

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.

Re: Why I’m betting on Nostr

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

Re: Why I’m betting on Nostr

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

Re: Why I’m betting on Nostr

#129
post #47

Earlier quoted context omitted.

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

> Perhaps I could write a program that downloads all of the history of Nostr Is this even possible? Won't relays throw away older messages at some point? Or are they supposed to scale infinitely?

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.

Re: Why I’m betting on Nostr

#130
post #127

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

Excellent point.

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.

Post reply on HN