Matt Corallo

> I don't think step 6 is valid? At least we will reject it, so I'm gonna call it invalid :)

> For this to work, we must have Sender -> Hub A -> ... -> Hub B -> Recipient where Hub A and B are always online. Hub A would...

> You should specify this "onion message mailbox" in more details, I don't think it is as obvious and simple at you imply. Not sure why this is complicated? Just...

> That's exactly what I wrote. I understand perfectly well why this hold HTLC scheme is a good feature for sending money to people you trust (which includes tipping because...

Yea, we could consider it definitely. First we do need onion messages to be broadly available, which is still a ways off, then we'll need to define the onion message...

> My very high-level idea for this kind of feature was to use something similar to non-hardened BIP 32 derivation: if we had a way for the receiver to give...

> And this idea? https://makers.bolt.fun/story/pitch-lightning-mobile-push-payments--489 That is solving a different problem - that talks about the recipient being online when constructing the invoice, something that we do not assume here....

Strongly disagree that announcement_signatures "is a BOLT 7 message" - its not a gossip message, its not something which is forwarded on, and its something which is generated from local...

I can't say I *particularly* care where it is specified, but from a practical implementation PoV, as in my example in #625, there really are reasons to have its send...

I really don't see how - as the recipient you have strictly more knowledge than the sender and can select the same set of channels as the sender would pick...