Forem: Julien Genestoux

🔐 Creating a Crypto Token Gated Express application

Julien Genestoux — Wed, 03 Nov 2021 13:34:48 +0000

Web3 encompasses a plethora of elements that empower us to build a more accessible web for everyone -- including Non-Fungible-Tokens, Token Gating, and decentralization. One perk from the emergence of web3 is moving away from the monetization of our personal data to sell ads. Win-win for us all!

I'm here to show you how simple the process is for token gating content in an Express.js application using the Ʉnlock Protocol. Ʉnlock is a protocol for memberships that allows anyone to deploy a "lock" (a membership smart contract). The contract specifies the terms of the membership: including price, duration, number of members, and many more parameters necessary to run a thriving membership subscription. When a supporter wants to join your membership, they simply pay the specified amount to the contract and will receive an NFT that represents the purchased membership.

app.get('/premium', membersOnly(), (req, res) => {
  // ... unchanged
})

TL;DR: that's all you need to monetize your application!
Try it | Code

🚀 Let's get started!

Requirements: you need to use an ethereum/web3 wallet such as MetaMask. We will be using a the Rinkeby test network for this tutorial (no need to spend real money, get some fake Ether on this faucet), and when you decide to ship, you can use Ethereum's mainnet, or the xDAI and Polygon networks if you want to skip the high gas fees.

Deploying a lock 🔒

This is the first step. Unlock Inc provides a front-end for this to be a bit easier, but know that you could also do it directly from the smart contracts.

Go to the Unlock Dashboard. Connect your wallet and then click on the "Create Lock" button.

You can then complete the form to specify the name of your membership contract, the duration (in days) of each membership, the amount of members, as well as the price for each membership.

Clicking on "Submit" will prompt you to submit a transaction that will deploy your lock! It usually does not take much more than a few seconds but you will be able to see the address of your lock right away. This is the address of the smart contract you just deployed! It is yours, and only yours.

The one I deployed is called "Another Lock", and its memberships are valid for 1 day, and they cost 0.001 Ether. It is at the address 0x32BeC8e1Fc72509fFa115bd6a0f064Ec77319E4A and we can inspect it on Etherscan.

The side bar shows lets you enable credit cards 💳 (for users who do not have a crypto wallet, withdraw its funds, and more... feel free to tinker with it!)

Express application for date and times

If you're familiar with Express, you won't learn much so skip to next section!

For this demo, I created a dummy Express application that gives the time ⏰ in all timezones. The "free" version just includes 4 cities around the world, but the premium version offers a list of 457 cities!

Here is how the code looks like:

const express = require('express')
const cookieParser = require('cookie-parser')
const zones = require('./zones')

const app = express()
const port = process.env.PORT || 3000;

app.use(cookieParser())

// Helper function that returns date as a string in a city
const dateInZone = (zone, city) => {
  const d = new Date();
  return `${d.toLocaleString('en-US', { timeZone: zone })} in ${city}`
}

// Main root of the application that only shows 4 cities
app.get('/', (req, res) => {
  res.send(`<h1>World Clocks</h1>
  <p>It is now: </p>
  <ul>
    <li>${dateInZone("Asia/Tokyo", "Tokyo")}</li>
    <li>${dateInZone("Asia/Kolkata", "Kolkata")}</li>
    <li>${dateInZone("Europe/Paris", "Paris")}</li>
    <li>${dateInZone("America/New_York", "New York")}</li>
  </ul>
  <p>Premium version: <a href="/premium">select any time zone</a>!</p>`)
})

// Premium route where times in all timezones are displayed!
app.get('/premium', (req, res) => {
  res.send(`<h1>World Clocks</h1>
  <p>Thank you for your support!</p>
  ... (check github for code that renders all zones!)
  <p>Premium version: select any time zone!</p>`)
})

app.listen(port, () => {
  console.log(`Example app listening at http://localhost:${port}`)
})

As you can see it is a pretty standard Express application. The list of zones is stored in zones.js file that you can find on the repo.

Adding the lock

