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! Tying up the loose ends. 🎀
✨ New w3ui ready for release
This week, we merged the PR integrating the
access-client to a branch called
next. Now, w3ui is more “space” centric, stores keypairs securely (unextractable) in IndexedDB and consumes the upload and access client, for talking to the updated services. https://github.com/web3-storage/w3ui/pull/119.
In the process, we discovered that the
access-api couldn’t get info on spaces, which is currently blocking uploads from succeeding. We are working on a fix! https://github.com/web3-storage/w3protocol/issues/243 ⛑️
Next week, we’ll be working on the
w3up-cli consuming the
Note that w3ui is now ready for release, but is blocked ⛔️ on a production release of the backend services to be used with. We’re hoping to get a production release out the door this week 🤞
📝 More docs updates!
We are continuing to update docs to reflect the changes to w3up. This week, all the w3ui examples were updated as well as the reference documentation.
👀 Take a look: https://github.com/web3-storage/w3ui/pull/129
Next week, we’ll be tackling the
upload-client README 🏈
🍭 Preview: Super-sugar API for w3ui
We’ve also started thinking about the different types of users for w3ui. Right now, we’re looking at building components at four levels of abstraction, so that w3ui can be integrated based on users’ needs. Note: w3ui currently provides abstraction level 1 😊
👀 Find out more here: https://github.com/web3-storage/w3ui/issues/120
🧩 Improved uploads listing
upload/list returns a single entry per root data CID along with a list of shard CIDs of the CAR files the DAG can be found in.
Previously you’d receive an entry for each shard. The intended flow is to store 1 or more CAR shards and then “register” an upload with a single call specifying the root CID + CAR shard CIDs. Receiving a list entry for each shard is asymmetric and unexpected.
👀 More details here: https://github.com/web3-storage/w3protocol/pull/229 and https://github.com/web3-storage/upload-api/pull/56
🥞 Organized SST infra
We use SST to manage our infra on AWS. We spent a bunch of time this week moving our SST from one monolithic “stack” to multiple “stacks” that more formally separate the concerns and allow us to reason about different parts of the system more easily.
🗺️ w3account spec
The proposal for w3accounts was merged to main after some iterations. TLDR; managing delegations and key pairs across multiple spaces, agents and devices is hard - here’s how we do it 😎
The most exciting UX problem that’ll be addressed by this spec is the need to verify your email address for each new space you create. Now once you’ve verified an agent (read application/device), you’ll not need to do that again when you create additional spaces!
👀 View the spec: https://github.com/web3-storage/specs/blob/main/w3-account.md
📦 Moving capabilities into their own package
We moved the Web3.Storage UCAN capabilities out of the
access-client and into a separate npm package so it can be used independently, which means folks don’t have to install all the dependencies of
access-client if all they’re using is the capabilities.
👀 The published package is here: https://www.npmjs.com/package/@web3-storage/capabilities and related discussion: https://github.com/web3-storage/w3protocol/issues/80
🐙 New mascot for
Our friends from Fission made a
dag-ucan mascot for us ❤️! If you turn the IPLD logo upside down, it looks like a jellyfish!
Thanks again to everyone involved in w3up work this week, you’re all awesome. Keep on trucking. 💪