Implement the @discipl/core-ipv8 connector

[n9iels]

General

The main purpose of this PR is to implement the IPv8 attestation in extend to the existing Ephemeral attestation. This is done by implementing the @discipl/core-ipv8 connector. During the "Confirmation" step of the process data of the paper is also attested in the IPv8 trustchain and later on verified by the app.

Other improvements

Besides the implementation of the IPv8 connector a few other improvements are made as well.

• The methods used to validate the QR codes are listed in the app (see screenshot)
• Optimizing the Docker files to make use of the layer caching so npm install is not executed each time a image is build
• Reduce the amount of global variables and methods in favor of the React state life cycle
• General improvements on naming conventions, code style, removing of dead code and anti-patterns

[n9iels]

@pimotte I think this PR reached a state where a small code review can be performed :smile: The IPv8 attestation is now working, but pretty much hard coded. So the next move is to make it more dynamic by adding configuration options and do some research in how to handle the IPv8 SSIDs.

The main thing I like to receive feedback on is how the IPv8 links are passed back and forth between the service and front-end. See ConfirmStep.js and waardepapieren-service.js. I believe this is the preferred Disciple way to do it.

[pimotte]

Actually, does that mean that the ipv8 link should be communicated in the channel provided by the abundance service. If that's possible, it is preferred due to privacy.

On Fri, 29 May 2020, 15:39 Niels van der Veer, notifications@github.com wrote:

@n9iels commented on this pull request.

In clerk-frontend/src/need-wizard/ConfirmStep.jsx https://github.com/discipl/waardepapieren/pull/139#discussion_r432488726 :

• let result = await observeOffer.resultPromise
• const result = await observeOffer.resultPromise
• const attestedIpv8Link = result.claim.data
• const resultLink = result.claim.previous

Yes and now I see what you mean. That is indeed a shared shared thus the previous claim is not reliable in this case

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/discipl/waardepapieren/pull/139#discussion_r432488726, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNEWEQKF34I5XLEHRP5AQLRT63JXANCNFSM4MXADZEA .

[n9iels]

Actually, does that mean that the ipv8 link should be communicated in the channel provided by the abundance service. If that's possible, it is preferred due to privacy.

Yes that was my intention, I only didn't notice that the nlxIdentity channel was used instead

[n9iels]

@pimotte The merge conflict and npm audit are both fixed now