Holochain Forum

"Standardised" common zome traits

Standardised common 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 would also faciltate better interopability between apps as well as speed up development.

Topic for discussion: What possible standard traits are there and how could we get a process going where we develop a few of these?

Working doc: https://hackmd.io/QSVLhFcVRsmkeuhEAOIcfw?both

Implements

List which other standard traits (and possibly trait versions) a zome uses. Or Rust possibly provides that functionality already? But 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

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.

A common way to manage ownership would faciltate better interopability between apps as well as speed up development.

Doc for collaboration here: https://hackmd.io/kWfnGNR4Ta-K1h0jpK71Hw?both

Metadata

Both zome level fields and entry level fields. Standard info found in zome.json (zome_description, …) as well as zome/app specific.

Preview

Renders a human readable preview of an entry or list of entries, possibly in the form of a webcomponent. Example: embed a nice looking representation of a chat entry in a humm blog post @nickmitchell?

Editor / 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.

1 Like

@ViktorZaunders and @guillemcordoba, possibly this is something for you to sink your teeth into at the Portugal hackathon?? I Know… finishing MailBoox… but one could always hope :slight_smile:

1 Like

Great start, thanks. Would you prefer I suggest things in this thread or the HackMD? Some come to mind right away:

  • BlobStorage: Supports the storage and retrieval of chunked blobs and their manifests.
  • 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.
  • 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? )
  • 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 )
  • Timestamping: Able to provide a timestamp for external entries, at varying levels of proof. Naturally, this can support Timestamped.
  • DIDResolver: Able to take responsibility for resolving W3C Decentralised Identifiers for the data this DNA’s DHT contains.
  • 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>.
  • 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).
  • 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.
  • Taxonomy: provides a list of categories for other things.
  • Notification: Allows agents to subscribe to things they want to be notified on; emits notification signals to clients.
  • 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.
  • Notary: Able to witness, and guarantee the uniqueness of, events.
2 Likes

The big ones we need that haven’t already been mentioned are:

  • Indexing patterns for browsing and retrieving other entries. I’ve seen anchors and DAGs (both have their use-cases), there are probably other flavours needed too.
  • 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.
  • LinkRegistry: zome that tracks links incoming / outgoing between the host DNA and other DNAs using XDI Link Contract schema. We would also want this as a standalone DNA that tracks links between two other DNAs.
  • 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.
4 Likes

@pospi’s mention of XDI link contracts reminds me of something I meant to say yesterday: whenever possible, we should lean on existing standards for everything we create.

2 Likes

Great additions! I compiled all ideas to one list and tried to identify some groups.

Holochain commons

Zome traits
Design patterns
Standalone DNA / hAPP
Potential core functionality

Next steps? One could easily see this evolve into a community run thing where developers from different projects collaborate on common functionality to strengthen the ecosystem and increase interoperability.

:+1::+1::+1:

@harlan, what library functions / zomes did you have in mind?

Awesome @kristofer ; thanks for compiling our ideas into that document.

@guillemcordoba are you aware of this thread yet? cuz I think your presence would be super valuable.

@kristofer if you have bandwidth to set these kinds of things up, a group of us have started a project on CoMakery where our goal is to list and fund possible contributions to our digital commons: https://www.comakery.com/missions/45

One possibility would be to list these works under a CoMakery project and to solicit crypto funds for their implementation. But a good framework for managing and governing contributions would need to be developed first :wink:

1 Like

It also occurs to me that a group with a larger vision could be pulled into this — they are probably already thinking about conventions for data exchange that could be used as starting points. I’m thinking specifically of the Open App Ecosystem group on Loomio, who are seeking to define common language for interoperable apps. I think people in the ActivityPub world are big into this too.

I don’t think strict standards compliance is a useful goal, because that stifles innovation (I’m thinking about how ValueFlows are taking a radically different approach to an existing thing, in ways that could change the game known as economics). But it does pay to recognise and collaborate with the work already being done!

