File Size Limitations with JoyID

[WhiteR4bbitt]

This is actually an issue with JoyID itself and how it handles lots of data.

Referencing it here so its known as it affects the file size when using JoyID

nervina-labs/joyid-sdk-js#44

[code-monad]

This is an already known issue for JoyID and seems have no actual fix currently. It has a discussion this year earlier, but end-up with no result. or you can use the APPEND feature to split them into multiple transactions for JoyID users

[code-monad]

seems have no actual fix currently

That is, different browser will have different limitations and the behavior is also different I remember.

[Flouse]

you can use the APPEND feature to split them into multiple transactions

Hi, @WhiteR4bbitt
Have you tried this method?

[code-monad]

you can use the APPEND feature to split them into multiple transactions

Hi, @WhiteR4bbitt Have you tried this method?

This should work properly since it JUST cutdown the transaction sizes if you are splitting them into multiple txs.
But i think this is not what @WhiteR4bbitt is talking about. I guess he's wondering is there anyway to post large tx bodies through joyid, since it is a valid transaction for the network/node validator

[WhiteR4bbitt]

you can use the APPEND feature to split them into multiple transactions

Hi, @WhiteR4bbitt Have you tried this method?

I will give it a try.

It is not ideal long term though to have to make the user do multiple confirms for a single item. (and circles back to the main issue nervina-labs/joyid-sdk-js#44)

[WhiteR4bbitt]

seems have no actual fix currently

That is, different browser will have different limitations and the behavior is also different I remember.

Yeah, they all have different limits when using GET, there is an "average", but even looking into it, its not the same across the board by any means.
But its also meant for limited DATA, in the case of generating larger transactions or relying more on Witnesses it will fill this up much quicker.

Even in terms of a batch with a lot of "co-build" witnesses, it will start to add up.

That is my other concern is the inconvenience of batch minting, as mentioned, I tried a bulk amount of Spores, which could be realistic for projects to want to do at once and I did quite a low number given some projects want to do "10k" and I couldn't even do 500 in 1 TX.

[Flouse]

It is not ideal long term though to have to make the user do multiple confirms for a single item

Okay, in the long term, may I ask a question:

Let's say a user wants to upload a 1MB file. What do you think the user experience (UX) should be? Do you have a way for handling this without splitting the file into multiple transactions?

[WhiteR4bbitt]

It is not ideal long term though to have to make the user do multiple confirms for a single item

Okay, in the long term, may I ask a question:

Let's say a user wants to upload a 1MB file. What do you think the user experience (UX) should be? Do you have a way for handling this without splitting the file into multiple transactions?

On imagiNation the 1MB file won't be an issue as anything on-chain will have a 500kb limit enforced to help promote responsible storage on chain. Otherwise users would be directed to use IPFS.

But to answer the 1MB question more direct, I don't think avoiding at least 2 TXs can be possible because of the Transaction limit itself if I understand correct with the size limits and unless the block size increases how much data can be transmitted in 1 TX/block, it will always be a limitation from that perspective.

Unless bundling multiple TXs into 1 signature is possible, but even then there is the requirement of unique inputs for them to be consumed unless you could leap capacity across a TX. What about a side channel or "layer" like Axon? Just curious as well what could be possible if anything to eliminate this because otherwise multiple TXs is something we will have to accommodate regardless given the TX block size limits.

[Flouse]

multiple TXs is something we will have to accommodate regardless given the TX block size limits.

You’re absolutely right that accommodating multiple transactions is a necessary consideration given the current CKB block size limits. From the dApp perspective, it's crucial to ensure a smooth user experience while navigating these constraints.