Closed gohumble closed 5 months ago
LGTM, people have been complaining about this for a long time.
I would probably change client to code to support both until all mints change their models.
Actually I don't see any benefit to this, but I don't have a strong opinion on it either
Actually I don't see any benefit to this
We've had many examples in the spec that started off as an array and turned into an object later because arrays suck. I hope we won't add any arrays anymore just to turn them into objects half a year later.
What about a backwards compatible update? We could add the new contact field as a new key, e.g. contact_info
, such that we don't break existing implementations with it.
done ✅. Added the contact_info
field for backwards compatibility.
I have also added a deprecation hint to the old contact
field.
I would suggest we implement this in mints and clients before we merge the PR.
ACK cd9d6ad362eb69bfd81326f553764c52acd1ff7b
Implemented in CDK in https://github.com/cashubtc/cdk/pull/117
Implemented in CDK in cashubtc/cdk#117
Updated, with new field now called "contact" and thus being a breaking change. @thesimplekid we renamed the type
field to method
now, which fits a bit better.
This PR updates the contact information structure.
The main change is in the representation of contact information, which is now a structured object instead of an array. This allows for a more explicit and readable representation of contact types and values.