Giter Site home page Giter Site logo

xrpl4j's Issues

Rewrite XrplClient to mirror the rippled API completely

While most of the methods in XrplClient follow the rippled API, meaning they take a set of XrplRequestParams and return an XrplResult, some methods (such as submit) are more abstract. We should consider reducing the complexity of the client by simply mirroring the rippled API. Also, we should go through and implement the rest of the rippled public API methods that are available.

LedgerResult and LedgerHeader objects break when asking for current ledger

The ledgerHash and ledgerIndex fields are not Optional in LedgerResult, nor are closeTimeHuman and parentCloseTime in LeaderHeader. These fields are always present in responses to requests for validated ledgers, but are absent when asking for the current ledger.

We should probably go ahead and make the breaking change of making these Optional

Add validation to LedgerIndex

LedgerIndex is just a wrapper around String. There are three defined character Strings that are recognized by rippled as shortcuts: "validated", "current", and "closed". All other ledger indexes must be a numerical String like "12345".

Currently, we don't do any client side validation that the String wrapped by LedgerIndex is either one of the shortcut Strings or a number, so a user could technically construct a LedgerIndex wrapping "foo". While this will ultimately be caught by rippled, we should add validation in the LedgerIndex class to short circuit any errors.

Fix Javadoc Warnings

There are a lot of missing javadocs and missing elements of certain javadocs. We should go through and improve these javadocs and make sure the maven-javadoc-plugin does not spit out any warnings

Re-type marker fields in request params and result objects

A lot of the request/response objects have a field called marker, which is a server defined field that can either be a String or a JSON object. Currently, our objects are typed as Optional<String>, which will break Jackson when the server sends back a JSON object in that field.

We should create a Marker type with a custom serializer/deserializer to handle this.

Always trigger GH Actions for forked PRs

Currently, if someone opens a PR from a forked version of xrpl4j, we have to assign the PR to someone in order for GH Actions to get triggered. This is fine for now, but if new commits get added to the PR, we have to re-assign the PR to someone else, which is a pain.

XRP Wallet only works with 16 byte seed

I'm using xrpl4j to generate xrp wallet as part of a HD wallet. I am able to generate the wallet fine when the seed size is 16 bytes (128 bits / 12 word mnemonic) but when the seed size is 32 (256 bits / 24 word mnemonic) it fails. The current workaround I have is to strip the seed of the bytes in excess of 16.

See HD wallet generation using bitcoin4j code here.

new DeterministicSeed(
        new SecureRandom(),
        256,
        Optional.ofNullable(passphrase).orElse("")
    );

See stripping of bytes in excess of 16 workaround here.

ArrayUtils.subarray(privKey.toByteArray(), 0, 16);

While this is functional, it strips the entropy and is restrictively less secure.

Requirement:

  • XRP Wallet should allow seed length greater than and equal to current length of 16 bytes for more secure wallets

Remove tfFullyCanonicalSig flag from all Flags Builders

The tfFullyCanonicalSig transaction flag was recently deprecated, and no new transactions submitted without this flag will be accepted. Currently, we do allow users to set tfFullyCanonicalSig to false for transactions which have custom flags, so we should always set tfFullyCanonicalSig to true. This can be done by removing the tfFullyCanonicalSig(boolean) method from every TransactionFlags Builder and always setting it to true.

Add Constants for TransactionResult Codes

See Transaction result codes here. It would be useful to have these defined in constants so projects using this library don't accidentally introduce typos.

E.g.:

String TES = "tes";
String TES_SUCCESS = TES + "SUCCESS";

Remove `ledgerIndex()` method from Transaction.java

The method ledgerIndex() in Transaction.java is only ever present in response to a account_tx call, and even then only sometimes.

So, we can create a new wrapper class called AccountTransactionsTransaction and inside of AccountTransactionsTransactionResult we can update the transaction() method to be as follows:

  /**
   * The {@link Transaction}.
   *
   * @return A {@link T} with the transaction fields.
   */
  @JsonProperty("tx")
  AccountTransactionsTransaction<T> transaction();

If AccountTransactionsTransaction has ledgerIndex() then everything should just work during deserialization, but from a developer perspective, the ledgerIndex() will be present in the correct circumstances.

Create a type for XRPL Timestamps

Instead of using UnsignedLongs to denote XRPL timestamps, we should just have a type that wraps UnsignedLong that also has utility constructors for Instants and other Java time API primitives

Resource definitions.json not found

Hi, I run into an issue when running a project with embedded tomcat in jar with Java 11.

It causes the following Exception:

Caused by: java.lang.IllegalArgumentException: resource definitions.json not found. at com.google.common.base.Preconditions.checkArgument(Preconditions.java:217) at com.google.common.io.Resources.getResource(Resources.java:195) at org.xrpl.xrpl4j.codec.binary.definitions.DefaultDefinitionsProvider.lambda$new$0(DefaultDefinitionsProvider.java:26)

And is coming from DefaultDefinitionProvider.java:26. The definitions.json file is in the jar, just the classLoader won't resolve it.

Fix issue with LedgerHeader transaction deserialization

XrplClient.ledger(params) method throws an exception if transactions are returned because the LedgerHeader.transactions() declaration tries to deserialize them as String instead of JSON.

The transactions that are returned can either be full JSON transaction objects, or the identifying hashes of the transactions. We could add a custom deserializer, but this kind of polymorphism isn't easy to do in Java, so I think we should just be opinionated and force the request to set expand=true when asking for transactions

