The Seed DApp Launcher will be the central app of the Seed ecosystem. While DApps can individually be hosted on websites to manually work with the Seed API, a unified launcher will be created for user convenience. The launcher is being created in Electron, allowing DApp developers to use the same code base for both their web apps and their desktop apps.
This design post will dive into what the launcher will be, how we're building the High level API (SeedHLAPI), and how modules/DApps will be added to the launcher.
The launcher window will be the first window opened when a user opens the app. Every DApp submitted to the launcher will be listed as dynamic tiles, showcasing the various DApps a user has installed. A DApp is opened by having a user click on a given tile, which will then open the DApp as its own window.
Once opened, the launcher will act as a homepage for the Seed ecosystem, showcasing all available DApps. Each DApp will be showcased in a small tile, which will list a given DApps name, any data they wish to show, background colors, and even preferred tinting color. When a DApp is closed, their tile is grayed out until a user hovers their mouse over the tile. Once a user hovers a tile, it comes to life, showcasing color and live updating any data the DApp wants to load.
The Seed DApp is the first module & DApp available in the launcher. This DApp hosts the Seed cryptocurrency and acts as a wallet for users. The theme is a simple while background with a light green tint. Upon opening, a users public address will be visible in plain text, as well as a QR code display of that address. The users' balance will also be available, live updating while sending or receiving funds.
The various actions a user can do, such as transfer currency, are listed as buttons below the information heavy header.
At the bottom of the DApp will be the recent transaction history.
The Seed launcher tile will use the same green tint as the DApp itself. The title of the tile will be "Seed", with a clean white background. The logged in users' balance will be displayed on the tile with a small loaded Seed icon to denote the currency. To conserve space, minimal decimal places will be displayed.
Modules & their accompanying DApp will be loaded dynamically from the launcher. The launcher should not know anything about the underlying modules, only where to find the downloaded modules and how to load them.
There are four primary requirements a DApp must describe to the launcher in order for the launcher to effectively load the DApp.
DApps must describe what information to display on their designated tile on the launcher. This information includes, but is not limited too, a DApp name, tint colour, background colour, description, and potentially what live updating data to fetch.
DApps must direct the launcher to the JavaScript file location of their module's source code. This module is to be loaded into the Seed Virtual Machine upon startup.
DApps must direct the launcher to the HTML file location of their DApp's source code. This HTML file will be opened as its own window when a user chooses to open a DApp.
DApps must be able to list the expected checksum of their module code. This is used to validate that the module code has not been tampered with.
All modules will be downloaded and stored in the /modules folder in the base directory of the client. Each sub folder of the /modules folder will represent a separate DApp that the launcher can launch. Inside each sub folder will be a module.json file, which contains a JSON object that describes the above DApp requirements to the launcher.
When the launcher opens, it will read each subfolder's module.json file and dynamically create each tile & associated module. In order to add modules to the launcher, one must simply be downloaded and places in the /modules folder.
DApps which choose to be hosted inside the launcher will have the luxury of accessing a High Level API for Seed. This High Level API is referred to as the SeedHLAPI. This API wraps all logic needed regarding how Seed works under the hood, and lets users create transactions, read from modules or subscribe for updates in a couple simple function calls.
This approach differs from the current Seed API, which is now being referred to as the Seed Low level API (SeedLLAPI). The Low Level API (LLAPI) exposes the underlying exports needed to communicate directly with Seed's subsystems, while the High Level API (HLAPI) wraps the logic, removing a developers need from understanding how to appropriately communicate with the Seed subsystems.
Electron brings its own set of constraints we must adhere to when building the HLAPI. The primary constraints we must respect is how Electron and the underlying Chromium system its built on communicate across processes.
Each process has its own set of memory, with each window being a separate process. The base process is known as "Main", which creates each individual window. Each window has its own process, which is known as a Renderer. Renderer's and Main communicate with one-other through Electron's IPC channels. These IPC channels cannot have JavaScript references sent through it, so all data or objects that are sent over IPC must be serializable.
Since we cannot send references, the processes cannot communicate with the same Seed API instances directly. Instead, Main must be the process that holds the Seed LLAPI instance used by the Seed HLAPI, and the Renderers must request Main do the processing. These requests must be made through IPC.
DApps must be able to make HLAPI requests, wait for a response from a separate process, and continue their work once the execution of the HLAPI has completed. Therefore, the DApps require that the HLAPI is asynchronous, despite the LLAPI being synchronous.
With regards to what DApps must be able to do, DApps must be able to:
| API | Description |
|---|---|
| Switch Accounts | DApps may request an accounts witch, as users may have more than one account they wish to use. |
| Get Account | DApps may want to know which account is currently logged in. |
| Create Transaction | DApps must be able to create transactions when a user chooses to execute a function in their module. |
| Get Transactions | DApps may want to fetch a transaction from storage by the transactions hash in order to read it. |
| Call "Getters" | DApps may want to call any modules getters, even other modules. |
| Read | DApps may want to read raw data from the ledger regarding a module. |
| Subscribe | DApps must be able to subscribe to function callbacks and data changes in order to live update appropriately. |
| Unsubscribe | DApps must be able to unsubscribe to avoid memory leaks and unwanted callback invocations. |
| Create Modules | DApps must be able to create modules, as well as add them to the Seed system. |
| Get Modules | DApps may want to fetch a module to read their data directly. |
The Seed HLAPI will be a two-part process.
For DApps, a SeedHLAPI object will be available which wraps communicating with the Main process. Upon construction of the object, the SeedHLAPI class will take in a PromiseIPC object, which is used for asynchronous IPC calls. This exposes the API calls to the user without the user needing to know how to communicate with Main.
The Main process will listen for the asynchronous IPC calls for each API request. Upon receiving the call, Main will wrap the implementation for each API call, communicating with the LLAPI directly to process the requests.
Adding a new DApp to the launcher is as simple as adding a it into the /modules folder in the client's base directory.
Unlike Ethereum, where Smart Contracts are uploaded to the network through large transactions, Modules are manually downloaded.
This adds a layer of inconvenience for the user and a layer of centralization to the launcher's development, however it has the benefit of also adding a layer of quality control over DApps. Users are not forced to download all DApps and accidentally run malicious code, if one somehow made it to the network. Users can also validate versions of modules before downloading.
This does not take away from the decentralization of the ecosystem. The launcher is not the same project as the Seed ecosystem. DApps can be hosted on websites using the Seed LLAPI, or this launcher can be forked on GitHub as its an open source project, should a module desire to use the HLAPI while avoiding our launcher.
For the time being, modules and DApps will be added to the ecosystem through GitHub pull requests. This allows for strong quality control. Users can keep anonymity, however must have a GitHub account to answer questions that the git-masters may ask about their project before approval. This lets developers peer-review code before accepting into public release builds.
It also reduces the scope of the project in the short term.
In the future, modules will be downloadable from a trusted source automatically, with an automated uploading system that bypasses GitHub.
This future plan is not within the scope of the research project, however it is within the scope of the product.
