Categories
Scintillating News

The Making of Delphus Chat: Matrix, Ethereum, & End-to-End Encryption

Delphus, our secure, decentralized research manager, just got a very important new feature: end-to-end encrypted and federated chat, voice, and video calls, powered by Matrix and Riot. Here’s how we built it.

Why Matrix?

End-to-end encryption is necessary for our private researcher-participant communications, where sensitive information is often exchanged. This made Matrix, one of the only chat protocols that truly offers end-to-end encryption, our ideal choice. Its encryption library has been audited by NCC Group and is supported on all platforms, including web, iOS, and Android. Its mission to create a global, open “matrix” of communication also fits well with our own goal to unify and share scientific research.

Further, Matrix’s Synapse server is open source, allowing us to self-host it. It has several useful administration features, such as the ability to send system alerts to all of our users or to automatically add users to a server-wide discussion or announcement room.

Matrix also has a featureful first-party client: Riot. We opted to integrate this client into our app instead of coding one ourselves to take advantage of their end-to-end encryption support and extensive efforts to improve the user experience. Riot also supports voice and video calls through WebRTC.

Integration

Unfortunately, Riot is not itself designed to be embeddable. It currently does not expose any hooks to tell when the application is loaded or to trigger specific UI actions.

Since we wanted to integrate it into our application—for example, by adding links to start chats with participants or researchers—we added these hooks by forking Riot. (Changes are open source on our GitLab instance at delphus-riot-web and delphus-matrix-react-sdk.)

At specific locations, such as to mark when the user has logged in, our fork of Riot sends a cross-frame message to Delphus:

{
    type: "LOAD_COMPLETE",
    matrixId: this._matrixClient.credentials.userId
};

Using an event listener, the main Delphus application picks up these messages and triggers an action. We save the current load state (loaded, signed in) of Riot in our local state so that buttons in the app can know when Delphus Chat is loaded, e.g. to show a specific chat window.

To show notifications from Riot, we added a similar notification cross-frame message, which is used to update a counter in our code and show a notification badge on the Delphus Chat button (The user can also enable desktop notifications in Riot, which will show notifications as popups on their computer).

To open specific views in Riot, we programmed a way to manipulate the current location of the iframe, since Riot stores its view in the URL. For example, viewing the Matrix HQ (a general chat room about Matrix) is at the URL /#/room/#matrix:matrix.org, while viewing my profile is at the URL /#/user/@kevin:chat.delph.us. By manipulating the iframe URL, we can effectively remote-control Riot.

Identity Verification

However, in order to let participants chat with researchers (or vice-versa), we still needed a way to link a user’s Ethereum address (their pseudonymous identifier on our platform) with a Matrix ID (a username on the Matrix side). We decided to write a simple smart contract to handle this:

pragma solidity ^0.5.0;

/// @dev Stores mappings of addresses <-> Matrix IDs as part of the chat
/// system.
contract ChatRegistry {
    mapping (address => string) public matrixIds;

    function setMatrixId(string calldata _mxid) external {
        matrixIds[msg.sender] = _mxid;
    }
}

This Ethereum smart contract maps a user’s Ethereum address to their Matrix ID.

Then, when we receive the LOAD_COMPLETE message from Riot, containing the user’s Matrix ID, we can compare it to the one saved by ChatRegistry. If the two differ, Delphus triggers a transaction to update the registry.

Thus, when we show Ethereum addresses on other parts of the site (such as when we display the researcher or participants in a study), we can include a “Start chat with this user” button to provide seamless integration. This button will automatically open Riot, load it if not loaded (since Riot is lazy-loaded to reduce the performance impact), and navigate to the specified user.

The end result is that we have a user-friendly, integrated embedded form of Riot on Delphus, allowing users to easily start encrypted chats, voice calls, or video calls with other users on the site.

Interested in learning more about Delphus? Contact us at info@scintillating.us, or sign up for our mailing list. If you are interested in learning more about Matrix, check out their blog as well.

Categories
Scintillating News Uncategorized

Interview with Will Hemond, Co-Founder of Delphus

Sponsr.us, a student-run entrepreneurial nonprofit group, recently interviewed Will Hemond, co-founder of Scintillating and Delphus.

Check out their article on Medium!

Categories
MakerDao's Dai and Delphus

Groundbreaking, Seamless Dai Integration in Existing DApps

Price volatility is the Achilles’ heel of a distributed application, or DApp for short. Nobody wants to deposit funds when Ether dipped 30% in the last month. And, while stablecoins like Dai can solve this issue, they have notoriously poor documentation, as we mentioned in our previous post. Furthermore, most existing DApps are already designed around Ether, which is relatively easy to process, and converting them to use DAI is an arduous and under-documented task.

