Sponsored Event

In my day job, I’m responsible (among other things) for our efforts to integrate block chain and supply chain. Most of this relies on Smart Contracts. In order to learn more about them, I did a project last year that let me get in-depth.

The idea came about while my wonderful other half was organising a sponsored walk – Museum Marathon Edinburgh. It should be possible to create a sponsored event then manage funds and pledges through a smart contract. Unfortunately, I didn't get the project completed in time but I did manage to build Sponsored Event (possibly my most uninspired project name ever).

This can be used to manage, collect and distribute donations for any kind of charity event – sponsored walk, climb, run, pogo-stick marathon, etc.

No more chasing people for money after the event. No need to worry about how or whether the money makes it to the charity.

This contract also allows cancellation and withdrawal from the event. In that case, the participant's initial sign-up fee is transferred to the receiving charity but any pledges are returned to the sponsor.

Additional information about the event (description, title, images) should be stored off-chain in another database.

I built it almost 12 months ago but just updated it to use the latest version of Solidity. Due to the fast-paced nature of these things, it may or may not still work. Who knows?

---

Web App Structure

The web app uses web3.js to interact with the smart contract SponsoredEvent.sol. It can also interact with a separate content database to keep as much non-critical data off the blockchain as possible.

---

Key Concepts

The Event

An event for charity where someone must complete all or part of something. In exchange someone else pledges to give money to a recipient.

The Recipient

The charity or body receiving the funds at the end. They don't need to do anything except have an account capable of receiving the funds.

The Organiser

The person creating the event specifying the name, date, description and designating the account of The Recipient. This account is the owner of The Event.

The Participant

The person actually taking part in The Event. This person signs up for the event and commits to taking part. They are given a unique URL which The Sponsor can use to pledge money. Participants are charged a sign-up fee.

The Sponsor

The source of the funds. This party has promised to donate money to The Recipient if The Participant takes part in The Event. They can include a message along with their pledge.

Cancellation

If the event is cancelled, all pledged money is automatically returned to The Sponsor. Sign-up fees are returned to The Participant.

Withdrawal from the event

If The Participant withdraws, all money pledged to them is automatically available for The Sponsor to reclaim. The participant's sign-up fee is not returned.

Ending the event

The Organiser can mark an event as Ended. This will transfer completed pledges and sign-up fees to The Recipient.

Retrieval of funds

Once the event has ended, The Sponsor is able to reclaim any funds donated to Participants who did not complete the event. The funds are not automatically returned as The Event may not have enough to cover the transaction fees.

Closing the contract

After a period of time following the end of an event, The Organiser will close the event. This will transfer any remaining balance to The Recipient.

Contract Lifecycle

Each Sponsored Event contract starts when The Organiser creates it and deploys it on the blockchain. From that point, The Participants can sign up and The Sponsors can make pledges.

Source

You can get the source on github and deploy it against a test network or run Ganache locally. Whatever you do, don't throw actual money against it. That would be a terrible idea.

Anyone who knows me knows I'm all about solving problems. That's my thing. There's a problem, here are the facts, here's the solution. It's almost always a technical solution.

So when I was presented with the problem of making it easier to make background music for YouTube videos, I built Harmonious Studio.

Technically, its a good solution – it lets you mix individual loopable instruments into a single track. Behind the scenes, it uses a the Web Audio API to manage the individual tracks in the browser and ffmpeg to prepare the final high-quality download.

The question is: what now?

The original plan was to allow others to upload their tracks and create a marketplace for music – basically positioning Harmonious Studio as "Shutterstock for Music". There are several options for this – monthly subscription for unlimited downloads, fee per premium track, fee per download.

There are a few problems with this, however.

1. Free is better

There is a huge amount of free music available online. Every week there's a post on /r/gamedev where a composer gives away thousands of tracks for free. The majority of responses I got from the feedback form I asked for on Harmonious fell into the segment "Yes, I use background music. No, I'd never pay for it".

2. Good enough is good enough

The idea was that content creators would be able to make music to fit their content exactly. However, getting something instantly for free that almost fits is preferable to making something custom that costs time and money. Kind of obvious when you think about it.

3. If it works, keep it

The other piece of feedback I got from YouTubers was that, once they've found a piece of music that works, they're more likely to copy-paste it into the next video than get a new one. Once they've got 3 or 4 'go-to' tracks, they've got everything they need for most kinds of videos.

---

So... what now?

It's a good technical solution to a problem without a good market. This is usually the point where the insightful entrepreneur pivots and relaunches using the tech in a completely new way. Anyone have any suggestions about how to do that?

You'll have noticed I haven't updated much recently. Even when I did, if was with distinctly non-tech stuff. The reason being I've been busy. Not "I've got a big to-do list" busy or "I've had a couple of browser tabs open for a few weeks that I'll get round to eventually" busy, either. I've got a text-file to-do list that's been open, unsaved in the background since January 2017 and there are a couple of background tabs I've been meaning to get round to reading since late 2014. Really.

What's been keeping me busy?

Easy answer: HERE Tracking.

