Building dApps with JavaScript and Menlo One

Matthew Nolan
Sep 19, 2018 · 7 min read
  • Users cannot use a web dApp without running a client app on their desktop, the Menlo Wallet. This app is responsible for the discovering and connecting to servers for the user to connect to. It also contains lite nodes of several blockchain systems, and it is responsible for interacting with the blockchain networks for the user. Lastly this app is responsible for validating data the user receives from the content nodes with the blockchain. A simple API is exposed for developers, and the complexity of the validation protocol is handled for the developer automatically.
  • On the server-side, application data is not stored in a single, centralized database. When data is saved to the database, a second call is made to save that data to the blockchain. Servers run an application which handle the protocol for communicating with the blockchain.
  • If you’re a developer new to decentralized systems, you might be surprised by the fact that all users coming to your dApp are automatically authenticated but, by default, are anonymous. The user does not log in with a traditional username and password, the user authenticates their identity with a cryptographic key pair. At launch, this is Ethereum, but it will be possible for the user to authenticate with several protocols. If the application requires 2FA or single-click sign on, Menlo comes bundled with an integration to Civic, a private, decentralized identity solution.

Framework Components

Menlo One comes bundled with everything you need to get started building a dApp. If you’re familiar with some of the “React / Node hackathon starter kits”, its very much in the same vein. It comes with the following major components:

  • The Menlo Wallet which runs on on the client side.
  • A content node docker configuration with Node.js preconfigured with h Express & Mongoose configured to support Typescript to safely handle REST APIs, Mongo as the database to index content distributed in IPFS and an Ethereum node to have the latest metadata living on the block-chain.
  • Kovan based deployed contracts the framework automatically uses to get you building on testnet quickly.
  • Deployment scripts to easily push your dApp server side solution to a central repository where all content nodes pull from to host applications.
  • Menlo middleware can be included in Express routes so that the client know’s to validate that data with the blockchain.
  • Although all data is saved to a public system, some user data such as private messages has to be kept private. We provide an API to a client side library which encrypts messages at REST.

Forward compatible for next generation blockchains

FAQ: Why decentralize in the first place?

If you’re new to decentralized systems, this might seem like we’ve turned classic web architecture on its head a bit, and we have, but for good reason. The general idea is that we should assume the server is not trustworthy, and the user is afraid the server will give them content different from what the content creator intended. Imagine if your friend makes a blog post entitled “Donald Trump has tiny hands”, but then our Commander in Chief asks the Medium CEO to please change that text to “Donald Trump has huuuge hands”. If not for Menlo One, you would have no way of verifying if that’s what your friend intended you to read. But with our framework, you the user would take a hash of the server response and compare that with a hash of the original message your friend left in a smart contract on a blockchain. That way both of you know you received the intended message, or if the content node is has been malicious.

FAQ: Who will pay for the cost of hosting content nodes and the users blockchain GAS?

In short there are three actors to consider in this ecosystem: The publisher (someone publishing some sort of data or content), the content node (someone hosting that data), and the user (someone consuming that content). In the Menlo One framework the publisher buys or earns Menlo’s ONE tokens, and when posting their message somewhere puts some ONE tokens in a smart contract. ONE is used to pay the content node for serving you the intended data. ONE is also used to reimburse the user for the inherent cost of using the Ethereum network.

FAQ: If the middleman can no longer make money, why would anyone build an app?

It seems there is an economic shift taking place. It’s no longer lucrative to build a *venue* for exchange, but instead a *medium* of exchange. We recommend you explore launching your own cryptocurrency, which is specifically suited for your use case.

FAQ: Do I have to use the ONE token for all transactions?

The ONE tokens is only used to pay for the transaction of data as a way of paying people running content nodes. You the developer are free to build your dApp as you please. The cost of running content nodes can be passed on to users, content creators or your dApp could pay for that cost depending on your scenarios.

Menlo One Blog

The Official and Only Blog for Menlo One

Matthew Nolan

Written by

Entrepreneur. Coder. Builder of things.

Menlo One Blog

The Official and Only Blog for Menlo One