Store delegations in space

[reidlw]

What

Start storing user delegations in the user space

Why

1. Not storing it in a user space introduces unbound operation costs that is neither tracked or billed.
2. Makes our infra central point of failure, because some information required for system operation is tied to it.

Cost

Should be fairly straight forward and simple change to make. Handling backwards compatibility and deletes (that user will be able to make) is going to be the most complicated part, although perhaps we do not need to worry about deletes.

Background

Currently shared delegations send via access/delegate are stored in separate bucket that access/claim reads from.

Instead we should client store archived delegation in their space and then allow sharing it through access/delegate. In fact access/delegate and access/claim should just provide pointers to the CIDs and client should take care of fetching those on their own.

[reidlw]

@Gozala it's unclear what user/network value we get from this. Could you please edit description? Generally will look for issue descriptions to clearly state:

what is the proposed change
why it's important to do it (impact; quantified if possible)
cost how complex/big/expensive is this

[hannahhoward]

honestly I think the goal here is to take it out of a bucket we don't charge the user for and into a bucket we do charge the user for. same can be said for spaces as dag ticket

[Gozala]

It is mostly what @hannahhoward said but there are some nuances about implementation also. Currently backend does extra work when you query pulling delegations and packing them into the response. That is both overhead and kind of silly since we provide service for storing and reading static assets. It would make more sense to leverage those API to store delegations from the client and change our API so it's just exposes list, then client can also go ahead and fetch those delegations via generic read interface we provide.

In other words we should use our own optimized APIs in our operations which would incur less costs and make system simpler.

[Gozala]

For what it's worth current implementation meant to be a temporary workaround to unblock it from other work threads that I'm proposing we leverage here. But as all things once it's out doing a proper thing never gets enough priority.

[Gozala]

I have update issue per suggested template

[reidlw]

@Gozala are these large amounts of data? I'm just trying to get to the business reason to invest here.

I read both "some cost reduction (not quantified)" and "makes us more decentralized". I don't suspect this is a big cost reduction opportunity nor are we necessarily prioritizing those right now. Decentralization argument is stronger, but there's also going to be lots of decentralization work in the roadmap over the next year and not sure where this fits in that priority-wise. My inclination here is:

• consider this a decentralization feature
• @Gozala and @hannahhoward work out where this goes in roadmap, and make sure it's captured there
• Keep ticket in backlog - I'm also going to start creating Github milestones corresponding to roadmap milestones, and we can tie it into the proper milestone once that's settled.

WDYT?

[Gozala]

@Gozala are these large amounts of data? I'm just trying to get to the business reason to invest here.

I have not looked into how much data it is right now, but it is

1. Constantly growing amount of data
2. It is unbound amount of data

The second is a key here, it may not cost us much but it has potential to become very costly and executing it fire fighter style is going to be hard and unpleasant