Merge pull request #146 from anandrgitnirman/updatedportal

Updated contents

_data/navigation.yml

@@ -92,6 +92,7 @@ concepts:
     url: "/docs/concepts/blockchain"
   ethereum:
     title: Ethereum
+    cta: Read more
     children:
         ethereum-overview:
           title: Overview
@@ -116,15 +117,23 @@ concepts:
   ipfs:
     title: "IPFS "
     url: "/docs/concepts/ipfs"
-  mpe:
-    title: "Multi-party Escrow"
-    url: "/docs/concepts/mpe"
-  staking:
-    title: "Staking"
-    url: "/docs/concepts/staking"
-  key-terms:
-    title: "Key terms"
-    url: "/docs/concepts/keyterms"
+  protobuf:
+    title: "Protocol Buffers"
+    url: "/docs/concepts/protobuf"
+  grpc:
+    title: "gRPC"
+    url: "/docs/concepts/grpc"
+  distributed-storage:
+    title: "Distributed Storage"
+    children:
+        etcd:
+          title: etcd
+          excerpt:
+          cta: Read more
+          url: '/docs/concepts/etcd'    
+  #key-terms:
+  #  title: "Key terms"
+  #  url: "/docs/concepts/keyterms"
 
 
 tutorials:
@@ -230,22 +239,22 @@ ai-consumers:
           cta: Read more
           url: '/docs/ai-consumers/setupguide'
         invoke-serivce-snet-cli:
-          title: Invoking a Serice using snet-cli
+          title: Invoking a Service using snet-cli
           excerpt:
           cta: Read more
           url: '/docs/ai-consumers/invoke-service-snet-cli'
         invoke-serivce-dapp:
-          title: Invoking a Serice using Marketplace Dapp
+          title: Invoking a Service using Marketplace Dapp
           excerpt:
           cta: Read more
           url: '/docs/ai-consumers/marketplace-service_invocation'
         invoke-serivce-java-sdk:
-          title: Invoking a Serice using Java sdk
+          title: Invoking a Service using Java sdk
           excerpt:
           cta: Read more
           url: '/docs/ai-consumers/java-sdk'
         invoke-serivce-sdk:
-          title: Invoking a Serice using sdk
+          title: Invoking a Service using sdk
           excerpt:
           cta: Read more
           url: '/docs/ai-consumers/sdk-tutorial'          
@@ -392,22 +401,22 @@ ai-developers:
           cta: Read more
           url: '/docs/ai-developers/service-setup-snet-cli'
         invoke-serivce-snet-cli:
-          title: Invoking a Serice using snet-cli
+          title: Invoking a Service using snet-cli
           excerpt:
           cta: Read more
           url: '/docs/ai-developers/invoke-service-snet-cli'
         invoke-serivce-dapp:
-          title: Invoking a Serice using Marketplace Dapp
+          title: Invoking a Service using Marketplace Dapp
           excerpt:
           cta: Read more
           url: '/docs/ai-developers/marketplace-service_invocation'
         invoke-serivce-java-sdk:
-          title: Invoking a Serice using Java sdk
+          title: Invoking a Service using Java sdk
           excerpt:
           cta: Read more
           url: '/docs/ai-developers/java-sdk'
         invoke-serivce-sdk:
-          title: Invoking a Serice using sdk
+          title: Invoking a Service using sdk
           excerpt:
           cta: Read more
           url: '/docs/ai-developers/sdk-tutorial'          
@@ -440,9 +449,28 @@ platform-dev:
       url: '/docs/platform-dev/registry'
   daemon:
       title: Daemon
-      excerpt: How to communicate with SingularityNET services with the stateless method.
-      cta: Read more
-      url: '/docs/platform-dev/daemon'
+      children:
+        introduction:
+          title: Daemon
+          excerpt: How to communicate with SingularityNET services with the stateless method.
+          cta: Read more
+          url: '/docs/platform-dev/daemon'
+        architecture:
+          title: Architecture
+          excerpt: Architechtire of all key components in Daemon
+          url: '/docs/platform-dev/daemon-architecture'
+  sdk:
+    title: SDK
+    children:
+      introduction:
+        title: SDK
+        excerpt: SDK
+        cta: Read more
+        url: '/docs/platform-dev/sdk'
+      architecture:
+        title: Architecture
+        excerpt: Architechtire of all key components in Daemon
+        url: '/docs/platform-dev/sdk-architecture'
   mpe:
       title: Multi-Party Escrow
       excerpt: How to communicate with SingularityNET services with the stateless method.

docs/ai-developers/grpc.md

@@ -9,7 +9,7 @@ micro_nav: true
 
 ---
 
