Philosophical discussion on barriers that encapsulate the various agents' entities and resources

[adaburrows]

Currently, the playspace is wide open. Any one with the correct UID can start using the playspace and sharing data. Everything is shared. There are no borders or boundaries between each entity. This makes using the playspace difficult because it becomes very cluttered very quickly.

One thing that will help immediately is making sure we support multiple plans. However, even with that, the list of items displayed in the sidebar for processes and resource specifications will grow unwieldy as more people keep adding theirs. Additionally, we don't have any restrictions on who can delete what (as long as it is not currently in use in the plan). So if I make a process and lay out the resources, and then someone doesn't like that process, they can delete it before I add it to my plan.

This means we really do need to add the relationships, roles, and behaviors that exist on the Valueflows spec. I assume this provides a neat way to specify if someone has access to a bit of inventory and that I can't just ship some of Microsoft's artwork to myself through the system. Additionally, we need a way of tracking who can see which ResourceSpecifications and ProcessSpecifications from what organization. This seems like we would need to extend the system further than what I see in the UML diagram, because I can't see a way to only create local ProcessSpecifications and ResourceSpecifications (though, I'm aware that hREA basically does this by only putting the specifications in the conductor's local disk and not sending it to the shared DHT). It's only at the level of EconomicResource that I can specify who is the primaryAccountable, and can then limit the possible actions taken based on that.

Of course, this opens up a whole new realm of UX concerns. Like: How are relationships established between agents? If two "organization" level entities have a relationship, what level of visibility do their sub agents have into the whole of each organization? How do we define the levels of access to certain inventory that is essentially a catalog of services performed and EconomicResources that an organization produces?

There's much to discuss and ponder and write about, but I just wanted to get the ball rolling because Shane and I had a conversation about EconomicEvent's toResourceInventoriedAs this morning at it makes sense to start thinking about these things before we have to rearchitect things.

I can probably create an enumeration of scenarios to think about to get the ball rolling. If you've already thought of other scenarios, please let me know.

[fosterlynn]

A couple initial thoughts, while agreeing this will require much more thinking. :)

One thing that will help immediately is making sure we support multiple plans.

👍 yes!

the list of items displayed in the sidebar for processes and resource specifications will grow unwieldy as more people keep adding theirs.

This is also recorded as part of issue #37. We might want to split up #37, but I think the specifications will grow too long irrespective of any permissions or barriers, especially as an inherently shared thing. And there might be another part of that for sharing between networks. So I'm thinking that part is basically a UI issue, as opposed to needing further ways to restrict it, but open to being wrong.

This means we really do need to add the relationships, roles, and behaviors that exist on the Valueflows spec. I assume this provides a neat way to specify if someone has access to a bit of inventory and that I can't just ship some of Microsoft's artwork to myself through the system.

Yes, I think that is a high priority, and we have generally seen the roles as a basis for authorization. But we'll need more I expect, I don't see how roles can do it all atm. Also, there might be basic rules that will be more hard-coded for everyone, like people who created an event can change it irrespective of role.

Some things to find out:

• What did holochain implement for object capabilities, and is that pretty "done"?
• Gather some specific requirements from the groups we know.
• Gather previous discussions on signing and counter-signing of commitments and flows that affect more than one agent, see how that fits in.

Note to self: Do some more work on the VF side, specifically more on the RoleBehavior list, and how to do something like "on behalf of" where a person is acting for another agent.

Also, should this discussion take place with hREA too, seems like the same discussion? @Connoropolous @pospi

[adaburrows]

... I think the specifications will grow too long irrespective of any permissions or barriers. ... So I'm thinking that part is basically a UI issue, as opposed to needing further ways to restrict it, but open to being wrong.

I actually view that other ticket as a separate but intersecting concerns. All of it turns into a UX problem once the general outline of the behavior is visible. They both converge on how to organize the information both through:

• Good discovery UX:
  • minimize overload of seeing everything or having to remember what to search
  • potentially have resources organized under organizational umbrellas
