# Clutter AD4M integration Design Outline
The following document outlines what I see as the major consideration in integrating ad4m with clutter. I'm also attempting to generalize these considerations as they may be useful patterns for ad4m in general.

- [ ] encapsulated expression icons
- [ ] language icon development scaffolding
- [ ] extend clutter dna to store ad4m expression metadata
- [ ] allow ad4m executor to use same holochain conductor as nix-shell for enhanced developer experience
## encapsulated expression Icons
I'm currently working on a default icon for mew expressions. The goal here is to create an icon that encapsulates the basic mew interactions (lick, reply, share, mewmew). This way, any ad4m compatible app can recognize the url and replace it with the default icon (thus the mew can be interacted with from Perspect3ve, flux, etc.) As of now, I have a basic `Icon.svelte` and `ConstructorIcon.svelte` component (both the `reply` and `mewmew` buttons display the `ConstructorIcon` component).

Ideally, clicking on the `Publish Mew` button in the constructor would internally be able to make use of the `createPublic` function in `adapter.ts`. The same would be for the `share` button.

The current approach (from the ipfs-notes language) is to pass in a `commitExpression` and `discard` function into the `ConstructorIcon` component, which requires UI developers to define their own function to pass in to the component, even though it should always be `ad4m.expression.create()`.

> Nico: I regarded `commitExpression` as a suggestion for a standardized interface for ConstructorIcons. Yes, any UI that allows for dynamic Language Icons would pass in `create()` from the `expression` client.

I'm wondering if it would be possible (and if it is something we should explore) to not need to pass in these functions as parameters, and instead define them inside the component?

> Nico: I don't think Icons should have their own `Ad4mClient` instance. They would need to know about the executors graphql port and open their own websocket. Discussed this in PIP-0002: https://github.com/perspect3vism/PIPs/blob/main/pip-0002.md

Another option would be to only pass in an `Ad4mClient` instance to the component, where the functions could still be encapsulated inside the components (as opposed to calling functions defined within `adapter.ts`.

> Nico: Also don't like passing in the whole `Ad4mClient` as the ConstructorIcon should only be able to create expressions.
> --> I think the best option is, similar to perspective views as defined in PIP-0002, pass in only the ExpressionClient.

The other aspect of this is the `lick` button, which does not create an expression but calls a zome function of the DNA which stores the expressions. Is it possible to get `LanguageContext` from `Ad4mClient` so that the icon can call dna zome function like `LanguageContext.Holochain.call()`? In this case we would be calling either the `lick_mew` or `unlick_mew` zome function.

> Nico: Languages can have "Interactions". I've added types for those in the early months of Perspect3vism and you can see all Languages returning an empty array - but never had a need to implement the full feature. The idea is that Languages can create Interaction objects and the UI can get them for a given expression to show a dynamic list of things the user can do with the expression.
See: https://github.com/perspect3vism/ad4m/blob/ede9a37bdf562a2c488dbb0ba215c0ad4f7f76f4/src/language/Language.ts#L35

## language icon development scaffolding
The idea here is to create a basic we app that can be spun up quickly during development and the expression icon can be injected into the web page.

There are a few considerations for this:
1. the svelte components can be compiled using a separate rollup config and then injected into a webpage
2. the entire language, including the svelte components, can be bundled like normal into `bundle.js` and then the icon can be injected as a web component in a similar way as it is in perspect3ve

> Nico: :+1:

## extend clutter dna to store ad4m expression metadata
Currently, the clutter ad4m language does not handle ad4m expression metadata. The goal here would be to extend the dna entry structures to work inject ad4m metadata. Ideally, being flexible enough to work with out without ad4m metadata.

> Nico: Much better would be if we could fill the metadata with data from the Holochain header. Timestamp should work ootb. Would be fine with using the HC agentpubkey for author for now, and fix this later when we have implemented the HC<>DID bridge. I wonder if we can get the signature out of Holochain somehow...

## integrate nix-shell conductor with ad4m executor conductor
Currently, nix-shell and ad4m cli spin up separate holochain conductors. For clutter development purposes, it may be helpful to integrate the two so that the same conductor is being used.