Po.et JS is a small library that provides methods to easily create and sign Po.et Claims according to the
Verifiable Credentials Data Model. These claims are JSON-LD
documents. As such, you can define your own JSON-LD
@context to map your submitted Claims.
Po.et does provide a few default
@context objects that you can extend or override in the
createClaim function. The current defaults are as follows:
npm i @po.et/poet-js
Note that the Po.et network currently uses Ed25519Signature2018, which requires a Base58 form of the Ed25519 Private Key. You can use the KeyHelper utility to generate a base58 public/privateKey pair, if you do not yet have one.
WARNING Do not use the example private key in these documents. No one should have access to your private key, and it certainly should not be in the example documents of a library. If you use the example private key, others can make additional claims using the same key.
configureCreateVerifiableClaim() to create a
createVerifiableClaim function to create an unsigned Verifiable Claim.
getVerifiableClaimSigner() to create the proper function to sign and verify your claims.
Example 1: Create and Sign a Verifiable Work Claims
Once this claim is created, you can publish it to a Po.et Node:
Example 2: Create and sign a Verifiable Work Claim with overriding context
If you want to extend or override the default context defined by Po.et, you simply need to pass a context object into
Notice you don't need to wait for the server's response to know the claim's ID. You don't even need to publish it!
claim.id is readily available right after creating the unsigned verifiable claim.
npm run build to compile the source. This will run TypeScript on the source files and place the output in
dist/ts, and will then run Babel and place the output in
Currently, we're only using Babel to support absolute import paths in the unit tests. This is due to how TypeScript and Babel process absolute paths. On build, TypeScript transforms the .ts files into .js and places type definitions in .d.ts files. Babel, with the module-resolver plugin, will then transform the absolute paths in these .js files into relative paths, but will leave the .d.ts unchanged, which still have absolute paths. This causes issues with clients of the library that want to use these TypeScript definitions.
Run all tests with
Coverage reports are created with Istanbul, which can be generated by running
npm run coverage.