vikiival/minimark#1

I copy tons of files around :))

As we've launched the Basilisk marketplace recently, we are looking for ways to programmatically raise the number of offers and bring more liquidity to NFT offers.

What should the bot include, and how should it behave?

At the start, it could be managed by tech-savvy users who can put in their private key, and bot will make offers on their behalf
User can set their strategy what amount they are willing to pay for particular artists, collections, and NFT set &c, this is about your creativity.
Then it would be nice to have setting for % of floor offers should be made, in some cases, underbid listing price per NFT, amount of % from others offers. For example, scan existing orders, and you want to overbid them higher at some certainty (because you believe in high reputation artists or value accrual particular NFT for reason)

This grant has an open end, so the more advanced, the higher reward could be for it.
Good option is to split reward in milestones.
Highly recommend is to use our upcoming uniquery API
In the long run, would be nice to have a telegram/discord bot which can users sent some watch alerts for particular artists offers etc

Ref

https://beta.kodadot.xyz/bsx/stats/

Introducing @kodadot1/hypercasual

It should be a set of utitilities we already use in KodaDot nft-gallery but we want to reuse them in sub-scaffold & so.

Example:

• trim address
• address to identity?
• link to explorer

ht/ @Roman-24 (maybe add something more)

WARN @kodadot1/sub-api doesn't appear to be written in CJS, but also doesn't appear to be a valid ES module (i.e. it doesn't have "type": "module" or an .mjs extension for the entry point). Please contact the package author to fix.

WARN @kodadot1/vuex-options doesn't appear to be written in CJS, but also doesn't appear to be a valid ES module (i.e. it doesn't have "type": "module" or an .mjs extension for the entry point). Please contact the package author to fix.

http://localhost:4350/graphql

It should be an IPFS CID: that will contain:

{
 "image": "ipfs://ipfs/<CID>",
 "name": "Placeholder",
 "description": "Something that tells this is an error"
}

https://orkhan.gitbook.io/typeorm/docs/find-options

export async function getOneAndJoin<T extends EntityWithId>(
  store: Store,
  entityConstructor: EntityConstructor<T>,
  id: string,
  relations: FindOptionsRelations<Entity>
): Promise<T | null> {
  const where: FindOptionsWhere<T> = { id } as FindOptionsWhere<T>
  return store.findOne<T>(entityConstructor, { relations, where })
}

REST api for uniquery :)
Compatible with libs like useSWR

https://swr.vercel.app/examples/basic

built with

https://github.com/unjs/ohmyfetch

The problem is that $obtain currently takes: IPFSProvider in provider parameter.

The task:

• extend that IPFSProvider is also HTTP_URI
• in mapper check if it's HTTP_URI than return that

This issue is a brain dump what needs to be done to successfully finish RMRK v2 in minimark package.

PLEASE BE AWARE THERE IS PR #43 FOR THAT

Critital

• Test Resources logic against the rmrk-tools package (inspo is written for create)
• Comply resource spec with rmrk-tools (we have different types than the package)
• Comply EQUIP - (Equip a child NFT into a parent's slot, or unequip)
• Comply EQUIPPABLE
• Comply SETPROPERTY
• Comply SETPRIORITY
• Comply THEMEADD

⚠️ For all critical stuff, unit test against rmrk-tool need to be written ⚠️

Minor

• createBase should take multiple parameters instead of object

Miscelanous

• fix the issue that is creating multiple minimarks in build

We need a proper minting SDK:

name:

@kodadot1/mint

Architecture:

It should somehow wrap the minting logic into simple functions.
About design patterns I am thinking to use either Builder, Adapter or Strategy.

Ref:

• kodadot/nft-gallery#1826
• kodadot/nft-gallery#4088
• kodadot/nft-gallery#3976

Patterns:

• paraspell/xcm-tools#15

https://github.com/rmrk-team/rmrk-spec/tree/master/standards/rmrk2.0.0

Implement interactions:

• ACCEPT
• BASE
• EQUIP
• EQUIPPABLE
• LOCK
• RESADD
• SETPROPERTY
• SETPRIORITY
• THEMEADD

Check if there are changes for existing interactions:

• BUY
• CHANGEISSUER
• SEND
• LIST
• EMOTE

Some interactions were renamed (we will support both for the sake of consistency)

• CREATE (v1: MINT)
• MINT (v1: MINTNFT)
• BURN (v1: CONSUME)

The minimark should do:

• Ability to create this v2 interactions
• should unwrap v2 interactions

having tests for this would be golden.

There is a telegram group for RMRK implementers

What is the current solution

currently when someone wants to use minimark she or he will need to export functions like

import { createCollection } from '@kodadot1/minimark'

It is good but we will have V2 #43 soon and I would cause chaos

What I am trying to achieve

that we will have Subpackages

For RMRK v1

import { createCollection } from '@kodadot1/minimark/v1'

For RMRK v2

import { createCollection } from '@kodadot1/minimark/2'

For Common

import { asSystemRemark } from '@kodadot1/minimark/common'

I already hacked something

but it is not ideal and I am missing CommonJS

main...unmark

• https://github.com/OpenRarity/open-rarity
• https://github.com/cryptoDevAmigos/rarity-analyzer
• https://github.com/kongnet/openrarity

https://pnpm.io/motivation#creating-a-non-flat-node_modules-directory

currently, the Polkadot-js API is a dependency that causes a couple of issues for both sub API and minimark.

The idea is to make Polkadot-js API as a peer dependency
ref kodadot/nft-gallery#2197

I found that TSUP and uses ESM by default but makes very big package

Alternatives:

• TSUP
• Rollup
• Optimize TSC

We don't need that as settings package is specifically customized to the @kodadot needs

It would be nice to tune up some good utility to have more verbose logs

✖  error     [COLLECTION] [PROBLEM] Entity needs notto be real, {"name":"Future#2","max":3,"symbol":"FUT","version":"RMRK1.0.0","issuer":"DUyAjx5KwFrv7JbdUtvTzvHJFsTaEzzgyeVTUp9TjatS8Lx","metadata":"ipfs://ipfs/QmNMgKU9GnSam44k8xzif21f91S2GSWR5ATZbPQFsji8aD","id":"282781680602E07B32-FUT"} 

It should work with consolidator outside of the box

Extend of @polkadot/types
+ KodaDot specific:

• identity
• extrinsics

+ Common generic

type GenericMap<T> = Record<string, T>

Soon #17 would be merged.
and would be good to support more routes

namely:

• classic https (https://example.com/metadata.json)
• IPNS (ipfs://ipns/<uri>)
• IPFS dirs (ipfs://ipfs/<hash>/1.json)
• Arweave? (ar://<hash>)

Explain every submodule namely:

[
  ".",
  "./consolidator",
  "./entity",
  "./types"
]

Looks like consolidator makes a lot of confusion

The singleton instance, rewritten 3 times is with us since summer 2019.
It served well but when you want to have multiple tabs with different chains it's not suitable

What does it cause:

• kodadot/nft-gallery#3220
• kodadot/nft-gallery#3312

Re-check kodadot/nft-gallery#2269
probably we are missing github URL in package.json for packages ?

For once a while it would be nice to bump packages to the latest version

It would be nice to have a wrapper for common functions of ->

class Query {
  static async getNonce(api: ApiPromise, address: string): Promise<BN> {
    const { nonce } = await api.query.system.account(address)
    return nonce.toBn()
  }

  static async getTokenBalance(
    api: ApiPromise,
    accountId: string
  ): Promise<string> {
    const { availableBalance } = await api.derive.balances.all(accountId)
    return availableBalance.toString()
  }

  static getChainProperties(api: ApiPromise): ChainProperties {
    const { chainSS58, chainDecimals, chainTokens } = api.registry
    return {
      ss58Format: correctFormat(chainSS58),
      tokenDecimals: chainDecimals[0] || 12,
      tokenSymbol: chainTokens[0] || 'Unit',
    }
  }
}

Hack a prefixed versions for the api

Migrate logic from kodadot into separated package

https://github.com/unjs/unctx

Either suited for Vue directly (as composables) or just a Typescript package to make it more portable.

ht/ @roiLeo for idea

Next it would be nice to:

• move import { secondaryFileVisible } from '~~/components/rmrk/Create/mintUtils' outside rmrk folder

Originally posted by @roiLeo in kodadot/nft-gallery#4637 (review)

Ideation

• for uid generation in Minimark
• for uid generation in Squids
• Vue specific ids?

Q: do we want azbuka chars for fun ?

a = 'https://example.com/Дякую'
console.log(encodeURIComponent(a)) 
//'https%3A%2F%2Fexample.com%2F%D0%94%D1%8F%D0%BA%D1%83%D1%8E'

I am gonna copy mappings/utils/entity into the snek

it would by nice to have a common lib which can be used by devs in the dotsama ecosystem

As far as I noticed getOrCreate is pretty much bog standard in most implementations.

Often times "getEvent"/"getExtrinsic" functions are built to handle multiple versions.
The interface expose the isV***/asV*** but additional logic is required to handle these conditional extractions.

We will use Vuex options-based prefixes.
I think that prefix is bsx
but indexers/ endpoints have basilisk

Unite it under the bsx

Maintaining packages is quite a time consuming thing. Having a pipeline for deploying & stuff would be awesome

https://turborepo.org

Once we will have profound readme &c
let's make PR

• sub-api
• minimark
• api

https://github.com/substrate-developer-hub/awesome-substrate#client-libraries

using it for NFT gallery as well as indexers means that pinata is so f*kin slow

import { Registration } from '@polkadot/types/interfaces/identity/types'

In the list of IPFS providers, extend it with kodadot ipfs gateway

Common synonym

Utils that I repeat again and again:

• isEmpty
• IPFS operations
• tba..

The idea is to run promise race over JSON metadata or something which is needed fast

• https://cloudflare-ipfs.com/
• https://kodadot.mypinata.cloud
• https://nftstorage.link/

EDIT:

The task

The goal is to have a function called ipfsGet which would be able to fetch the data from the ipfs using the Promise.race function

export function ipfsGet<T = any>(url: string, providers: Provider[] = DEFAULT_PROVIDER_LIST): Promise<T> {
 // ... to be implemented
}

then in code we should be able to call

const metadata = await ipfsGet<Metadata>(url)

Inputs for the function

url

- ipfs://ipfs/bafkreiazeqysfmeuzqcnjp6rijxfu5h7sj3t4h2rxehi7rlyegzfy7lxeq
- ipfs://bafkreiazeqysfmeuzqcnjp6rijxfu5h7sj3t4h2rxehi7rlyegzfy7lxeq

optional: Provider list (this is already done)

to check what is inside ipfs url prefix the hash with (https://ipfs.io/ipfs/)

https://ipfs.io/ipfs/bafkreiazeqysfmeuzqcnjp6rijxfu5h7sj3t4h2rxehi7rlyegzfy7lxeq

You need to do:

1. if the url starts with prefix ipfs://
2. extract the hash (called CID) from the function
3. get providers
4. using Promise.race fetch the array.
5. promise.race will return the fastest resolved value :)

P.S you won't need await in the function

Where to start?

There is branch hacky-ipfs with the setup :)

main...hacky-ipfs

If you need to ask something feel free to ping me here or Discord

Rather having right now read-only at MoonRiver & MoonBeam, let's change it to have there (Beta) to signal people things are in active development and not ready to use.

It would fits much better for upcoming design too.

kodadot/nft-gallery#3500 (comment)

Basically app runs out of the free websocket

I'm afraid that it could not use sub-api. Because If I want to teleport tokens from Kusama, I need to use ApiPromise of kusama. On the other hand, I would use ApiPromise of basilisk.

And sub-api would only return the API endpoint according to the current prefix. 👀

kodadot/nft-gallery#4297 (comment)

Support at least level one

https://blog.logrocket.com/how-to-use-keyof-operator-typescript/

export type SomeNFT = {
  currentOwner: string
  id: string
  issuer: string
  meta?: {
    description: string
    name: string
    image: string
  }
}