1 Like

:slight_smile: Yeah, that could be a good way to develop common tools and functionality actually. Start co-developing the tool needed to continue co-developing. Some basic DAO-functionality like managing funds etc. Could the foundations use the REA vocabulary / HoloREA? In the process of developing that framework, needs for common zomes, functional libraries etc will arise. Develop those in separate branches / sub projects and let them become part of the Holochain Commons.

In the process, ideas will also pop up that could be branched of as commercial enterprises. I’m thinking of stuff discussed in another thread, such as standard middleware functions not part of Holochain core:

  • Cron like functionality
  • Caching
  • Indexing
  • Search
  • etc

… stuff that would give someone willing to pay a monthly Holofuel fee access to more “enterprise like” functionality. Then it would be a good idea to set something up similar to Consensys or Infura from the ETH galaxy.

Maybe this is a talking point for the developer call?

Btw @pauldaoust & @pospi, I think both the Open App Ecosystem and CoMakery groups sound really interesting!

But… I also get a sense that what you are describing, like “common language for interoperable apps”, that is quite high level stuff. Which is totally needed and vital for the long term development of the eco system. I am more of a plumbing type of person. I would like to build the actual tools and libraries needed today. The stuff that could facilitate the “cambrian explosion” of apps we are hoping to appear on holochain in the short to medium term.

1 Like

Hi @kristofer, @pauldaoust and @pospi! Great to be having these kind of conversations.

Regarding standards and traits between happs… I’m not sure :slight_smile:

With the holochain architecture being as it is, my first instinct is to bring all possible bridging-like functionality to the frontend, where dynamic piping is much easier. And actually, since all holochain entities are hashed, in most cases they can be referenced as if they existed in a global “namespace”, and this makes building generic zomes (as in: a “reviews” zome that can review any kind of entry, or a “comments” zome that can reply to any kind of entry) extremely easy. In the cases where you don’t need “statically typed” references (in those cases maybe rely on explicit and normal holochain links) you can have cross-zome or cross happ functionality without any bridging on the holochain side. In the _Prtcl where are building infrastructure for these cases here.

The cases I see where bridging needed are somewhat limited. Maybe when you need to share information between peers in two different DHTs (eg. Subscriptions), or to avoid ending up in an inconsistent entries state that could be possible if you only rely on the frontend. If your validation rules rely on entries on other happs you’ll need either:

  1. To have a hard dependency to the other app, since the rules need to be deterministic all peers need to have the happ installed.
  2. To rely on the agent that brings the information from one space to the other, and in this last case you may as well bridge through the frontend.

Maybe I’m wrong on this, would love to be proven so with examples :smiley: as I don’t have that much experience building complex multi-dna systems like REA.

Regarding the commonly needed zomes/mixins, I actually like this idea a lot, it’s great having these starting points on top of which to build (I would add roles and generic tagging, and also WebRTC discovery!). Actually I think this initial pack will be built by the community itself without much effort, most of them are not so hard to build.

However I’d personally focus more on helping/educating the community to build and design applications this way by default, by finding ways to come closer together as a community to see possible sharing points, or increasing the education resources, design trainings, etc.

This way, we would increase the factor by which we build on top of each other and have much more visibility on what we all need. We’d also follow the principal “build concrete first, generalize after, build adapters to make interoperable what’s left” which I personally prefer to standards.

Also the few existing standards I’ve wanted to play with directly assume http protocol and URL links in which the entities live, and http assumes client-server interaction. It just feels weird to build on holochain, and only really works when you add Holo to the equation (eg. OpenBadges, which I started building on Holochain but ended up with this). I don’t know to which point making a bridge-app that follows the standard but does things the holochain way is worth it, I guess it depends on each individual case.

I’m very grateful that you made visible these online groups/communities, did not know about them but will review for sure.

From now on, I’ll try to be more active in this forum (if I think the community should come closer together, I should to apply that to myself first :slight_smile: ). So see you around!

Cheers!