-## gRPC Overview
+## Overview
 
 gRPC is a modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services. By default, gRPC uses <a href="https://developers.google.com/protocol-buffers/docs/reference/proto3-spec#service_definition" target="_blank">protocol buffers</a> as the Interface Definition Language (IDL) for describing both the service interface and the structure of the payload messages. .gRPC <a href="https://grpc.io/docs/">Docs</a> is the recommended starting point to understand how this works
 

docs/concepts/erc20.md

@@ -8,7 +8,6 @@ comments: false
 micro_nav: true
 
 ---
-# ERC-20 Tokens
 ERC-20 is a standard interface for tokens. It allows any tokens on Ethereum to be re-used by other applications: from wallets to decentralized exchanges. The ERC-20 standard is documented <a href="https://eips.ethereum.org/EIPS/eip-20" target="_blank">here</a>
 
 It defines a standard interface that all tokens should adhere to. This enables users and developers to understand how the token will work in the Ethereum ecosystem. This standardization enables richer interaction between the various tools and usecases built on top of Ethereum

docs/concepts/etcd.md

@@ -1,7 +1,7 @@
 ---
 # Page settings
 layout: default
-keywords: concepts
+keywords: intro concepts
 comments: false
 
 # Micro navigation
@@ -18,4 +18,13 @@ micro_nav: true
 * **Fast**: benchmarked 10,000 writes/sec
 * **Reliable**: properly distributed using Raft
 
-etcd is written in Go and uses the Raft consensus algorithm to manage a highly-available replicated log.
+etcd is written in Go and uses the Raft consensus algorithm to manage a highly-available replicated log.
+
+## etcd and SingularityNet Platform
+
+<a href="https://github.com/etcd-io/etcd" target="_blank">etcd</a> is used as storage to store context related to 
+* <a href="https://dev.singularitynet.io/docs/platform-dev/daemon-channel-storage/" target="_blank">Payments</a>
+* Free Call Usage
+at an organization level. 
+
+The section [ETCD setup](../etcdsetup) section details how to set up an etcd cluster

docs/concepts/grpc.md

@@ -0,0 +1,25 @@
+---
+# Page settings
+layout: default
+keywords: intro concepts
+comments: false
+
+# Micro navigation
+micro_nav: true
+
+---
+
+
+## Overview
+
+gRPC is a modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services. By default, gRPC uses <a href="https://developers.google.com/protocol-buffers/docs/reference/proto3-spec#service_definition" target="_blank">protocol buffers</a> as the Interface Definition Language (IDL) for describing both the service interface and the structure of the payload messages. gRPC <a href="https://grpc.io/docs/">Docs</a> is the recommended starting point to understand how this works.
+
+
+## gRPC and SingularityNet Platform
+
+AI Services on the Singularitynet platform need to define their API using <a href="https://developers.google.com/protocol-buffers/docs/reference/proto3-spec#service_definition" target="_blank">protocol buffers</a> and expose a gRPC endpoint. This allows SingularityNET clients to determine the request/response schema programmatically. The first step in getting the AI service ready for the SingularityNet platform is to have a proto definition and expose a gRPC endpoint for it. Once this is done, the service can be integrated with the SingulartiyNet Daemon.
+
+## Samples
+
+* The <a href="https://github.com/singnet/example-service/tree/master/service" target="_blank">example service</a> is an example of a Python arthimetic service with gRPC endpoints and a proto definition.
+* These <a href="https://grpc.io/docs/guides/" target="_blank">guides</a> are a good starting point to creating gRPC based services

docs/concepts/protobuf.md

@@ -0,0 +1,21 @@
+---
+# Page settings
+layout: default
+keywords: intro concepts
+comments: false
+
+# Micro navigation
+micro_nav: true
+
+---
+
+Protocol Buffers also know as Protobuf, is a method of data serialization. It provides a simple and efficient way of describing data that is to be stored or exchanged between systems. Its similar to XML and JSON but is
+much smaller in size thereby improving performance of network communication. The method involves an interface description language that describes the structure of some data and a program that generates source code from that description for generating or parsing a stream of bytes that represents the structured data.
+
+Google developed <a href="https://developers.google.com/protocol-buffers/docs/overview" target="_blank">Protocol Buffers</a> and provided a code generator for multiple languages under an open source license.
+
+Data structures (called messages) and services are described in a proto definition file (.proto) and compiled with protoc. This compilation generates code that can be invoked by a sender or recipient of these data structures. For example, example.pb.cc and example.pb.h are generated from example.proto. They define C++ classes for each message and service in example.proto.
+
+Canonically, messages are serialized into a binary wire format which is compact, forward- and backward-compatible, but not self-describing (that is, there is no way to tell the names, meaning, or full datatypes of fields without an external specification). There is no defined way to include or refer to such an external specification (schema) within a Protocol Buffers file. The officially supported implementation includes an ASCII serialization format,[6] but this format—though self-describing—loses the forward- and backward-compatibility behavior, and is thus not a good choice for applications other than debugging.
+
+Protocol buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data.

