I saw that you have a ticket for S3 compatibility, that would be nice: S3-compatible API · Issue #692 · eigerco/polka-storage · GitHub
I am using filebase.com currently to archive things, since it integrates with the AWS cli through S3 compat. But I would rather use something Polkadot powered
Another thing that I think is very useful is mounting it into the file system. I tried Sia coin (storage as well) a few times over the years and was always disappointed at how badly it integrates with Linux or MacOs. They do not offer a simple CLI where you can do sia mount --config-whatever.... --mount-path /mnt/archive. It could be very nice to have this, since it makes it usable for non-tech users as well.
As example, there is the ProtonDrive MacOs UI app which makes it a no-brainer to mount a remote drive.
We start by apologizing for the time in between updates, we’ve been keeping our heads down, pushing forwards.
In Delia, we’ve done several improvements to the UI; namely, we did several improvements to the deal toast, replaced the old provider selection with a table listing the final deal price, improved error messages and more behind the scenes, some notable PRs below:
@0xTaylor you’re right! Thanks for noticing, I had extracted the list from GitHub using a template and forgot to re-write the repo name on the second batch of links. It has been fixed now!
We’ve been hard at work squashing bugs and testing and we’re ready to announce that our testnet is currently up and will be until the end of the week (27th of June, 18:00 CEST).
You can upload and retrieve files using our Delia client:
And you can check the README for detailed instructions.
Will you actually be deploying this as a system chain or just providing the deliverables for the fellowship to implement?
In your grant you’ve stated that it will be payable in DOT. I assume it will also be available in USDT/USDC?
What are the planned tokenomics for this if any exist? It will be a market places for buyers and providers – I assume treasury will have a fee taken from purchases and renewals?
Will there be any initial provider incentives – If so, Have these numbers been crunched already? Can you share them?
Really exciting that we’re finally going to have this – I would like to better understand how it will impact the rest of the network.
Will you actually be deploying this as a system chain or just providing the deliverables for the fellowship to implement?
The final goal is native jam integration, system parachain is just temporary current design for testing.
In your grant you’ve stated that it will be payable in DOT. I assume it will also be available in USDT/USDC?
Is a good question, we can consider it but current plan is just DOT.
What are the planned tokenomics for this if any exist? It will be a market places for buyers and providers – I assume treasury will have a fee taken from purchases and renewals?
Tokenimics will be one of the work streams of phase 4.
Will there be any initial provider incentives – If so, Have these numbers been crunched already? Can you share them?
No provider incentives because we are not creating a new token. Providers earn by selling storage.
Acting as a decentralized storage network for preimages.
Guaranteeing that preimages are accessible to validators when required.
Tracking availability over time to satisfy JAM’s invariants.
But I think the first two points might be incorrect. Preimages are request by a service via solicit host call. Once requested, they are provided to JAM via E_{p} and are stored onchain, in the main JAM state, until expunged or forgotten. Therefore, all validators are forced to store all preimages anyhow. In that sense, I don’t see how you can act as a “decentralized network for preimages”. Storing historical preimages might be something though, although they are also all present in previous state.
What is actually left blank in the paper is: once a hash is solicited, someone has to give the preimage to the JAM validators to provide the E_{p}, and to me this seems like a potential gap. Have you considered this so far?
personal 2c: While the work for the parachain is mostly set in stone by now, I hope we can tackle storage for JAM from a different perspective. Storage is a low level primitive, so I will look at it from the perspective of the low-level services’ code, hosted on the JAM super-computer/cloud:
As it stands, a service has access to 3 types of storage:
Expensive, long-lasting onchain state (accumulate)
Transient, cheaper, more available, but not infinite DA storage (refine)
Service storage, fully kept offchain (analogous to parachain state). Can be as large as it wants to be, but the issue is that all of this has to be part of the work-package (analogous to PoV in a parachain).
(I define these storage types in this presentation, although the slides might be a bit crude)
I would first ask myself: what storage primitive that a service’s code/coder could use, that the above 3 cannot address? And what use-cases would it enable? Frankly, my imagination ends here, but I would love to discuss this further with you and find a good use-case/gap
I’ve been wondering a bit about long term storage options for the very early stage JAM service I’m brainstorming, the protocol is meant more for realtime p2p collaboration(like a matrix on JAM) that would operate mostly on the DA, light clients send work packages directly to JAM without an intermediary network that persists data like with parachains and at least initially the lack of long term storage would have to be seen as a feature.
The OS layer will abstract the DA as a file system, it could be known to applications they are dealing with temporary data by mounting it as a tempfs on /tmp and asking apps to use mktemp, but I’d like apps to be able to persist documents for longer simply by moving/writing files to a different location(e.g. /archive/*), that action should trigger some kind of preimage pinning that uses a separate storage service.
I imagine an option doing as Kian mentions which requires more work on the client, the app detects it needs to pin the data on an external service(e.g. ipfs) then when it needs to be read on JAM due to a user command/action the WP includes the subset of the data it needs and the OS on the JAM side abstracts the incoming data as a file in the persistent location.
Another interesting option I assume it will be more expensive, for people doing JAM storage services is to allow my service to pay you directly on chain to keep my data alive on the DA, like a touch command, then I just assume the data is always there and I can read it months later from my long running service even without external user interaction.
