UDA Attachment Improvements

[cryptoquick]

We'll need to support three separate media attachment formats for our UDAs:

• [ ] Consignment Embedded Thumbnail
• [ ] External SHA-256 Image
• [ ] High Definition Blake3

[crisdut]

Ok, sure.

Some questions

1. Just a confirmation, today in RGB21 we have a 3 fields: preview, media and attachments.

Let's add thumbnail to the preview, the media's sha2 to the media and HD blake3 to the attachments?

pub struct TokenData {
    (...)
    pub preview: Option<EmbeddedMedia>, 
    pub media: Option<Attachment>,
    pub attachments: Confined<BTreeMap<u8, Attachment>, 0, 20>,
    (...)
}

2. Today we use a resolver to make information's about media information and these resolve download the media in memory to obtain sha2. Are we going to keep doing this? If so, we must have a certain limitation on the size of the medias in wallet, right?

3. For more complex media, created via the marketplace, we could provide in the struct used to issue the UDAs, options to add pre-processed data, especially those referring to High Definition, etc... I imagine an optional parameter where we send the ready-made information and we don't even need to download anything, do you agree?

4. What is "Consignment Embedded Thumbnail"?

[cryptoquick]

1. Yes, preview is a better name than thumbnail. And yes, that approach makes sense.
2. Let's continue doing this, with no limit for now.
3. Sounds good.
4. Preview.

[cryptoquick]

One thing to keep in mind, Preview should have constrained dimensions, and be encoded in a lossy format, like JPEG.

I believe you can use this image crate method to resize the media to a specific dimension: https://docs.rs/image/latest/image/enum.DynamicImage.html#method.thumbnail

A good dimension would be 630px, because it's the dimension used by Facebook and Instagram.

[crisdut]

One thing to keep in mind, Preview should have constrained dimensions, and be encoded in a lossy format, like JPEG.

I believe you can use this image crate method to resize the media to a specific dimension: https://docs.rs/image/latest/image/enum.DynamicImage.html#method.resize_to_fill

A good dimension would be 630px, because it's the dimension used by Facebook and Instagram.

Does it make sense, instead of doing this within the contract issuance method, to expose a method for BME to perform image adjustments and then send it for contract issuance?

[cryptoquick]

It's easier to do it in Rust in my experience.

[cryptoquick]

Also, let's use this method instead https://docs.rs/image/latest/image/enum.DynamicImage.html#method.thumbnail

[crisdut]

It's easier to do it in Rust in my experience.

I think I didn't explain it right. I'm saying we have a method in rust, just for that. This way, before sending to the contract issuance method, the media are already "in the correct format". This way, we could create a UX where while this method is running "adjusting image" appears, for example, like when you upload a photo. Then, when this is finished, we only send the data to issue the contract.

Does make sense to you?

[cryptoquick]

The only problem with that approach, as nice as it sounds, is that we would have to return bytes back to JavaScript and then immediately return them to Rust WASM, like the type signatures in these methods: https://github.com/diba-io/bitmask-core/blob/d62161cea6cf8cb3f0555d18ab6fff41802176ab/lib/web/carbonado.ts#L6-L17 That's a lot of memory allocation that could be avoided by providing the media to Rust WASM just once.

[crisdut]

The only problem with that approach, as nice as it sounds, is that we would have to return bytes back to JavaScript and then immediately return them to Rust WASM, like the type signatures in these methods:

https://github.com/diba-io/bitmask-core/blob/d62161cea6cf8cb3f0555d18ab6fff41802176ab/lib/web/carbonado.ts#L6-L17

That's a lot of memory allocation that could be avoided by providing the media to Rust WASM just once.

What if instead of returning the bytes, we just return the hash and name of each file, because this method, in addition to processing images, is already hosted on the rgb-proxy, because our images are not on carbonado, they are on rgb-proxy and today we use it on the bitmaskd server.

[cryptoquick]

Where does the thumbnailing occur?

[crisdut]

Where does the thumbnailing occur?

I was thinking that resolving the images could be a request to our bitmaskd server and it wouldn't return the thumbnail, just the ids, names and hashes.

Then when we issue it, I would retrieve the information directly (if necessary) from rgb-proxy and then issue it.

[cryptoquick]

You haven't answered my question, how do we get a thumbnail to embed in the consignment preview?

[crisdut]

You haven't answered my question, how do we get a thumbnail to embed in the consignment preview?

I need to think a little, but in the consignment file, I believe we can use the contract ID, or the contract property itself called TokenData to be able to fetch this data from the rgb-proxy.

[cryptoquick]

No, we need to embed the preview within the consignment. That's what EmbeddedMedia is, right?

[crisdut]

No, we need to embed the preview within the consignment. That's what EmbeddedMedia is, right?

EmbeddedMedia is the type only of the preview field, of the RGB21 contract.

In Transfer type Consignment, it does not have this type of data.

What I was proposing is that in this consignment preview (I think you are referring to this issue), I could return the thumbnail in the response.

Does it make sense to you?

[cryptoquick]

That works. But we agree that the media needs to be thumbnailed and embedded within the Contract Consignment preview?

[crisdut]

That works. But we agree that the media needs to be thumbnailed and embedded within the Contract Consignment preview?

I agree if we are talking about the return of the issue. Can I do it in release 0.7.0?

[cryptoquick]

Sure, so long as we can get that and our new swaps done over the weekend. We need to have a beta 0.7.0 wallet ready by Monday.