Sprint #9 - 2019-04-18

Sprint Metrics

  • Story Points: 114,5

  • Average Velocity: 73,7

  • Story Points for Code Freeze: 207

  • Story Points for Technical Go-live: 593

User stories

RLAU-1110 - JSON-RPC Method: Universe.getUniverse

Story
Criteria

Implementation of the “getUniverse” JSON-RPC API call in the Swift library. As a library consumer, the user can get the Universe configuration.

  • Contributor: Alex

  • Component: radixdlt-swift

As a library consumer I want to be able to get a universe config from a given node over WS So that I can connect know if said node is "compatible" according to the current config

Scenario 1: Get Universe config from node

Given A Node's IP address When I request Universe.getUniverse Then I get a Universe config from said node

Scenario 2: JSON decoding error

Given A Node's IP address When I request `Universe.getUniverse` from a node returning incompatible JSON Then I get a JSON decoding error

RLAU-1104 - JSON-RPC Method: Network.getLivePeers

Story
Criteria

Implementation of the “getLivePeers” JSON-RPC API call in the Swift library. As a library consumer, the user can get a list of live peers (nodes).

  • Contributor: Alex

  • Component: radixdlt-swift

As a library consumer I want to be able to get a list of live peers (nodes) from a given node over WS So that I can connect to multiple nodes

Scenario 1: Get Live Peers

Given A Node's IP address When I request `Network.getLivePeers` Then I get list of live peer nodes said node is connected to

Scenario 2: JSON decoding error

Given A Node's IP address When I request `Network.getLivePeers` from a node returning incompatible JSON Then I get a JSON decoding error

RLAU-972 - Node discovery

Story
Criteria

Implementation of the Node discovery feature in the Swift library. As a library consumer, the user can discover live nodes available and access the Radix network.

  • Contributor: Alex

  • Component: radixdlt-swift

As a library consumer I want to be able to connect to a Node So that I can access the Radix network via said Node

Scenario 1: Connect to a Node via IP address

Given A Node's IP address When I ask it about its Node Info using REST API `/api/network` Then I get information so that I can open a WS connection to it.

Scenario 2: JSON decoding error

Given A Node's IP address When I ask it about its Node Info using REST API `/api/network` and it return incompatible JSON Then I can see an error speciyfing the JSON decoding error

Scenario 3: Connect to a Node via Node Finder

Given A Node Finder URL (e.g. `https://betanet.radixdlt.com/node-finder`) When I load the page at the given URL Then I get an IP address I can use to connect to Node

Scenario 4: Incorrect IP address

Given an incorrect IP address (to what was believed to be a Node) When I try to connect to said computer Then I can see a connection error, or a timeout after X seconds a timeout error.

Scenario 5: Incorrect Node Finder url

Given An incorrect URL for a Node Finder (e.g. `google.com` instead of `https://betanet.radixdlt.com/node-finder`) When I parse the contents of the incorrect page Then I get error saying that we failed to parse out the Node IP.

RLAU-581 - Human readable serializers for JSON

Story
Criteria

Implemented human readable serializers for the Core libraries. This should improve code review, code readability and unit testing.

  • Contributor: Florian

  • Component: core

As a library and Core developer I want to be able to just from looking at the JSON know what kind of model I should deserialize it into So that I increase my velocity and more easily verify the correctness of my code and unit tests.

Scenario 1: All Serialized Forms have Human-Readable Serializer

Given any request to a node, When I inspect its JSON-serialized form Then I want to know what type every element by looking at it

RLAU-656 - Atom Metadata Constraints

Story
Criteria

Implemented atom metadata constraints for the Core libraries. This scaffolding will enable the definition of network-wide Atom constraints and limits.

  • Contributor: Florian

  • Component: core

As a Radix Governor, I would like to be able to define Network wide atom constraints/limits so that the network is more flexible.

Scenario 1: Kernel Fee Constraint with Fee

Given that I have defined an Atom Kernel requiring a fee, When when I submit an Atom with a fee, Then then the Atom will be accepted

Scenario 2: Kernel Fee Constraint without Fee

Given that I have defined an Atom Kernel requiring a fee, When when I submit an Atom without a fee, Then then the Atom will be rejected with a validation error

Scenario 3: Kernel Size Requirement with a valid sized Atom

Given that I have defined an Atom Kernel requiring an Atom below the size limit, When when I submit an Atom with a valid sized Atom, Then then the Atom will be accepted

Scenario 4: Kernel Size Requirement with an oversized Atom

Given that I have defined an Atom Kernel requiring an Atom below the size limit, When when I submit an Atom with a too large Atom, Then then the Atom will be rejected with a validation error

RLAU-640 - Metadata Constraints

Story
Criteria

Implemented metadata constraints for the Core libraries. This allows the developers to define constraints based on Atom metadata.

  • Contributor: Florian

  • Component: core

As a ParticleScrypt Developer I would like to define constraints based on atom metadata So that I can create more sophisticated state machines based on metadata such as atom size, timestamps, signatures

Scenario 1: Atom does have required signatures

Given that I have defined an Application Constraint Scrypt requiring a specific signature in metadata, When when I submit an Atom with that signature, Then then the Atom will be accepted

Scenario 2: Atom does not have required signatures

Given that I have defined an Atom Kernel requiring a specific signature in metadata, When when I submit an Atom without such a signature, Then then the Atom will be rejected with a validation error

Scenario 3: Atom does have required Particle

Given that I have defined an Application Constraint Scrypt requiring a specific Particle to be present, When when I submit an Atom with such a Particle, Then then the Atom will be accepted

Scenario 4: Atom does not have required Particle

Given that I have defined an Atom Kernel requiring a specific Particle to be present, When when I submit an Atom without such a Particle, Then then the Atom will be rejected with a validation error

Scenario 5: Atom does have required metadata field

Given that I have defined an Application Constraint Scrypt requiring metadata field with a specific value, When when I submit an Atom with such a field, Then then the Atom will be accepted

Scenario 6: Atom does not have required metadata field

Given that I have defined an Application Constraint Scrypt requiring metadata field with a specific value, When when I submit an Atom without such a field, Then then the Atom will be rejected with a validation error

RLAU-638 - Particle Static Constraints

Story
Criteria

Implemented Particle static constraints for the Core libraries. This allows the developers to define static constraints which are always applied to an instance of ParticleType.

  • Contributor: Florian

  • Component: core

As a Particle Developer I would like to define static constraints which are ALWAYS applicable to an instance of a particleType So that I can rely on the static constraints when I use these particleTypes to make more sophisticated transition constraints

Scenario 1: Constraint for Particle Type is satisfied

Given that I have defined an Application Constraint Scrypt with a certain constraint, When I validate a Particle that satisfies that constraint, Then the Particle will be accepted

Scenario 2: Constraint for Particle Type is not satisfied

Given that I have defined an Application Constraint Scrypt with a certain constraint, When I validate a Particle that does not satisfy that constraint, Then the Particle will be rejected with an error