There are multiple ways to integrate Ʉnlock in application, from the lowest levels by hooking into smart contracts directly, all the way to the front-end where some JavaScript can be used to hide/show content.

Here we will use the @unlock-protocol/unlock-express npm module. This module provides a middleware that can be added to any Express route in order to ensure that members only can indeed access the content.

Add the plugin through yarn add @unlock-protocol/unlock-express or npm i --save @unlock-protocol/unlock-express, and then let's include it in our application:

const configUnlock = require('@unlock-protocol/unlock-express')

After this, it's just a matter of configuring the express and using the middleware. The configuration has 3 important elements:

yieldPaywallConfig
getUserEthereumAddress
updateUserEthereumAddress

Let's go through them one by one.

`yieldPaywallConfig`

This one is used by the plugin to ask the application what configuration it should use. The main aspect of this is of course to list what "locks" should be used specifically. You can find more details in the Unlock docs, but here is what we'll use:

    yieldPaywallConfig: (request) => {
      return {
        locks: {
          '0x32BeC8e1Fc72509fFa115bd6a0f064Ec77319E4A': {
            network: 4,
          },
        },
      }
    },

Quite simply, we say that we only have a single lock that we accept memberships from and it is on the network 4 (the Rinkeby test network).

`getUserEthereumAddress`

This one is a way for the middleware to ask the application for the user's Ethereum address, if it knows about it. Here for example, the application could look up its user database and just yield the address of the user... etc. However, in this example, we do not have a user database/table, so we will only use a cookie. So here is what that looks like:

    getUserEthereumAddress: async (request) => {
      return request.cookies.userAddress
    },

`updateUserEthereumAddress`

Finally, the middleware has a way to inform the application of the user's wallet address, so that the application can store it. There again, the application could decide to store that information in a database or, like we do it here, just store the address in a cookie.

    updateUserEthereumAddress: async (
      request,
      response,
      address,
      message
    ) => {
      response.cookie('userAddress', address)
    },

And that's it, here is how the full configuration looks like:


const { membersOnly } = configureUnlock(
  {
    yieldPaywallConfig: () => {
      return {
        locks: {
          '0xafa8fE6D93174D17D98E7A539A90a2EFBC0c0Fc1': {
            network: 4,
          },
        },
      }
    },
    getUserEthereumAddress: async (request) => {
      return request.cookies.userAddress
    },
    updateUserEthereumAddress: async (
      request,
      response,
      address,
    ) => {
      response.cookie('userAddress', address)
    },
  },
  app
)

💡 Please note that the configuration block yields the membersOnly middleware that we'll use in the last step!

Adding the middleware to our premium route

Now that the middleware exists, we can very easily plug it into our premium route and here is how it looks like:

app.get('/premium', membersOnly(), (req, res) => {
  // ... unchanged
})

✅ As you can see, it's quite trivial!

Final touches

A nice addition is to let the user "log out" by just deleting the cookie. For this, we're adding a route:

app.get('/logout', (req, res) => {
  res.clearCookie('userAddress')
  res.redirect('/')
})

🧪 Want to try it out? We deployed the application on Heroku.
🧐 Want to look at the code? It is all on Github!

A note on security: one could note that the cookie itself could be spoofed. This is true, but also easily fixable using multiple approaches. One of them is to change how updateUserEthereumAddress is implemented by using the 4th and 5th arguments passed to this function that include a signature and the message signed by the user. By recovering the signature, the application can get the certainty that the user's address actually matches the visitor (especially if the message signed includes a timestamp or some kind of unique nonce, configurable in the paywall config).

👋 Closing thoughts!

Using this express plugin means that a developer can start monetizing their application from anywhere in the world, in a matter of minutes. There is no need to agree to terms of service, apply for an API key and no approval or review of your application!

Additionally you as a developer can decide of the benefits you want to offer to your members, whether its access to unique content, special features. One of my favorite feature is that the locks themselves are not even tied to a specific platform. For example, if you decide to do support over Discord, you could use a bot like SwordyBot to easily identify paying members (or grant them access to a special channel!)

Examples of Projects using Unlock!

If you enjoyed this and want to learn more, please join the Unlock Discord. I would also recommend that you apply for an Unlock grant!

