Does this also mean that you can no longer manipulate entries defined in a foreign zome? Because that was an important part of my security model that will have to be reviewed… 
@pospi Hmmm, that’s a good question. So you’re asking if zome A can write/update/delete entries of a type defined by zome B in the same DNA? Looks like it can’t; the zome ID is enforced on the host side of the create call. I think in my mental model I always pictured a zome’s public functions as the way of interacting with its data types, for encapsulation’s sake (ignoring the fact that the encapsulation leaks; any zome can read another’s data or hang links on it… and cross-zome deletes aren’t enforced either).
what’s your security model look like, and in what ways do you anticipate this revelation messing it up?
1 Like
Just had a chat about this with @guillemcordoba and I think things are workable as before.
He tells me the zome ID is set by the crate that defines the entry def. Any foreign zome attempting to manipulate those entries is actually deferring the calculation of EntryDefId to the host, which is able to make the lookups across zomes.
Anyway, in answer to your security model question: sometimes, there are behaviours that you want to trigger in a foreign zome that you only want to trigger as the result of some logic elsewhere. This makes capability tokens between zomes non-applicable, since assigning such a token would allow the agent to manually call the foreign API method as desired (rather than being forced to call it through some other ‘controller’ method).
There are of course complexities to this when it comes to validating data held in multiple zomes, but that’s a topic for separate threads.
2 Likes
Ha ha, I love hearing things through the grapevine! So let’s see if I’m parsing this right. if zome A defines an entry type and zome B tries to write an entry of that type, it’ll still get tagged as belonging to zome A and hence validated by zome A’s validation callbacks? I still don’t know how to read the codebase but didn’t see any facility for that; the entry type ID appeared to just be a non-prefixed string rather than a tuple of (zome ID, entry type ID) like I’d expect.
So it sounds like you’re using zomes here for code organisation rather than encapsulation or information hiding?
I believe that’s the expectation, yes. It may be the case that it only works currently by “first come, first served” and that zomes redefining entry IDs might unexpectedly take over responsibility for executing validation rules, which would be bad. Probably worth checking that with someone in core.
It’s kinda both. Hard to explain, but manipulating foreign zome entries within a DNA allows one to write validation rules which coordinate data across multiple cells cleanly. It’s like, even if I have to write separate bits of data in some order between different application cells in order to coordinate a more complex action, I can still write validation rules which safely presume the dependent data is available. It allows one to get transactional guarantees between multiple cell calls where no such guarantees exist natively.