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