feat: w3-deal protocol

[Gozala]

First pass on the storacha/w3filecoin-infra#29 flow.

• Translates structs used by https://github.com/data-preservation-programs/filsigner-relayed/ to IPLD Schema / TS interfaces
• Describes HTTP API flow that could be implemented to allow spade to invoke signing without learning about UCANs
  • We can also route through spade-proxy as an alternative or complimentary approach

[vasco-santos]

This iteration looks great! Thanks for putting it together

1. we should present it to spade team and gather feedback sooner rather than later, so that we can understand if this is something that we can work together to land (including spade side of things). if not the case, we should reduce scope for now to only have interaction between storefront and agency in a perspective that someday they will be the same.
2. should we spec how we would provide source URLs for each piece in this flow? could be good to have something in place we could also present their team to initiate dialog on that side of things too

[vasco-santos]

The broker that in this case would be the Agency, at least in first iteration where Agency and Broker are not the same. Think it would be good to make that clear, or at least describe Agency role above and make clear its role today

[vasco-santos]

ok, I see now the HTTP interface section below. With that in mind, I would suggest to add a small note here still to avoid same confusion from readers until later

[vasco-santos]

We can delegate capability when we perform aggregate/offer individually per piece (aggregate). When spade-proxy receives the offer it can re-delegate to the broker. Given we can easily have this, should we consider to have it required instead of the long term solution?

[Gozala]

I think we should go for auth per offer, that said I think it's good to have both options listed. There is another tradeoff that I failed to communicate here, which is token per offer means that those tokens are likely to be included in requests and consequently can get leaked very easily. Long term tokens are likely exchanged ahead of time and out of bound, so they are less likely to get leaked in comparison to per-request approach.

[Gozala]

Suggested change

	All the filecoin deals need to be signed by a Fil wallet, in order to avoid passing private keys to wallet _Storefront_ could delegate a capability to a sign a deal to a _Broker_ instead.
	All the filecoin deals need to be signed by a Fil wallet, in order to avoid sharing wallet private keys, _Storefront_ could delegate a capability to a sign a deal to an _Agency_ or a _Broker_ arranging a deal on their _Storefront_s behalf.

How does this sound ?