tqtezos / minter Goto Github PK

-0 balance
-etc.

After the server publishes an operation, we need a system in place that notifies the client when the operation is confirmed. This system should survive browser refreshes as well as server restarts.

Behavior

• When an operation is published to the server:

  • insert a published_operation row in the database with a 'published' status, return the new entity to client
  • asynchronously poll for confirmation update the row in the database with a 'confirmed' status
    • (option 1): rely on client polling to receive update
    • (option 2): send update via websocket

• When a published operation is returned to the client:

  • (option 1): poll server endpoint and check for confirmation
  • (option 2): listen over websocket for operation confirmation

The contract factory to create new auction contracts:
-User makes the factory an operator for their FA2 account
-User submits request for new auction with specific parameters to factory
-Factory checks list of unused auctions and originates a new one if it's empty
-Factory sends auction params to the unused auction contract and transfers the desired number of FA2 tokens on the user's behalf, beginning the auction
-Buyer bids on auction and it ends: the auction completes the "sale" transfer, clears its storage of params, and pings the factory

Integrate Beacon or Thanos for user-side txns

Create a basic ID system that supports aliases in order to abstract transfer recipients.

Outline necessities regarding control over contracts, functions for assets, and importing existing contracts associated with accounts.

Give users the ability to choose to mint via our existing contract or deploy their own.

Additionally, allow them to mint more NFTs to their existing contracts.

Drilldown view includes the associated metadata and individual functions. This is more to display the artifact in question more prominently.

Ensuring first release works with testnet

Without for the generalized, with for the creation of new contracts

Primary to stand up before IPFS integration

Implement IPFS integrations in order to save and host user images

Please add a standard MIT license to the project.
New file-> Create file
Type the name "License"
The button appears in the top right to choose a template.

Review existing work from Tez-Auction to see if viable for implementation for fixed-price sales in OpenMinter

Gut the server side as much as possible in order to have a dapp-like structure. IPFS for image hosting will remain the only component on the server side in order to retain data availability.

GitHub repo administration

1. flextesa docker
2. indexer docker
3. client/server projects docker
4. Postgress docker
5. LIGO docker

1. originate and call contract from taquito
2. add LIGO compilation
3. Implement tests

Designate the component library used for the vanilla version

We need to add a form field that allows the user to specify the TZ address they want to mint a new NFT. This also needs to be implemented in the createNonFungibleToken mutation

First pass for soft launch: list of created assets based on implementation

Support Delphinet and Depreciate Carthagenet

Cleanup of messages, general app copy, etc.

Build out RACI Matrix

Initial frames based on original wireframes and workflows to be connected to the backend.

I deployed both the multi nft and the minter contracts and set their admin to the be the same. When I call mint entrypoint on minter from my admin-address it fails on the internal call to the multi-nft due to NOT_AN_ADMIN on line 508. Presumably because the check for sender is failing due to the sender being the minter contract which is not the admin of the multi-nft.

Is the intention that the minter contract would always be the admin of the nft contract or should the admin validation look for a match on source instead of sender?

Using BCD / TZKT

Using the latest designs, rebuild Minter

Add support for Beacon wallet