👩‍💻 Oh! And we're hiring a Dev Evangelist. Is that you?

Front End Engineering is Nothing to Sneer At

Julien Genestoux — Mon, 08 Oct 2018 17:45:59 +0000

Even though Unlock, at its core, is a protocol to build a better business model for the web, I believe it cannot succeed if it does not provide a stellar experience to both creators and consumers. The fact that Unlock is a blockchain based protocol means that there are a few extra challenges to handle, but our goal is to build the best “unlocking” experience anyway.

Because of that, we’re focusing our early hires on software engineers who can help us build both that amazing experience and the architecture which will support it. For this reason, we are particularly looking for front end engineers.

Unfortunately, as we made progress and looked at applications and feedback from the candidates, we started to witness that front end software still has a stigma for a lot of software engineers as not being real engineering. It is time to end that myth.

Many still think that front end is not real engineering. It is time to end that myth.
At this point, any modern web application has probably more happening on the client (web browser) than it does on the server. That was certainly different 20 years ago, when most web applications were serving “static” HTML documents, but 2 trends have since then taken us to a very different place:

Most of the backend “platforms” have gotten infinitely more powerful. For example, when I started my career (early 2000s), sharding a MySQL database was pretty much considered cutting edge. Today, Google’s cloud platform offers what a lot of people consider to be the Grail with Cloud Spanner. While you had to design your whole web application around a database limitation, you can now build application which can (almost) completely ignore how the data is stored. Platforms like AWS, Azure or GCP, brought us transparent infinite file storage, managed queue servers, email services or auto-magic scaling, and now, services likes on-demand AI… I will go as far as saying that, unless you’re building some of the largest systems/APIs out there (hundreds of millions of users and more), you can go very very far with “out of the box(cloud!)” solutions.
The front-end constraints, requirements and usages have seen a Cambrian explosion. It started with Ajax, which, despite being a hack, paved the way for much smoother user interfaces (remember when each click meant a full page reload?). The mobile revolution of course made everything orders of magnitude more difficult: when most websites had to consider a dozen different resolutions, we now have dozens of aspect ratios alone! Mobile devices also took us a couple years back when it comes to available resources (CPU, memory and bandwidth) and added a new one: energy consumption. The web stack itself became incredibly more complex with half a dozen in browser data storage mechanisms (we started with cookies… only!), multiple streaming protocols, and of course a whole set of new JavaScript APIs. It’s no wonder why we have dedicate javaScript libraries to manage state alone. This means that, at least for me, the biggest impact that most engineering teams can have is on the front end, not on the backend. I’d even go as far as saying that a great front end experience can still make up for slow API requests, eventual consistency (have you tried reloading your FB home page twice?) or badly designed backend services… while there is no way a modern web application can recover from a sub-par front end layer.

Of course, the concept of a full stack engineer still has a great future, but we should also consider that, like always, context switching has a cost. One can be a great front end engineer and a great back end engineer in their career (after all, these are 2 facets of software engineering…), but I’d start to challenge the idea that they can be both at the same time. In the same way that a great musician can be both a great pianist and great guitarist, the amount of work to master any of these 2 instruments means that it’s nearly impossible to master both at the same time.

(this was initially published here)

Oracle-less bets on the Blockchain

Julien Genestoux — Tue, 14 Nov 2017 20:33:07 +0000

The blockchain is a decentralized database whose data can be trusted because it is the sum of other previously recorded transactions. That data can then be used as an input for all sort of transactions (called smart contracts).

Yet, one of the challenges is that there is actually not a lot of physical data on the blockchain. The way around this is to use trusted third parties called Oracles which are expected to speak the truth. Their job is to capture “real world” knowledge and store it on the blockchain. That data becomes immutable and part of the long chain of transactions.

An obviously financial example is stock prices. In order to write a smart contract which would rebalance a portfolio, one would have to use an oracle to capture the stock prices of assets in that portfolio.

