Create package for generating NFTs offline

[whoabuddy]

Related to #19 - we should separate the idea of generating the NFT based on a Bitcoin address so that any front-end could implement this as a simple package. That way others could quickly show the Bitcoin NFTs for a given address using the same algorithm.

[whoabuddy]

@larrysalibra we have the basic algorithm in a python script thanks to #19 and #31 in the generation folder.

Do we just need to port this over to javascript/typescript as the next step toward creating this package? Should we set up a separate repo?

[whoabuddy]

Found this best practices article from Snyk that looks like a good starting point.

(noting the source repo seems to be updated here)

I think we'll need a separate repo, and through the steps in that article can use GH actions to perform the releases.

We probably want to start with bitcoin-colors-generator and can later use that as a template to create bitcoin-faces-generator.

The NPM registry and some other optional services will require a public email address. I can use mine for now if it makes sense unless anyone has another idea!

[larrysalibra]

Do we just need to port this over to javascript/typescript as the next step toward creating this package? Should we set up a separate repo?

A separate repo seems easiest.

Perhaps it would be best to define the public interface of the desired resulting js/ts library.

The code in

From the library user's pespective, I would imagine this should be a single function like

generateBitcoinFace(bitcoinAddress: string) => svg

Internally there might be two components:

1. generating traits from an address: takes a bitcoin address and returns the json object of traits

  [ { "trait_type": "Eyes", "value": "Laser Eyes" },
    { "trait_type": "Shirt Color", "value": "Blue" } ]

2. generating an svg from traits object

Have you settled on how to generate the svg from the traits?

On looking (very) briefly at the generation python code:

• it appears that traits don't vary by address type...is that intentional?
• why sha1 and not sha256 like bitcoin?

[whoabuddy]

A separate repo seems easiest.

Done! Created it for Bitcoin Colors first, we can copy the code or revise it for Bitcoin Faces when we have everything together.
https://github.com/bitcoin-nfts/bitcoin-colors-generator

Perhaps it would be best to define the public interface of the desired resulting js/ts library.

This makes sense, I agree on the function signature from the user's perspective, and like the idea of separating methods 1 and 2.

Have you settled on how to generate the svg from the traits?

The preliminary testing split the rendering into two pieces from Clarity's perspective, with SVG path data stored in a data-map.

1. generating the svg and path HTML skeleton code
2. filling the path data based on the function called

In Bitcoin Colors it's only the fill color that changes for the 2 layers. Adding in the four quadrants should make it a better simulation of what to expect with Bitcoin Faces.

SVGs are pretty flexible too, and I think the important thing to remember is we need a matching function in Clarity as well, so it may be nice to scope it out in TS, write it in Clarity, then make sure output from both matches.

CSS in SVGs could be another way we can simplify some things as well. Components are components with IDs, styles are set separately.

it appears that traits don't vary by address type...is that intentional?

Yes, but #35 covers some possibilities to expand it, including changes by address type or other data we can get from the TX.

Also #33 aims to answer some general questions about limiting combinations, which would be useful to limit a certain trait to a certain address type.

The test does generate and run against legacy, wrapped and native segwit addresses.

why sha1 and not sha256 like bitcoin?

See #34 and (this comment) - I opened a PR to update this to sha512 to give us a longer string to work with. That way if we want to add traits or layer on traits client-side we're not limited by the number of substrings we can create.

It also might be worth "reserving" some of the hashed data for future use and using the first n bits of the string. I'll open a separate issue to cover this. See #37

[whoabuddy]

Closing as this will not be needed with the reduced scope.