Coder Social home page Coder Social logo

hyperledger-archives / quilt Goto Github PK

View Code? Open in Web Editor NEW
219.0 38.0 79.0 2.53 MB

Hyperledger Quilt - An implementation of the Interledger Protocol

Home Page: https://wiki.hyperledger.org/display/quilt

License: Apache License 2.0

Java 100.00%
interledger interledger-protocol interoperability blockchain payments

quilt's Introduction

Hyperledger Quilt

⚠️ ⚠️ ⚠️

Hyperledger Quilt has been moved to End of Life status by the original project maintainers. Although Hyperledger Quilt is not currently being developed or maintained, the code is still available under an open source license so you would be welcome to reactivate this project. If you are interested in continuing development of this code, please consider submitting a PR at https://github.com/hyperledger/hyperledger-hip and sending and email to [email protected]. See more details about project proposals at: https://hyperledger.github.io/hyperledger-hip/

⚠️ ⚠️ ⚠️

Discuss twitter circle-ci codecov lgtm-cq lgtm-alerts issues

Quilt is a Java implementation of the Interledger protocol.

This library can be used to send and receive Interledger payments using STREAM. It also supports a variety of other core Interledger primitives and protocols.

Note that this library does not implement a full Java Connector. For this functionality, see the Java ILP Connector project, which is built using Quilt.

Modules

Quilt is organised as a Maven multi-module project. Each module exists in a subdirectory that has its own child POM and README file. Dependency and plugin versions are managed in the parent project.

Issues are labelled and prefixed to make it easy to identify which project they relate to.

ilp-core GitHub issues

The ilp-core module is the base library for any Interledger Java projects, providing service interfaces, packet definitions, and data models supporting the ILPv4 protocol (defined in IL-RFC-27).

These primitives form the foundation of the Interledger suite of protocols, and are used throughout the other modules in this project.

ILP Module Javadoc Link
ilp-core Javadocs

READ MORE

btp-core GitHub issues

The btp-core module contains primitives to support the Bilateral Transfer Protocol (BTP v2.0) as defined by IL-RFC-23.

BTP Module Javadoc Link
btp-core Javadocs

codecs-parent

The codecs-parent module contains an encoding and decoding framework plus serializers for ASN.1 OER formats defined in each IL-RFC. This module supports all primitives for the following protocols: ILP v4.0, IL-DCP v1.0, BTP 2.0, and STREAM v1.0.

Codec Module Javadoc Link
codecs-framework Javadocs
codecs-btp Javadocs
codecs-ilp Javadocs
codecs-ildcp Javadocs
codecs-stream Javadocs

ildcp-core GitHub issues

The ildcp-core module contains primitives to support the Interledger Dynamic Configuration Protocol (IL-DCP v1.0) as defined by IL-RFC-31.

IL-DCP Module Javadoc Link
ildcp-core Javadocs

jackson-datatypes GitHub issues

The jackson-datatypes module contains utilities to marshal and unmarshal various Quilt primitives to and from JSON using the Jackson library.

Jackson Module Javadoc Link
jackson-datatypes Javadocs

link-parent

The link-parent module contains libraries that can be used as a network transport for Interledger accounts. Currently supported links are ILP-over-HTTP as defined in IL-RFC-35.

Link Module Javadoc Link
link-core Javadocs
link-ilp-over-http Javadocs

spsp-parent GitHub issues

