Access Control I think one of the key innovations in web3.storage was recognition that following roles in the system could be played by different actors Resource owner - Actor that generated a space and has full authority over it. Service customer - Actor responsible for handling billing for a provided service Service consumer - Actors that are (cryptographically) authorized to perform set of operations on resource(s). In traditional systems customer = owner, which implies they have to handle access control. Roles

After blob is uploaded user agent will receive a location commitment like this flowchart LR site[(asia.w3s.link)] space(["🪣 zAlice"]) site --delegate--> space { // bafy..site // Storage node authorize access to the stored resource

Requirements We want to write and query right awayWe could use local IPNI replica Be able to do joins in query query both location and blob slicing query by authority

Freeway reads (ipfs gateway reads) Gateway reads via freeway which uses following R2 buckets CARPARK - CAR file storage area. Key format <CAR_CID>/<CAR_CID>.car SATNAV - Indexes of block offsets within CARs. Key format <CAR_CID>/<CAR_CID>.car.idx, index format MultihashIndexSorted. DUDEWHERE - Mapping of root data CIDs to CAR shard CID(s). Key format <DATA_CID>/<CAR_CID>. How it works: Extract DATA_CID from URL.

Notes blob/add request is handled by a router which performs negotiation with storage nodes from which we get memory address. Client writes data into memory address and gets commitment from the storage node. What are the deal parameters ? Specify region Specify TTL anything else ? Deployable Routing algorithms

UCAN 1.0 UCAN Powerline

Authors Irakli Gozalishvili Oli Evans Benjamin Goering Travis Vachon Alan Shaw Vasco Santos Abstract Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

Abstract Protocol describes synchronization primitives that domain specific application could utilize for concurrency control. Introduction Protocol describes a Memory as primitive for managing a mutable state and set of operations for synchronizing it across concurrent sites. Memory Memory is represented using a Prolly Tree (excluding leaf layer perhaps) so that it's properties can be exploited for efficient synchronisation. Operations

UCAN based protocol allowing actors to share information about specific content (identified by CID). We base the protocol on top of UCAN invocation specification 0.2 NextGen IPFS Content Discovery Content discovery in IPFS today is “peer based,” meaning that an IPFS client first performs a “content discovery” step and then a “peer discovery” step to read data in the following way: Client finds peerids that have announced they have a CID Client finds transport protocols for the given peerid that it can use to read IPFS data from that peer. Client retreives data from that peer.

on s3-event storefront calls aggregate/queue - adds to piece into an SQS queue aggregate/add - writes to piece store aggregate/queue fx aggregate/add aggregate/dequeue

Services that have adopted UCANs are able to server requests to customers of their customers directly, reducing operational costs and complexity. However integrating with systems that have not adopted ucans can be challenging and forces following trade-offs: Privileged proxy services need to be introduced to allow requests from such actors. It is impossible to provide provable trace of accountibility in recieipts. In practice service is forced to introduce a less secure backdoor into the system. Here we explore various ways interoperabality could be achived with UCAN disabled systems and tradeoffs.

Contributed to js-multiformats Authored did:mailto specification Authored UCAN specification extension to support did:mailto identified princials.Implemented proof of concept of DKIM signed authorization Contributed to multidid specification which adopted binary encoding I proposed for ipld-ucan Co-authored UCAN Invocation specification Made interactive specification explorer

we have new provider thingy with api that returns effectsServer.provider2(cap, ({ invocation, invoke, id }) => { return { result: { ok: {} } fx: { join: invoke("offer/arrange", { with: id.did(), ... }) } }

Goals We would like to index arbitrary UCANs and allow querying those so we can iterate on content claims protocol Protocol Deploy provider We can allow deploying arbitrary capability provider (implement as ucanto server) using special provider/deploy capability. type Deploy struct { op "provider/deploy" # did of the provider

# ucanto workshop

This is further thinkng on the subject of attaching extra info to the UCANs. In web3.storage we use define authorization session which is a fancy signature & an attestation that web3.storage has performed a validation of that chain and concluded it be sound. In the example below we see a UCAN delegation where Alice delegates store/* capability to the new did:key:zAlice agent with her email address. It also supplies the proof that shows that did:key:zAlice has delegated access to the space://did:key:zAlice Alice's email address which it redelegates { "iss": "mailto:alice@web.mail", "aud": "did:key:z6MktafZTREjJkvV5mfJxcLpNBoVPwDLhTuMg9ng7dY4zMAL", "att": [{ "with": "space://did:key:zAlice", "can": "store/*"

Spaces We identify mutable spaces via DID URIs, because unlike any other identifier they have provable ownership, which is really important for mutating them in an open, trustless protocol. Specifically only owner of the space can authorize mutation by delegating capabilities through UCANs. ℹ️ Space is just collaboration tool allowing groups of agents to cooperate on. It is a name space and not a memory space or a compute space, although those could be abilities that space can aquire through memory and compute providers. In order to enable cooperation participating actors need to prove they had been invited to do so by space owner, which is why we need provable ownership. I think it is a good idea to think of the space as an IPNS or an MFS - A mutable pointer to an IPLD DAG. We may not have an actual materialized IPLD DAG for a space but we do define set of capabilities for querying and updating mutable pointer to transformed revisions. You can think of compute as a sub-DAG, a map where keys are invocation CIDs and values are results of that computation.

Motivation Current authorization protocol allows application to obtain access to all account capabilities by creating a session within which (application local) did:key can be used to sign UCANs issued by account's did:mailto identifier. flowchart LR Space("📦 did:key:zAliSpace { can: * with: did:key:zAliSpace }") BobSpace("📦 did:key:zBobSpace { can: store/list with: did:key:zBobSpace }") Alice("👩‍💻 did:mailto:web.mail:alice { can: * with: * }")

stateDiagram-v2 direction TB invocations: \n components: \n auth: Authorization send: Invocation send.task: Task

web3.storage as Finite State Machine (FSM) https://hackmd.io/@gozala/w3-fsm Concurrency is Hard in subtle ways Software transactional memory (STM) is an alternative to lock-based synchronization