As I write the first version of this, many of the foundational architectural elements have not yet been built. Ceptr is a work in progress without a fully formed and defined API, and Decko, the platform, hasn't quite yet emerged from Wagn the web application. The last three chapters are not yet written and they concern issues of central importance for Cetpt Cards to become possible. We will proceed to describe Ceptr integration with cards as if we already had these fascilities available for implementation. This isn't all bad as it may help the tool builders concentrate on the most important work.

Both Ceptr and Decko are development platforms and support the idea of extending, or really completing the platform with custom applications. This means that we will need integration components on both sides. As a Ceptr developer, one implementation choice would be to read and write card data directly, maybe through Rack based middleware interfaces to maximize in-process advantages, maybe through ruby/go cross APIs via ffi, or less integrated configurations with networked connections between system components.

Alternatively, the Decko interacting Ceptr instances might choose not to access card based data, and instead would support Decko applications by exporting a representation of its data to the Card based API and act as a participant in the networked card model to be described in Cards on the Move.

It would also be simple enough to arrange for Decko events from life cycle triggers on stored cards to trigger ceptr actions at the edges. If you needed to, you could even coordinate with sub-action events, for example reading or initializing a new card, before, after or around validation or commit, etc. New cards with signatures and signed objects could be created with fine grained control through interfaces already defined and in use in implementing

or .

As a Decko developler, I will want to access holochain based services in order to seemlessly integrate trust features with card applications. We will need/want various services from Ceptr agents. From the Decko/ruby side, I can implement an exportable view of ceptr and holochain information as cards. It is a matter of programming ceptr instances to respond to a protocol the provides what the Decko app needs.

One thing is pretty apparent, all of this will require programming on both sides of the interface. It is likely that some features and functions need to be available on both sides and it will be hard to tell if you are working on a ceptr interface for decko or a decko interface for ceptr. Could be many of the system components will be used in both directions.

The bottom line is that the integration components might be implemented in either platform and used in both when they are linked, so at some level it doesn't matter if they are Ceptr modules for Decko or the reverse, it is all part of the customizing and building of apps that use both platforms in an integrated way.