Implement Readable for Offer and Refund

[tnull]

In order to make storing Offer and Refund objects easier, we here implement Readable for them (both already implement Writeable).

As I'm not sure if this was omitted on purpose so far, waiting on a concept ACK from @jkczyz.

If we agree we want this, we should probably also implement Writeable/Readable for Bolt11Invoice, and add serde de/serialization for Offer/Refund as requested here.

[TheBlueMatt]

I believe the intended serialization for all of this is ToString. We could implement a packed binary encoding like this, but ISTM To/FromString should generally suffice.

[tnull]

I believe the intended serialization for all of this is ToString. We could implement a packed binary encoding like this, but ISTM To/FromString should generally suffice.

Hmmm, but for example in LDK Node's upcoming Offer/InvoiceStorage we'd then need to implement custom logic or a wrapper that would then de/ser the objects via FromStr/ToString, even though we could just store the objects as TLV fields as everything else? Surely doable, but I'm not quite sure what the drawback of (additional) implementations would be?

[TheBlueMatt]

Yea, I mean I'm okay with supporting more here, just noting that we've historically just suggested string'ifying the BOLT11 things.

[jkczyz]

Hmmm, but for example in LDK Node's upcoming Offer/InvoiceStorage we'd then need to implement custom logic or a wrapper that would then de/ser the objects via FromStr/ToString, even though we could just store the objects as TLV fields as everything else? Surely doable, but I'm not quite sure what the drawback of (additional) implementations would be?

Is it desirable to parse the offer into all of its in-memory parts? Like, if you were listing most recent payments, showing the bech32 string might be more desirable, only parsing it when examining a specific payment. I guess I don't have a strong feeling about whether we should add Readable, though given we already have Writeable.

[tnull]

Is it desirable to parse the offer into all of its in-memory parts? Like, if you were listing most recent payments, showing the bech32 string might be more desirable, only parsing it when examining a specific payment.

Hmm, so far the payment store holds and returns the full Rust objects, which would allow users to take advantage of the full API. While I agree that for display purposes showing the bech32 could make more sense, it would still be good to maintain easy access to any of the provided Offer fields/methods. For context: in LDK Node bindings we currently de/serialize all Bolt11Invoices from/to string, which however lead to some complaints of missing functionality, e.g., the ability to access and verify the invoice fields before sending. I expect similar complaints to arise even in Rust when we'd generally only expose serialized versions of and Offer/Refund.