client-sdk: Add store blobs API on specified Storage

[poelzi]

Description

The current API hides the Storage object from the user, which might not be the desired for all use cases.
We need an API which takes a mut reference to an existing Storage object that is manually handled and uses this exclusively. The function to get the Storage object, should be customizable.
It should check and extend the Storage object if the size is to small.

Reasoning

I'm implementing nix on SUI/Walrus which stores nix flakes. These are package repositories, that consist of many blobs. The sui flake implements the permission which users can push new versions to the flake, but on the backend side, all blobs should end in the same Storage object, so they can be managed together and extended as fit.

public struct Flake has key, store {
    id: UID,
    name: String,
    storage: Storage,
    description: Option<String>,
    project_url: Option<Url>,
    source_url: Option<Url>,
    /// List of public keys allowed
    sign_keys: vector<String>,
    
    // list to generations
    generations: VecMap<u64, Generation>,
    active_generation: u64,
    next_generation: u64,

    // permissions
    uploaders: vector<address>,
}

/// Returns a reference to the storage resource
public fun get_storage(flake: &mut Flake, ctx: &mut TxContext): &Storage {
    if !array::contains(&flake.uploaders, &ctx.sender()) {
        assert!(false, EPermissionDenied);
    }
    &mut flake.storage
}

Code of Conduct

• I agree to follow this project's Code of Conduct.

[github-actions]

Thank you for opening this issue, a team member will review it shortly. Until then, please do not interact with any users that claim to be from Sui or Walrus support and do not click on any links!

[LambertAlpha]

Let me solve this issue:)

[mlegner]

Let me solve this issue:)

Please do not work on this issue. If we want to handle this properly, we need to change the contracts and perform a contract upgrade. This is not something that can be done easily.

[LambertAlpha]

Let me solve this issue:)

Please do not work on this issue. If we want to handle this properly, we need to change the contracts and perform a contract upgrade. This is not something that can be done easily.

oh, okay:) thank u

[poelzi]

@mlegner could you please triage this in your next meeting. This unlocks many use cases, since it will make storage allocation fully flexible.
For example:
Git on SUI + Walrus - one Storage object with donation function.
Software Repositiories, nix flakes, archives, ...
In the sense of sui composability, the Storage should belong to the upper datastructure.

A medium change with endless use cases. These are the amplification changes that should be done on a new project early.

[mlegner]

@poelzi We are currently working on a comprehensive design that allows managing multiple blobs together with shared resources and funds. It will still take some weeks until that is fully fleshed out, however.

[poelzi]

@mlegner is there an update ?
This is an absolute road blocker for any advanced usage of walrus - I have multiple projects blocked by this :(
The simplest API that would allow me to move a Blob from one Storage to another or merge one Storage together with all the Blobs into another Storage would be enough for me.

[mlegner]

@poelzi Please take a look at the ongoing related work in #2684. cc @liquid-helium

[linear]

from @liquid-helium:

@poelzi, We are actively working on the project, where the storage resource of blobs can be managed by a single object.