A couple of years back, a few of us got interested in how IoT devices could work with location. What's the smallest, simplest device we can connect to the cloud and pin point on a map? Within a few weeks, we had a basic cloud and at CES in January this year, we launched a fully-fledged product. In that time, I've moved from 'prototyper who built version 0.1 on his laptop during the Christmas holidays' to something roughly equivalent to CTO of a medium-sized tech company. Not bad.

What's it do?

In essence, a small IoT device with some combination of GSM, WiFi and Bluetooth does a scan to find out what wireless networks, Bluetooth beacons and cell towers are visible and how strong they appear. They send their scan to HERE Tracking where it gets resolved into a latitude/longitude and then saved. The best bit is that it works indoors and outdoors.

Look, we've even got our own shiny video with cheesy voiceover!

And another that shows what it actually does!

There are a bunch of other features as well such as geofences, notifications, filtering, etc. but the main focus is this large-scale ingestion and storage of data.

At this point, our original Tracking team has grown to include HERE Positioning (the clever people who actually figure out where the devices are) and HERE Venues (we recently acquired Micello). By combining, the Tracking, Positioning and Venues bits together, we can follow one of these devices from one factory, across the country on a truck or train, overseas, into another country, into another factory, out into a shop... and so on.

Seeing as both Prolog and CSS are declarative languages, I found myself wondering if it would be possible to create a mapping from one to the other. It was an interesting thought experiment that quickly found itself being turned into code.

Way back when, Prolog was actually one of the first languages I learned to program in. It had been a while since I'd last used it for anything (a chess endgame solver in high school, I think) so I looked up an online tutorial. The following example is derived from section 1.1. of Learn Prolog Now

Simple rules

If you think of Prolog facts as denoting true/false attributes of elements, you can consider every known item in a KnowledgeBase (KB) as a DOM Element. For example:

mia.

Is equivalent to:

<div id="mia"></div>

While

woman(mia).

Equates to:

<div id="mia" class="woman"></div>

You can make multiple statements about an item in the KB:

woman(jody).
playsAirGuitar(jody).

Which is mapped to:

<div id="jody" class="woman playsAirGuitar"></div>

You can then represent these facts using visual attributes:

.woman {
  background: yellow;
}
.playsAirGuitar {
  border: 1px solid black;
}

The only real issue is that CSS values can’t be aggregated. If they could be, you could always use the same attribute (e.g. box-shadow) and combine them:

.woman {
  box-shadow: 1px 1px 0 red;
}
.playsAirGuitar {
  box-shadow: 2px 2px 0 red;
}

You'd want this to render two box-shadows, one with a 1px offset and one with a 2px offset.

Instead, you have to use a unique CSS attribute for each class of facts. However, for the simplest examples, It’s not too complicated...

If you want to query the KnowledgeBase, you need to map a standard Prolog query such as:

?- woman(mia).

Into the a different output mechanism: HTML.

The response is visualised in HTML and CSS using the following rules:

• There is an element with id "mia"
• There is a class "woman"
• The element with ID "mia" has the class "woman"

In the demo below, you can read this by verifying that the #mia div has a yellow background. Done.

Here's the complete KnowledgeBase for the first section of "Learn Prolog Now".

<!-- woman(mia). -->
<div id="mia" class="woman"></div>

<!-- woman(jody). -->
<!-- playsAirGuitar(jody). -->
<div id="jody" class="woman playsAirGuitar"></div>

<!-- woman(yolanda). -->
<div id="yolanda" class="woman"></div>

<div id="party"></div>

And here are the queries that could be answered by looking at the visual output:

?- woman(mia). 
Yes (the element with id="mia" has a yellow background)

?-  playsAirGuitar(jody).
Yes (the element with id="jody" has a solid black border)

?- playsAirGuitar(mia).
No (the element with id="mia" does not have a solid black border)

?- playsAirGuitar(vincent).
No (there is no element with id="vincent")

?- tattooed(jody).
No (there is no CSS style for a class '.tattooed')

?- party.
Yes (the element with id="party" exists)

?- rockConcert.
No (the element with id="rockConcert" does not exist)

View the output

More complex rules

It starts to get tricky when you have rules depending on other values such as

?- happy(jody):- playsAirGuitar(jody)
(“If jody plays air guitar, jody is happy”)

But I think some clever element nesting could handle that.

First, change the structure so that the classes/properties are on parent elements

<div class="woman">
    <div class="playsAirGuitar">
        <span id="jody"></span>
    </div>
</div>

Make properties into divs and entities into spans

Then update the structure of the rules:

.woman span {
    background: yellow;
}
.playsAirGuitar span {
    border: 1px solid black;    
}

Now you can make rules dependent using the cascade. First, add the property:

<!-- happy(jody):- playsAirGuitar(jody) -->

<div class="woman">
    <div class="playsAirGuitar">
        <div class="happy">
            <span id="jody"></span>
        </div>
    </div>
</div>

Then create the rule:

.playsAirGuitar .happy span {
    box-shadow: 1px 1px 0 red;  
}

The rule for happy(jody) will only be true (show box-shadow) if the rule for playsAirGuitar(jody) is also true.

View the output

Conclusion

Sure, it's all a bit silly but it was quite a fun little experiment. There are probably a few big aspects of Prolog that are unmappable but I like to think it might just be possible to create a chess endgame solver using nothing but a few thousand lines of CSS.