IPLV2 High level Architecture

Gadi Srebnik
Kin Blog
Published in
4 min readDec 28, 2017

Following my previous post, which presented the context of the IPLv2 project and its goals, I want to discuss the architecture, flow and design of the project. These are based on the following requirements which in-turn are derived from project goals:

Functional Requirements:

  • Initial granting of KIN to selected Kik power users
  • 2-sided KIN economy within the Kik ecosystem
  • Kik End-users support

Non-functional Requirements:

  • Security
  • Privacy
  • Availability
  • Scalability (up to 10K users)
  • Compliance and Regulations

Following are the infrastructure and application level components participating in the product:

Client

  1. Kin mobile SDK — A component that interacts with the blockchain(iOS, Android)
  2. Kin Plugin — Communication layer between the web and native implementations on mobile clients that adds Kin SDK functionality
  3. Bots UX — Kik messenger bot user experience
  4. Wallet — Web display of balance and offer wall, which communicates with the Kin SDK through the Kin plugin
  5. Confirmation dialogues — Web display of confirmations to send or receive Kin, communicates with the Kin SDK through the Kin plugin
  6. Sticker shop frontend — Web display, communicates with the wallet and confirmation dialogues through the Kin Plugin

Server

  1. Kin SDK — A library used by server components to connect to the blockchain
  2. Kikteam bot
    - Initial on-boarding procedure
    - Earn bot — serves polls to clients, allowing them to earn kins
  3. Initial award service
  4. Sticker store backend

Protocols used in the process:

  1. HTTPS — Communication between Secured web view and initial award service and sticker-shop front end and back end.
  2. Encrypted XMPP — Standard communication in Kik application. In this flow it is used for communication with the bots.
  3. Json-RPC over HTTP — Used for communication with blockchain nodes by the client and server Kin SDK
  4. Javascript Bridge — Client internal communication channel between webviews and native client code

Following are 3 flowcharts:

  1. Onboarding — The initial approach to power users, wallet creation, granting of KIN and initial use of wallet
  2. Sticker store — Purchase stickers from creator using KIN
  3. Earn bot — Earning KIN by interacting with a bot, usually by answering a poll

Onboarding

Not shown in the flowchart: A whitelist of power user is created and stored in the initial award service and every user is approached by on-boarding bot.

Flow

  • The Onboarding bot approaches a pre-selected user, asking her to participate in the KIN ecosystem
  • The User reads and accepts the term of service (confirmed via a secured webview)
  • The Client then creates a wallet and sends public address to initial award service for granting
  • The Initial award service validates the user and sends KIN and ETH (for transaction)
  • The Client can then see the granted KIN amount in his wallet

Sticker store

Not shown in the flow: the Sticker service datastore contains cost and public address of pack creators

Flow

  • The user opens the sticker store frontend from the wallet page or from another option in the app. After validation, the user sees Kin-exclusive packs (those that can only that can only be purchased by spending Kin).
  • The user selects a sticker pack to purchase and receives an order id for tracking as well as the creator’s public address and the cost in Kin.
  • The user verifies the payment in a secured view and the SDK performs the transaction through the blockchain. The client then receives the transaction Id.
  • The client sends the order Id and transaction Id to the sticker store backend for validation, and after the validated pack info is returned to the client, the user can use the pack.

Earn bot

Not shown in the flowchart: The user has already accepted the Kin terms-of-service and has created a wallet on his device. The user selects the earn bot from offer wall.

Flow

  • The Bot sends an assignment to the user, such as answering a poll question
  • The client completes the assignment
  • The bot requests the client’s public address in order to transfer Kin
  • The client needs to explicitly permit sending the public address to the bot
  • The Bot transfers Kin to the client’s public address through the blockchain
  • Bot may notify the client that the payment was completed

--

--

Gadi Srebnik
Kin Blog

Head of blockchain @Kin. Chess and Poker enthusiast.