id: plugins-overview title: D-TA Plugins Overview sidebar_label: Plugins Overview

Out of the box Milagro D-TA doesn‘t do much: a Principal gets a public key from a Master Fiduciary and at a later date can request the corresponding secret key. (Although it does this in a highly secure, and fully auditable way). However this basic capability unlocks a huge range of potential uses cases, some of which related to the Prinicpal - what the keys can be used for, and some relate to the Master Fiduciary - how the seret key is kept safe (a.k.a. custody). Open source “vanilla” Milagro is an attempt to engage a wider community to make the communication between these parties as robust as possible, the plugin framework enables developers to extend Milagro’s core capability an apply it to solve real world problems.

Out of the box Milagro comes with two plugins:

  1. Encrypter - allows the principal to use the public key to encrypt a string, then get the secret key back from the Master Fiduciary D-TA and decrypt it
  2. BitCoin Address - uses the public key to genarates a Bitcoin address and the constructs the corresponding secret key only when it is needed (this is a neat trick using eliptic curve magic).

This is Not Secure

The point of these plugins is to show you how the framework works and encourage you to develop your own, they do not (out of the box) provide a secure way to store your secret keys becasue the key pair seed is stored only in the Master Fiduciaries database.

Approach

The Milagro D-TA plugin framework has been designed with the following constrains:

  • One-at-a-Time

    Each Milagro server can only run one plugin at a time. We considered how to allow multiple plugins to interoperate but this produces significant operational and security concerns - so it doesn‘t do that! (We’d really appreciate you thoughts about that). Ofcourse if you run a pair of servers as Principal and Master Fiduciary then they can each run different plugins

  • No New Endpoints

    You can only write plugins to support the Standard Endpoints. This probably seems quite restrictive but we think it is important that Milagro D-TA operates within a defined scope and in a predictable way. Milagro D-TA is about the distributed management of key pairs, we are concerned that if the plugin framework allowed developers to add endpoints such as GET fastfood/burger?orderby=mostTasty the Milagro would just become a cool implementation of Go kit. It would be difficult for users and integrators to know what it was going to do. However

    • Let's Talk As a community we‘re excited to add new features to Milagro D-TA. Propose your new end point as a feature (or even submit a PR) and we’ll collectively consider adding it
    • Let's Fork Go ahead and fork the Milagro D-TA. (But remember that Milagro D-TA is basically a communication protcol so keep it compatible with other Milagro users)

  • Extensions

    Although we restrict what endpoints Milagro provides we give you a highly flexible way to define what data each endpoint accepts and returns via the extensions JSON prop. For example the encryptAThing plugin extends the POST /order endpoint like this:

     POST /order

 Request    
 {
     "beneficiaryIDDocumentCID" : "IPFSAddress",
     "extensions":{
         "plainText":"encryptme"
         }
 }

 Response
 {
 	"OrderPart1CID" : "IPFSAddress",
	    "OrderPart2CID" : "IPFSAddress",
	    "Commitment"    : "IPFSAddress",
	    "CreatedAt"     : 1563982017,
     "extensions" : {
         "cyphertext":"iAmEncrypted"
     }	    
 }