#1: The most interesting part of this is probably the proposal to address channel jamming attacks on Lightning. I've talked about this concern here before: #169274 before. Basically when you make a LN payment, the liquidity is "locked up" along the nodes in the route. A malicious actor can lock up large amounts of liquidity on the network by starting payments and never completing them, potentially also triggering a wave of force-closures that could lead to fund loss if the network ends up getting congested.

This proposal adds a "reputation score" to lightning nodes, and allows nodes to limit their exposure to such attacks by not allowing less reputable nodes to lock up large amounts of liquidity. This feature might be deployed soon on the lightning network as an experiment to see how well it works.

#2: A proposed specification for Lightning Service Providers, including a standardized API to purchase channels and setting up Just-in-Time channels.

#3: Discussion regarded dual-funding zero-conf channels. Currently it is possible to open a Lightning channel and start using it before it's confirmed on-chain if the funding transaction's inputs are entirely controlled by one side of the channel. For example, if Alice opens a 0-conf channel to Bob and Bob attempts to route a payment to Carol through Alice, Alice can safely do this with zero confirmations because she's in complete control of the channel opening transaction. But if Bob also has an input in the funding transaction, then he could RBF the open and cause Alice to lose funds. There are several proposals for making such dual-funded zero-conf channels safer to use.

#4: Advanced payjoin applications: Bob Gould proposed some interesting applications for payjoins besides increasing privacy. This includes transaction cut-through, and also some other interesting use-cases. One example is that instead of Alice paying Bob, Alice could pay people Bob owes money to. For example, a payjoin could be used by an exchange, so when you deposit funds, the funds are instead sent to someone who is withdrawing from the exchange, leading to more efficient use of block-space.