13 ms·

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

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.

drexlspivey 3y ago
> 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 3y ago
  > 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.
  - curtisblaine 3y ago
    > 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?
    - gkbrk 3y ago
      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.
  - kdragon 3y ago
    nostr has an early NIP that talks about publishing timestamp commitments to the bitcoin blockchain, using the open timestamp protocol
jazzyjackson 3y ago
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 3y ago
  Someone with money should create a VC fund for simple IPFS alternatives. That's a good idea.
- kaliqt 3y ago
  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.
  - genewitch 3y ago
    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.
    - bubersson 3y ago
      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.
jb55 3y ago
Hey, author of https://damus.io 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 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 3y ago
  > > 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 3y ago
    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.
lovvtide 3y ago
So I've been building of one of the nostr web clients ( https://satellite.earth 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 3y ago
  All good points! I believe Nostr is doing way better than Bluesky at achieving the goal of being a distributed social network.
woah 3y ago
> 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
antisocialist 3y ago
In other words, Nostr can't do almost anything that matters. > First, I want a replication strategy. xx Network has message replication built in. > Third, someone needs to delete some of these NIPS. xx Network lets you delete messages. > Fourth, it needs a dedicated blob store protocol. For blobs, clients should be able to plug in to any 3rd party blob storage (e.g. Crust Network). This secondary storage is needed only for large attachments and isn't strictly required in messaging. If you think about it, you could upload large attachments anywhere and send links in messages. Look how Teams or Outlook work with One Drive.
- 3np 3y ago
  Oh hey David Schaum has entered the chat to shill their thing

drexlspivey 3y ago

> 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 3y ago
> 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.
- curtisblaine 3y ago
  > 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?
  - gkbrk 3y ago
    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.
- kdragon 3y ago
  nostr has an early NIP that talks about publishing timestamp commitments to the bitcoin blockchain, using the open timestamp protocol

jazzyjackson 3y ago

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 3y ago
Someone with money should create a VC fund for simple IPFS alternatives. That's a good idea.
kaliqt 3y ago
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.
- genewitch 3y ago
  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.
  - bubersson 3y ago
    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.

jb55 3y ago

Hey, author of https://damus.io 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 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 3y ago
> > 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 3y ago
  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.

lovvtide 3y ago

So I've been building of one of the nostr web clients ( https://satellite.earth 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 3y ago
All good points! I believe Nostr is doing way better than Bluesky at achieving the goal of being a distributed social network.

woah 3y ago

> 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

antisocialist 3y ago

In other words, Nostr can't do almost anything that matters. > First, I want a replication strategy. xx Network has message replication built in. > Third, someone needs to delete some of these NIPS. xx Network lets you delete messages. > Fourth, it needs a dedicated blob store protocol. For blobs, clients should be able to plug in to any 3rd party blob storage (e.g. Crust Network). This secondary storage is needed only for large attachments and isn't strictly required in messaging. If you think about it, you could upload large attachments anywhere and send links in messages. Look how Teams or Outlook work with One Drive.

3np 3y ago
Oh hey David Schaum has entered the chat to shill their thing