The UX Problem

Using Dai also poses another issue: the user experience. If a smart contract only accepts Dai, new users will have to manually go to an exchange (of which there are few) to convert their Ether to Dai, then return to the DApp and deposit their Dai. Then, when taking out Dai, they have to manually convert it back to Ether to sell it for fiat on an exchange.

Enter Oasis.Direct.

Oasis.Direct is the prime example of what the UX for a decentralized app could be  a one-click transaction converts your Ether to Dai, without any manual ordering or price setting. Moreover, by integrating it into Dai-accepting smart contracts, it has the potential to make them far easier to use.

Step 1: Connecting to Maker Contracts

First, let’s take a (slightly simplified) look at how the entrypoint for our StudyManager contract looked like before Dai integration:

Ignore the other parameters, what matters is that it’s a payable function to which the user can send Ether. That Ether is then held by the contract and recorded in the new study’s paymentPool.

To convert this function to accept Dai, we have to retool it a little:

We’ve changed the contract to look much like a function that accepts ERC20 tokens which it should, since Dai is, at its heart, an ERC20 token.

However, there are two issues with this approach:

  1. The user still has to manually convert their Ether to Dai.
  2. The user has to manually call dai.approve(YOUR_CONTRACT_ADDRESS, tokenAmount) before calling this function, thanks to the design of the ERC20 standard. This means that the user has to approve two transactions.

Thankfully, we can solve both of these issues simultaneously:

Step 2: Interfacing with OasisDEX

OasisDEX is a decentralized exchange that converts ETH to DAI, running on both the Kovan test network and the main network. Its contract addresses (under “market”), along with Dai’s Kovan and mainnet addresses, can be found in the source code repository.

By interacting with OasisDEX, we can simplify the user flow, automatically converting deposited Ether to Dai for long-term storage.

Let’s see an example from our code:

(Contract interfaces from Oasis.Direct’s code.)

Here, the contract does four things:

  1. It deposits the paid Ether into the WETH contract, which is needed to trade on OasisDEX. Our contract now owns msg.value in WETH.
  2. It gives OasisDEX approval to use as much WETH as it needs to trade it to Dai.
  3. It executes an automatic trade from WETH → DAI, requiring an outcome of at least minBuyAmt DAI or else the trade will fail.
  4. It creates the study as we did in the previous step.

Note that the function has to be passed in the “minimum buy amount” of Dai that they want; it specifies the minimum exchange rate, in effect. You can calculate this on the DApp end by calling (with ethers.js/web3):

Which you can do invisibly before sending the createStudy transaction, in this case.

Step 3: Mocking Maker

Now, there’s one downside with this approach: to test your contracts in the future, you’ll have to use the live OasisDEX contracts on Kovan or the main network. This obviously doesn’t play very well with automated testing like Truffle, as each test would require actual Kovan/mainnet Ether.

First, we tried a new way of testing: with the tool ganache-cli, you can actually do a virtual chain fork by connecting to a mainnet/Kovan node and effectively creating a development blockchain that starts with all the state of the live network. This would let you test cheaply, without incurring costs on the live network, but while still connecting to “real” MakerDAO contracts.

Unfortunately, we ran into issues where our contracts either failed to deploy or didn’t work properly with this setup, so ultimately we ditched it for a more traditional, if more annoying, approach.

Let’s deploy all the Maker contracts on the Truffle development network!

The full code is pretty long, but I’ve put it on a GitHub gist at the end of the post if you’d like to use it. Here are the major steps:

  1. Deploys OasisDEX, WETH, and a FakeDAI contract (just a mintable ERC20 token) from /contracts/maker/.

  2. Whitelists the WETH and FakeDAI pair for fake-trading. This is necessary to prevent the OasisDEX contract from erroring on “untrusted” token pairs.

  3. Creates the WETH to DAI trading side of the exchange and the DAI to WETH side.

    To do this, you have to deposit WETH, approve it for use by OasisDEX, and make a fake WETH → DAI offer at a fake exchange rate. For the other side, you have to mint some fake DAI, approve it for use by OasisDEX, and make a fake DAI → WETH offer.

This creates a marginally-functional OasisDEX contract on the development network which you can use to mock Dai trading.

And there you go! That’s how you convert a contract accepting Ether to one that seamlessly converts it to Dai for long-term storage.


This code was used in our product Delphus, a DApp revolutionizing the management of clinical data in scientific studies. Find out more there!

Appendix

Other interesting links:

Development Truffle migration script:

Categories
MakerDao's Dai and Delphus

