[HN Gopher] Why I'm betting on Nostr
___________________________________________________________________
Why I'm betting on Nostr
Author : jseliger
Score : 126 points
Date : 2023-09-01 15:00 UTC (8 hours ago)
(HTM) web link (hivemind.vc)
(TXT) w3m dump (hivemind.vc)
| Brighthurst wrote:
| 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.
| xigoi wrote:
| Still, cryptocurrency is inherently baked into the network due
| to the "zaps" mechanism.
| zzo38computer wrote:
| 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.)
| troupo wrote:
| > 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"?
| zzo38computer wrote:
| By experience. For handling multilingual text (and non-
| multilingual text), Unicode is worse.
| jimmydoreornot wrote:
| 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.
| zzo38computer wrote:
| > 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?
| dewey wrote:
| 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:
|
| https://github.com/nostr-protocol/nips
| cropcirclbureau wrote:
| 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.
|
| [0]: https://maggieappleton.com/cozy-web
|
| [1]: https://primal.net has a great start
| Arathorn wrote:
| fwiw we're plugging away at acct portability in Matrix via
| MSC4014, which is even implemented in the Dendrite server impl
| now...
| jrm4 wrote:
| 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.
| zikduruqe wrote:
| 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.
| izzydata wrote:
| Why should money be involved when interacting with friends on
| the internet? I don't think I get it at all.
| dang wrote:
| Related. Others?
|
| _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)
| clarkmoody wrote:
| 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.
| [deleted]
| rchaud wrote:
| 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".
| unshavedyak wrote:
| 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.
| clarkmoody wrote:
| 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.
| jron wrote:
| Damus has come a long way since this article was written.
|
| 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.
| spraveenitpro wrote:
| [dead]
| dekervin wrote:
| 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.
|
| [0]
| https://datum.alwaysdata.net/?explorer_view=quest&quest_id=q...
| azangru wrote:
| That's actually quite impressive, considering that Mastodon is
| both talked about much wider, and is easier to use.
| JAlexoid wrote:
| 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.
| imachine1980_ wrote:
| 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 centric 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
| evbogue wrote:
| 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.
| lovvtide wrote:
| 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.
| evbogue wrote:
| All good points!
|
| I believe Nostr is doing way better than Bluesky at achieving
| the goal of being a distributed social network.
| jazzyjackson wrote:
| 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
| evbogue wrote:
| Someone with money should create a VC fund for simple IPFS
| alternatives. That's a good idea.
| jb55 wrote:
| 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.
|
| Cheers!
| evbogue wrote:
| > > 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.
|
| I'm sorry if I'm wrong about this one. How does it work?
| jb55 wrote:
| 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.
| evbogue wrote:
| 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.
| jb55 wrote:
| 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:
|
| 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!
| evbogue wrote:
| I read NIP-57 just now.
|
| 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.
| supertestnet wrote:
| > if someone Zaps me right now, I haven't specified a
| place for those Zaps to go
|
| 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
| evbogue wrote:
| 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.
| clarkmoody wrote:
| Lightning is an online protocol, so your wallet must be
| available to complete the transaction. No online wallet,
| no zaps.
| satvikpendem wrote:
| > _Hey, author ofhttps://damus.io here (ios twitter-like
| nostr client)_
|
| Haha, like Nostradamus, very clever name!
| drexlspivey wrote:
| > 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.
| evbogue wrote:
| > 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.
| woah wrote:
| > 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
| imhoguy wrote:
| Interesting technical solution. However looking at the stats it
| seems it lost the momentum: https://stats.nostr.band/ What
| happened?
| unboxingelf wrote:
| 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.
| JAlexoid wrote:
| 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.
| DANmode wrote:
| Who are _you_?
| JAlexoid wrote:
| That random person that this pitch is supposed convince to
| use it.
| unboxingelf wrote:
| Sorry I'll have ChatGPT write it next time.
| mplewis wrote:
| Perhaps try and make it compelling to a prospective user
| next time?
| ssivark wrote:
| 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?
| unboxingelf wrote:
| You are correct on both points.
| intotheabyss wrote:
| Why would you use Bitcoin lightning when you can use Ethereum
| L2s?
| Brighthurst wrote:
| 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.
| Edes wrote:
| 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.
| unboxingelf wrote:
| 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.
|
| [0] https://cointelegraph.com/news/51-of-ethereum-blocks-are-
| now...
| Canada wrote:
| > If a validator adds a blacklisted transaction, they will
| be slashed [0].
|
| 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.
| unboxingelf wrote:
| They do not have to, but they risk being slashed if they
| add transactions that are not "correct" as per the
| network.
|
| The link I provided shows this coercion via OFAC
| compliance.
| troupo wrote:
| > 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.
| unboxingelf wrote:
| 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.
| troupo wrote:
| > 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?
| mhink wrote:
| > 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.
| troupo wrote:
| > 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?
| Edes wrote:
| 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.
|
| [1] https://youtu.be/iXMHKZGVZ0g
| mhink wrote:
| 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.
| MuffinFlavored wrote:
| > 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?
| mhink wrote:
| 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.
| unboxingelf wrote:
| It removes trusting a 3rd party.
| MuffinFlavored wrote:
| 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?
| unboxingelf wrote:
| 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.
| MuffinFlavored wrote:
| How is this any different from sending an event from an
| account you authenticated from (like an e-mail, or a
| Twitter account)?
| unboxingelf wrote:
| It removes trusting a 3rd party.
| JAlexoid wrote:
| How is trusting a third party to deliver you the
| authentic public keys isn't "trusting a third party"?
| rendx wrote:
| 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.
| [deleted]
| jazzyjackson wrote:
| 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.
| unboxingelf wrote:
| Afaik there is no key rollover story or recovery. I know it's
| been discussed and I found this PR: https://github.com/nostr-
| protocol/nips/pull/637
|
| KERI sounds interesting, I'll read up on that. Maybe you can
| review that PR and share some insights?
| gsihzjGsha wrote:
| [dead]
| nacs wrote:
| 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.
| jimmydoreornot wrote:
| 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.
| JAlexoid wrote:
| > If you want to meet new people, then use relays that filter
| spam.
|
| And tada! You have centralization... Because filtering spam
| is a very complex operation.
| mrd3v0 wrote:
| 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.
|
| [1] https://radicle.xyz/
| StuntPope wrote:
| I would recommend ponying up a few sats and using paid relays.
|
| 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).
| ignoramous wrote:
| 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.
| jb55 wrote:
| 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.
| dekervin wrote:
| 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
| vorpalhex wrote:
| 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.
| JAlexoid wrote:
| 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.
| mik1998 wrote:
| 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.
| jb55 wrote:
| 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.
| itslennysfault wrote:
| 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).
| tortoise_in wrote:
| Why not try xmpp?
___________________________________________________________________
(page generated 2023-09-01 23:01 UTC)