What’s the logic behind that conclusion? Would be nice to avoid reinventing the wheel.

I’m curious about what problems you encountered.

Never looked at MessagePack.

Last time I had to design a consensus critical message format I came to the unenviable conclusion that none of the existing ones were right. But that was for something different than nostr.

How about MessagePack? Faster to encode and decode than TLV, good for dynamic data structures apparently.

JSON was a dumb idea...

#[0]

#Nostr is the bitcoin hivemind. 🐝

The cyber hornets have spoken, and I respect it. To maintain the momentum of Nostr, everything we build will be backwards compatible. Contention is such a drain anyway. 🥲

🌲Our syncing and large-file storage protocol🌳 will be a layer in between #bitcoin and #nostr

Intellectually honest debate is hard to find. But when you do find it, both people tend to learn things. I personally enjoy having my thoughts challenged. I don't tie my identity closely to my beliefs. I'm ready and excited to be wrong!

#Bitcoin

i actually don't know where the purple as the color of Nostr came from.

#[0]​ asketh, fiatjaf receiveth.

I worry that this is an understated risk in lightning for routing nodes. I’m not even sure if lnd exposes this as an option at channel open.

Shorter timeouts on HTLCs means that if you route an htlc that is a large % of a channel, you could be putting that amount at risk.

If you go down while an HTLC you are forwarding is pending, you could end up missing the preimage. If you don’t come back in time, you could find yourself in a situation where your outbound HTLC has been claimed by one peer via preimage and your inbound htlc has been claimed by the other via the CLTV timeout.

In effect, you would have unintentionally donated your money for the benefit of the original payment sender :)

#[0]

Ok everyone, put your backs into it, we're officially competing with Elon for "everything app" status.

Nice. Is it for sale?