[therocktrading] txid and address incorrectly parsed for FIAT withdrawals

{
  "id": "12564223",
  "info": {
    "id": 12564223,
    "date": "2017-08-07T08:13:50.023Z",
    "note": "GB7IDL401573388",
    "type": "withdraw",
    "price": 4345.93,
    "fund_id": null,
    "currency": "EUR",
    "order_id": null,
    "trade_id": null,
    "transfer_detail": {
      "id": "EXECUTEDBUTUNCHECKED",
      "method": "wire_transfer",
      "recipient": "GB7IDL401573388",
      "confirmations": 0
    }
  },
  "txid": "EXECUTEDBUTUNCHECKED", <-- wrong
  "type": "withdrawal",
  "amount": 4345.93,
  "address": "GB7IDL401573388", <-- wrong
  "currency": "EUR",
  "datetime": "2017-08-07T08:13:50.023Z",
  "timestamp": 1502093630023
}

[npomfret]

I do believe that even with fiat transactions among banks

I’m sure there is, but I’ve done 500 fiat deposits/withdrawals and so far I’ve not found any sort of id that has any use.

I think of an address as an identifier of the account, and the more i think of it the more i tend to consider a bank account number to be equivalent to a crypto address – it identifies the recipient within the systems on the receiving side of a transfer or a transaction.

I think I agree. An address is globally unique, as is an IBAN is suppose. Except in the case where there’s an accompanying tag/memo or some other extra identifier? I believe the Coinbasepro EOS address is just coinbase or something like that.

Regarding the general question of backward compatibility. I’ve seen projects slow down enormously with an obsession over backward compatibility. It’s a nice thing to have, but in my mind we should be prioritising the future over the past.

There are good and bad ways to make non-backward compatible changes. At the most basic level you do have version numbers to indicate breaking changes. People don’t have to upgrade of course, and in extreme circumstances they can manage they’re own fork. But, in reality there are always nice tricks you can employ to make the transition more comfortable. You can for example start with duplication of data within our structures. You can deprecate (depending on the language I guess). And when developers access deprecated stuff you can start logging warnings.

I think using javascript classes over raw objects would empower us to push breaking changes forward. I don’t have a good grasp on how they cross compile though which is a significant hurdle. Something like this might help with the current discussion

class Transaction {
    /**
     * @deprecated use destination instead
     */
    get address() {
        console.warn(`"address" property will be removed soon, please use "destination.address" instead`);
        return this.destination.address;
    }
   ...

I agree there’s no reason to rush, this is a minor point. I was looking at my data and saw some misleading stuff. One of the many great design decisions in this project was to include the info element. Having the original data is incredibly useful when debugging these issues. It also allows you to re-parse the data should you disagree with the way it’s done in ccxt (which is what I do in a few cases).

deep structures are sometimes less convenient for tabular views and rdbms

This is certainly true, although a lot of modern databases are json compatible. I use Postgres and Firestore and the both handle son fine. We of course already have this problem because the fee object is a structure. I don’t think having a flat structure is the right way to go, the data is unfortunately structured. Flattening is (IMO) easier than re-structuring.

[npomfret]

@kroitor DSX has a similar problem:

{
  "id": "1555922",
  "fee": {
    "cost": 0,
    "currency": "USD"
  },
  "info": {
    "id": 1555922,
    "type": "Incoming",
    "amount": 7465,
    "status": 2,
    "address": "000-628242",
    "currency": "USD",
    "timestamp": 1521202192,
    "commission": 0
  },
  "type": "deposit",
  "amount": 7465,
  "status": "ok",
  "address": "000-628242", <-- wrong (looks like some sort of internal DSX identifier)
  "currency": "USD",
  "datetime": "2018-03-16T12:09:52.000Z",
  "timestamp": 1521202192000
}