Define `did:bmk` method operations

[nodestory]

Acceptance criteria:

• Sequence diagrams for the following operations
  • class operations: create, transfer, and update
  • token operations: create and transfer
• Block diagram (wallet, bitmark blockchain, resolver, and resource server)

References:

• https://github.com/decentralized-identity/github-did/blob/master/docs/did-method-spec/index.md#crud-operations
• https://github.com/blockstack/stacks-blockchain/blob/stacks-1.0/docs/blockstack-did-spec.md

--

Overall goal

1. High-dimensional thinking about all needs

   Role, NFT, endpoint
   Decide on NFT Controller
   Determine the USER controller
   Is the item owning the "person" or the person owning the item.

2. Convert all requirements into modules

   Convert into specific objects and modules
   Decide whether the verification module after CRUD is organized by node or an external company.

3. Convert the type to UTXO

   Even if the verification mechanism of an external company organization is adopted. The most basic UTXO transaction verification mechanism is also required
   The mining mechanism of UTXO transactions is the same as BTC?LTC? or new tokens are to be issued. If there are new tokens in the future, support should be retained.

4. Deploy the new UTXO to Bitmarkd's system
   • lib builds a new type of UTXO
   • lib reads UTXO in new state
   • lib Verifies the new state of UTXO
   • lib get rpc UTXO
   • RPC receiving type UTXO
   • RPC builds a new type of UTXO
   • RPC read UTXO in new state
   • RPC verifies the new state of UTXO
   • p2p synchronization implementation

[hxw]

Alternate Possible Solutions:

1. class: create<doc> → update → update → transfer → …update/transfer
   NFT:   token<class,i> → update → update → transfer → …update/transfer

2. class: create<doc> → update → update → update → …
   NFT:   token<class,i> → update → update → update → …

3. class: allocate<did> → class<doc> → update → update → update → …
   NFT:   token<class,i> → update → update → update → …

KEY:
did = the did identifier
doc = complete class did document
i   = an edition number [1…n]

Comments on items

1. mixture of update and transfer records makes chain verification difficult
2. how to pay for large create record? it must be free
3. new_class would be small and free and give a block to pay for initial doc

Fields in a possible solution(3) for bitmarkd

1. Allocate
   • Hash of IID (use hash to avoid revealing the actual DID until later)
   • account
   • signature
2. Class
   • Class IID
   • linkedResources (media+associated files)
   • max editions (other static metadata)
   • account
   • signature
3. Token
   • NFT IID
   • link to master artwork record
   • hashset across selected immutable fields
   • edition number (other metadata?)
   • minter account (must match class version - can this be removed)
   • minter signature
4. Update
   • link to previous txid
   • updates [{key:val}] only for mutable fields
   • owner signature (the most recent owner if any owner updates)

[hxw]

for reference

// read JSON from stdin, convert to CBOR and display the hex bytes
package main

import (
	"bytes"
	"fmt"
	"log"
	"os"

	"github.com/ugorji/go/codec"
)

func main() {
	// to hold the decoded JSON
	var m interface{}

	// read JSON from stdin
	err := codec.NewDecoder(os.Stdin, new(codec.JsonHandle)).Decode(&m)
	if nil != err {
		log.Fatalf("json decode error: %s", err)
	}
	fmt.Printf("decoded JSON type : %T\n", m)
	fmt.Printf("decoded JSON value: %+v\n", m)

	// output CBOR to buffer
	w := new(bytes.Buffer)
	h := new(codec.CborHandle)
	h.WriterBufferSize = 8192

	enc := codec.NewEncoder(w, h)
	err = enc.Encode(m)
	if nil != err {
		log.Fatalf("encode error: %s", err)
	}
	fmt.Printf("CBOR result: %#v\n", w.Bytes())
}