should have a quick way of identifying if a utxo is still pending in mempool visually

Release plan for nosft v3

Nosft v3 will be the upgraded version of our current website. And since we have a lot of different pieces, here's the plan

Home changes

Home should be modified to support the following functionality:

• Get inscriptions and utxo's should be moved into single method should be called to get all the data we need. (This is because we are going to move later on to nosft-core this method.
• Include the list of inscriptions for sale from nostr (#84)
• On click (either on my inscriptions or the live elements), it should take the user into the inscriptions page view #102 (missing click event)

Inscription details

Since it is very difficult to keep adding features in the list page, we are creating a view for it. From this view, you not only can see inscription and collection details, but also to share, boost, buy, sell, or send that inscription.
Here's what needs to be implements:

• A single method that takes an inscription id as a parameter, and from there gets all the required information (just as listing inscriptions) to be able to view and send that inscription
• A tab component or a different UI idea to be able to support boost, send, buy, sell, share. (@andredevjs will take care of this)
• Since we have at this point, live ordinals from nostr and that integration we can buy and sell using also #100, the idea here is that from that inscriptions page, if you own the utxo, you can place a sell order in nostr, by signing and sending the order through nostr. (see open order implementation)

Analytics

• Support #101

Nosft-core

All of this functionality, should live in nosft-core, nosft is just a client of that library, but since we have a lot of code done in nosft, we have 2 options.

1. We move right away main to nosft-core, we keep working iterations on nosft-core, and integrate them later in nosft.
2. We finish this plan, and then migrate everything into nosft-core.

Ideally it is easier to move main to nosft-core right away, since we are adding a ton of new functionality that might be difficult to move later.

Releases

Since this is a lot of functionality, we are going to separate releases

Release 1 (Inscription details)

The purpose of this release is to layoff the ground for the next cool features!

1. Create a feature branch of off main, that will hold all of these features for a single release (since releasing them one by one doesn't make much sense)
2. Add typescript support (without types or anything just the support, since most of the code is going to be moved into nosft-core which already has typescript, we just need to benefit from typescript here)
3. Create single method to get inscriptions based on a single address parameter #105
4. Create a single method to get the inscription by inscription id #106
5. Create a single method that based on my address and a inscription id, tells me if I own the inscription or not (maybe with the outpoint endpoint) #107
6. Create view details page #102
7. Integrate send in details page

Release 🚀🚀🚀

Release 2 (Sell)

The purpose of this release is to be able to create a sell order in openOrdex to sell our inscriptions

1. Add live view in home page #84 (do not allow them to go to inscription detail page YET), we are adding this view, since in this release we are supporting selling ordinals
2. Integrate in the details page openordex and #102 to be able to sell our own inscriptions, with open ordex and nostr it will create a sell order that everyone can see sign/buy

Release 🚀🚀🚀

Release 3 (Buy)

The purpose of this release is to be able to buy inscriptions from openOrdex

1. From the live view, allow users to go to the details page, and buy the inscription
2. Create a view all page, that shows all the inscriptions that are for sell

Release 4 (Boost)

The purpose of this release is to allow users to boost the utxo

1. Uses nosft-core that already implements boost
2. Add a button in nosft to boost our own inscriptions (maybe others?)

Release 🚀🚀🚀

Release 5 (Nosft-core)

The purpose of this release is to move all of the code into nosft-core, and make nosft the first nosft-core client.

1. Move getInscriptions single method into nosft-core, and integrate that into nosft.
2. Move getInscription by inscription id into nosft-core, and integrate that into nosft
3. Move open ordex into nosft-core, and integrate that into nosft
4. Move sell into nosft-core, and integrate that into nosft
5. Move buy into nosft-core, and integrate that into nosft

Release 🚀🚀🚀

Unisat is a very nice open source bitcoin wallet. I believe it uses the Web-BTC Standard

https://unisat.io/

We should prompt the user to create 1 or 2 dummy UTXOs if none are found and guide them through it

Some nits to follow up
#148

We'd like a way to see how many active users are on the platform

currently only image files display

Some other websites like generative.xyz and ordswap.io are adding a Metamask integration. It's kinda janky if I understand - they are generating a private key from a signature of the metamask wallet. But if this is going to be the standard, then I guess we can adopt it as well

I should be able to click somewhere to get a link to mempool.space or something so i can investigate a transaction that doesn't have an inscription on it

Instead of trying to show these UTXOs differently and individually, we should do what ordswap.io does and abstract these UTXOs into an available balance. Nobody wants to make sends 1 UTXO at a time

This will also close #1 #12

Currently nosft assumes the utxo was directly minted, and fails to show the image when the utxo was sent from somebody else

I'm constantly brainstorming how to make a PSBT for trading (atomic swap between the seller UTXO id ordinal NFT and the buyer cardinal sats as payment for the NFT); and I think nostr might support for a good UX.

Are you thinking about implementing something like that?

We should have a better layout for the app so the header and the footer will be across other pages.

Create single method to get inscriptions based on a single address parameter

Right now, UI has some weird logic, object should return

{
inscriptions:
utxos:
utxosWithoutInscription
}

Each time we sort, for some reason new objects are created

Should have automated test coverage for key functionality.

Personally, I'm more of a fan of functional tests first, and then unit tests if you have time. Keeping up with unit tests can be laborious, and ultimately if a unit test would fail critically, it would be noticed in a functional test as well

We should allow people to send unconfirmed utxos. People may want to do this to do CPFP on something that is stuck pending

Should be able to search by txid, inscription id, utxo key, etc

Hi, I just started contributing to the repo and I noticed we are using javascript. I think we should migrate to typescript as soon as possible as scaling with javascript without any issues can get difficult.
Also the developer experience is so much better with typescript leading to lesser errors generally.

I got a couple ordmojis and they are trying to render as an image

Create a single method that takes the inscription id and the user address and figure it out if the address is the owner of the inscription.

This will be used in the details page, to find out if user is able to send or not the inscription that it is viewing.

People want to have a link to mempool.space after sending to view their sent ordinal

Current umbrel users don't have the ability to install Nosft locally. Maybe creating a Docker install method would work better for umbel's set up. I believe that would be one of the steps you would need to take if you want to have it on the umbrel store.

It would be nice to see the contents of your inscriptions while they're in mempool - currently they only show up when confirmed on chain

Currently we are doing a lot of heavy calls to get the address's historical transactions, then calculating existing utxos. its super slow

Try loading utxos for the address: bc1p2344tp4n8c47jpuekprrxdztt4v0u79ghqwtgn9y9k4u3kwex7nqt866up and you'll see it fails to load due to a mempool.space error:

https://mempool.space/api/address/bc1p2344tp4n8c47jpuekprrxdztt4v0u79ghqwtgn9y9k4u3kwex7nqt866up/utxo

Perhaps we use blockstream.info here instead

Create a custom hook to get the ordinal and keep the on sales component.

should be able to sort your gallery items by inscription number

Its too slow for people with a few hundred items. We should have separate pages for the utxos, or only load more utxos when they scroll

Please a new option next to "Buy" that says "Buy with lighting ". And integrate there, that's the most consistent way of adding this feature.
You should modify the buy modal to add the following:

1. If is buying with lighting, it should NOT, validate the dummy utxos. (look for the update payer function)
2. Of course, instead of using our psbt and signing function, just call the API with the signed seller psbt.
3. Deezy api will give you back an bolt11_invoice, pay that invoice using Alby first, (then we can add the logic for metamask)

For the lighting icon please use "feather-zap", that is the most similar and it is consistent with the rest of the icons.

Create a new file under utils call lighting.js, and place all your logic there.

It is pretty much the same we have, but much much better, no need for users to be sending some dummy utxo's, something that for most people is hard to understand.

For people with lot of items, this is a pain. Or if we do reload, lets ensure that ordinals are on different pages so it doesnt take forever

Would be nice to add a tab at the top or something "Inscribe" that links out to https://inscribor.com

I think we are checking all our inputs multiple times for inscription presence when it should be in local storage

Right now, since we don't control the content of the iframe, text ordinals looks like this:

But, if we get the content with axios, and push it to the div, we have better control to display the content for example:

 const isText = /(^text\/plain)[a-zA-Z0-9_]*/gm.test(utxo.content_type);

if (isText) {
            axios.get(`${ORDINALS_EXPLORER_URL}/content/${utxo.inscriptionId}`).then((res) => {
                handleLoad();
                document.getElementById(`iframe-${utxo.inscriptionId}`).innerHTML = res.data;
            });

            return (
                <div
                    id={`iframe-${utxo.inscriptionId}`}
                    style={{ visibility: loading ? "hidden" : "visible", backgroundColor: "red" }}
                />
            );
        }

Which looks much better

What u guys think?
@Uthpala @habibitcoin @dannydeezy @topether21

Text inscriptions (like emojis) should be scaled to full width or height, but they look like this:

can test by using my address: bc1p8l0pstx8umh6dx3e8vtw7sd3pspe9r0nh94v7ncwkqleljnr5zdqa3cvlm

When an ordinal runs low on its satoshi value, it become unable to pay for sending itself. To solve this issue, Deezy has added a boost API endpoint.
https://docs.deezy.io/#tag/Boost

To use the boost, the user creates a PSBT, submits it to Deezy, and then Deezy provides a lightning invoice. When user pays the lightning invoice then Deezy completes the PSBT by adding a input to fund the send and top up the ordinal's satoshi value

This should be seamless for the user. My proposal is something like this:

• On the Send modal, have an "Advanced options" section

• In advanced options have a checkbox "Replenish Juice" or something

• If this is checked, don't do the normal send flow, instead use the Deezy Boost send flow

• This flow involves paying a lightning invoice, which should show a modal similar to below (one-click Pay with alby browser extension, or expand to via QR code).

https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki

Anyone here done work w/ PSBTs? Having an issue where the PSBTs we are generating in mv2 are actually "finalized" it seems somehow, so when you try to buy one of our ordinals on OpenOrdex, it gives an error that "all signatures are finalized"

If you take a look at one of our PSBTS (https://openordex.org/inscription?number=13c44582fcaaaa717cef8956d7548ccf25099a6a2d2e6e7684746721726732e1i0):
cHNidP8BAF4CAAAAAZWfzLIXc1zp8TbQrj3z2hNWDES/kQtCEvJtUD8UatbjAAAAAAD/////ASChBwAAAAAAIlEgjRBVFdkOll+Llvk6CoHu1TRh2fvrpF1uY8Wcqc7/NisAAAAAAAEAXgIAAAABGCPFwzeDVKKbFd93XuiuUeicUbaKMfuDgsbmK/HO5voAAAAAAP////8BnwIAAAAAAAAiUSCNEFUV2Q6WX4uW+ToKge7VNGHZ++ukXW5jxZypzv82KwAAAAABASufAgAAAAAAACJRII0QVRXZDpZfi5b5OgqB7tU0Ydn766RdbmPFnKnO/zYrAQhCAUDHHVJ0K5Wmd2a1B4RoHlzfA/SlXkb/yGg2EqfuLWRj9MIWhkqZjyZgYRcKdVPhM0cT0p7Nb1ZysLxSKMXOhITrAAA=
vs one generated externally(https://openordex.org/inscription?number=58b91200e443bed1f17cc909e6672403aa317b3c6a02e594e1459e7967048ec9i0):
cHNidP8BAF4CAAAAAfsBZvuuLlNBPbRW8y3G1NbD987TDi2FBVJNrrQ5YVwmAQAAAAABAAAAAZ+7DQAAAAAAIlEgiqMrl7zEj5mM8RXwMOG1OKBsg9fsudrZufXrIQt5OmMAAAAAAAEBKxAnAAAAAAAAIlEgiqMrl7zEj5mM8RXwMOG1OKBsg9fsudrZufXrIQt5OmMBCEMBQaUymjyf7pGMkBBVMXpyXsHnBAJ4DRWYE5HxoY1fYQ/1hKVLnv1KV1iyT7x5+VvAMP6co/G+T+i9j1UibK1xqNeDAAA=

You'll notice that when importing into Sparrow, the externally generated one has 0/1 signatures whereas ours has 1/1 signatures. Both have the witnesses data populated correctly though.

Will also ask some openordex devs if I can get ahold of em.

Relevant code portion:

      const sigHash = virtualToSign.__CACHE.__TX.hashForWitnessV1(
         0,
         [virtualToSign.data.inputs[0].witnessUtxo.script],
         [virtualToSign.data.inputs[0].witnessUtxo.value],
         // eslint-disable-next-line no-bitwise
         bitcoin.Transaction.SIGHASH_SINGLE | bitcoin.Transaction.SIGHASH_ANYONECANPAY
      );


      const sign = await signSigHash({sigHash});
      virtualToSign.updateInput(0, {
          tapKeySig: serializeTaprootSignature(Buffer.from(sign, "hex"));
      });

      virtualToSign.finalizeAllInputs();

Can try buying with bc1p7u8nsdrdqam4u4huvryzgageg3vfc2mlcfsxrmezl76rnsukwg6qsa2uqr to reproduce

Inscription details

Adds a new page for view details

What problem are you trying to solve?

• There are plenty of features we can add to a inscription, it can be send, boost, sell, or buy even auction. The problem that we have right now is that we have a list of inscriptions, and there isn't too much space to play with all of those features, because of that, we would like to have a specific inscriptions page, in which we can view more details of the inscription like collection and also do more actiions

Why should we solve it?

• Why is this an important problem for us to solve? Because we have some open PRs that integrates nostr and also some others to sign psbt, this means we can now buy and sell from our website if we achieve this!
• Is it a big enough problem to solve? -
• Should we solve it now, or later? This is a blocker to add more features

How do you propose to solve it?

• When a user clicks on a inscription we are going to have some dynamic path that fetches information about the inscription and renders the inscription in the page
• If the user owns the inscription, it should be able to send it, or sell it (once we integrate this)
• If the user doesn't own the inscription and it is for sell, we can allow the user to buy it

What could go wrong?

• What risks does your proposed change entail? That if server code fails, it will break the UI, also we need to be careful of the utxo managment.
• How could this system fail, and what would be the impact if it did? People cannot send/sell/buy inscriptions

Receiving the above type error while trying to send the ords to a different wallet (ie. Sparrow).

Its done serially now but should be parallelized

Proposals:

#75
#74

We need to get as much information as the current getUtxo's function instead of using the address as a parameter, it should be the inscription id.

We will use this to feed the details page, in which, we should be able to view and send the inscription.

this will give us better fee estimation. Different destination address types will have different sizes