docs/platform-dev/daemon-architecture.md

@@ -0,0 +1,98 @@
+---
+# Page settings
+layout: default
+keywords: intro concepts
+comments: false
+
+# Micro navigation
+micro_nav: true
+
+---
+
+## State Service Calls 
+
+As the name suggests, this call will be used by the client to determine the next amount to sign to make a service call. 
+
+Daemon keeps track of the off chain state of the channel
+Details involve Channel Id Nonce,Amount signed , Signature and the nonce of the channel 
+, and in order to sign the amount for the next call, the client needs to know the amount it had last signed (X), the new call will be signed with an amount X + P , where X is the last signed amount and P is the price 
+
+Daemon also sends back the last signed signature of the old nonce ( in case a claim is in progress or a claim was made)
+
+
+![Stateservice](/assets/img/daemon/stateservice.png)
+
+
+## Pay Per use calls 
+The client signs in for the next cumulative amount ( i.e X+P), where X is the amount last amount signed on the given Channel Id and Nonce
+![Pay per use](/assets/img/daemon/payperusecalll.png)
+
+
+## Free Calls
+
+### How many free Calls are Left ? 
+As a service provider one may wish to provide free calls .
+However you need some validations to ensure , that only authorized users can make this call and as a service provider you would want to 
+restrict the number of such free calls made.
+To even check if free calls are allowed, you need to send in Daemon
+a signature and a token 
+
+![Free Call use](/assets/img/daemon/freecallstate.png)
+
+### Making an Actual Free Call
+If the Signatures are valid,Daemon increments the usage count by 1.
+The Signature validations and authentication is exactly the same as 
+explained , just that the ETCD State is upated with usage accordingly
+
+## Control Service Calls 
+
+Please note, Daemon doesnt do any claims on blockchain, it is responsible 
+ONLY for maintaining the states.
+Actual claims can done using snet-cli/publisher portal
+Daemon provides a bunch of grpc calls to retrieve data the service provider needs to make claims on block chain.
+Keeps track of claims in Progress.
+One can view all the data using cli commands in snet-daemon 
+
+
+No write operation on block chains are done by Daemon (will be take care of by the snet client ), Finish on the claim(reset channel amount used to zero!) should be called only after the payment is successfully claimed and block chain is updated accordingly.
+One way to determine this is by checking the nonce in the block chain with the nonce in the payment,for a given channel if the block chain nonce is greater than that of the nonce from etcd storage => that the claim is already done in block chain.
+and the Finish method is called on the claim.
+
+### List-unclaimed requests
+As a first step the service provider needs to be aware of all the 
+unclaimed money
+Service Provider needs to send the following message (using snet-cli/publisher portal):
+mpe_address, current_block_number, signature(“__list_unclaimed”, mpe_address, current_block_number)
+![List unclaimed](/assets/img/daemon/listUnclaimed.png)
+
+After receiving this message, daemon does the following:
+Verify that mpe_address is correct
+Verify that actual block_number is not very different (+-5 blocks) from the current_block_number from the signature
+Verify that message was signed by the service provider (“payment_address” in metadata).
+Send list of unclaimed payments without signatures (we don’t send signatures here just to be safe!!!)
+
+### Start-claim request/requests
+
+using snet-cli the following message:
+mpe_address, channel_id, signature(“__start_claim”, mpe_address, channel_id, channel_nonce)
+
+After receiving this message, daemon does the following:
+Check that current channel nonce in blockchain is equal to nonce of the channel in etcd. It means that all previous payments on this channel was claimed already.
+Daemon should remove all payments with nonce < channel_nonce from payment storage.
+Verify that signature is authentic ( “payment_address” is in metadata !)
+Increase nonce in storage and send last payment with old nonce to the caller (snet-cli/publisher portal)
+
+
+### List-in-progress
+Get the list of all claims that have been initiated but not completed yet
+Before sending a list of payments, daemon should remove all payments with nonce < blockchain nonce from payment storage (call finalize on them?). It means that daemon removes all payments which were claimed already. 
+
+
+![List in Progress](/assets/img/daemon/listInProgress.png)
+
+## Concurrent calls 
+
+
+## Signature Details 
+
+For exact details on signatures please refer to [snet-daemon](https://github.com/singnet/snet-daemon/blob/master/escrow/README.md)

docs/platform-dev/sdk-architecture.md

@@ -0,0 +1,14 @@
+---
+# Page settings
+layout: default
+keywords: intro concepts
+comments: false
+
+# Micro navigation
+micro_nav: true
+
+---
+
+# SDK Architecture
+
+![SDK](/assets/img/sdk/SDK.svg)

todo.txt

@@ -0,0 +1,2 @@
+- Delete grpc.md from ai-developers 
+- Delete etcd.md from ai-developers