Add HD Wallet Support

When we initially wrote xrpl4j-keypairs, we decided to skip over implementing HD Wallet support. For the sake of having a full feature set, we should add support for HD wallet generation

Create type for XRPL Timestamps

Instead of using UnsignedLongs to denote XRPL timestamps, we should just have a type that wraps UnsignedLong that also has utility constructors for Instants and other Java time API primitives

Make it easier to get the amount of an XRP payment as BigDecimal

The way amounts are mapped could be more convenient to use. In most cases, people just want to get the amount in XRP as a decimal, not drops. But on things like payments, that requires doing an instanceof then a cast to XrpCurrencyAmount then no obvious way to get the decimal value (instead of drops) from there

wrong type for load_factor in ServerInfo

I started getting Exceptions from serverInfo() method when connected to s2.ripple.com. I realized the library expects load_factor to be UnsignedInteger (and it usually is "1"), but rippled sometimes returns it as double.

It can be shown here: https://xrpl.org/websocket-api-tool.html?server=wss%3A%2F%2Fs1.ripple.com%2F&req=%7B%22id%22%3A1%2C%22command%22%3A%22server_info%22%7D

clicking send several times eventually get you response with some higher load like:

{
  "id": 1,
  "result": {
    "info": {
      "build_version": "1.7.0",
      "complete_ledgers": "61881385-62562429",
      "hostid": "LARD",
      "io_latency_ms": 2,
      "jq_trans_overflow": "0",
      "last_close": {
        "converge_time_s": 3.002,
        "proposers": 38
      },
      "load_factor": 511.83203125,
      "load_factor_server": 1,
      "peer_disconnects": "224008",
      "peer_disconnects_resources": "747",
      "peers": 261,
      "pubkey_node": "n9MozjnGB3tpULewtTsVtuudg5JqYFyV3QFdAtVLzJaxHcBaxuXD",
      "server_state": "full",
      "server_state_duration_us": "2274468435925",
      "state_accounting": {
        "connected": {
          "duration_us": "231197490",
          "transitions": 2
        },
        "disconnected": {
          "duration_us": "1156933",
          "transitions": 2
        },
        "full": {
          "duration_us": "2274468435925",
          "transitions": 1
        },
        "syncing": {
          "duration_us": "4065001",
          "transitions": 1
        },
        "tracking": {
          "duration_us": "63",
          "transitions": 1
        }
      },
      "time": "2021-Mar-30 15:37:51.486384 UTC",
      "uptime": 2274704,
      "validated_ledger": {
        "age": 4,
        "base_fee_xrp": 0.00001,
        "hash": "E5A958048D98D4EFEEDD2BC3F36D23893BBC1D9354CB3E739068D2DFDE3D1AA3",
        "reserve_base_xrp": 20,
        "reserve_inc_xrp": 5,
        "seq": 62562429
      },
      "validation_quorum": 31
    }
  },
  "status": "success",
  "type": "response"
}

The exception I am getting is clearly saying that jackson can't construct UnsignedInteger from 512.90234375

com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct instance of `com.google.common.primitives.UnsignedInteger` (although at least one Creator exists): no double/Double-argument constructor/factory method to deserialize from Number value (512.90234375)
 at [Source: (String)"{"info":{"build_version":"1.7.0","complete_ledgers":"32570-62562188","hostid":"CARR","io_latency_ms":1,"jq_trans_overflow":"2942","last_close":{"converge_time_s":3.005,"proposers":38},"load_factor":512.90234375,"load_factor_server":1,"peer_disconnects":"171040","peer_disconnects_resources":"4176","peers":214,"pubkey_node":"n9Kr6UDJAd2yUn9J6bXWpRvQcKRPAEVpeV33NJVBcaDSDVt2eho2","server_state":"full","server_state_duration_us":"172918538055","state_accounting":{"connected":{"duration_us":"471959630"[truncated 524 chars]; line: 1, column: 199] (through reference chain: org.xrpl.xrpl4j.model.client.server.ImmutableServerInfoResult$Json["info"]->org.xrpl.xrpl4j.model.client.server.ImmutableServerInfo$Json["load_factor"])

I suppose there fields like load_factor_local, load_factor_net and others may be the same case. I will try to investigate this to find the proper type later.

LedgerIndex uses UnsignedLong but Transaction uses UnsignedInteger

The LedgerIndex class emits an UnsignedLong via unsignedLongValue(), but the Transaction class uses an UnsignedInteger to represent lastLedgerSequence.

We should decide which Unsigned number type is best for representing numeric XRP Ledger index values, and be consistent across the library.

Reduce public API footprint

Currently, almost everything in the library is public, when only a few classes are really needed in the public API that we expose. While it's nice to give users flexibility to use bits and pieces of the library, a large API increases the amount of code we need to make sure we don't break.

We should go through the different modules and figure out which classes we want to keep public and which we can make private

Improve Request/Response Java API for improved developer experience

Anywhere there's an Optional result, we should consider a sibling method that helps a developer not have to throw an exception as an alternative case.

Example, in AccountInfoResult.java, we could add:

@JsonIgnore
default LedgerIndex ledgerIndexSafe() {
  return ledgerIndex().orElseThrow(IllegalArgumentException::new);
}

If we embrace this pattern, we should add this to every client model object.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.