# Holochain commons

An open ideas document and a wish list for common functionality the dev community needs and possibly would like to develop.

[Zome traits](#Zome-traits)
[Design patterns](#Design-patterns)
[Standalone DNA / hAPP](#Standalone-DNA--hApp)
[Potential core functionality](#Potential-core-functionality)

# Zome traits

Standardised traits would allow for third party apps to better access and visualise an agents data (DNA-instances/zomes/entries) but also to interact with the data in a meaningful way. It faciltates better interopability between apps and speeds up development.

### `Implements`

List which standard traits (and possibly trait versions) a zome uses. Possibly the trait definitions in the zome code are sufficient? But I have a sense we would like to have one more level of detail - trait id, a version number etc. The information has to be accessible not only for the app developer but for third party apps calling zome functions.

(Similar to `IERC165`, `supportsInterface(interfaceId)` https://docs.openzeppelin.com/contracts/2.x/api/introspection)

### [`Ownable`](https://hackmd.io/kWfnGNR4Ta-K1h0jpK71Hw?both)

The notion of “ownership” over a digital resource is a basic pattern many Holochain applications will need. With ownership comes the user expectance of being able to transfer that ownership, to renounce ownership, etc.

https://hackmd.io/kWfnGNR4Ta-K1h0jpK71Hw?both

### `Metadata`

Both zome level fields and entry level fields. Standard (`zome_description`, ...) as well as zome/app specific.

### `Taxonomy`

Provides a list of categories for other things.

### `Preview`

Renders a human readable preview of an entry or list of entries, possibly returns a [webcomponent](https://www.webcomponents.org/)? Example: embed a nice looking representation of a chat entry in a humm blog post.

### `Editor`? or `Plugin`?
Returns a plugin editor that can be embedded in other apps. Example: Every Humm blog post embeds a "Comments Editor" from the "HoloComments" app allowing for users to comment posts.

### `Timestamped`

Entries carry metadata that give varying levels of proof that they happened at a certain moment in time. (cf [Mixin zome(s) for entry timestamping](https://forum.holochain.org/t/mixin-zome-s-for-entry-timestamping/1307/))

### `ClaimsPermissioned`

Actions are allowed or denied based on the possession of valid claims/credential (cf W3C Verifiable Credentials).

### `MembersOnly`

A special application of ClaimsPermissioned that requires a valid credential to join the network.

### `DIDResolver`
Able to take responsibility for resolving [W3C Decentralised Identifiers](https://www.w3.org/TR/did-core/) for the data this DNA’s DHT contains. (cf [Mixin zome and utility libraries for RESTful APIs and URI resolvers](https://forum.holochain.org/t/mixin-zome-and-utility-libraries-for-restful-apis-and-uri-resolvers/2071))

### `Signable`

Signing: something that allows arbitrary participants to sign other entries by hash, thus indicating that they have seen and agreed with the information contained therein.

# Design patterns

### `BlobStorage`

Supports the storage and retrieval of chunked blobs and their manifests.

**This could as well be a standalone DNA other DNAs can interact with.**

### `Indexing patterns`

...for browsing and retrieving other entries. I’ve seen [anchors](https://github.com/holochain/anchors) and [DAGs](https://github.com/holochain/basic-chat/pull/6) (both have their use-cases), there are probably other flavours needed too.

# Standalone DNA / hApp

### `Annotation`

Able to annotate other data, either in the same zome/DNA, in some other DNA, or outside of Holochain entirely. Should probably be polymorphic, e.g., `Annotation<BlogPost>`.

### `Presence`

Shows whether an agent is online, offline, available, busy, typing, idle, etc.

### `Scheduling`

Shows whether an agent is available or occupied at a given date in the future.

### `Events`

Calendars, etc. Can be composed with Scheduling to do some cool things.

### `Messaging`

Chat, IM, DM, comments, etc.

### `Posting`

Similar to Messaging but meant for syndication. May just be an application of Messaging.

### `Notification`

Allows agents to subscribe to things they want to be notified on; emits notification signals to clients.

### `Notary`

Able to witness, and guarantee the uniqueness of, events.

### `LinkRegistry`

Zome that tracks links incoming / outgoing between the host DNA and other DNAs using [XDI Link Contract](https://en.wikipedia.org/wiki/Link_contract) schema. We would also want this as a standalone DNA that tracks links between two other DNAs.

### `Presence`

Shows whether an agent is online, offline, available, busy, typing, idle, etc.

### `Identity`

Able to make assertions about facets of an agent’s identity, whether in a legally recognised (e.g., driver licensing office) or an informal capacity (web of trust).

# Potential core functionality

### `GroupAgency`

Agents can form recognisable groups with persistent identifiers; group membership (= authority to act as group representative) can be verified by third parties. Related to ClaimsPermissioned. (ping @pospi, cf [How will Holochain handle group agents?](https://forum.holochain.org/t/how-will-holochain-handle-group-agents/1095) )

### `MultiNodeAgent`

This DNA is capable of combining multiple agent public keys into one human representation. Similar to GroupAgency and may be able to take advantage of the same codebase.

### `ExistenceCheck`

Simple API that checks if entries with given hashes exist in the DNA, for use by other DNAs that need to perform referential integrity checks.

### `Timestamping`

Able to provide a timestamp for external entries, at varying levels of proof. Naturally, this can support `Timestamped`.

### `Persistent Off-Chain Storage`

Provide a way to cache expensive computations and data-structures without poluting the source chain with transient data.