Trinity also aims to be a software platform. We’ve started work on what we’re currently referring to as our Plugin API. Plugins will be software that runs alongside Trinity and which is managed by the Trinity process. A plugin could be something as simple as the code which reports information to ETHStats, or something as complex as implementing Swarm. Anyone who runs a Trinity node should be able to install a plugin as easy as installing a normal python package.

We’re already using experimental plugin APIs to build our transaction pool. The Trinity Python REPL is also written as a plugin, and most of our new features are now being built on this API. By dogfooding these APIs we can be sure that they support the broad use cases we’re targeting as well as ensuring that they work as expected.

One of the more compelling use cases for plugins that we’ve thought up are application specific plugins for the popular Ethereum protocols. Using MakerDAO as an example, the plugin would likely expose some new JSON-RPC APIs which expose specific data like the total supply of DAI . In the case of something like Augur the plugin could run a webserver to the Augur web application.

Protocols like TrueBit requires external software to execute the off chain computations as well as check the results of other computations for correctness. We think distributing these types of software as plugins will lower the barrier to entry for wider participation in these protocols. It may also be easier to write them as plugins since Trinity will manage starting and stopping the application as well as providing it with a reliable connection to the network.

There are many more compelling use cases for plugins which will have to be explored in another blog post.