RE zome interfaces, I agree! Those would probably be good abstractions. I’m not sure role-based access control fits into these low-level primitives, though. We may be conflating “network participation” (which is a technical thing) with “group membership” (which is a social thing).
As a result, I was planning on building role-based abstractions on top of the network membership API. Once there are some common interfaces to describe whether agents are members of networks, then we can add layers to describe whether they are members of groups within those networks. Maybe… at this stage it’s hard to say if those are necessary, or if sub-groups would just be more networks. We’ll see what happens when I add an extension to allow “group agent” DNAs to register with “agent registry” DNAs.
FWIW there is already a roles implementation out there, but it treats roles differently to how ValueFlows treats them and thus illustrates how this is a higher-order abstraction with some ideological choices within it.
Oh, and thanks on the agent registration stuff, I had been thinking that. You use
%agent_id instead of an entry type name when you refer to those in entry defs, correct?
(Aside: why aren’t zome traits and Rust traits the same thing? Surely there is a way to use proc macros and the type system to iterate and describe native trait objects for exporting over RPC…?)