• Good relational permissions UX
  • certain things may be public, but still need a good IxD around them
  • some things may need a relationship in place to see them
  • we may need to be able to guide people into the right relationship

But we'll need more I expect, I don't see how roles can do it all atm.

Ok, cool. I was wondering if I was missing something or if it just wasn't all there. I'm also perfectly fine with implementing RBAC for the third time in my life. It's pretty simple, but it always seems to have a very tedious UxD and hooks into the code in all kinds of places. We can also discuss how this can coordinate with the existing roles and behaviors.

What did holochain implement for object capabilities, and is that pretty "done"?

It is basically done:

• https://blog.holochain.org/keystore--new-admin-api-function--and-capability-grants-and-claims/
• https://holochain.github.io/holochain-rust/zome/capabilities.html

The big part of this that is missing is that until the signed call changes are merged, none of the cap grants really make a difference since they can't be enforced.

This will take some time to update the launcher to make the process of getting into apps not impossible — but it's all been discussed recently and may be in place by the beginning of 2023.

I would actually try to stay away from relying on that until it actually works and we can get a version of hREA that we can migrate all the data to.

Gather some specific requirements from the groups we know.

This would be great. I can also feed in requirements for larger organizations in the scale of 200-1000 employees. What is missing from my perspective, and what I think we'll need to figure out together, is the way cross-organizational boundaries work. There's been a few examples in things like LifeRay, Alfresco, Google Suite, and some stuff we did for RBAC at a past company that I can't mention.

Gather previous discussions on signing and counter-signing of commitments and flows that affect more than one agent, see how that fits in.

Oh, was this all around hREA? Or were there other implementations that do this too? I think this will be more useful further down the road. I'm not sure how far away from a simple prototyping datastore we want to take our little tiny zome. So yes, we do need to work closely with the hREA team to get things working smoothly especially for the security model.

[Connoropolous]

"Stupid question". If playspace isn't intended for "actual production scenarios" and is intended as "a learning tool" then why would permissions (beyond network_seed to isolate data from bleeding into a global pool unintentionally) be needed? I feel the project can't be 'both' and is begging for decisiveness on this issue.

[fosterlynn]

"Stupid question". If playspace isn't intended for "actual production scenarios" and is intended as "a learning tool" then why would permissions (beyond network_seed to isolate data from bleeding into a global pool unintentionally) be needed? I feel the project can't be 'both' and is begging for decisiveness on this issue.

Very good question imo. Warrants some discussion going forward. I do expect playspace to be of interest to other groups, with improvements or extensions, but we don't know that yet, at least in enough detail. In the meantime, Code A can play with it and we'll see if they need anything around permissions.

We agreed last meeting to focus now on cleaning up the rough edges enough to support the initial users UX so we can get more feedback. We have a list that supports this milestone, then my understanding of the discussion was next to move to hREA while getting that feedback. So fortunately there is time for these other topics to coalesce and mature a bit.

[adaburrows]

If playspace isn't intended for "actual production scenarios" and is intended as "a learning tool" then why would permissions (beyond network_seed to isolate data from bleeding into a global pool unintentionally) be needed? I feel the project can't be 'both' and is begging for decisiveness on this issue.

I see the core of what is being built as a foundation for any possible UX to be built upon. A lot of these things will surface as UX questions when serious projects actually start using it.

Also, a main reason why it's being funded is because the funder would like to use it for day to day management. One of the offhand statements was that it would be great to be able to use it to run the business invoicing, billing, payments and other accounting through it.

So that's why I labeled this as a philosophical discussion. It's low priority for now, but at a point in the near future, the UI can shift and it will be a big issue.

[adaburrows]

As I've been reading through the Distributed Social Sensemaking doc from the Neighborhoods folks, it looks like they might have some of the useful glue that provides permissions on top of the Valueflows ontology. When I saw their demo at DWebConf I thought they might be a good candidate for integration. Since I gave two of the Neighborhoods people a ride to SF, we had time to talk and start to get to know each other. We're already chatting and it'll be interesting to see how these sorts of things align with what they are building.