account.fbs

include "key.fbs";
include "primitives.fbs";


namespace iroha.api;


table Account {
  pubKey: PublicKey (required);  // primary key for account
  alias:  string;
  assets: [Asset]; // TODO: Is this OK?
  
  // for m-n multisignature scheme
  // signatories.size() = n, useKeys = m
  signatories: [PublicKey];
  useKeys:     ushort = 1;
}

asset.fbs

include "primitives.fbs";


namespace iroha.api;


table Asset {
  // composite primary key:
  name:          string (key, required);  // sorted; name should be unique inside a domain and not globally
  domain:        Domain (required);
  
  amount:        ulong = 0;
  precision:     ulong = 0;
  description:   string;

  advanced:      [KeyValueObject]; // using this, you can create complex assets
}

commands.fbs

include "asset.fbs";
include "account.fbs";
include "key.fbs";
include "primitives.fbs";


namespace iroha.api;


// we union only those objects.
// they share the same commands
union Object { Domain, Peer, Asset, Account, Chaincode }


table Add {
    object: Object (required);
}

table Remove {
    object: Object (required);
}

table Transfer {
    currency: Asset     (required); // TODO: should transfer domain exist, or is that just handled under permissions?
    sender:   PublicKey (required);
    receiver: PublicKey (required);
}

table Store {
    msg: Message (required);
}

table Execute {
    name: string;
}

table ChangePeerTrust {
    peerPubKey: PublicKey (required);
    newTrust:   Trust     (required);
}

table ChangePeerPermission {
    peerPubKey: PublicKey  (required);
    permission: Permission (required);
}

// to change a chaincode, you should construct new chaincode with the same 
// name and with different data (.class)
table ChangeChaincode { // TODO: maybe ReplaceChaincode is more accurate?
    chaincode: Chaincode (required);
}

union Command {
    Add, 
    Remove, 
    Transfer, 
    Store, 
    Execute, 
    ChangePeerTrust, 
    ChangePeerPermission,
    ChangeChaincode
}

key.fbs

namespace iroha.api;

// another ledgers can use another algorithms
enum KeyAlgorithm: byte { ed25519 }

table PublicKey{
  algorithm: KeyAlgorithm;  
  data:      [ubyte] (required);
}

main.fbs

include "transaction.fbs"; 
include "command.fbs";


namespace iroha.api;


file_identifier "IRH";
file_extension  "iroha";


table ConsensusEvent {
  signatures:    [Signature];
  transactions:   [Transaction];
  order:         ulong;
  status:        string; // TODO: This opens a possible attack for validators that lie about the status
}

table TransactionResponse {
  message:      string;
  code:         ushort;
  transaction:  Transaction; // Probably best to have one transaction, rather than a list
}

table RecieverConfirmation {
  signature:    Signature; // hash can be computed separately; signature should be of sign(hash + timestamp)
  timestamp:    ulong;
}

table QueryResponse {
  objects:      [Object];
  code:         ushort;
  timestamp:    ulong;
  signature:    Signature;
}

table PeerResponse {
  message:      string;
  code:         ushort; // TODO: enumerate codes ^^
  timestamp:    ulong;
  signature:    Signature;
}

table StatusResponse { // TODO: something seems not quite right...
  value:        string;
  message:      string;
  timestamp:    ulong;
  confirm:      RecieverConfirmation;
  signature:    Signature;
}

root_type ConsensusEvent; // TODO: should review this

primitives.fbs

include "key.fbs";


namespace iroha.api;


/////////////////////////////////////
table Message {
  text: string (required);
}

/////////////////////////////////////
table Chaincode {
  name: string  (required);  // primary key
  domain: Domain (required); // TODO: should domain be here?
  java: [ubyte];             // .class data
}

/////////////////////////////////////
/// Key-Value object

table KeyValueObject {
  key:   string (key, required);  // primary key, sorted
  value: [ubyte];                 // arbitrary data
}

/////////////////////////////////////
/// Permissions 

// same as /etc/group
// contains list of all users in particular group
// to add user to group, add him here
table Group {
  name:     string      (key, required); // primary key, sorted; unique globally TODO: should this be global or only within the domain?
  accounts: [PublicKey];                 // list of accounts in a group
}

// same as unix directory
table Domain {
  // composite primary key for domain
  name:     string (required, key);  // sorted by name
  ledgerId: string (required);

  permissions_owner:  Permission;
  permissions_group:  Permission;
  permissions_others: Permission;
  
  // public key of account:
  owners:       [PublicKey]; // same as owner for file/directory in unix, except with multisig!
  useOwnerKeys: ushort = 1; // to enable m-of-n multisig administration

  // name of the group
  // group:       string   ; // same as group for file/directory in unix
  // TODO: maybe we should have this? or is this too complicated??
  groups: [Group];

  // list of accounts, which belong to this domain
  accounts:    [PublicKey];
}

// like rwx in unix, but without execute
table Permission {
  read:  bool;
  write: bool;
}

/////////////////////////////////////
/// Peer

table Trust {
  value:    ulong;
  isActive: bool;
}

table Peer {
  // primary key
  publicKey: PublicKey (required); 
  
  ip:        string;
  trust:     Trust;
}

/////////////////////////////////////
table Signature {
  publicKey:  PublicKey;
  signature:  [ubyte];
  // TODO: should we also include the "message" that is signed?
}

transaction.fbs

include "key.fbs";
include "commands.fbs";
include "primitives.fbs";

namespace iroha.api;


table Transaction {
  creatorPubKey:   PublicKey(required);
  command:         Command;
  signatures:      [Signature];
  tag:             string; // TODO: is this really needed?
  hash:            [ubyte];
  timestamp:       ulong;
  message:         string; // TODO: should we also consider [ubyte] payloads?
}

Could you please consider it?

Want to change it

table ChangePeerTrust {
	    peerPubKey: PublicKey (required);
	    newTrust:   Trust     (required);
}

After Change


### Do increase and decrease Trust of peer.

table ChangePeerTrust {

	peerPubKey: PublicKey (required);
	changeTrust: Trust 	(required);

}

Activate peer ( isActive -> true )

table ActivatePeer {
	peerPubKey: PublicKey( required );
}

Stop peer ( isActive -> false )


table StopPeer {
	peerPubKey: PublicKey( required );
}

Use-Case

There are transaction that is done to issue by peer-service.
removePeer is used by root user ( by human ).

In commands.fbs

I think Iroha should have exchange logic for transfer.
I cannnot explain clearly. sorry 🙇‍♂️

or
Asset should have exchange logic.

table ExchangeLogic{
    forAssetName: string;  //( A is asset has it logic; B is asset is written as forAssetName. ) This logic is only case A => B
    chaincode: ChangeChaincode;
}
table Asset{
   ...
   exchangeLogics: [ExchangeLogic];
}

In primitives.fbs

https://gist.github.com/takemiyamakoto/81364b706e90c3f6cf99d355d5a69d79#file-primitives-fbs-L87
I think Signature should contain message.

In transaction.fbs

https://gist.github.com/takemiyamakoto/81364b706e90c3f6cf99d355d5a69d79#file-transaction-fbs-L12
Tag isn't necessary.