Week in w3up is a newsletter on the blog that shares updates and progress on improving w3up and integrating it into the core web3.storage platform.

🌈 This week in w3up! Feature parity++

⏫ Staging upload-api backend deployed

The upload-api is the new version of the backend service that is in the private w3up repo. It now is at feature parity + has these additional cool things:

  • Ucanto 0.9 integration - This is a breaking change that aligns the Ucanto library with the latest version of the UCAN spec.
  • We added a super helpful README with information for developers allowing them to get started with the project, also information about the API routes it exposes and UCAN capabilities that can be invoked.
  • Upload size validation 🗜 - the upload API now requires and validates a size parameter for store/add invocations. It allows us to account for used storage and ensure users don’t upload data beyond their allocated quota without being warned. The signed URL we generate also bakes in the size restriction!
  • 🐛 Fix for removing stored CARs and uploads - We found and fixed a bug that is currently disallowing data to be removed.
  • Tests for everything! 🧪🧪🧪

Next week, we’re going to be fixing up the database schema and adding pagination to our list endpoints (allowing listing of more than just the first page of uploads).

👀 Check it out: https://github.com/web3-storage/upload-api

🛍 Released new upload-client to npm

A brand new client library for the upload API, it exposes a super simple API for the majority of users as well as all the primitives that allow users to compose their own pipeline of building a DAG, encoding a CAR, spliting a CAR into shards, and transferring it to the service.

It supports automatic request retries and concurrent uploads (for CAR shards) and is tested with 100% coverage.

A couple of other notable features:

  • Uses Ucanto 0.9.
  • Adds size parameter for store/add invocations.

👀 Check it out: https://www.npmjs.com/package/@web3-storage/upload-client

📖 Documented UCAN Capabilities

The PR for documenting the capabilities our service exposes was merged! We now have a reference guide that we can refer to as well as service definitions! 🙌

👀 Check it out: https://github.com/web3-storage/w3protocol/blob/main/spec/capabilities.md and https://github.com/web3-storage/w3protocol/blob/main/spec/services.md

🎯 Nomenclature Honing happened

TLDR; Account → Space

This week, we came to the realization that “Account” was not an accurate name as the target for our UCAN invocations. Space seems both generic and specific enough that we’re likely going to commit to that. We already have code referencing things called space so…

👀 For more backstory/reasoning, check here: https://github.com/web3-storage/w3protocol/issues/142

💪 w3access upgrades

The w3access package is about to receive an upgrade to the agent class that allows switching between spaces (formerly accounts). It also tracks the “current” space so when you come back to an app you can start where you left off, without having to re-select the space you were in.

It also adds support for fetching proofs that your agent has been delegated a specific capability, which can be used in the upload-client.

The PR also adds generated API documenation which covers other packages in the monorepo as well.

👀 The PR can be found here: https://github.com/web3-storage/w3protocol/pull/177

🧭 Planning for the #1 Use Case

We need to rebase NFT.Storage on our new stack, and more generally we need a way to allow some entity to pay for other users storage of data and it has to be flexible enough to support a bunch of sub-requirements.

We evolved from a simple proposal around tagging to a more thoroughly considered protocol of contracts/agreements (name TBC) that we’re iterating towards.