hydra VS cardano-haskell-packages

So many wrong statements made in your comment it's pretty wild. My original comment was to highlight some differences between Cardano and Ethereum in regards to how they operate rather than to decide which one was better. Regardless, you've decided it was complete non-sense and gone on a tangent because I state both tx fee models have their pros and cons? Lol. If you think a viable solution is to have insane gas fees on the L1 then we fundamentally disagree and crypto will never find real adoption. You've blurted so many things idk where to start but to sort of sum it up is that Cardano has scaled and is still scaling with things like input endorsers and hydra which is actually just about ready to start using: https://hydra.family/head-protocol/ This also tells me your information about what's happening is outdated. Also I know exactly what throughput is, my point was that the metric doesn't capture the full picture for different blockchains capabilities.. We can go all day but you clearly have something against Cardano, I'm happy to have a genuine discussion but the intent on bashing is clear here as this was unprovoked.

Hydra, a L2 solution using isomorphic state channels. Caveat: This is NOT an easy fix that can simply scale all Cardano dapps, it remains to be seen what parts of Cardano can actually be scaled by Hydra. This currently is a bit complicated. Sundaeswap is experimenting with Hydra, but Axo devs do not think Hydra is good for scaling DEXs...

The Hydra team completed work on a different way of dealing with contests during the contestation period. These will now always push the deadline out, making contestation periods easier to pick depending on the network a head runs on. They also added an important acceptance test and completed internal refactoring of the protocol logic, making future changes easier to implement.

I'm thinking about this for some time, about having a bot for P2P exchange much like P2P lightning bot but for Cardano and no, necessarily implementing a full-blown "lightning network", but I'm confused about the state of the Hydra Head Protocol and its capabilities for this particular use case.

The Hydra team released version0.8.1, which includes several fixes and an extension of the persistence (introduced by version 0.8.0) of replaying server outputs to make clients like the hydra-tui aware of the latest hydra-node state. The team also worked on the specification and closing gaps in the on-chain scripts, collaborated with the education team on a Hydra tutorial, and renamed the repository from hydra-poc to `hydra`.

Finally, they released ouroboros-consensus v.0.2.0.0 and ouroboros-consensus-cardano 0.3.0.0 to CHaP.