Rename Event::PaymentClaimable::inbound_channel_ids to via_...

[TheBlueMatt]

In c62aa23 we merged via_channel_id and via_user_channel_id and added support for MPP to the fields, but created a new inbound_channel_ids field to replace them. The existing fields were labeled via_ to differentiate between inbound channels (i.e. channels which were to us) and channels over which we received the payment.

Here we restore the original naming by renaming the new inbound_channel_ids field to via_channel_ids.

[ldk-reviews-bot]

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-reviews-bot]

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

[joostjager]

I thought that in the context of a payment, inbound channel isn't ambiguous? I can understand that there might be some confusion if inbound channel is a global term within LDK for remote-initiated channels.

Via is also non-ambiguous for an incoming payment and avoids that confusion, so better indeed.

But is there a general term for "channel that something came in through"? Because in other cases, it might be necessary to distinguish between in and out, and via doesn't do that.

[TheBlueMatt]

Yea, in context its not quite as ambiguous, but via is at least not used elsewhere for anything else, which seemed worth it (I know it was discussed when the fields were first added here). I'm definitely open to something better than "via", because indeed with a list now I can see someone thinking they're getting a list of all channels the payment went through. Maybe last_hop_channels?

[joostjager]

That is a question of whether one can assume that users understand that it is impossible to know all channels?

Perhaps a less ambiguous name than 'inbound channel' for the channel open direction would have been better, such as 'remote-initiated channel'. That would free up the term 'inbound channel' to indicate htlc direction.

Other alternatives are:

• Incoming channel - although it is quite similar to inbound channel
• Receiving channel

To me, receiving channel is the clearest.

Probably something to revisit the next time we touch this code.

[TheBlueMatt]

That is a question of whether one can assume that users understand that it is impossible to know all channels?

Yea, I think its fair to say we shouldn't assume that.

Probably something to revisit the next time we touch this code.

For that reason, I think I'd prefer to just rename this again (sorry lol).

To me, receiving channel is the clearest.

Hmm, yea, that's not bad. Is receiving or last_hop clearer?

[joostjager]

Hop is a bit strange because this node is the last hop? I'd almost think we'd be dealing with some other hop. My preference would be receiving, staying close to the payment direction.