Initial Cookbook structure

[6r1d]

We just had a meeting with @0x009922, @mversic, @AlexStroke and @dmitrivenger.

We need a new API documentation structure to make all examples between different API versions available. This is a structure we've established:

• Transactions
  • Using different ISIs
  • MST
  • Smartcontracts
  • Expressions?
• Query
  • Show default usage
  • Show filters (not a priority, as DSL can be implemented, a few examples would be useful - @mversic)
  • Show how lazy pagination should be used
  • Query connected peers
• Block stream
  • Show how to subscribe
  • Show how does the output look
• Events
  • Different filters, different events
• Telemetry
  • How to do something useful with telemetry, e.g. check load or performance
  • How to check status
  • How to get metrics
  • Healthcheck - route, data structure
• Triggers
  • Show multiple examples of different triggers with different actions
• Executor
  • Write and update one
• Philosophy of how to work with different aspects of Iroha
  • Checking what peer among the current is the leader??
  • Checking current peer's load?

[0x009922]

I revised the list again and come to a more user-goals centric structure:

• Assets (Numeric, Store, Mintable, Non-mintable, Register, Mint, Burn, Transfer)
  • Numeric Assets
  • Store Assets
  • Transferring
  • Minting More of a Mintable Asset
  • Non-Mintable Assets (not ones in Genesis)
  • Creating Asset-backed Tokens (i.e. gold)
  • Creating Non-Fungible Tokens (NFTs)
• Access Control (permission tokens, roles (permission groups), permission validator?)
• Metadata
• Events and Filters (subscription, filtering)
• Triggers (+ smartcontracts)
• Executor (smartcontract)
• Telemetry (metrics, health, status)
• misc
  • Transactions with Smartcontracts
  • Multi-Signature Transactions
  • Expressions

This all should be refined for sure. I will start with this. Hopefully, when we start building the actual code snippets, we will get more understanding of how to structure them better for educational and practical purposes.

[Mingela]

@0x009922 this looks great, just a few questions:

• how about domains, its relation to other entities?
• isn't permission validator and executor kinda the same concept?
• by a smartcontract you mean WASM, right?

[0x009922]

@Mingela,

1. We should probably include both Domains and Accounts as well. I just don't know in what form. Do you have any introductory, educational, and expressive examples on mind?
2. I think so, wasn't 100% sure
3. Yes, smartcontract = WASM executable in terms of Iroha 2

[Mingela]

@0x009922 domains generally are intended to represent countries, organizations, departments, branches and so on. Some sort of access management (or permissions) based on the domain might be sufficient.

[6r1d]

I've added a separate issue on a store asset as the current information is lacking and it's very useful

[dmitrivenger]

@6r1d , @yamkovoy Looking at @0x009922 revised structure, where do we place Domains and Accounts?

[outoftardis]

you can see and review the revised structure in #424