diff --git a/docs/reference/types/_includes/blockchainevent_description.md b/docs/reference/types/_includes/blockchainevent_description.md index 554153420..277850b22 100644 --- a/docs/reference/types/_includes/blockchainevent_description.md +++ b/docs/reference/types/_includes/blockchainevent_description.md @@ -1,9 +1,9 @@ Blockchain Events are detected by the blockchain plugin: -1. When a [ContractListener](./(contractlistener.md) has been +1. When a [ContractListener](./contractlistener.html) has been configured against any custom smart contract through the FireFly API 2. Indirectly via a Token Connector, which understands the correct events - to listen to for a [Token Pool](./(tokenpool.md) configured against a + to listen to for a [Token Pool](./tokenpool.html) configured against a standard such as ERC-20/ERC-721/ERC-1155 3. Automatically by FireFly core, for the BatchPin contract that can be used for high throughput batched pinning of off-chain data transfers diff --git a/docs/reference/types/_includes/event_description.md b/docs/reference/types/_includes/event_description.md index 709fad9e8..abecba752 100644 --- a/docs/reference/types/_includes/event_description.md +++ b/docs/reference/types/_includes/event_description.md @@ -13,8 +13,8 @@ order that they are delivered to your application. ### Reference Events have a `reference` to the UUID of an object that is the subject of the event, -such as a detailed [Blockchain Event](./(blockchainevent.md), or an off-chain -[Message](./(message.md). +such as a detailed [Blockchain Event](./blockchainevent.html), or an off-chain +[Message](./message.html). When events are delivered to your application, the `reference` field is automatically retrieved and included in the JSON payload @@ -44,14 +44,14 @@ the type of event. This is intended to be a property you would use to filter events to your application, or query all historical events associated with a given business data stream. -For example when you send a [Message](./(message.md), you set the `topics` +For example when you send a [Message](./message.html), you set the `topics` you want that message to apply to, and FireFly ensures a consistent global order between all parties that receive that message. ### Transaction When actions are submitted by a FireFly node, they are performed -within a FireFly [Transaction](./(transaction.md). The events that occur +within a FireFly [Transaction](./transaction.html). The events that occur as a direct result of that transaction, are tagged with the transaction ID so that they can be grouped together. @@ -74,24 +74,24 @@ Note that some events cannot be tagged with a Transaction ID: | Types | Reference | Topic | Correlator | |---------------------------------------------|--------------------------------------|-----------------------------|-------------------------| -| `transaction_submitted` | [Transaction](./(transaction.md) | `transaction.type` | | -| `message_confirmed`
`message_rejected` | [Message](./(message.md) | `message.header.topics[i]`* | `message.header.cid` | -| `token_pool_confirmed` | [TokenPool](./(tokenpool.md) | `tokenPool.id` | | -| `token_pool_op_failed` | [Operation](./(operation.md) | `tokenPool.id` | `tokenPool.id` | -| `token_transfer_confirmed` | [TokenTransfer](./(tokentransfer.md) | `tokenPool.id` | | -| `token_transfer_op_failed` | [Operation](./(operation.md) | `tokenPool.id` | `tokenTransfer.localId` | -| `token_approval_confirmed` | [TokenApproval](./(tokenapproval.md) | `tokenPool.id` | | -| `token_approval_op_failed` | [Operation](./(operation.md) | `tokenPool.id` | `tokenApproval.localId` | -| `namespace_confirmed` | [Namespace](./(namespace.md) | `"ff_definition"` | | -| `datatype_confirmed` | [Datatype](./(datatype.md) | `"ff_definition"` | | -| `identity_confirmed`
`identity_updated` | [Identity](./(identity.md) | `"ff_definition"` | | -| `contract_interface_confirmed` | [FFI](./(ffi.md) | `"ff_definition"` | | -| `contract_api_confirmed` | [ContractAPI](./(contractapi.md) | `"ff_definition"` | | -| `blockchain_event_received` | [BlockchainEvent](./(blockchainevent.md) | From listener ** | | -| `blockchain_invoke_op_succeeded` | [Operation](./(operation.md) | | | -| `blockchain_invoke_op_failed` | [Operation](./(operation.md) | | | - -> * A separate event is emitted for _each topic_ associated with a [Message](./(message.md). +| `transaction_submitted` | [Transaction](./transaction.html) | `transaction.type` | | +| `message_confirmed`
`message_rejected` | [Message](./message.html) | `message.header.topics[i]`* | `message.header.cid` | +| `token_pool_confirmed` | [TokenPool](./tokenpool.html) | `tokenPool.id` | | +| `token_pool_op_failed` | [Operation](./operation.html) | `tokenPool.id` | `tokenPool.id` | +| `token_transfer_confirmed` | [TokenTransfer](./tokentransfer.html) | `tokenPool.id` | | +| `token_transfer_op_failed` | [Operation](./operation.html) | `tokenPool.id` | `tokenTransfer.localId` | +| `token_approval_confirmed` | [TokenApproval](./tokenapproval.html) | `tokenPool.id` | | +| `token_approval_op_failed` | [Operation](./operation.html) | `tokenPool.id` | `tokenApproval.localId` | +| `namespace_confirmed` | [Namespace](./namespace.html) | `"ff_definition"` | | +| `datatype_confirmed` | [Datatype](./datatype.html) | `"ff_definition"` | | +| `identity_confirmed`
`identity_updated` | [Identity](./identity.html) | `"ff_definition"` | | +| `contract_interface_confirmed` | [FFI](./ffi.html) | `"ff_definition"` | | +| `contract_api_confirmed` | [ContractAPI](./contractapi.html) | `"ff_definition"` | | +| `blockchain_event_received` | [BlockchainEvent](./blockchainevent.html) | From listener ** | | +| `blockchain_invoke_op_succeeded` | [Operation](./operation.html) | | | +| `blockchain_invoke_op_failed` | [Operation](./operation.html) | | | + +> * A separate event is emitted for _each topic_ associated with a [Message](./message.html). > ** The topic for a blockchain event is inherited from the blockchain listener, > allowing you to create multiple blockchain listeners that all deliver messages diff --git a/docs/reference/types/_includes/identity_description.md b/docs/reference/types/_includes/identity_description.md index ae129710d..95fe8b226 100644 --- a/docs/reference/types/_includes/identity_description.md +++ b/docs/reference/types/_includes/identity_description.md @@ -10,12 +10,12 @@ Root identities are registered with only a `claim` - which is a signed transaction from a particular blockchain account, to bind a DID with a `name` that is unique within the network, to that signing key. -The signing key then becomes a [Verifier](./(verifier.md) for that identity. +The signing key then becomes a [Verifier](./verifier.html) for that identity. Using that key the root identity can be used to register a new FireFly node in the network, send and receive messages, and register child identities. When child identities are registered, a `claim` using a key that is going -to be the [Verifier](./(verifier.md) for that child identity is required. +to be the [Verifier](./verifier.html) for that child identity is required. However, this is insufficient to establish that identity as a child identity of the parent. There must be an additional `verification` that references the `claim` (by UUID) using the key verifier of the parent identity. diff --git a/docs/reference/types/_includes/message_description.md b/docs/reference/types/_includes/message_description.md index 8821d7fee..a5670ad5f 100644 --- a/docs/reference/types/_includes/message_description.md +++ b/docs/reference/types/_includes/message_description.md @@ -18,7 +18,7 @@ The hash is a function of the header, and all of the data payloads. Calculated a - JSON data is serialized without whitespace to hash it. - The hashing algorithm is SHA-256 -Each node independently calculates the hash, and the hash is included in the manifest of the [Batch](./(batch.md) by the +Each node independently calculates the hash, and the hash is included in the manifest of the [Batch](./batch.html) by the node that sends the message. Because the hash of that batch manifest is included in the blockchain transaction, a message transferred to a node that does not match the original message hash is rejected. @@ -95,7 +95,7 @@ Some examples: ### Transaction type -By default messages are pinned to the blockchain, within a [Batch](./(batch.md). +By default messages are pinned to the blockchain, within a [Batch](./batch.html). For private messages, you can choose to disable this pinning by setting `header.txtype: "unpinned"`. @@ -103,7 +103,7 @@ Broadcast messages must be pinned to the blockchain. ### In-line data -When sending a message you can specify the array of [Data](./(data.md) attachments in-line, as part of the same JSON payload. +When sending a message you can specify the array of [Data](./data.html) attachments in-line, as part of the same JSON payload. For example, a minimal broadcast message could be: diff --git a/docs/reference/types/_includes/operation_description.md b/docs/reference/types/_includes/operation_description.md index 5d0af0d63..7ccf60ae9 100644 --- a/docs/reference/types/_includes/operation_description.md +++ b/docs/reference/types/_includes/operation_description.md @@ -3,6 +3,6 @@ They are grouped into Transactions in order to accomplish a single logical task. The diagram below shows the different types of operation that are performed by each FireFly plugin type. The color coding (and numbers) map those different types of operation -to the [Transaction](./(transaction.md) types that include those operations. +to the [Transaction](./transaction.html) types that include those operations. [![FireFly operations by transaction type](../../images/operations_by_transaction_type.jpg)](../../images/operations_by_transaction_type.jpg) \ No newline at end of file diff --git a/docs/reference/types/_includes/subscription_description.md b/docs/reference/types/_includes/subscription_description.md index 15a82b11f..e38fddf82 100644 --- a/docs/reference/types/_includes/subscription_description.md +++ b/docs/reference/types/_includes/subscription_description.md @@ -75,12 +75,12 @@ FireFly has a simple protocol on top of WebSockets: 1. Each time you connect/reconnect you need to tell FireFly to start sending you events on a particular subscription. You can do this in two ways (described in detail below): - 1. Send a [WSStart](./(wsstart.md) JSON payload + 1. Send a [WSStart](./wsstart.html) JSON payload 2. Include a `namespace` and `name` query parameter in the URL when you - connect, along with query params for other fields of [WSStart](./(wsstart.md) + connect, along with query params for other fields of [WSStart](./wsstart.html) 2. One you have started your subscription, each event flows from - the server, to your application as a JSON [Event](./(event.md) payload -3. For each event you receive, you need to send a [WSAck](./(wsack.md) payload. + the server, to your application as a JSON [Event](./event.html) payload +3. For each event you receive, you need to send a [WSAck](./wsack.html) payload. - Unless you specified `autoack` in step (1) > The SDK libraries for FireFly help you ensure you send the `start` diff --git a/docs/reference/types/_includes/transaction_description.md b/docs/reference/types/_includes/transaction_description.md index b87790325..70fc4e6c5 100644 --- a/docs/reference/types/_includes/transaction_description.md +++ b/docs/reference/types/_includes/transaction_description.md @@ -1,4 +1,4 @@ -FireFly Transactions are a grouping construct for a number of [Operations](./(operations.md) and [Events](./(events.md) +FireFly Transactions are a grouping construct for a number of [Operations](./operation.html) and [Events](./event.html) that need to complete or fail as unit. > FireFly Transactions are not themselves Blockchain transactions, but in many cases there is @@ -24,7 +24,7 @@ event as well. [![FireFly Transactions - Explorer View](../../images/firefly_transactions_explorer_view.png)](../../images/firefly_transactions_explorer_view.png) Each FireFly transaction has a UUID. This UUID is propagated through to all participants in a FireFly transaction. -For example in a [Token Transfer](./(tokentransfer.md) that is coordinated with an off-chain private [Message](./(message.md), +For example in a [Token Transfer](./tokentransfer.html) that is coordinated with an off-chain private [Message](./message.html), the transaction ID is propagated to all parties who are part of that transaction. So the same UUID can be used to find the transaction in the FireFly Explorer of any member who has access to the message. This is possible because hash-pinned off-chain data is associated with that on-chain transfer. diff --git a/docs/reference/types/_includes/wsack_description.md b/docs/reference/types/_includes/wsack_description.md index a20218330..b9ca8c53c 100644 --- a/docs/reference/types/_includes/wsack_description.md +++ b/docs/reference/types/_includes/wsack_description.md @@ -1,6 +1,6 @@ An `ack` must be sent on a WebSocket for each event delivered to an application. -> Unless `autoack` is set in the [WSStart](./(wsstart.md) payload/URL parameters to cause +> Unless `autoack` is set in the [WSStart](./wsstart.html) payload/URL parameters to cause > automatic acknowledgement. Your application should specify the `id` of each event that it acknowledges. @@ -11,5 +11,5 @@ application that has not been acknowledged is the one the `ack` is associated wi If multiple subscriptions are started on a WebSocket, then you need to specify the subscription `namespace`+`name` as part of each `ack`. -If you send an acknowledgement that cannot be correlated, then a [WSError](./(wserror.md) +If you send an acknowledgement that cannot be correlated, then a [WSError](./wserror.html) payload will be sent to the application.