SRC721 Web Apps

[DerpHerpenstein]

I think we can make SRC721 extendable to web apps and rich generative experiences if we make some slight modification to the structure of the src721.

The deploy op has a

        "type": "data:image/png;base64",// mime type of the images used in traits t0-tx

When i first did this i assumed that the type would be the same and that it would be used in the creation of an SVG filled with images. This works well when you're trying to stack a bunch of images but doesn't really allow for more feature rich content.

I think we should create a special mimetype like

       "type":"src721:text/html", // special mime type for building HTML from chunks

This mimetype would signify that all traits t0-tx are either

1. Javascript
2. CSS
3. HTML (fragment)

Note: HTML content should be presented in an iframe in a sandboxed environment to ensure no outside scripts are run. The only exception to outside references should be to cp assets with the destination /asset/{xcp asset id}

Storing any file in a stamp

Even though they wont be indexed by the current indexer,
Files will be uploaded with the stamp prefix, then their name followed by the data.

In this example, the files are gzipped the base64 encoded. For javascript libraries, gz compression averages 77%. when accounting for the 1/3 increase in b64 encoding, we can still get a ~71% size reduction

stamp:filename.js.gz.b64;H4sIAOv1nmQAA...

For files larger than 6kb, it will be necessary to allow these stamps to point at other stamps. This is easily achievable by adding a pointer to another asset after the filename. This allows us to store files of any size in 6kb chunks. Obviously the costs would be very large so it would be desirable to keep these files as small as possible.

stamp:filename.js.gz.b64,A12345678;H4sIAOv1nmQAA...

Creating the gzipped then base64 encoded file is easy, we just need to output the file and pipe it into the libraries gzip then base64.

cat filename.js | gzip | base64

Note: If anyone says these aren't fully on chain because the tools to decode/inflate arent on chain, we can easily upload the libraries for inflating, b64 decoding and mime checking so that everything is on chain... it will only be a few kb. it's kind of a silly argument though...

Referencing files in SRC721

So with this format a user can store any file on chain. When interpreting an SRC721 of "type":"src721:text/html" Each traits t0-tx would be added to the DOM of a bare html file in the body section in order. With this structure we can compose any html document. This is very similar to what Scripty.sol is doing on ethereum and also has some similarities to what we did with LNR Web

Additionally we should have an optional property in the mint op d:{b:"", t0:"", tx:""} where we can store general purpose data that will will be put inside of script tags before (b) or after each dom item.

[n4kashu]

cost will be high, but libraries can be reworked (size optimized), and carefully rewritten with for example changing the bloated js/html variable names into wery ugly and hard to read but functional code.. I managed to make make it from, 4 to 1,6kB just doing this...

@DerpHerpenstein exciting stuff sir!!!!

[btcopenstamp]

@DerpHerpenstein

This is undeniably a good idea. However, I suggest that we do not need to consider this extension for now, allowing us more time to plan and design. We can consider updating the SRC721 protocol in the future to support this feature, as you have designed a "v" parameter in the deploy json data.

[SN-Noop]

Hello,

I am intrigued by this subject due to the potential it offers.

I would like to propose a simpler process in my view. If the "js files" were placed within "<script>...</script>" tags, we could use the standard mimetype (which would function for any HTML tag, such as and others):
"type": "data:text/html;base64"

Because all HTML tags can be rendered without requiring html/body/head tags, this would streamline the process of creating src-721 mints (by sequentially appending them).

Given their utilization as src721 and the possibility of dealing with larger files, proper functionality could be maintained by splitting the large file at a JavaScript-compatible point (such as after a ';'). By placing both chunks in two stamps during deployment without introducing any added complexity, the result would be:
t1: [A(first-chunk)], t2: [A(second-chunk)],...

===============================

Regarding the 721 minting process, it might be worthwhile to examine whether a trait possesses a unique tag and subsequently add an "id" to the element:

For instance, an asset could be transformed into prior to the final src721 minting process, thus enabling them to be "selectable."

Utilizing Gzip compression would remain compatible and appears to be a good idea

===============================

I appreciate your initiation of the src-721 movement; I thoroughly enjoyed the experience of implementing it. 🫡