DEV Community: Ape Unit

The Tech Behind Eventivize Drops

Andrew Chiw — Wed, 20 Jan 2021 18:33:33 +0000

Behind the Eventivize Drop App is a database that keeps track of how many drops each user has. However, it is not just any database - it is a full-fledged blockchain! Specifically, one based on the Cosmos blockchain, just like Binance Coin and Crypto.com.

But why are we using a blockchain at all? The intent is to spread responsibility for the reward mechanism between multiple parties - the event organizer, partners, artists, venues, and even merchants, such as food stall owners (for events IRL). Besides the myriad possibilities enabled by tokens, spreading ownership of the event (or part of it, at least) could result in interesting crowd behaviours.

Deploying chains on demand

Deploying a new blockchain is not meant to be easy — especially for a Cosmos blockchain. Deploying a new blockchain is not meant to be done often, and there is a lot of back and forth signing-and-verification of messages between several very responsible parties, usually heavily invested companies. Then once it's deployed, you keep it running indefinitely.

That’s not the case with Eventivize.. For each event, a new so-called "burner" chain is created, which, once it is over, can either be stopped or kept running to enable interesting interactions between subsequent events. The service that we created to orchestrate this is called LaunchControlD, and the chain that it launches is called LaunchPayload.

LaunchPayload

LaunchPayload is a standard Cosmos blockchain packaged in a Docker image with scripts or utilities that provide a standard interface for LaunchControlD to work with. There are two binaries of note:

launchpayloadd: the blockchain node that actually maintains the database and balances and guarantees fair behaviour. To spread responsibility for the event's drop mechanism across stakeholders, the stakeholders must generate their own validator accounts using launchpayloadcli and run this program with their validator account on their own computers.

launchpayloadcli: manages accounts and, when connected to launchpayloadd over the network, provides an interface for apps like the Eventivize Drop App to query and post transactions.

These programs can be run on different computers as well, although the computer running launchpayloadd should have launchpayloadcli to provide the validator account.

LaunchControlD

LaunchControlD is meant to be continuously run on a server, waiting for new requests to spin up new chains. Such requests can come in through the HTTP REST API or command line interface.