Some people expect that oracle will eventually becomes obsolete in a world where all possible data sources are available “natively” on the blockchain. For example, if stocks where actually traded on the blockchain, then the price data itself is in the blockchain and the rebalancing algorithm does not need to use and rely on a 3rd party oracle.

Can we go without oracles?

If we’ve crossed path in the last couple weeks, you know that I am researching the blockchain these days. (but no, I am not doing an ICO!). As part of this work, and I wanted to see if we could actually not rely on oracles, but rely only the participants good behavior and their ability to form a consensus with the right incentive. Staking is one of the key concepts of the blockchain world and I think this solves our problem here.

The Smart Contract

Let’s take a simple example: we want to write a smart contract which lets an arbitrary number of people bet on an outcome. For the sake of simplicity, we use only binary draws (the thing people bet on actually happens or does not).

In the “traditional” smart contract, participants would be asked to bet on whether the statement is true or false and their bet would be placed in a shared wallet. The oracle would then deliver the truth and all the participants who bet on the right outcome should be able to withdraw their share of the shared walled.

If we did not want to rely on a 3rd party oracle, we would have to ask the participants themselves to contribute the truth, before the payout can happen. Our smart contract would then have 3 phases:

Betting phase
Consensus formation phase
Payout phase

Consensus formation

Unfortunately for mankind, we have to assume malice: some participants will lie and submit lies as truth.
One way to prevent this is by requiring a “stake”. The smart contract only allows people to place bets if they are staking an amount larger than their bet along with the bet to show their intent to contribute truth.
Once the event has been realized, all players are asked to contribute its outcome if they want their stake to be returned to them. If they don’t, then their stake is lost. Participants do this by voting on what is the actual outcome. Once enough participants have voted, the truth is determined by seeing which proposition got more “votes” compared to it share of bets (not necessarily the majority).

All the players who have placed a bet on the right value have a strong incentive to vote: not only would they get the stake back, but also their share of the jackpot.

Players who have placed the wrong bet, on the other end, also have an incentive to vote on the right value because they would get their stake back. If they did not, not only would they have lost the bet, but they would also lose their stake. If all the losers where cheaters, then they could, in theory, break the smart contract, but if only a single one of them is indeed a fair participant, then all the losers but this one would lose their stake. This is a typical prisoner’s dilemma which lets us expect that most losers would not try to lie in order to not worsen their situation.

An example

In order to clarify things, let’s take an example: people have been asked whether this story will get strictly more than 100 reads before November 5th 2017. They are each asked to bet $1 on what they think is the most likely outcome and they are also asked to stake $2 to come and contribute the truth after November 5th. Betting is only open before that post goes public (I shared the draft with players).

At the publishing time, 65 people said that yes this story is good enough to get 100 reads and 35 people placed the bet that it would not. We have a pot of $100 which will be shared among winners.

Time passes and we are eventually on November 5th. Unfortunately (I am biased), this story did not get the 100 reads it deserves. Each participant is asked to contribute to the truth. Out of the 35 people who placed the right bet, 34 contributed the truth (the last one forgot about the bet and the story!). Most of the 65 people who placed the wrong bet were honest (or too scared that their fellow losers were more honest than them) so 50 of them contributed the truth. 13 of them did not bother to vote as they were too disappointed and did not care much about their stake and 2 cheaters lied.

The voting is pretty clear: 85 (97% of votes) people claimed that the story did not get its 100 claps, while only 35% of bets where for that proposition. Consensus was formed and these 85 people got their stake back. The winers also each get $2.8 payout.

In my mind, decentralized staking is one of the most important elements of the blockchains economies and incentives. In this example, we can encourage (enforce?) good behavior and actually turn each participant into an oracle, eventually removing the need to share and trust a third party.

One of the benefits of removing 3rd party oracle is to also reduce the cost to operate such a contract: there is no need to pay for that oracle. In the example above, 100% of the bets are passed down to the winning participants. The house could very well use the lost stakes as its payment for operating the contract.

Additionally, this “framework” can also be incremented with many other aspects. For example, one could add the ability to trade bets by adding a “cooling” period between the betting period and the consensus formation period where participants can trade their votes (and cash out early or minimize risk exposure…).

Originally published there.