5 ms·

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 authent

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.

intotheabyss 3y ago
Why would you use Bitcoin lightning when you can use Ethereum L2s?
- unboxingelf 3y ago
  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-compliant-with-ofac-standards-raising-censorship-concerns https://cointelegraph.com/news/51-of-ethereum-blocks-are-now...
  - Canada 3y ago
    > 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 3y ago
      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.
      - 3np 3y ago
        No, your link shows that a majority of validators will not include certain transactions in a block. While problematic in itself, there is nothing around slashing other validators who do so, on their allotted blocks. Technically you can still obtain 32 ETH on the market, permissionlessly set up your own beacon-, validator- and execution clients and wait until it's your go to send out txes.
        unboxingelf 3y ago
        Ok, I assumed a validator providing blocks with unexpected transactions would trigger a penalty - guess not.
- Brighthurst 3y ago
  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 3y ago
    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.
- irusensei 3y ago
  I think someone did some monero focused client and relay implementation. Go on and create your own nostr eth implementation. Maybe even try to submit a NIP for this.
JAlexoid 3y ago
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.
- unboxingelf 3y ago
  Sorry I’ll have ChatGPT write it next time.
  - mplewis 3y ago
    Perhaps try and make it compelling to a prospective user next time?
- DANmode 3y ago
  Who are you?
  - JAlexoid 3y ago
    That random person that this pitch is supposed convince to use it.
    - DANmode 3y ago
      Point was: pitches should be given with the receiver in mind.
      - JAlexoid 3y ago
        Agreed. Posting your pitch on a technical public forum should have a random critically minded technical person in mind.
ssivark 3y ago
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 3y ago
  You are correct on both points.
troupo 3y ago
> 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 3y ago
  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 3y ago
    > 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?
    - unboxingelf 3y ago
      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.
      - troupo 3y ago
        > 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.
MuffinFlavored 3y ago
> 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?
- unboxingelf 3y ago
  It removes trusting a 3rd party.
  - MuffinFlavored 3y ago
    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 3y ago
      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.
      - JAlexoid 3y ago
        How is trusting a third party to deliver you the authentic public keys isn't "trusting a third party"?
        rendx 3y ago
        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.
jazzyjackson 3y ago
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 3y ago
  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 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 3y ago
and if there ever is spam you will have to choose a) see all the spam or b) block everyone new

intotheabyss 3y ago

Why would you use Bitcoin lightning when you can use Ethereum L2s?

unboxingelf 3y ago
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-compliant-with-ofac-standards-raising-censorship-concerns https://cointelegraph.com/news/51-of-ethereum-blocks-are-now...
- Canada 3y ago
  > 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 3y ago
    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.
    - 3np 3y ago
      No, your link shows that a majority of validators will not include certain transactions in a block. While problematic in itself, there is nothing around slashing other validators who do so, on their allotted blocks. Technically you can still obtain 32 ETH on the market, permissionlessly set up your own beacon-, validator- and execution clients and wait until it's your go to send out txes.
      - unboxingelf 3y ago
        Ok, I assumed a validator providing blocks with unexpected transactions would trigger a penalty - guess not.
Brighthurst 3y ago
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 3y ago
  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.
irusensei 3y ago
I think someone did some monero focused client and relay implementation. Go on and create your own nostr eth implementation. Maybe even try to submit a NIP for this.

JAlexoid 3y ago

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.

unboxingelf 3y ago
Sorry I’ll have ChatGPT write it next time.
- mplewis 3y ago
  Perhaps try and make it compelling to a prospective user next time?
DANmode 3y ago
Who are you?
- JAlexoid 3y ago
  That random person that this pitch is supposed convince to use it.
  - DANmode 3y ago
    Point was: pitches should be given with the receiver in mind.
    - JAlexoid 3y ago
      Agreed. Posting your pitch on a technical public forum should have a random critically minded technical person in mind.

ssivark 3y ago

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 3y ago
You are correct on both points.

troupo 3y ago

> 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 3y ago
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 3y ago
  > 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?
  - unboxingelf 3y ago
    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.
    - troupo 3y ago
      > 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.

MuffinFlavored 3y ago

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

unboxingelf 3y ago
It removes trusting a 3rd party.
- MuffinFlavored 3y ago
  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 3y ago
    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.
    - JAlexoid 3y ago
      How is trusting a third party to deliver you the authentic public keys isn't "trusting a third party"?
      - rendx 3y ago
        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.

jazzyjackson 3y ago

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 3y ago
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 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 3y ago

and if there ever is spam you will have to choose a) see all the spam or b) block everyone new