Should the amount (and expiry) be in the IlpPrepare?

[emschwartz]

Standardizing the amount and using unitless UInt64s made a lot of sense when we had the destination amount in the packet, which needed to be understood by everyone. Now we have the local amount though, which not only will be changed by each connector, it is also fundamentally a bilateral concern. If a pair didn't want to use unitless UInt64s they could leave that field as zeros and wrap the packet in another message with a float or a UInt128 if they wanted. Does it make sense for the packet to include the amount? One could argue that the worst case scenario would be this field ends up unused and there are just 8 wasted bytes in every packet.

A somewhat similar question applies to the expiry. It is changed at every hop and connectors could use a different format if they wanted to. I think the case for having different formats is weaker than for amounts, because I think it's unlikely that we'll need greater than millisecond precision and otherwise the different formats would be communicating the same information.

(I hope the answer to the question posed by this issue is 'yes', but I thought it was important to bring up)

[michielbdejong]

Two peers could use a different packet type and still participate in the same payment. As soon as two connectors want to implement a peering relationship where the amounts are floats, they have two choices: use their own custom format, or open a pull request to this repo, to add an extra packet type to support their use case.

I guess the main lesson is that packet type 12 is not the only valid way to forward an Interledger payment, it depends on what your peer expects you to send. But for now, it's the packet type we expect almost everybody to use.

[justmoon]

The encoding format as a whole is a bilateral concern, this is not specific to the amount. The benefit of having one format is to make it easier to write an implementation. For example, if I use UInt64 amounts everywhere I can make a rate backend that deals in UInt64 and passes on Interledger packets very efficiently without a lot of conversions.

So yes, we should keep this information in the standard packet. The whole point of having a packet is to minimize the surface area between the ledger and interledger layers and what we have now is pretty close to minimal.

The only thing that we can remove imo from the interface between ledger and interledger layer is the fact that it's request/response. But having that vastly simplifies implementation, so it's a good tradeoff imo.