Module Manifest

The module manifest – dapplet.json – is a JSON that is placed in the root of the module and contains all the required information that is needed to deploy the module and add it to the dapplet registry. It is a necessary part of every module.

Here is an example of the module's manifest:

1{
2 "name": { "$ref": "package.json#/name" },
3 "branch": "default",
4 "version": { "$ref": "package.json#/version" },
5 "type": "FEATURE",
6 "title": "Dapplet Template",
7 "description": { "$ref": "package.json#/description" },
8 "main": { "$ref": "package.json#/main" },
9 "icon": "src/icons/dapplet-icon.png",
10 "contextIds": ["twitter-adapter.dapplet-base.eth"],
11 "config": {
12 "schema": "config/schema.json",
13 "default": "config/default.json"
14 },
15 "dependencies": {
16 "twitter-adapter.dapplet-base.eth": "0.9.0"
17 }
18}

Manifest Structure#

Some fields refer to package.json. They have "$ref" children with the field link values. "$ref" is a part of JSON Reference specification. More details:

All these fields are obligatory. Set them in package.json:

  • name – the name of the module. The name is the ID of your module so it must be unique.
  • version – a version of the module. Refer to SemVer format: https://semver.org/
  • description – a brief description of your module. It's displayed in the dapplets list inside the extension's overlay and in the Dapplets Store.
  • main – sets the entry point for the dapp.

Other parameters are specified in dapplet.json:

  • branch – used for resources with A/B testing. In most cases, you just need to leave the "default" value. However, if you want to create different versions of the module for different versions of the web-resource you can make several branches and run them depending on some condition.

    The Twitter Adapter (twitter-adapter.dapplet-base.eth) uses branches, here is an example of how it works:

  • type – indicates the type of module. There are four types:

    • FEATURE – a dapplet, its main part that interacts with the adapter and the Core

    • ADAPTER – a site-specific adapter that allows dapplets to work with site specific contexts

    • INTERFACE – a virtual adapter which provides an interface for dapplets so they are able to use several site-specific adapters

    • LIBRARY – a dynamic adapter. It provides the work of all other adapters. It's specified in the extension's settings

      set dynamic adapter

  • title – a module's name. It's displayed in the extension's dapplets list, in the Dapplets Store, on the NFT, etc.

  • icon – a link to the dapplet's icon. It's an optional parameter.

  • contextIds – a list of resources where the module is loaded and activated. You should list site domains or a name of the module (adapter, interface), where domains are already listed.

    For example, you can specify certain domains in the adapter's manifest:

    1// ./adapter/dapplet.json
    2{
    3 "contextIds": [
    4 "twitter.com",
    5 "www.twitter.com",
    6 "mobile.twitter.com",
    7 "twitter.com/id",
    8 "www.twitter.com/id",
    9 "mobile.twitter.com/id"
    10 ],
    11}

    and specify this adapter in the dapplet's manifest:

    1// ./dapplet/dapplet.json
    2{
    3 "contextIds": ["twitter-adapter.dapplet-base.eth"],
    4}

    So this dapplet will be loaded and activated with the same resources as the adapter.

    There is an opportunity to specify the dynamic context. It means that this context can appear on the page at any time and the module will start working. It may be a tweet or another type of post:

    {
    "contextIds": ["twitter.com/1551967807428071431"],
    }

    The last way to specify ContextIDs is setting the contexts determined by content detectors. Currently they are specified in the Dapplets extension and only one is available – "video" context:

    {
    "contextIds": ["video"],
    }

    This means that the module works if there are <video> elements on the page. This is also dynamic context.

  • config – a dapplet's config. It's an optional field that's used only in dapplets. The idea is to add some settings to the dapplet which can be changed in the extension. For more information look here.

  • overlays – a list of the overlays that use the dapplet. If your dapplet uses the overlay you have to add its name/ID and the development server here:

    1{
    2 "overlays": {
    3 "example-04-overlay": "http://localhost:3000"
    4 }
    5}

    An assets-manifest.json should be available at the root of overlay's URL. Example:

    1{
    2 "index.html": "index.html",
    3 "main.js": "main.js"
    4}

    Check out how to make a dapplet with an overlay here: Ex04: Overlays

  • dependencies – adapters which are used in the module. You have to set dependencies for the FEATURE and ADAPTER modules. Set the site-specific and virtual adapters in dapplets, in the site-specific adapters – the dynamic adapter:

    1{
    2 "dependencies": {
    3 "dynamic-adapter.dapplet-base.eth": "0.6.22"
    4 },
    5}
  • interfaces – a list of interfaces (virtual adapters) that the adapter implements. It is an optional parameter for site-specific adapters. If some dapplet use a virtual adapter from this list the site-specific adapter runs in supported contexts.

    1{
    2 "interfaces": {
    3 "identity-adapter.dapplet-base.eth": "0.3.0"
    4 }
    5}

Manifest Update#

The changes in dapplet.json will not be considered in the dapplet registry when you will deploy new module versions. To change some information open the Dapplets extension, connect the wallet of the owner or admin of the module, and go to the Settengs -> Developer. You will see the Registry chapter with your published module. Open its settings.

developers tab

Here you can change: title, description, icon, ownership, admins, context IDs.

module settings