package:filestorage

[adiled]

@TheGreatAxios Is this one planned to be a TS rewrite of filestorage.js or only a wrapper to FileStorage.sol?

I built some high-level APIs on top of filestorage.js called DeFileManager.ts with file management features, such as tracked uploads, navigating the tree, a CLI, and react hooks (used by filestorage-ui). It's more of a stateful-client orientation than a contract primitive.

Depending on the scope of this monorepo we could either bring the package in here as filemanager, or filestorage.ts could be an improvement of filestorage.js within filestorage, or a mix of both.

I think SKALE filestorage is crucial to so many applications around network's use cases and a set of low-friction libraries will allow a productive DX.

[TheGreatAxios]

Hey @adiled!

That all looks great, I agree. Would I would recommend is the following:

1) Let's look to bring as many resources together as possible into this monorepo. This is for the community and the easier we can make it the better. 2) The organizational structure of this monrepo currently is so that nearly every smart contract will have it's own package. I plan to have all the pre-deployed contract wrappers (including IMA & Filestorage) be added to the primary skale.js package.

3) All Mainnet contacts will be aggregated in a skale-mainnet.js package to reduce bundle size for devs building on the SKALE Chain (Longer Term)

4) I would love to see ui components, hooks, tools as well in this, however, decoupled from the core library. Filestorage for example would have a filestorage package that has the core wrapper for Filestorage.sol. From there, it can also contain the TS rewrite of filestorage.js under the functions.ts and utils.ts files as those are just "extensions" to improve usability. For UI components I would love to discuss a proper structure further, but high level:

filestorage - main filestorage-ui - reusable components for the frontend

5) CLI -> You can see an open issue. I will be building out a CLI over the coming months that will inherit from all the other packages and be a SKALE CLI for both SKALE Chains and Mainnet ideally (that should not live in a core package, but be a package itself).

Please let me know if you have any questions, I will continue to add more documentation on contributing and adding packages so this a bit more clear!

[adiled]

That's well-detailed, thank you. A cohesive JS package is much needed, and scoped packages serve well.

Learning from growing EVM ecosystem, I've some observations that can shared as a mental model for UX-DX balance and its significance in this case, particularly around your point 4.

On the highest level, I see these distinct usability verticals:

1. contract ABIs, RPCs, and language wrappers are procedural primitives forming a stacked vertical

2. terminal clients (CLIs, TUIs)

3. web / mobile / desktop / game clients

From ground-up, the decentralized stack is for the lack of a simpler word, async (let's assume finality a given), because the internet is. With web2, they had to introduce ReST to convince enterprise ecosystem of transferability of state to clients. All they did was leveraging of ground realities, existing infra, fused into conventions, and inventing a good acronym. It was only later they had to ideate RESTfulness with levels going from 0 through 3, yet the introduction of the idea lowered the barrier of API development, evolving the clients to be stateful.

That said, we see two distinct dev classes in crypto:

1. actionaries: chain throughput hungry

2. reactionaries: chain state hungry

The status-quo of crypto DX has so far optimized for actionaries, whereas further growth of networks is dependent on feeding the reactionaries, and a lot of these build clients... including CSS writers :P

A practical scenario I'd propose, that may spread bliss across the dev tooling through all verticals:

1. Contract wrappers are two-pronged, catering both user classes on even keel: ship events as an API, separately from method callers (Contract.ts/events).

2. A layer goes between primitive vertical and client verticals: bind the wrapper prongs by associating events and methods (Contract.ts/context) AKA a spoon.

3. SDKs consume the union above, with a provision to being watchful of state. e.g. filestorage, ima becoming inclusive for reactionary devs. Initially, this may be under an experimental flag.

This is likely easier done than said, with potential of larger impact on the ecosystem, especially given that SKALE is well-positioned for users vested in hyper-utility of chains, with a very interactive audience. It will also create a push for improved interfacing at node level, a window of opportunity that is wider prior to scale. Ethereum mainnet for one missed it with popular clients now trapped in momentum.

By an example, filestorage.js rewritten with the help of above model, slims down defilemanager.ts to file-tree caching and search, each delegatable to 3rd libraries, eliminating the need for maintenance. Clients then can exclusively rely on SDKs. Client state (hooks and family) can also be shipped (e.g. wagmi) under skale.js while the UI components (e.g. skalenetwork/metaport) may grow independently using @skale.js/*.

Metaphorically, the reactionaries are not to be perceived as propellers, but the fuel that's high-octane, except it burns to become elements of the ship. We only have to haul the anchors up a yard, and that's when the propellers will function optimally while maintaining a smoother and faster sail.

We could open a discussion and explore implementation side. An example: SKALE Metaport as a UI widget seems to emit window events following the RPC naming convention.

[TheGreatAxios]

Thanks for all of this, I think we are on a similar train of thought. There are some minor differences that I will open in a dicussion.

[TheGreatAxios]

@adiled https://github.com/Dirt-Road-Development/skale.js/discussions/54