clone management functionality in the HDK (currently only available in the client api)

[nphias]

clone management functionality in the HDK (currently only available in the client api)

[mattyg]

Huh. Very good point.

I don't have a specific use case in mind, more of an implementation preference. I would prefer to treat cell cloning as a "backend" functionality in my apps, where it is kept in the coordinator zomes, rather than the UI.

It definitely makes sense to me that a cell in an app should be free to clone other cells in the same app. Just as it is free to call zomes in cells in the same app.

[nphias]

cool.. that would be epic.. happy to help

[ThetaSinner]

This is in good shape now.

@nphias If you'd like to take a look at the PR and see if you think it'll meet your needs that would be super helpful! Especially the *Input types for calling the new HDK functions and the tests to see how this behaves.

[ThetaSinner]

Just trying to think through how this looks. If you're using clone_only then there won't be a back-end zome to call to create the first clone. So you'd need to create at least one clone to be able to manage more from the backend. Is that expected? Or would you either

• Want a different cell which is also installed on the conductor to be able to manage clones
• Not use clone_only so that a cell is provisioned and can be responsible for managing the clones.

If possible I'd like to restrict clone management to within the cell so that you can't just go creating clone cells for another app but if there's a use-case for that I'm happy to have a deeper think about how we keep this reasonably secure. It does sound from the linked discussion like that's the intention.

@mattyg It would be good to hear your use-case for this too before I dive into implementation

[ThetaSinner]

That makes sense to me, unless I hear differently then I'll assume that

• The clone_only strategy will require a 'bootstrap' clone cell to be created with a client call so that other clones can be managed from it.
• A creation strategy which provisions an initial cell to be cloned will be needed

The second makes more sense to me really because the effect is the same. So maybe we document that as the option to try first.

That way I can restrict clone management to within an app and if we need to revisit that restriction we can

[jost-s]

Just trying to think through how this looks. If you're using clone_only then there won't be a back-end zome to call to create the first clone.

The conductor API call create_clone doesn't need an existing zome or cell to create a clone. A host fn must be called inside of a zome, that's true, so that way of creating a clone requires an existing cell.

If possible I'd like to restrict clone management to within the cell so that you can't just go creating clone cells for another app but if there's a use-case for that I'm happy to have a deeper think about how we keep this reasonably secure.

The create_clone call takes an app id, and I think that while the app websocket is not restricted to apps, you can't really know "from which app" a client is calling. We have the suggestion to bind app websockets to apps and that would take care of this concern as well.

The clone_only strategy will require a 'bootstrap' clone cell to be created with a client call so that other clones can be managed from it.

Then it's essentially the provisioned strategy. There's very little difference between a clone cell and a provisioned in the way it functions, and only a few differences in how it's created and addressed.

This conversation is turning into discussion about the clone_only strategy, when the OP's suggestion is about host functions to manage clones. I think we can go ahead with the host fn implementation and discuss the provisioning strategy elsewhere.

[github-actions]

This item has been open for 30 days with no activity.

[ThetaSinner]

I've got a few things in progress but I'm going to make a start on this