Yesterday we made public the GitHub repository for the new Mobius DApp Store 2.0 Ruby SDK containing the first beta release. As mentioned in our last two company updates (one and two) we are redesigning the Mobius DApp Store to be open source and non-custodial. This beta release of the Ruby SDK is the first piece of this new DApp Store architecture to be released.

In the first version of the closed source DApp Store users sent MOBI to the DApp Store and were given an equal number of credits that they could then spend. After a developer earned credits they could exchange the credits for MOBI through us.

In the new version of the DApp Store MOBI are sent directly between the user and the developer — MOBI never go through us and we never have access to any of the user’s or developer’s secret keys.

Request for Beta Testers: We are planning to launch a beta version of the new DApp Store next week. We need both developer and user beta testers. Developers — you can start integrating with the new DApp Store now with the above linked Ruby SDK. We may also request design feedback from you and ask you to participate in user research and/or designer interviews in the future. If you would like to signup please go here https://goo.gl/jZkFPa.

DApp Store 2.0 Overview

A user logs into the DApp Store by either loading from a file or creating a new seed (Ledger support is on the to-do list). Using BIP44 an infinite number of Mobius accounts can be generated from a seed. The user’s primary account (GUSER) will be the Mobius account at index 0 and is the account where the user deposits MOBI they want to spend in the DApp Store. The user will also have to send a small amount of XLM to GUSER to cover transaction and Mobius account creation fees. SUSER, the secret key for GUSER is never transmitted to our servers — it might be generated via the open source DApp Store running in a web browser but it is not transmitted to our servers. Alternatively we will be adding Ledger support (and Trezor if they add MOBI support!).

The DApp Store loads a list of DApps from a server — the DApp Store we host will default to our server but it could be forked, hosted elsewhere, and pointed to a different server (in the future we will work on decentralizing this DApp list which goes with our overall strategy of progressive decentralization starting with the payments layer). Each DApp in the list will contain some properties that allow the DApp Store to show/work with it such as its name and developer submitted public Mobius address (GDAPP). The DApp Store also generates a Mobius account for each DApp based on the user’s seed — for example, the first DApp will be connected to the Mobius account at index 1 generated via the seed using BIP44 (GUSER_DAPP).

For a user to use a DApp and pay for it via MOBI they need an easy and secure way to send MOBI from their main account GUSER to the DApp’s GUSER_DAPP account, and for the DApp to be able to withdraw MOBI from GUSER_DAPP. The DApp Store and its SDKs such as the beta Ruby SDK we just released make this easy and it involves three parts: 1) deposit, 2) authentication, and 3) payment.

Setup

Next to each DApp in the DApp Store will be a text box where the user can enter the number of MOBI they want to transfer to the DApp and a Deposit button. Assume we have DApp with index 1 as mentioned above with the user’s unique public account for this DApp being GUSER_DAPP — the secret key to this is derived from the user’s seed. The DApp has its own public account GDAPP for which it has the secret key.

1. Deposit

Deposit is the easiest step. When the user clicks the Deposit button the DApp Store will:

A) Create GUSER_DAPP by sending it a few XLM (~3) if it doesn’t exist.

B) Transfer the specified number of MOBI from GUSER to GUSER_DAPP

2. Authentication

A user needs to:

A) Tell a DApp what MOBI account to withdraw MOBI from;

B) Grant the DApp access to the MOBI account so it can withdraw; and

C) Prove to the DApp that it owns the MOBI account it claims to.

We accomplish this through the following procedure — when a user opens a DApp from the DApp Store it:

A) Adds GDAPP as a signer to GUSER_DAPP if it isn’t already added — this gives DApp permission to withdraw MOBI from GUSER_DAPP.

B) Requests a Challenge Transaction (CT) from the DApp. A CT is a 1 XLM payment transaction from GDAPP to GDAPP signed by SDAPP (the secret key to GDAPP that the developer has) and has default time bounds of current time to 24 hours in the future.

C) The DApp Store receives CT and verifies that it is signed by SDAPP by checking it against GDAPP (it does not know SDAPP — only DApp and its developer does) — if not it errors.

D) The DApp Store signs CT using SUSER_DAPP which is either loaded in memory (never transferred to our server) or on a Ledger (upcoming support) and creates Challenge Transaction Signed (CTS).

E) The DApp Store now sends CTS to the DApp which verifies i) it is signed by SDAPP and SUSER_DAPP and ii) happened within the last 10 seconds (prevent replay attacks).

F) The DApp sends back a session token T containing time limits and GUSER_DAPP to the DApp Store if CTS is valid (probably via JWT) else it errors.

G) The DApp Store now opens the app passing in T which is used by the DApp to “login” the user to the Mobius wallet GUSER_DAPP represented in T.

3. Payment

The user has now successfully opened the DApp from the DApp Store and past in token T which proves to the DApp that it is the owner of GUSER_DAPP.

When the user takes an action that requires payment in the DApp, the DApp withdraws MOBI from GUSER_DAPP using its SDAPP which works because GDAPP was added as a signer in 2(A) above.

Example DApp

We have also released a sample DApp that uses the above Ruby SDK — Floppy Bird! You can view the source code here https://github.com/mobius-network/floppy-bird-dapp.

If you have any questions please join us in our Developer Telegram (https://t.me/Mobius_Developers) or feel free to email developers [at] mobius.network

What’s Next

We are currently finishing up development on a beta of the new DApp Store front-end and plan to release it within the next two weeks along with a JavaScript SDK. We will also be working on additional SDKs (Python, etc).

Yesterday a new product designer started working on a new design for the DApp Store. He is going to start by interviewing and collecting feedback from existing DApp Store users and developers to identify pain points and areas for improvement beyond the obvious (search, categories, developer pages, etc). We tentatively plan to have the new DApp Store design finished and implemented in May. Once the redesign is complete we will release the new DApp Store to production.

During the beta phase of the DApp Store we will be working with existing developers to upgrade their DApps to the new system and recruiting additional developers to the Mobius DApp Store.

We are also going to soon start hosting DApp Store hack-a-thons and workshops all over the world (probably May/June) and working to get Mobius DApp Store development added into school (high school, university, etc) and coder bootcamp curricula to start training more developers.

In the future we’ll implement Ledger wallet support (we’ve also emailed Trezor to try and get them to add MOBI support generally).

Yesterday we also started development on a mobile wallet and DApp Store app.

Thanks for your continuing support and help!

Team Mobius

Join Mobius Online!

Email: https://join.mobius.network/

Chat: Telegram (Announcements, Developers, Chinese, Russian), KakaoTalk

Social: Twitter, Facebook, LinkedIn, Weibo, Reddit

Events: Meetup

Code: GitHub, npm, Ruby Gems