kord-network / go-kord Goto Github PK

See #54 for background.

Add a filter param to the identity query that accepts either id OR owner variables.

This would enable a query like so:

query readIdentity($filter: Filter) {
  identity(filter: $filter) {
    id
    owner
    signature
  }
}

The Filter schema definition would look something like this:

input Filter {
  id: String
  owner: String
}

The following needs to be fixed:

• support nanosecond precision in the tests here (this is why the TestSQLBackend/qs/load_typed_quad fails)
• update OpIsTrue to handle the fact that SQLite does not have a built-in 'true' literal (the vendored cayley currently has OpIsTrue set to IS 1, but upstream it is IS true
• add a SQLite regex extension so that the REGEXP operator works (this is why TestSQLBackend/qs/paths fails)
• update cayley so that it supports creating indexes in the CREATE TABLE statement (currently we are just not creating the indexes by setting NoForeignKeys)

An Ethereum address should only be the owner for a single META-ID.

If this address is used to create a second identity an error should be returned.

See discussion in Slack.

To aid client side parsing of the response payload from the Media API it would be good to alter the way in which the META node handles nullable object responses, especially on the account query due to its potential size.

type Account {
    performers: [MusicPerformer]!
    labels:     [RecordLabel]!
    composers:  [MusicComposer]!
}
type MusicPerformer {
  identifiers: [PartyIdentifier]!
  name: StringValue
  recordings: [MusicRecordingLink]!
}

If the META ID being submitted does not return any performers/labels/composers it returns a single object with no values defined:

"performers": [{
  "identifiers": [],
  "name": {
    "value": ""
  },
  "recordings": []
}],

When it would be preferred to simply return an empty array.

performers: []

There are missing documentation for exported functions and structs at error.go and encode.go

Problem

The raw username of a META-ID is required for display purposes.

Use case 1

An application has a page that displays data about a META-ID, including the claims made about that ID. With the current API the application would only be able to represent the issuer of the claim by the address, which is not immediately useful to a human user.

Use case 2

An application has a page that displays data about a META-ID, including the claims made by that ID. With the current API the application would only be able to represent the subject of the claim by the address, which is not immediately useful to a human user.

Solution

One option is to pass the raw username to the API when creating an identity. This value will then be stored with the identity and returned when requested:

mutation createIdentityMutation($username: String!, $usernameHash: String!, $owner: String!, $signature: String!) {
  createIdentity(
    username: $username,
    usernameHash: $usernameHash,
    owner: $owner,
    signature: $signature
  ) {
    id
    signature
    owner
    username
  }
}

A META-ID's username could then be retrieved using the identity query:

query getIdentity($owner: String!) {
  identity(owner: $owner) {
    id
    owner
    signature
    username
  }
}

Ideally, the claim query would return issuerUsername and subjectUsername.

claim (issuer: $issuer) {
  id
  issuer,
  issuerUsername,
  subject
  subjectUsername,
  claim
}

This would fit both use cases 🎉. But, if this is not possible, the client can recursively fetch each issuer's identity - although this is pretty inefficient at scale.

The grammar and spelling needs looking at in the README.

Problem

With the current API, it is not possible to write a single query that could accept either an issuer variable or a subject variable. It is therefore necessary to construct two separate queries with different variables.

For example, this query:

query readClaims($issuer: String, $subject: String) {
  claim (issuer: $issuer) {
    id
    issuer
    subject
    claim
  }
}

would return:

{
  "errors": [
    {
      "message": "Variable \"$subject\" is never used in operation \"readClaims\".",
    }
  ]
}

Use case

A JavaScript service that exposes a generic interface for making META Network GraphQL requests, which allows consumers of the service to simply provide query parameters without writing the underlying GraphQL query.

(pseudo-code used to demonstrate desired function signature)

const readClaims = (variables={ issuer || subject }) => metaNetworkRequest(`
  query readClaims($issuer: String || $subject: String) {
    claim (issuer: $issuer || subject: $subject) {
      id
      issuer
      subject
      claim
    }
  }
`, variables)

Solution

Add a filter param that accepts either issuer or subject or a combination of the two (along with the other possible variables)!

This would enable a query like so:

query readClaims($filter: Filter) {
  claim (filter: $filter) {
    id
    issuer
    subject
    claim
  }
}

And the JS service would look something like this:

const readClaims = (variables={ filter: { issuer, subject } }) => metaNetworkRequest(`
  query readClaims($fitler: Filter) {
    claim (filter: $filter) {
      id
      issuer
      subject
      claim
    }
  }
`, variables)

See this for reference.

The Filter schema definition could look something like this:

input Filter {
  claim: String
  issuer: String
  signature: String
  subject: String
}

We need to decide on an appropriate license for all code in this repository and put it in a LICENSE file at the root of the repository.

The PartyIdentifierType is not returning a useable value for the type field, on all queries:

{
  "type": "<media.partyIdentifierType Value>",
  "value": "01010101010"
}

Expected to return the respective enum value, as defined in the graphQL schema definition.

enum PartyIdentifierType {
  ISNI
  IPI
  DPID
}

type PartyIdentifier {
  type:   PartyIdentifierType!
  value:  String!
  source: Source!
}

meta:MusicRelease

• CHANGE name to Song
• CHANGE parser to ignore ern:Release:isMainRelease item
• ADD: ern:Duration as meta:Duration
• ADD: all items within ern:ReleaseId, using the meta:identifiers:[PartyIdentifier] field syntax
• CHANGE: meta:Performers renamed to meta:Performer, with the value changing to the single value from: ern:DisplayArtistName || ern:DisplayArtist
• ADD: meta:RecordLabel

meta:MusicProduct

• CHANGE name to meta:MusicRelease
• CHANGE parser to only check for ern:Release:isMainRelease item
• CHANGE: meta:Performers renamed to meta:Performer, with the value changing to the single value from: ern:DisplayArtistName || ern:DisplayArtist
• ADD: ern:ReleaseType as meta:ReleaseType
• ADD: ern:ReleaseDate as meta:ReleaseDate
• ADD: all items within ern:ReleaseId, using identifiers: [PartyIdentifier]
• ADD: meta:RecordLabel

meta:MusicRecording

• CHANGE: Performers => ern:DisplayArtistName || ern:DisplayArtist
• ADD: ern:ReleaseReference
• ADD: ern:LabelName
• ADD: ern:ResourceContributor as meta:Contributors:[MusicPerformer]
• ADD: ern:Duration as meta:Duration

A requirement for the META-ID dapp UI is to display additional data about an individual, such as name, image and web address.

Initial thought is this would be stored as a reference to a Swarm location in the META Identity database.

Something like:

{
  profile: 'f8fd38fcdd90c667cbf25b4011686d64a49e822d04851858129ae8610e921f13'
  ...
}

The CWR package needs to add the AGR transaction header to be converted, indexed and available via a graphQL query.
It is needed as we wish to display the share percentages for each interested party on a work.
The desired fields within each detail record are outlined below.

TER

• Inclusion/Exclusion indicator
• TIS Numeric Code

## IPA

• Interested party IPI Name #
• IPI base number
• Interested party #
• Interested Party last name
• Interested Party writer first name
• PR affiliation society
• PR share
• MR affiliation society
• MR share

It has been proposed on two occasions by @nolash that package import URLs which don't end with the same name as the package they are importing should be explicitly aliased (see here and here).

So for example, import github.com/ipfs/go-cid should actually be import cid github.com/ipfs/go-cid even though the package is already called cid.

I am against this because I never manually edit imports (I just let goimports do it, which I assume most people do), and so doing so means I have to go and look at the imports all the time, even if the code compiles just fine.

That being said, I am happy to do this if most contributors find it useful.

/cc @nolash @orenyodfat @zelig

A schema.json file is required by GraphQL clients to compile queries.

neelance/graphql provides this function: https://godoc.org/github.com/neelance/graphql-go#Schema.ToJSON