Resolving a release via channel

Let's walk through resolving a version given a theoretical channel.

Overview:

1. Get the project and channel records. Check for a renamed project, verify that the channel and the project match

2. Get version that the channel specifies, then get the manifest that the version specifies. Compute/compare their CIDs to validate the strongRefs

3. CAR validate everything to ensure they match the signing identity

4. THEN fetch resources according to the manifest

   1. For blobs, treat their CID as a checksum and validate that they match
   2. For URL resources, check them against a checksum (that should be provided with their link)
   3. Apply any other verification practices as mandated by the consumer

5. Your assets are verifiably what they are claimed to be by the entity making the claim!

Assumptions

For this exercise, we'll refer to a project owned by user @graham.systems with the name trawler. Let's assume that this is a self-updating desktop application.

The client has already been shipped with three pieces of information:

1. The DID of the project owner; in this case, did:plc:57od6g2ic3e3b3kauctjmo3k.

2. The name of the project; in this case, trawler.

3. The default channel for the application to track. We'll use latest in this example.

1: Resolve the project and channel records

Given the pre-provided components, we can construct fully-formed AT URIs for both the project and the tracked channel. Those look like these:

# Our project URI
at://did:plc:57od6g2ic3e3b3kauctjmo3k/software.release.project/trawler

# Our channel URI
at://did:plc:57od6g2ic3e3b3kauctjmo3k/software.release.channel/trawler:latest

Your application will want to resolve these in parallel. Why? The project record could contain rename information—in that case, we'll need to repeat this step given the project URI specified in that record. If no rename has occurred, then we can proceed as planned with the resolved channel.