Rationale for Tutorial

While Dai is a useful tool and allows for stability of a platform, there are not many instructions on how to implement this token into either a new Distributed Application or an existing one. Further, existing documentation does not appear to exist with few understandable comments, which, to be fair, is somewhat understandable with such a new implementation.

MakerDao’s official chat has been more than helpful, but we believe that it may allow for easier integration if there was a documented journey from start to finish, including the most common errors found, it may be useful for others.

We will be showing snippets of our code as we implement them, and our full source code will be released at the public release (we aim to be open source).

Thank you for joining us on this journey, and we hope that it ends up working for both you and us.

Categories
MakerDao's Dai and Delphus

Why does Delphus use Dai?

If you don’t know what Delphus is and would like to know more, please check out our earlier post here as well as our website here.

As you may already know, the one issue most have with cryptocurrencies is the overall volatility of most networks.

For example, Bitcoin, mostly due to surrounding hype and a positive relationship between investors and miners, spiked in prices, reaching $20,000 back in December, but then “normalizing” down to its current price of around $8,000.

These increasingly different prices, often with no correlation to any conventional market trends to the average user, provide for a marketplace not useful for many cases in which a static amount of value may need to be stored. This is the case with Delphus as the researcher -> participant payments cannot change in value throughout the duration of the study.

There are many viable options for addressing this issue, with new stablecoins appearing every so often. The stablecoin most prominent, trusted and well supported by developers as of now is MakerDao’s Dai. It is tied 1:1 with the US dollar with very few deviations of non-discernible value (>.01 cents). It is collateralize using valuable assets in the open-source Maker contract.

For this reason, it is far easier for researchers to set static payments that can be distributed through smart contracts, rather than relying on the rise and fall of a cryptocurrency. Since we rely on the Ethereum Blockchain, we can use the ERC20 token, Dai, in order to keep stable prices and allow both researchers and patients an easy way to receive non-volatile payments.

This allows us to garner better communication between the researcher and the patient, while reducing the risk of patients not receiving their specified payment or complaining about how what could be $1,000 the first day, is $5 the next day (they probably won’t be complaining if the price increases). Further, as Dai is being continuously developed and scaled with them introducing more collaterals to their system, it is ideal for the ever-expanding field of medicine and clinical trials.

Thus, we arrived at the logical conclusion of incorporating Dai into our project and we’d like to share with any interested parties, the entire process of its integration.


edited product name from reblock to Delphus

Categories
Scintillating News

Our Plans for the Future

Welcome to the official blog of Scintillating and Delphus.

In this blog, we would like to talk about the development of our product.

In an age of increasing lack of privacy, evidenced by corporations like Facebook and Amazon, data is easily sold off and not valued by corporations. The medical field specifically faces a large problem when dealing with the results of studies; data transparency is nonexistent in comparison to the quantity of available data from said studies. An estimated 90% of study results are never released, preventing others from building upon their work and creating an open scientific community. Even if obtained, sensitive data is difficult to secure from alteration or tampering which creates issues with study transparency and consent in the long term. Finally, discovering participants is costly and time-consuming, while the budget of many researchers is comparatively not enough to deal with these issues alone.

Researchers need software that can cut costs and save time. They require tools capable of managing payments and securing data. Patients need a greater access to their own data and a larger degree of privacy.

While other companies have developed their own clinical trial management platforms in an effort to solve these issues, these conventional systems often create new problems. They do little to preserve the results of completed studies for future researchers and breed distrust due to a lack of transparency. Thankfully, these issues can be solved via the blockchain which allows for immutable and transparent studies through smart contracts. Using Delphus, the blockchain-based decentralized study management system, all of these problems are solved.

Delphus is our flagship product that aims to improve clinical studies by modernizing the workflow of researchers’ data submission and collection.

By using the blockchain, we can dramatically cut down the costs of data management and are able to improve communication between participants and researchers through trustless smart contracts.

We aim to finish the minimum viable product of Delphus by the end of July, which includes these features:

  • COM token (with dividends)
  • Uploading consent forms, consent recording
  • The ability to create a study with custom fields
  • Integrated participant database
  • Encrypted upload of data points to IPFS
  • Distribution of funds to patients through ETH
  • DAI as intermediary currency for stability
  • Importing/exporting data points
  • Comprehensive system for adding data fields to allow for customizable studies
  • Seamless tutorial and smoothly flowing UI

By implementing all of these features, we can solve the key issues that worsen the experience for both researchers and participants. After this, we will do extensive testing before expanding to local colleges.

If you would like to learn more, you can visit our website here.


edited product name to Delphus