Improve OfferId / serialized Offer / Offer details information interplay

[TheCharlatan]

The OfferId is currently difficult to retrieve from the API. At the same time I question the utility that the OfferId may provide a user. The Offer itself is already a fairly short string. The main utility I can think of is that the OfferId can be more easily visually compared to another, than a full serialized Offer.

The current API also lacks an endpoint to retrieve de-serialized information from a Offer.

I see two options to improve the current situation:

1. Dropping the use of the OfferId in the API altogether and working only with either the serialized offer strings, or deserialized representations of the Offer. Have the following endpoints
   • make returns the full offer
   • list-offers lists all offers
   • offer-info <Offer> deserializes an offer
   • cancel <Offer> cancels an offer
2. Add an endpoint for going from Offer to OfferId and vice-versa. make
   • make returns the full offer and offer id
   • list-offers [OfferId] lists all offers and alternatively all offers with a certain Id
   • offer-info [OfferId] [Offer] deserialies an offer with a certain OfferId or a raw Offer
   • cancel <OfferId> cancels an offer

I prefer the first option.

[h4sh3d]

I think the first option is better for now. But I'd introduced later an ID again, but this time just a standard UUID generated when offer is created instead of using a hash to derive the id. This allows:

• manipulating public offer ids when it is more convenient
• allows two identical offers or more in parallel (we may want twice the same trade with two different counter-party)