interledgerjs / ilp-packet Goto Github PK
View Code? Open in Web Editor NEWMoved to monorepo in interledgerjs/interledgerjs
Home Page: https://github.com/interledgerjs/interledgerjs
License: Other
Moved to monorepo in interledgerjs/interledgerjs
Home Page: https://github.com/interledgerjs/interledgerjs
License: Other
It might make more sense to change these fields from amount
and account
to destinationAmount
and destinationAccount
. Amount and account are only used in the Ledger Plugin Interface's transfer objects, which describe local transfers. Across all the other interledgerjs code, (quoting, payments, etc.) we use destinationAmount
and destinationAccount
. It might be clearer if we used the same field names here.
For a certain group of interledgerjs repos, the integration tests make sure that their master branches are always compatible with each other. Breaking changes to e.g. ilp-connector only pass those integration tests if they are done in a named branch, linked to corresponding changes in e.g. ilp-plugin-virtual where necessary.
IIUC, this repo is outside that group of linked repos, and a breaking change was just merged that makes this repo's master branch incompatible with the master branches of our reference stack? Is that intended behavior, or should we maybe configure integration tests on this repo as well?
3.1.0
to 3.2.0
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
codecov is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
The new version differs by 3 commits.
e427d90
feat(services): add azure pipelines (#114)
023d204
Use small HTTP dependency (#110)
500f308
Update Readme
See the full diff
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
In #17, a fulfillment packet was introduced, which can be used as a standard representation of the arbitrary transport-layer or application-layer data, that may be passed back from the receiver, along the payment path, to the sender.
However, in other contexts, the term 'fulfillment' is already used to refer to the preimage which unlocks the hashlock of a conditional transfer.
@justmoon Wouldn't 'serializeIlpFulfillmentData' be a better name than 'serializeIlpFulfillment'?
for consistency with interledgerjs/btp-packet#4 (comment)
serializeIlpReject
puts triggeredBy
before the message
, while the ASN.1 definition in interledger/rfcs#361 has the message first. Which one is correct?
Also, it would be useful for IlpPacket
to export a separate interface for IlpReject (rather than just using IlpRejection).
3.0.1
to 3.1.0
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
oer-utils is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.
The new version differs by 5 commits.
4a0fd30
3.1.0
e0813c4
fix: reject variable integers of length zero
3cdb8ab
chore: re-enable code coverage reporting
c072342
chore: update dependencies
f3dc629
feat: allow using JS numbers instead of BigNumbers
See the full diff
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
10.11.0
to 10.11.1
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
Hi, I cant see any comments on releases that indicate the different levels of compatibility with the various ILP versions? I need a v1 compatible ilp-packet but am not sure which version I should pull. It looks like master is implementing v4. Many thanks.
It should return the type and the deserialized contents
Relevant to:
interledger/rfcs#440
See impl:
https://github.com/interledgerjs/ilp-packet/blob/master/src/utils/date.ts#L43
Considering:
> new Date().toISOString()
'2018-07-16T08:37:52.250Z'
Non significant 0s and decimal points should be stripped from the microseconds at the least ? ( at the least
meaning I'm not entirely clear about all the rules, but have noticed some by playing briefly with the encoding features of ASN.1 studio from OSS.com )
Useful for connectors because the data isn't for them anyway, so there's no reason to touch it
https://github.com/interledger/rfcs/blob/master/asn1/InterledgerPacket.asn#L43 says that the InterledgerPacket's data
field should be "a length-prefixed header", and that seems to be what https://github.com/interledgerjs/ilp-packet/blob/master/index.ts#L22 does.
But when I read the ASN.1 without reading that comment, my interpretation is that PACKET.type
is an ASN.1 OpenType of the PACKET CLASS, and although I couldn't really find a good reference on asn.1, from what I've read, I would expect PACKET.&Type ({PacketSet}{@type})
to just be replaceable with e.g. InterledgerProtocolPayment
if typeId is 1?
cc @justmoon
see also interledgerjs/btp-packet#10
5.2.6
to 5.2.7
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
@types/mocha is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
Companion to interledgerjs/ilp-connector#405
4.2.1
to 4.2.2
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
@types/chai is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
If you don't specify all of the fields for a packet type when serializing you end up with unhelpful errors. This module should use default values where appropriate and throw specific errors when required fields are undefined.
Hi there,
I was looking through the implementation to see how the ASN.1 GeneralizedTime value is encoded for the quotes by liquidity response.
Concrete documentation of the ASN.1 spec seems hard to come by but from various sources it appears that most of the time portion is optional, including time zones
For example, the generalized time entry at wikipedia says
A GeneralizedTime is a time format in the ASN.1 notation. It consists of a string value representing the calendar date, as defined in ISO 8601, a time of day with an optional fractional seconds element and the optional local time differential factor as defined in ISO 8601.
Other documentation describes the format as:
Type GeneralizedTime takes values of the year, month, day, hour, time, minute,second, and second fraction in any of three forms.
- Local time only. ``YYYYMMDDHH[MM[SS[.fff]]]'', where the optional fff is accurate to three decimal places.
- Universal time (UTC time) only. ``YYYYMMDDHH[MM[SS[.fff]]]Z''.
- Difference between local and UTC times. ``YYYYMMDDHH[MM[SS[.fff]]]+-HHMM''.
This is echoed in ASN.1 β Communication Between Heterogeneous Systems (page 201) available at www.oss.com
A value of type GeneralizedTime is a character string of type VisibleString with one of the following lexical restrictions:
a ) a string of the form "AAAAMMJJhh[mm[ss[(.|,)ffff]]]" standing for a local time, four digits for the year, two for the month, two for the day and two for the hour (the value 24 is forbidden), followed by two digits for the minutes and two for the seconds if required, then a dot (or a comma), and a number for the fractions of second (the maximum precision depends on the application); orb ) a string of a) followed by the letter "Z" (which would denote a UTC time); or
c ) a string of a) followed by a string "(+|-)hh[mm]"
These sources all seem to confirm more or less the same thing
Given all of this, i think the javascript implementation is incorrect, though my javascript is rusty.
It also makes me wonder whether it is preferable to use a more rigid format for date-time information, i will log a question for the RFC separately.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.