The request contains the stakeholders’ email addresses, the currency in question (always a "drop" in Eventivize's case), and the initial balances of each account.

Here's what an event request looks like in YAML:

---
owner: "owner@email.com"
token_symbol: "drop"

genesis_accounts:
  -
    name: "alice@apeunit.com"
    genesis_balance: "500drop,1000000evtx,100000000stake"
    validator: true
    faucet: false
  -
    name: "dropgiver"
    genesis_balance: "10000000000drop,10000000000evtx"
    validator: false
    faucet: true

LaunchControlD will then start as many virtual machines as there are validator accounts, invoke LaunchPayload to randomly generate the validator accounts and additional configuration, copy the configuration to each virtual machine, and tell the virtual machines to run everything.

The virtual machines may be deployed on the same machine as LaunchControlD (virtualbox) or provisioned elsewhere on any cloud service supported by docker-machine.

The astute reader may realize, "wait a minute, doesn't he who controls LaunchControlD have total control over the validator accounts, and thus, ownership of the event reward mechanism itself?"

Why, yes. Yes indeed. Evil smile.

Given our target audience (event organizers who don't care so much about the technical details), the overall unproven social effects of introducing a token into an event, and the delays that signing the genesis state and transmitting it back and forth between the event organizers, partners, artists, and even merchants would cause, we decided it was a worthy tradeoff.

An obvious improvement would be importing validator accounts generated by stakeholders, and creating a mechanism for these accounts to sign the genesis transaction together before making an event request. Should an event result in a particularly long-lived asset, a link to a more permanent chain could be established with IBC.

Conclusion

LaunchControl and LaunchPayload are still in their infancy, and there are many opportunities to improve. This is a first step to empower event organizers to build their ideas on top of decentralized technologies based on Cosmos SDK, making the power of Cosmos available to a whole new user group.

We at Unit 8 see opportunities in using burner chains, perhaps with custom Cosmos-SDK modules, to ride the current trend of decentralization, exploring exciting new social effects that arise from tokens that can be plugged into the crypto financial system.

Build a demo dataset for your product

Andrea Giacobino — Wed, 17 Jun 2020 10:42:14 +0000

I am working on a new product (btw it's name is VALIS) and we needed a fake dataset to showcase the product and it's functionalities, here some suggestion if you have to do the same¹

Start from a real world scenario that you know and you are familiar with

Faking stuff is hard, better to stick with what you know and experience directly: take the data from your personal or work life and use to create the canvas for your demo dataset, next you'll replace names and other details.

Make it familiar for your audience

Who is your audience? Are they young? Is gender relevant? You probably already have a good idea about that if your are building a product, keep this in mind when choosing the actors in your dataset.

Keep it as straightforward as possible

The goal of your demo dataset is to showcase your product, not your demo dataset, try to make evident what is what: for example, use well known identifiers for companies (LLC, Inc, ...), locations (City, Lake, ... ), projects, etc.

About using existing brands

Trademarks are a complicated issue, it may be fine to use existing brands or it may not, treat with care. When not sure, don't: better to avoid to recreate your demo and material because of trademark infringement.

The holy grail: tailored demo data

Can you think of a way of generating tailored demo data? maybe processing publicly available info from Wikipedia, GitHub or Crunchbase? Then go for it, showcasing a product using your client data will be way more effective than using unknown or fake data.

What about well known dataset?

It depends, well known for who? If your are not 100% sure that your audience is familiar with a topic is safer to assume that they are not.

And since your are here, check out VALIS!

it doesn't apply for every type of project 😉 ↩

From HackMD to PDF

Andrea Giacobino — Sat, 09 May 2020 08:42:49 +0000

Full disclosure, I'm a big fan of Markdown, and also a big fan of HackMD (and it's community fork CodiMD).

Now imagine you have to write a technical assessment or specifications and you started writing it down on hackmd/codimd because, you know, reasons 😤. But then, for the sake of the argument, let's say that you have to produce a deliverable artifact that can be shipped to someone, like a customer; then a link to a online document might just not cut it 🤔.

So what to do? Alright, easy solution, fire up typora (or similar), paste the markdown, File > Export > PDF. The day is saved.

You go back skimming through the news and you find this: Writing a Book with Pandoc, Make, and Vim

Wait a second... what if... 🤯 vim Makefile

AU_HACKMD_CODE  = bfScafhcTdGzzhJ4B3evlQ
AU_FONT         = NeufileGrotesk
AU_FONT_DIR     = $(HOME)/.fonts/NeufileGrotesk
AU_OUTFILE      = $(HOME)/$(AU_HACKMD_CODE).MD.$(shell date +%F).pdf
AU_FORMAT       = article

hackmd2pdf:
    @echo format doc
    curl -s -L "https://hackmd.io/$(AU_HACKMD_CODE)/download" -o /tmp/$(AU_HACKMD_CODE).md
    pandoc /tmp/$(AU_HACKMD_CODE).md -o $(AU_OUTFILE) \
  --table-of-contents \
  --pdf-engine=xelatex \
  --highlight-style=monochrome \
  --number-sections \
  -H $(HOME)/.config/apeunit/header-$(AU_FORMAT).tex \
  -V 'mainfont:$(AU_FONT)' \
  -V 'mainfontoptions:Extension=.otf, UprightFont=*-MediumExtended, BoldFont=*-BoldExtended, ItalicFont=*-MediumExtendedItalic, BoldItalicFont=*-BoldExtendedItalic, Path=$(AU_FONT_DIR)/' \
  -V 'fontsize: 12pt' \
  -V 'papersize: A4' \
  -V 'urlcolor: blue' \
  -V 'date: \today{}' \
  -V 'documentclass: $(AU_FORMAT)' \
  -V 'geometry:margin=3.8cm'
    xdg-open $(AU_OUTFILE)
    @echo done

make hackmd2pdf HACKMD_CODE=bfScafhcTdGzzhJ4B3evlQ

BOOM!¹²

Now, I do understand that from a pure aesthetic point of view this might not be enough to satisfy the sensitive eye of the graphic designer, but it can be shipped!

some dependencies need to be installed, on ubuntu texlive-xetex and pandoc ↩
this command will not work for you, because it contains specific branding stuff from Ape Unit, but if you are looking for a simpler one, look no further! ↩

GitHub is now free for teams 🤔

Andrea Giacobino — Tue, 14 Apr 2020 21:59:46 +0000

Today GitHub announced that you don't need a payed plan anymore to have private repositories for teams.
That is a big announcement and the first thought goes to the competing service, GitLab, that has been offering the same since the very beginning.

But this is somewhat also an interesting announcement that might have implications for the open source movement in general. Of course this is just a pure speculation, but anyway let's roll with it.

I think GitHub has been one of the organization that made the "Free for open source" business model popular. The "Free for open source" model works like this: you can use our service free of charge and we get back advertisement and feed our WOM marketing. Now developers (and companies) tend to be jealous/shy/protective toward their code, but they are also a pragmatical bunch: subscribing to a payed plan for my weekend-long side project or my hello world flutter might not be something worth doing.
But one thing about open source is that, like most thing, is a quantitative issue more then a qualitative one: once you get used to have your stuff open source, it becomes quite liberating (and, who knows, could even help you land a job). We can say that GitHub with its model has, at the very least, encouraged and promoted the open source software experience.

Microsoft on the other hand has historically been the fiercest enemy of the Open Source Movement. Microsoft, since 2018, owns GitHub, and, with this last move, if you are one of those suspicious people, you might think that they kind of want you not to think too much about all this OSS business: get your free proprietary repository and off you go.

Also this.

A pensar male si fa peccato, ma spesso ci si azzecca. - Giulio Andreotti