Common GraphQl schemas

Technical Discussion App Development
#1

Hi all!

So I’ve been drafting some basic and very common building blocks with GraphQl. I want to open their schemas to discussion to enable as much alignment in our ecosystem as possible. Here they are:

I’d ideally want to be able to have them compatible with holo-REA’s ones, to enable easy interoperability.

@tats_sato @pospi

1 Like
#2

To start the discussion, I think that we should change the Profile type definitions to support the kind of mapping that we are going to have in Personas & Profiles, something like:

# This would be from the point of view of the application, 
# not being able to access the persona abstraction
type Profile {
  username: String!
  fields: [ProfileField!]!
}

type ProfileField {
  key: String!
  value: String!
}

# And then from the point of view of my agent
# I can get my personas and mappings
type Me {
  personas: [Persona!]!
  profileMappings: [ProfileMapping!]!
}

type Persona {
  name: String!
}

type PersonaField {
  key: String!
  value: String!
}

type ProfileMapping {
  # I'm assuming a profile is created once per happ, 
  # but maybe this should allow for dna granularity as well?
  happID: ID! 

  persona: String! # Maybe this should be the hash of the persona?

  fields: [ProfileFieldMapping!]!
}

type ProfileFieldMapping {
  personaKey: String!
  profileKey: String!
}

We also have @nphias 's nPersonas as a first reference.

#3

Great initiative! Thanks for starting this :slight_smile:

I can’t quite figure how the Holochain personas & profiles are going to map to the VF agent spec but there could be things where the mapping between “agent” in the Holochain sense (ie. a public key) vs “agent” as an REA Person could be interesting, since the mapping of Holochain profiles to agent keys is many:1, is that correct? (CC @lynnfoster @bhaugen who might be interested)

From experience I can tell you that the query naming spec you choose should start with the name of the entity. You want profiles rather than searchProfiles so that you can also have profile(ID!) and other edges grouped together. When developers are working they usually think “I want to do something with profiles” before they think “I want to make a search”. It helps with autocomplete too.

Unfortunately I probably wouldn’t recommend doing this with your mutations, because reasons and unpredictability across various implementations. So createX / updateX / deleteX seems pretty sensible for CRUD atm as far as I’m concerned.

1 Like
#4

Thanks for the comment, I see what you are seeing with the prefixes yeah.

As far as the profiles goes… The short answer is that in the normal case I see one agent key mapping to one profile only.

Here is the long answer:

  • Each physical person will have:
    • A set of public/private key pairs managed by DeepKey
    • A private and dedicated personas&profiles dna, which contains:
      • Your set of personas (key value pairs with your actual information)
      • Your profile mappings for each happ (I think happ, could be dna but doubt it)
  • Whenever you install a happ, you install multiple dnas. Those dnas will all share the same public key to start with.
  • I think that in the normal case, you will want only one profile per happ (per set of dnas). This is because although dna read access could be different for every agent, I don’t think you should need to create a separate profile mapping inside each dna (imagine your holo-REA dnas but in each one a different profile… not very consistent in my opinion, better to have only one place in one of the dnas for that)

So, the data structures look reaaally different whether you are seeing your personas and profiles info (in which you can access all your private information and see your mappings), or a profile for another user, in which you should only see the resolved profile for that user for that app (here, f(persona, profileMapping) -> Profile) where you apply the mapping transformations from the mapping to the persona to get the profile).

One thing this touches on also is the group agency thing, I’ve been thinking. in REA’s schemas, if you reference the organization directly for an EconomicEvent let’s say, you are losing the information about who acted in behalf of the organization. Have you or anyone in valueflows thought about saying something like “this economicevent was approved by this agent on behalf of this organization”? Then if we find out that the delegate is misbehaving we can track all the places in which they did.

Granted, this makes it difficult to implement other governance systems than delegation, but… I don’t know if your idea is that REA should cover things like “we have approved this economicevent as a result of this voting process”. That could be also done by a single agent who is just “implementing” the result of the vote, though.

#5

Yeah, we’ve been thinking about this as a core architectural need since way back, and I think it’s essentially covered by the core attribution layer of Holochain’s DHT. The immediate use case is for “pospi worked 5 hours coding for Holo-REA”, where EconomicEvent.receiver must indicate “the Holo-REA project”. Who counter-signs for that?

This is where role implementations like yours come into play- because there are various permissions that organisations might want to layer on top of these economic events as validation rules. Core to this is the ability to validate delegated authority rules for the group- i.e. “in our collective, only members may contribute work” is a validation rule where EconomicEvent.receiver is only valid for group agents which pass the check that the authoring agent has a member role within the specified membrane.

I can forsee some common patterns for managing permissions on countersigning, a few detailed here.

#6

Ohhhh right awesome, that’s perfect. It helps a lot in grounding more my understanding of how Rea will work in technical detail.

Looking forward to closing the gap in the implementation. Right now to start with I’m not thinking about it as “group countersigning” as in someone actually signing the entries but just a validation rule that checks that the agent can commit that action. I think that can cover a lot of use cases and is more natural according to the roles module.