Closed mDuo13 closed 1 year ago
Snakes vs camels!
Fight!
Although RippleAPI is now obsolete, I think the RippleAPI names for these flags are still good. Of course, if we know of a better name for one (or more) of these fields, we should feel free to propose it as well.
@godexsoft @officialfrancismendoza What are your thoughts on addressing this in Clio?
@intelliot would not be a high priority for clio
but certainly can add to our backlog if @mDuo13 confirms this is still desired (it's been ~5 years).
I'm not @mDuo13 , but I still think this would be a good idea. It's amazing how time flies when there are other priorities.
I completely agree with the premise of this issue and the proposed implementation. Needing to do bitwise operations when making JSON API requests is definitely not a nice time.
While you could argue that "the client should deal with it", overall I think it makes a lot of sense to tighten up the API returned by clio/rippled to be a little more in line with the modern web. Providing nice/elegant interfaces that make interop with various tools easier improves developer happiness and experience which IMO is a high priority.
One fairly simple bit of functionality that's more complicated for users than it needs to be is parsing account flags. We can make things friendlier for users by modifying the account_info command to break the flags up into separate booleans in the response.
Performing bitwise operations on the
Flags
field is not inherently difficult, but it is an extra step that's easy to get wrong, because there are three kinds of account flags and it's easy to mix them up. The three types of flags are account-set flags (asf), AccountSet transaction flags (tf), and AccountRoot ledger-state flags (lsf*). For purposes of account_info, we only need to care about the ledger-state flags.I propose adding an
account_flags
object to the top level of theaccount_info
response, alongsideaccount_data
,signer_lists
, etc. This object would be a map flags enabled for the account. I recommend using the names of the fields from RippleAPI so we can be consistent across interfaces. (The lsf* names are currently used in the code and documentation but never exposed in the rippled APIs.)The existing convention of the rippled APIs would dictate that the
account_flags
object in the response should contain only flags for which the account's value is not in the default state. Since all flags default tofalse
, all fields which appear in the response would have the valuetrue
. I disagree with this design and believe that the response should always contain fields for all flags, whether their values are true or false. (That makes it easier to write simple code to check a flag's value, and more closely matches the design of RippleAPI.)true
, new trust lines to this address have rippling enabled by default on this account's side.true
, the account can't be the destination of payments, etc.true
, the account can't send transactions signed with its master key pair.true
, client applications should reject or prompt before sending XRP to this account.true
, all currencies issued by this account are frozen.true
, this account has given up the power to selectively freeze issued currencies.true
, this account has used its free key reset.true
, trust lines to this account require approval before they can hold currency issued by this account.true
, transactions that send money to this account must specify a destination tag.