## Problem
With the implementation described in this document we're tying `UserA` to a `didX`, and currently we allow for 1 root bucket.
We're strongly coupling `UserA` to `didX`(bucket).

Conceptually, `userA` (through a did, keypair) is at the moment accountable for "ticket printing" via UCANs.
Which I suspect might be a problem when we scale to a more complex architecure: multiple buckets, payments, etc.

### Scenario - Multiple buckets
In this scenario we want to have multiple projects, ie. `myApp1`, `myApp2` projects. With the current architecture we could achive this by having `UserA` create a `didX/myApp1` and build a UCAN like `{with: 'storage://didX/myApp1', can: "*" }`. While this works it still keeps a strong relationship between those buckets and the original user.

If we think about it, assume `userA` has created a UCAN than grants `can: "*"` to `userB` for their entire bucket. Pratically, `userB` has the same level of auth as the original user, but from our DB perspective we're treating them "differently". There's no relationship between that userB and that bucket. At the moment the DID is column on the `User` table, so we are not linking to it.

I wonder if we should be thinking about Buckets as their own entities, that are accountable for signing UCANs (printing the tickets), and that ability can be delegated to multiple `did`s... But there's no hard 1:1 link between a single User and a single bucket. This would then leave open the possibility for things such as:
* One user having more than one bucket.
* A user being able to delete a bucket and start again through the web UI.
* Multiple users sharing _equal_ access to a bucket.
* Having "organisations" where multiple users share _equal_ top-level access to a bucket.

While these things (or similar setups) are theoretically possible by getting users to manage things through UCANs, we should probably ask whether that is the most convenient thing for the users.

I still struggle to envision how much duplication between ucan and service data structure is required to have this model working in practice. I suspect that the only way to undertand that is to start building an mvp

# Questions
1. Who creates the keypair for the bucket in the first place? The user generating the bucket in the first place? The service?
2. I feel a relationship between the bucket creator should exist, but I reckon it should be an external key to user table.
3. While UCAN would work for auth, I suspect the service (ie to hadle the UI), should still store information about delegation etc? Or am I missing something?
4. Ultimately, do we want to build the thing which is the simplest to build (current architecture), or is there an architecture that would create a better experience for the users, and should we build that?