7. Using custom connectorsΒΆ

By default, all identities created using the Jolocom library are indexed in a contract deployed on the Rinkeby test network, and the corresponding DID documents are stored on IPFS.

The interaction with the corresponding networks is delegated to two components:

Using custom connectors (e.g. to experiment on a private network) is also supported.

You can also supply your custom implementations of both connectors, in case your identities are indexed on a private Ethereum deployment, or you would like to connect to a custom IPFS cluster. A custom implementation might look as follows:

class CustomEthereumConnector implements IEthereumConnector {
  async resolveDID(did: string) {
    console.log(`Intercepted request for ${did}`)
    return fetchFromCacheIfAvailable(did)

  async updateDIDRecord(args: IEthereumResolverUpdateDIDArgs) {
    console.log(`Intercepted request for ${args.did}, updating to ${args.newHash}`)
    return queueUpdateRequest(args)

class CustomIpfsConnector implements IIpfsConnector {
  async storeJSON({ data, pin }: { data: object; pin: boolean }) {

  async catJSON(hash: string) {

  async removePinnedHash(hash: string) {

const customRegistry = JolocomLib.registries.jolocom.create({
  ethereumConnector: new CustomEthereumConnector(),
  ipfsConnector: new CustomIpfsConnector()


Using only one custom connector is also supported.

In the event a connector is not provided when instantiating the registry, the default implementation provided by Jolocom will be used.

In some cases, it might make sense to define connectors that rely fully on databases maintained in a centralised manner. The current library API supports this use case as well.