Extensions can then be installed in two ways:

1. By providing the implementation in the app parameter of the clone function.
2. By declaring a module in the domain information.

The first option is suitable when the data is always going to be used by the same app – because the app will always know it has to include the extension.

The second option is more suitable if the data may be shared to other apps, because the need for the extension is declared in the data itself, and apps can load it dynamically as required.

To write an extension to be declared in the domain data, implement MeldExtensions with one or more of its methods, in a Javascript class. Then, to declare the extension in the domain, you write:

{
  "@id": "http://m-ld.org/extensions",
  "@list": {
    "≪priority≫": {
      "@id": "≪your-extension-iri≫",
      "http://js.m-ld.org/#require": "≪your-extension-module≫",
      "http://js.m-ld.org/#class": "≪your-extension-class-name≫"
    }
  }
}

Breaking this down:

• "http://m-ld.org/extensions" is the identity of the extensions list. This is a constant that m-ld knows about (it's in the m-ld.org domain).
• The extensions list is declared as a List, with the @list keyword, because extensions are ordered by priority.
• The value you give for ≪priority≫ (a number) will determine where in the list your extension appears. The highest priority is "0". The value is decided by you, based on what you know about your extensions. In most cases it won't matter, since extensions shouldn't interfere with each other.
• The "http://js.m-ld.org/#require" and "http://js.m-ld.org/#class" properties tell the module loader how to instantiate your module class. It will call a global require function with the first, dereference the second and call new on it.

Most extensions will provide a static convenience function to generate this JSON, which can be called in the genesis clone (example).