Project registration endpoint

[xla]

We want to support registration on the Registry in the context of existing projects. For that we need a new mutation.

Design

The schema addition proposal:

scalar Rad

type TransactionCosts {
  fees: Rad!
  total: Rad!
}

union TransactionState = Accepted | Applied | Rejected

type Accepted {
  # Address or other identity of the node that accepted the transaction.
  node: String!
}

type Applied {
  # Number of blocks that this transaction has been applied to.
  blocks: Int!
}

type Rejected {
  # The issue that prevented this transaction to be accepted/applied.
  reason: String!
}

union Message = ProjectRegistration

type ProjectRegistration {
  name: String!
  domain: String!
}

type Transaction {
  id: ID!
  messages: [Message!]!
  costs: TransactionCosts!
  state: TransactionState!
  timestamp: Datetime!
}

type Mutation {
  registerProject(domain: String!, name: String!): Transaction!
}

input TranscationCostInput {
  messages: [Message!]!
}

type Query {
  transactionCosts(draft: TranscationCostInput): TransactionCosts!
}

Implementation roadmap

• Consume Registry client for registration: Integrate new transaction flow #78
• Implement registration mutation
• Migrate to futures-0.3 which landed in the client
• Pass metadata once Add metadata field to Project radicle-registry#167 landed
• Store librad::ProjectId in metadata

[geigerzaehler]

type ProjectRegistration {
  name: String!
  domain: String!
}

Project registration also requires an existing checkpoint.

type Mutation {
  registerProject(domain: String!, name: String!): Transaction!
}

Does registerProject submit the transaction? What is the purpose of the Transaction.state field?

[xla]

Project registration also requires an existing checkpoint.

We going to surface that once we have that concept in the UI, until then we construct one silently in the proxy.

Does registerProject submit the transaction? What is the purpose of the Transaction.state field?

Yes it submits the transaction. The state is to surface the lifecycle of transactions in the UI (notifications, progress, etc.).

[geigerzaehler]

Yes it submits the transaction. The state is to surface the lifecycle of transactions in the UI (notifications, progress, etc.).

If registerProject returns once the transaction is submitted then the Applied transaction state can never occur. It will always be Accepted or Rejected. How is the UI notified of changes?

[xla]

@geigerzaehler Maybe I mixed something up, but wasn't it communicated that the when the sign_and_submit call returns it is accepted and when the future it carries returns it is applied?

[geigerzaehler]

@geigerzaehler Maybe I mixed something up, but wasn't it communicated that the when the sign_and_submit call returns it is accepted and when the future it carries returns it is applied?

Yes, that is correct. I’m just wondering how it would work in the GraphQL communication between the UI and the proxy

[xla]

We gonna see, for now it's more important to account for possible states. A general route we can take is pushing updates with the help of subscriptions.

[rudolfs]

Additionally would be great if we could get a list of all transactions to show them in the wallet section:

type Query {
  transactions(walletId: ID!): [Transaction]!
}

The transaction status subscription could look something like this:

type Subscription {
  transactionStateChanged(transactionId: ID!): Transaction
}

Potentially we could also use a subscription for new transactions to show a badge on the wallet icon:

type Subscription {
  newTransaction(walletId: ID!): Transaction
}

[xla]

@rudolfs These look pretty good, might breaking it out into its own issue? Don't think these are crucial for the project registration success.

[rudolfs]

Could we have a query to check if the name is already taken? Or would that also be beyond the scope here?

[xla]

That's very reasonable, it should be equivalent to a getProject(domain, name).

[xla]

The main share of this issue is completed, the last point is being addressed in #98.