I wrote a long answer then I lost it because Primal doesn't persist drafts apparently :)) Feel free to contact me on Email or Signal if you want, you can find my contacts on Nuh.dev

I am not 100% aligned with your design here and I think there is important changes I would try to explore, but I think the idea of short yet randomly generated names based on Bitcoin is the right direction... So all power to you.

Nostr isn't like IP at all, it is like writing on a wall for people to read later. IP actually help you route your packets to their destination. But I am not here to shit on people's passions, if you are satisfied with this stack, so be it. But we can't wishcast engineering. A broadcast system will never do to higher layers what routing system did to the internet higher later... Almost by definition.

The analogy is not perfect but good enough... If your protocol uses a destination database that ACKs like Email and TCP does, and which the reader checks as the source of the truth... Reliability would have been similar to Email. And of course you don't need excuses, you designed something for a specific need and it worked great... Not your fault that Devs decided that 1) it fixes everything AND 2) it fixes everything without changes. But now I don't know if I am talking about Nostr or Bitcoin :')

Read it again.. I didn't say there is a need for Blockchain... But I tried too many times to explain why are insufficient, I shouldn't do that any more

Communicate privately could mean encrypted data on a Blockchain... So I think there is a 0 capability; find each other messages consistently without fatal disruption like DNS takedowns.

Everything in place for people who want to build on Bitcoin anything they think is necessary. The real uncertainty is demand... If there is still demand for Bitcoin to scale or get any features or do anything beyond being a ticker for ETFs. That lack of demand, if true is not anyone's fault. Just a tragedy.

"we? Who's we?"

I like this because I don't like legible regulated Bitcoin.

I think your main issue with using L1 for DA, is that you think people are trying to add scalability... No, people are trying to have usuable smart contracts, then do all the fraud proofs or validity proofs or proof of stake and any tricks they might need for scaling there, with actual smart contract language that is not as awful as BitVM (which by the way forces people to use ZKVMs that are far from water tight)... So it doesn't matter that the "side"'chain will be expensive, it is not meant to compete with LN it is meant to make L2s nicer to develop+ enable things like Stablecoins and vaults ... All usecases for large transactions anyways.

I think you are not noticing what I am saying; whoever slashes the sequencer could have been themselves the Data Availability Committee and sign on all blocks... Unless you mean slashing with BitVM which means the data has to be posted with BitVM hacks... In which case I check out. Either way, it is not clear why should we bother with introducing a challenge system for DA, when we already have a proof of publication, and we would be using it not to post dick butts but to basically add something that everyone agrees is needed. Is it really better to post tons of inflated data with BitVM challenges, than just write contracts onchain and hold the escrows accountable that way. I didn't even mention the effect of watching the demand for smart contracts evident on chain. Anyways, I think I understand your position now, thanks.

No Stablecoins backed by Bitcoin are not mere tokens... There is a whole lending contract necessary to mint them, not just a token you mint and transact with RGB without need for observable chain. Now, if you take your DA challenge idea to its extreme you will find that it devolves to exactly always embedding blocks on Bitcoin... Because either there is no cost for the challenge in which case I will personally challenge everything just to prove a point, OR there is a high cost for challenging, which can't be refunded because you can never prove the data was withheld so you will just have to pay it. So if you want a chain to do things that require people to be aware of what is going on, like minting Stablecoins with Bitcoin lending, or with optimistic challengeable bridges etc... then you will need to keep posting the data all the time, except now you also need to publish the challenges, so more "spam". The other viable alternatives here are to use the same federation of the pegout as the DA committee AKA liquid... Or use merge mining AKA Rootstock (which is way harder to bootstrap). But if your blocks are meant to be small and infrequent, just embedding them on Bitcoin removes tons of complexity and ton of ways for things to go wrong. And again, if you are trying to do something difficult like exploring covenants or Simplicity... Choose your battles

When Finney said that Bitcoin will scale with banks, he didn't say whether or not we can have both accounts and freedom.

RGB doesn't work for everything that you want a Blockchain for, I don't think it works at all to showcase how smart contracts help L2s with fraud proofs etc... for many reasons, but let's just start with the data witholding. In fact there are zero interesting applications that RGB offers me, I don't want to create tokens. I only care about: 1. Experiments for L2 bridges 2. Possibly satisfying the demand for Stablecoins while still using Bitcoin as backing both for freedom and sustainability of Bitcoin with more value and demand. Neither of these are possible with RGB as far as I know, the next best thing is BMM but that is why I said that is not Metaprotocol. BMM is cool but there is a good argument that when you are already battling 2WP, might as well not also fight Data Withholding... Especially when you are aiming for a Metaprotocol (let's call it embedded consensus or embedded chain) that is not expected to require too much data (if you only use it as stepping stone to L2s). Is adding 10% of extra data really spammy if that is the goal? If we are affording some grace to Bitvm (which I often see spam concernors do) why not do the same for other attempts to break free of the endless "PrOvE tHe DeMaNd FoR CoVeNaNtS fIrSt". Of course one can argue that the demand could be proven on Liquid instead ... But I submit to you that people spent money on worthless Ordinals instead of doing the same on Liquid for a reason.

I am not sure I get the distinction... So if Liquid didn't create a sidechain and instead just wrote blocks in the opreturn of a linked list of transactions on Bitcoin is that spam? A Metaprotocol by definition is written on Bitcoin, otherwise it is a sidechain or Spacechain or a Spiderchain or whatever. If I am trying to black list misbehaving members of a dynamic federation, it makes tons of sense removing the DA question from the equation. Another factor is showing the demand of these advanced smart contract evident on block space fee bidding. Are you saying anything but a hash is spam, or are you saying inconsiderate unnecessary bloated formatting would be spam?