hydra VS CIPs

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`.

CPS-???? | Governance Security [New Problem]: This problem statement describes security issues to be considered by protocol governance CIPs.

The Lace team is already working with the community on how to find the best way to develop the CIP-72 - DApp Registration & Discovery. If you’re interested in taking part, contribute here

All mobile wallets have some kind of dApp browser, but there are no hard specs for how they should be run that is implemented at the moment. You might be interested in CIP72 if you're interested in standards for this topic more generally: https://github.com/cardano-foundation/CIPs/pull/355

CIP-???? | Extend token metadata for translations [New Proposal]: This proposal defines an addition to CIP-25 | Media NFT Metadata Standard to support more languages than English.

If you wish to add your perspectives to CIP 1694, make sure to share them here. Add your voice as the era of Voltaire rolls out!

Last week, a community-led roundtable took place on the topic of CIP-1694. You can catch the recap and outcome in last week’s newsletter or this Cardano Forum recap here. Worth a read.

Conditions inside a native script (but there is a CIP for changing this here)

Thank you for the information! That is very important. Actually I wrote a specification https://github.com/cardano-foundation/CIPs/pull/442 where I address exactly that issue.