DBoM IOTA Agent

An example agent that uses IOTA for persisted storage and exposes the CQA (Commit-Query-Audit) interface as required by the DBoM gateway

Table of Contents generated with DocToc

• How to Use
  • API
  • Configuration
• Private IOTA Tangle
• Helm Deployment
• Multi-Node Channel Support
  • Supported:
  • Limitations:
    • A possible solution to deal with these limitations is provided as an example here
• Platform Support
• Getting Help
• Getting Involved

How to Use

API

Latest OpenAPI Specification for this API is available on the api-specs repository

Configuration

Environment Variable	Default	Description
DB_PATH	db	The path where the json asset db is stored
DEPTH	3	How many milestones in the past tip selection starts
LOG_LEVEL	info	The verbosity of the logging
MAM_MODE	restricted	Type of MAM channel created
MINIMUM_WEIGHT_MAGNITUDE	9	How much proof of work is done
PORT	3000	Port on which the gateway listens
PROVIDER	https://nodes.devnet.thetangle.org:443	IOTA node to send and query transactions from
SECURITY_LEVEL	2	Length of signature
JAEGER_ENABLED	false	Is jaeger tracing enabled
JAEGER_HOST	``	The jaeger host to send traces to
JAEGER_SAMPLER_PARAM	1	The parameter to pass to the jaeger sampler
JAEGER_SAMPLER_TYPE	const	The jaeger sampler type to use
JAEGER_SERVICE_NAME	Iota Agent	The name of the service passed to jaeger
JAEGER_AGENT_SIDECAR_ENABLED	false	Is jaeger agent sidecar injection enabled

Private IOTA Tangle

This agent is created to directly interface to the public IOTA node. You can also create you own private IOTA tangle. A private Tangle is one that you control and that contains only nodes that you know.

You may want to set up a private Tangle if you want to test an application without using a public IOTA network such as the Mainnet or the Devnet where everyone can see your transactions in the public Tangle.

Please refer to this link to know more about how to setup a private IOTA tangle.

Helm Deployment

Instructions for deploying the database-agent using helm charts can be found here

Multi-Node Channel Support

With the default IOTA agent, sharing channel information between 2+ nodes is currently shared by manually copying over that channel configuration to the necessary nodes. This method currently supports the following channel access abilities.

Supported:

• 1+ node read write
• 1+ node read write, 1+ node read only
• 1+ node read write, 1+ no access to channel
• 1+ node read write, 1+ no access to channel due to no/different side key
• 1+ node read write, 1+ no access to specific assets
• Same channel across 2+ nodes, but with different name for each node
• Access to asset data without a dbom node
  • Use Iota MaM Explorer
  • Nodejs @iota/mam
  • Nodejs @iota/mam.js

Given the current implementation of the example agent, there are a few limitations.

Limitations:

• Duplication of asset ids across the nodes
  • IOTA does not throw error if writing to an existing MAM address
  • Can lead to inconsistent state
• Cannot share same db file
  • This example agent uses lowdb which is local
    • Option to use a different db with multi-node access controls

Platform Support

Currently, we provide pre-built container images for linux amd64 and arm64 architectures via our Github Actions Pipeline. Find the images here

Getting Help

If you have any queries on iota-agent, feel free to reach us on any of our communication channels

If you have questions, concerns, bug reports, etc, please file an issue in this repository's issue tracker.

Getting Involved

Find the instructions on how you can contribute in CONTRIBUTING.