requested by this ser
https://twitter.com/ordinalsreserve/status/1654208108842061829?s=20

TODO: FILL INFORMATION OF YOUR SOLUTIONS

GOAL IS: From a single call, get all the data we need to loop and render the inscriptions, be aware that in the current implementation the object contains inscription and utxo data to view or send the inscription.

What problem are you trying to solve?

• Realtime ordinals events with easy server/browser interface.

Integrate with Deezy.io

As part of the core functionality we are bringing to nosft, we would like to integrate with deezy.io and all it's APIs.

What problem are you trying to solve?

• Expose browser/node library with deezy.inscriptions integration.

Why should we solve it?

• We are going to integrate deezy through this library, so that everyone can benefit from the code

How do you propose to solve it?

• At the beginning by just adding a deezy service that extends api service, and create all the types and methods from the deezy.io API.

What other approaches did you consider?

• A different solution will be to let everyone just integrate the API directly, but then everyone will have to create the types and the integration by themself, also they will have to take care of network configuration and others.

What could go wrong?

• Since this should be compiled and available for browser and node environments, there is a risk that it doesn't work on every framework, since we might have some complex dependencies.
• How will you mitigate them? By testing them in both browser and node, even though, other frameworks might be useful as well
• How could this system fail, and what would be the impact if it did? At this point not much, since it is not in use

Get address UTXO's

Creates base foundation of functionality in nosft-core to expose the getUtxo's method from nosft

What problem are you trying to solve?

• Expose core functionality to get any address utxo's in such a way in which either nosft or any other client is able to consume that functionality..

Why should we solve it?

• Because nosft should be just a client of this library, we would like to have other clients to build their own projects, and this library will help them to do it.
• As the repo suggest, nosft core functionality should live here

How do you propose to solve it?

• By exposing the method in the library in the following way:

const { nosft } = require('nosft-core');

(async () => {
    const utxos = await nosft.getAddressUtxos({ address });
    console.log(JSON.stringify(utxos, undefined, 4));
})();

What other approaches did you consider?

• We thought first to have this code in nosft, and expose an API that this library will consume, but we figure it out that some of the calls are slow, we are just going to allow this library to have the entire logic..

What could go wrong?

• One of the negatives of this, is that, in order to release a new change, we will have to publish a new version of nosft-core (which get published automatically) and to update the client(s) with the new version