Request: Parse flags in account_info method

[mDuo13]

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 the account_info response, alongside account_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 to false, all fields which appear in the response would have the value true. 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.)

RippleAPI Name	Code Name	Description
defaultRipple	lsfDefaultRipple	If true, new trust lines to this address have rippling enabled by default on this account's side.
depositAuth	lsfDepositAuth	If true, the account can't be the destination of payments, etc.
disableMasterKey	lsfDisableMaster	If true, the account can't send transactions signed with its master key pair.
disallowIncomingXRP	lsfDisallowXRP	If true, client applications should reject or prompt before sending XRP to this account.
globalFreeze	lsfGlobalFreeze	If true, all currencies issued by this account are frozen.
noFreeze	lsfNoFreeze	If true, this account has given up the power to selectively freeze issued currencies.
passwordSpent	lsfPasswordSpent	If true, this account has used its free key reset.
requireAuthorization	lsfRequireAuth	If true, trust lines to this account require approval before they can hold currency issued by this account.
requireDestinationTag	lsfRequireDestTag	If true, transactions that send money to this account must specify a destination tag.

[sublimator]

Snakes vs camels! Fight!

[intelliot]

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.

[intelliot]

@godexsoft @officialfrancismendoza What are your thoughts on addressing this in Clio?

[godexsoft]

@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).

[ximinez]

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.

[justinr1234]

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.