The spsp-parent module contains libraries that can be used to resolve Payment Pointers (as defined in IL-RFC-26 as well as the broader Simple Payment Setup Protocol (SPSP) as defined in IL-RFC-009.

SPSP Module Javadoc Link
spsp-core Javadocs
spsp-client Javadocs

stream-parent GitHub issues

The stream-parent module contains libraries for sending and receiving packetized payments using the STREAM protocol, defined in IL-RFC-29.

Stream Module Javadoc Link
stream-core Javadocs
stream-client Javadocs
stream-receiver Javadocs

examples GitHub issues

The examples modules shows how to use the Quilt library in your code.

READ MORE

Usage

Requirements

Unlimited Strength Encryption Policy Files

In order to properly build this project, you must download and install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy files. For more details, follow the instructions here.

Maven

Modules in this library can be included in your Maven project by adding the Maven dependency for the module you would like to use. For example, to import ilp-core, use the following coordinates:

<dependencies>
  ...
  <dependency>
    <groupId>org.interledger</groupId>
    <artifactId>ilp-core</artifactId>
    <version>1.0.3</version>
  </dependency>
  ...
</dependencies>

Gradle

Modules in this library can be included in your Gradle project by adding the Maven dependency for the module you would like to use. For example, to import ilp-core, use the following coordinates:

dependencies {
    ...
    compile group: 'org.interledger', name: 'ilp-core', version: '1.0.3'
    ...
}

Artifacts

Artifacts for this project are published to Maven Central. For a complete list, see: https://search.maven.org/search?q=g:org.interledger.

Development

We welcome any and all submissions, whether it's a typo, bug fix, or new feature. To get started, first download the code:

git clone https://github.com/hyperledger/quilt
cd quilt

Maven

This project uses Maven to manage dependencies and other aspects of the build. To install Maven, follow the instructions at https://maven.apache.org/install.html.

Snapshot dependencies for this library can be included in your project by first adding a Snapshot Repository to your pom.xml file, like this:

<repositories>
    ...
    <snapshotRepository>
        <id>sonatype</id>
        <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
    </snapshotRepository>
    ...
</repositories>

Next, add the following Maven dependency:

<dependencies>
  ...
  <dependency>
    <groupId>org.interledger</groupId>
    <artifactId>ilp-core</artifactId>
    <version>HEAD-SNAPSHOT</version>
  </dependency>
  ...
</dependencies>

Gradle

To import this library into a project that uses gradle, first add the Snapshot Repository to your gradle.properties file, like this:

repositories {
    mavenCentral()
    maven {
        url "https://oss.sonatype.org/content/repositories/snapshots/"
    }
}

Next, import this library as a dependency, like this:

dependencies {
    ...
    compile group: 'org.interledger', name: 'ilp-core', version: 'HEAD-SNAPSHOT'
    ...
}

Docker

By default, the build runs integration tests which depend on Docker daemon to be running. If you don't have Docker running, you can skip integration tests using -DskipITs (e.g. mvn clean install -DskipITs).

Otherwise, to install docker, follow the instructions at https://docs.docker.com/install/

Build the Project

To build the project, execute the following command:

$ mvn clean install

Checkstyle

The project uses checkstyle to keep code style consistent. All Checkstyle checks are run by default during the build, but if you would like to run checkstyle checks, use the following command:

$ mvn checkstyle:checkstyle

quilt's People

Contributors

adrianhopebailie avatar dependabot[bot] avatar dvrajitha avatar earizon avatar gregvh avatar kai-chu avatar keefertaylor avatar nhartner avatar nkramer44 avatar reedrosenbluth avatar ryjones avatar sappenin avatar sjshekhar avatar sublimator avatar sudheesh001 avatar theotherian avatar tkuhrt avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

quilt's Issues

[ilp-core] Questions about readme

Issue by michielbdejong
Tuesday Oct 03, 2017 at 07:47 GMT
Originally opened as interledger-deprecated/java-ilp-core#89


What is/are the allowed type(s) for 'hash' in Condition condition1 = Condition.of(hash)? 32-bytes, just like for Fulfillment.of(preimage), I guess?

What is/are the allowed type(s) for 'destinationAmount' and for 'data' in InterledgerPayment.builder().destinationAmount? And I guess 'address' there has to be an InterledgerAddress object? Or can it also be a String?

Revisit ExchangeRateProvider instead of LiquidityCurve and LiquidityPoints

We need to revist the ILQP implementation and determine a proper interface for the LiquidityQuoteResponse.

Some options:

  1. Create a more general interface for org.interledger.ilqp.LiquidityCurve that has functionality on it like getAmountFor(BigInteger sourceAmount). This would allow us to replace the implementation with either an ExchangeRateProvider or just a curve of BigInteger.
  2. Move to ExchangeRateProvider in the actual interface, and use that for LiquidityCurves.
  3. Don't use ExchangeRateProvider at all.

[crypto-conditions] Make each concrete Condition/Fufillment into an Interface so they can have alternate implementations

Issue by sappenin
Thursday Oct 19, 2017 at 18:33 GMT
Originally opened as interledger-deprecated/java-crypto-conditions#75


We should make each concrete Condition/Fufillment class (e.g., PreimageSha256Condition into an Interface instead of a class so it can have alternate implementations.

This suggestion is based upon feedback in this PR: interledger-deprecated/java-ilp-core#102 (comment)

For example:

We should probably define an interface for each type so that alternative implementations can exist and still expose things like PreimageSha256Fulfillment.getPreimage().

Implement InterledgerAddress#hasPrefix

It would be convenient to have a method InterledgerAddress#hasParentPrefix which returns true if an address has a parent prefix. The address g. would return false.

Alternatively, we could implement InterledgerAddress#isRootPrefix.

Create new ilp-core

We need to pull some things out of ilp-core into their own modules. For example, codecs, ilqp, psk, spsp, etc should not be in ilp-core. See this commentary here for some more guidance:

[crypto-conditions] Consider Removing Condtion.getFingerprintBase64Url

Issue by sappenin
Thursday Oct 19, 2017 at 18:39 GMT
Originally opened as interledger-deprecated/java-crypto-conditions#76


See discussion in this PR: interledger-deprecated/java-ilp-core#102 (comment)

The reason Condtion#getFingerprintBase64Url was introduced was to try and create a truly immutable implementation of each condition. However, this encoding is a bit ambiguous (e.g., is padding used, or not, etc), and while this ambiguity could be cleared-up in Javadoc, perhaps it's better to simply remove this method entirely, and return a copy of the bytes in any implementation of Condition#getFingerprint.

The downside of this is possibly performance, but as @adrianhopebailie indicated, these are only 32 bytes, and if somebody encounters a perf problem, we could potentially add a new method to just return a reference to the array. The reason we aren't doing that now is mutability -- returning a reference to the array would allow an external caller to mutate the array (though this is likely already possible via Reflection, so until Java introduces an immutable byte array, there's probably not much use in trying to guard against this -- unless we want to only store a String, but that has its own downsides due to potential encoding/decoding mistakes on the part of a developer).

[crypto-conditions] Clarify Threshold Fingerprint Generation

Issue by sappenin
Monday Jul 24, 2017 at 15:52 GMT
Originally opened as interledger-deprecated/java-crypto-conditions#63


While investing the Java test failures, I noticed that some of the ThresholdCondition's fingerprint generation results don't line-up with the TestVectors published in the CryptoCondition RFC project.

For example, looking at the fingerprintContents binary in 0008_test-basic-threshold.json, I see the following:

308184800102A17FA12B8020451FE15F16299D495993FE692DB989E56A5230A90476F77392A3CD3213C0733F810302040382020308A32780204DD2EA7F85B3EACB8F19058E8360955C32E74C124392A1F44660739709C539C38103040000A4278020799239ABA8FC4FF7EABFBC4C44E69E8BDFED993324E12ED64792ABE289CF1D5F8103020000

However, in the Java code, the following call...

BaseEncoding.base16().encode(CryptoConditionReader .readFulfillment(BaseEncoding.base16().decode(testVector.getFulfillment())).getCondition().getFingerprint());

yields the only following fingerprint value:

31AF10E168BA56AB38BEBF27065413C76896A6683C53D746F15A6438FD2A6C66

I think the source of the problem is that method ThresholdSha256Condition.getFingerprintContents() only looks at the subconditions when computing the fingerprint. When CryptoConditionsReader reads the binary of the fulfillment in the test vector, it yields a ThresholdFulfillment with one subcondition and two subfulfillments (one RsaSha256Condition and then one PrefixSha256Fulfillment and a Ed25519Fulfillment).

Is it possible that the implementation is wrong, and should somehow be considering the genrated Condition of each subfulfillment, too?

As it stands, the fingerprint in the TestVector seems to have much more data than anything I can generate using the Java library.

[ilp-core] Improve README to explain/link-to concepts like "Condition" and "Fulfillment", etc.

Issue by sappenin
Wednesday Jul 26, 2017 at 13:45 GMT
Originally opened as interledger-deprecated/java-ilp-core#61


Much of the language in our README and Javadoc assumes people know what "Conditions" and "Fulfillments" are and other jargon are. We should not make this assumption, and always provides links or small explanations of various concepts.

One helpful source of truth is the glossary.

Also, see this comment here for another example.

[ilp-core] PSK: PskMessage does not contain an Encryption header until after its written

Issue by sappenin
Wednesday May 10, 2017 at 00:30 GMT
Originally opened as interledger-deprecated/java-ilp-core#29


Should instances of PskMessage built by the PskMessageBuilder.java contain the Encryption header before the PSK data is actually written via PskWriterFactory?

As it stands now, that header is only written by the PskWriterFactory, and so doesn't show up in Java until the PskMessage is written, and then read back into a PskMessage.

As an example, consider the following snippet...

final PskMessage pskMessage = new PskMessageBuilder().withNonce()
      .addPrivateHeader(privateHeader1)
      .addPublicHeader(publicHeader1)
      .setApplicationData(applicationData)
      .toMessage();

// This is always false (until the message is written, and then read back into a PskMessage
    boolean isPresent = decodedPskMessage.getPublicHeaders()
          .stream()
          .filter(header -> header.getName().equalsIgnoreCase("Encryption"))
          .findFirst().isPresent();

...isPresent is always false, which was unexpected.

Create a CONTRIBUTING file

I could not locate a CONTRIBUTING file in the latest Hyperledger Quilt code. Please add a CONTRIBUTING file that contains information on how to contribute to the development of Hyperledger Quilt.

[crypto-conditions] Use the term "Validate" instead of "Verify"?

Per rfcs/crypto-conditions#28, the question of whether to use the term verify vs validate was raised. The spec and the JS implementation use the term validate when referring to the evaluation of a fulfillment.

What does everyone think about changing the name of Fulfillment#verify to be Fulfillment#validate to align with the spec and the JS implementation.

I realize that, at first glance, this might take us away from the goal of being able to treat crypto-conditions as generic JCA code (best example is java.security.Signature#verify), but considering our previous discussions, perhaps it might be a good idea to use a different term like Validate so we don't confuse the difference between Signature verification and a CryptoCondition validation/verification?

Additionally, would we be better off designing some sort of wrapper interface for crypto-conditions to allow them to more pluggably be used in Java/JCA systems?

(I'm not entirely sure about this proposal, so feel free to push back with alternative ideas).

[ilp-core] Publish artifacts to Maven Central

Issue by sappenin
Wednesday Apr 12, 2017 at 17:32 GMT
Originally opened as interledger-deprecated/java-ilp-core#25


As discussed on the Java ILP community call, we need to make it easier for new developers to checkout, build, and use Java ILP code.

To that end, we should be releasing versions of each library (java-ilp-core, crypto-conditions, etc) and pushing those to Maven Central.

  1. Create account at Sonatype for the organization org.interledger (this will allow us to create any modules under that).
  2. Configure CircleCI to deploy artifacts to maven central.

[ilp-core] Enforce Regexes from RFC-15

From RFC-0015

5.) Destination addresses [...] MUST contain at least two segments after the allocation scheme prefix.

Currently, InterledgerAddress.java doesn't enforce that a destination address have at least 2 segements (i.e., g.foo is allowed in the InterledgerAddress implementation, but should not be).

We should update #isValidInterledgerAddress to utlilize a different regex depending on whether or not the String ends with a period [.]. Additionally, we might consider improving the error output instead of just saying, "reference ILP-RFC-15."

Problem in tests classes

Having problems compiling ilp-core I commented some lines to run the test classes and build packages.

Classes are:
InterledgerErrorOerCodecTests (lines 122 and 137)
IlqpCodecTests (line 95(

(line like: assertThat(error, is(packet)); )

I had to comment this line to run the test. Is any problem with that ?

I'm using Eclipse, compiling with java 9.01 with Maven 3.5.2

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.