| date | recording |
|---|---|
2024-10-16 |
- ???
- Sebastian Nagel
- Perry Wasserbauer
- George Flerovsky
- Reza Baram
- Sasha Bogicevic
- Tudor Cotruta
- Philip Di Sarro
- Pi Lanningham
- Ilia Rodionov
- Benjamin Hart
- Franco Testagrossa
- Noon van der Silk
- Trym Bruset
- Caiña Costa
- Sam Leathers
- Lucas Pedro
- Sandip Pandey
- Jingles
- Martin Schere
- Aaron Boyle
- Jingles K
- Incremental commits
- Partial fanout
- https://cardano.ideascale.com/c/idea/130826
- Aiken
- Could try plutarch (George says more performant than Aiken!)
- Hydra in the Browser (with Pi)
- Ledger in the browser?
- AltNodes?
- Wasm
- Networking
- Interoperability
- Lots of Hydra heads
- Savings and chequeing accounts
- Very rapid networking
- Gumyworm
- "Composability across the boundary"
- Instead of sending to address; send with datum; mint tokens?
- Withdrawal across layers
- Can do something similar like Hydrazoa for deposits re: datums
- Common language for doing these operations; agreement
- Pi, Phil, George working on these details
- Goal of the working group as well!
- Discuss interoperability early, to avoid fragmentation!
- Hydra interoperability between themselves can look a little different than between completely different L2s
- Start an FRO
- Interhead hydra has a scalability issue
- Braiding is an option?
- HDLCs are an option instead
- Phantom tokens
- cardano-scaling/hydra#358
- Tokens minted and burned on the L2
- What about non-Ada tokens in Hydra?
- x Tokens in
- y Minted in Hydra
- m Burned
- What happens now?
- Extra field for Phantom tokens?
- Allow minting tokens to be input
- On fanout reject
- Need to handle arbitrary closings
- How to handle this?
- Minting policy needs to recognise this specific instance of the Hydra head
- Whitelist of white things the L2 can mint based on what the L1 has
permission to mint (doesn't have to be everything that the L1 can mint.)
- Can this be done dynamically like incremental commits/etc?
- Governance mechanism to change these things?
- Metadata/Metric collection