sadoprotocol / ordit Goto Github PK

The indexer only record the inscription inscribed on the first input. In my case, I was using batch inscriptions to create multiple inscriptions in one transaction, but only the first inscription was recorded in indexer.

Here is my transaction on testnet:
https://mempool.space/testnet/tx/40c71f4ed13b4587ba3831069edaa69e639e2b7d4ec5ec7ddc22a876c0d478e2

Here is the transaction on your explorer:
https://testnet.explorer.sado.space/tx/40c71f4ed13b4587ba3831069edaa69e639e2b7d4ec5ec7ddc22a876c0d478e2

You can also check the inscription information on this link:
https://testnet.ordinals.com/inscription/40c71f4ed13b4587ba3831069edaa69e639e2b7d4ec5ec7ddc22a876c0d478e2i19

What would you like to be added:

Write up documentation for all the available API methods and endpoints.

• ...

Why is this needed:

Ensure that the community has easy access and documentation on how to consume the ordit api.

Considerations:

This will aim to lock down expectations of what the API produces so we can retain expected behavior in future updates.

What would you like to be added:

Add a content moderation service that can be provided with an inscriptionId to moderate and mark nsfw if it contains questionable content.

Why is this needed:

To ensure that our services are compliant with potential regulations where nsfw may not be appropriate we want to ensure to give pre-moderation of said material and mark them accordingly.

Considerations:

We may want to add this as part of the worker scope built in a way so that it can run on a independent server depending on the amount of resources this process needs. It needs to be able to process a anything from 1,000 - 10,000 inscriptions per block with an interval of 3 - 60 minutes.

We only need to run moderation over media content so it won't be every inscription in a block, and most inscriptions are text based so we shouldn't be seeing an unreasonable amount of media to cover per block.

What would you like to be added:

Add support for OIP-02 Verifiable Ordinal Collection

Why is this needed:

Display the validity of ordinal collections.

What would you like to be added:

Add mempool indexing to align with other explorers and pre-emptively update our own indexes to reflect better results for spendable and inscription transfers.

Why is this needed:

Currently we do minor tracking of movements that occur through our api. For example when someone relays a transaction we update our utxos with a spent state. Currently this only affects relays through our own api as we don't currently consume the mempool.

Another benefit is being able to handle known futures allows us to provide unconfirmed transaction information and show early movement of data such as BRC-20 and Sado events providing higher responsiveness of blockchain movement.

What would you like to be added:

Add functionality to get ordinal aware overview over a wallets balances.

Why is this needed:

Optimized meta for wallets to display current balance state.

Considerations:

Original logic: https://github.com/sadoprotocol/utxo-api/blob/main/src/wallet.js

This should probably be its own index that mutates with blockchain changes.

What would you like to be added:

We need a faucet that can distribute bitcoin to test addresses.

Why is this needed:

One needs some coins to test.

Considerations:

Look at porting over v1 regtest faucet functionality.

What would you like to be added:

Add ability to ask for more blocks through pagination.

Why is this needed:

Supporting explorers by giving the ability to load more content.

Considerations:

Since the latest blocks will update behind the scenes, paginated results may not be 100% accurate when the index positions shift.

What would you like to be added:

Add a method where the user can request a list of spendable utxos that fulfills a desired amount.

{
  "jsonrpc": "2.0",
  "method": "GetSpendables",
  "params": {
    "value": 1,
    "options": {
      "maxOrdinalRarity": "common"
    },
    "filter": [
      { "txid": "<txid>", "n": 0 }
    ]
  },
  "id": "postman"
}

Why is this needed:

Using GetUnspent will result in many round trips for the pagination and also provides more details than required for a spendable utxo result. This method gives all the information needed in a single request for third party services to construct transactions using the provided result.

What would you like to be added:

Add inscriptions indexer to streamline the ability to query inscription via api.

• Add inscriptions indexing solution.
  • Support tokens such as BRC-20.
  • Resolve creator addresses.
• Index networks.
  • Regtest
  • Testnet
  • Mainnet

Why is this needed:

Ord does not inherently provide all the data we need in the way we need it. Also optimizing the specific data we care about for faster lookups.

Considerations:

The tooling around this is still very immature so the work here is substantial.

What would you like to be added:

Add a filter option to Brc20.GetTokens to only return tokens that has mint availability.

Why is this needed:

Allows for generating results that can be displayed for minters.

What would you like to be added:

Move all public base code from SDK to API.

Why is this needed:

Trinity's main goal is to provide a single source of truth for multiple entities to make use of. To do this we want to move a majority of functionality from SDK to API.

Primary benefits:

• A single environment makes the behavior more predictable regardless of client environments.
• A single source of truth for trinity specific features and behavior.
  • Avoid having multiple client implementations of the same functionality.
• Language agnostic clients, with this change the client consumers can be written in any language with the benefit of cross platform shared functionality with deterministic outcomes.
• Close to the source of truth data. With this the SDK no longer has to consume the API for public functionality and can go directly to the database for information. Such as unspents, safe to spends, and better filtering.

Considerations:

This needs to be done in parallel to any work done in the SDK until we are fully feature complete and can update the SDK to become a thin layer without public functionality.

We need to be stringent with quality control on the switch for this as it will have significant outcomes from upstream consumers.