Implementing cross-app agent centricism

I’ve logged a requirement for managing one’s commitments to all work, across all projects.

The way that Holochain conceptualises “agent centric” means this actually isn’t a feature that Holochain provides for. In standard arrangements, the commitments one has made within community A are isolated within the apps of community A and cannot be accessed elsewhere.

It seems to me that these kinds of use-cases need to be handled in the frontend. Is anyone else thinking about how to build them yet?

4 Likes

Great use case to surface! Is there any way your user’s source chain could help with this?

I’ve given some options on the linked GH issue; see what you think.

1 Like

Replied there, but maybe the deliberation is better done here for visibility… sorry, not sure which conversation context is better :confused:

Short version: this needs to be something that can work for normal users without having to do advanced configuration or compromise the security of their conductor. I’m not sure that opening up the admin API to the app satisfies those criteria…

Agreed — certain operations (spawning new DNAs, instances, and agents) will be critical for most userland apps, including Holo-REA I suspect, but right now the security UX is not great. I’d love to see the admin API become safer to use, and I have a few ideas:

  • The hApp bundle could whitelist certain admin actions; e.g., “clients accessing this interface can only fork DNAs with hash X, and can create new agents with new name strings but cannot create new public keys for those agents”.
  • The conductor could pop up dialogs whenever a client is trying to perform an admin action.
  • Clients should have public keys and be whitelisted.

In the meantime, do you think it’d be safe to prototype some patterns based on assumptions that the admin API will be ‘safer’ for the agent in the future?

I don’t really like the idea of implementing features against an API that is unstable and has no protocol spec that it’s following, tbh. Tends to be a good recipe for churn and maintenance burden. So, these kinds of things tend to end up going on the backburner behind other stuff that comes with more guarantees about future relevance (; Which is fine, I just wanted to log this as a target to aim for!

1 Like