Spells

From Zach’s GitHub site .

Overview At a recent discussion of adding **Sessionless** to the Signature Plugin of the federated wiki, the topic of using this signature system as a sort of Smart Contract. This spawned a lot of great discussion, which I'll first summarize here, and then offer some thoughts on how MAGIC could be used to enable the desired behavior.

First, what is a smart contract? Well a **dumb contract** is one whereby two humans and/or groups of humans agree to perform some action, which when completed results in some transaction. The performance(s) of the action(s), and the subsequent transaction, are **enforced by the law** of the land, and, I suppose depending on your feelings about lawyers, that's what makes it dumb.

A smart contract supplements this legal enforcement, with **automated processes** managed by computers. This makes it "smart," because computers don't have millennia worth of branding problems like lawyers.

We have demonstrated that the signing of the contract in the first place is possible on the federated wiki (the code for this is incomplete, on this **Planet Nine ** fork of the plugin: WardCunningham/wiki-plugin-signature@master...zach-planet-nine:wiki-plugin-signature:master github github . So the next steps are how to establish the **action(s)** are performed by the signatories, and that the subsequent **transaction** is performed.

Let's consider a reasonable example from existing use cases for people, that of an **online marketplace**, which enables the transfer of physical goods.

MAGIC has three kinds of participants for a spell (if you're unfamiliar with these terms in this context, here's the quick hit:

Some terminology. In a moneyed interaction, this flow could be called a transactional pipeline, but since MAGIC enables this flow when nothing is actually exchanged, a broader term is needed. And since I want to stay on brand, let's call it a Spell.

The initiator of a spell is the Caster. The first receiver of a spell is the spell's Target. The server that authenticates all the messages is the spell's Resolver. The intermediaries (of which there can be an arbitrary amount) of a spell are called Gateways. > Targets are gateways. > Resolvers are gateways. The response to a spell is its Effect. Effects may affect any number of the gateways involved. Effects always modify something in either the caster, the target, or both. ): the caster, gateways, and the resolver.

The actions

In the call where we were discussing this, we talked about how when establishing **trust** between two participants on the internet, a **third party** is needed. In the case of https, the third party is a too-centralized shadowy org called letsencrypt . Though MAGIC wasn't focused on providing a global mechanism of trust, this is the **role that the resolver plays**. The participants in a spell don't "know" about each other, and thus don't trust them, but they all do **trust the resolver** to know about all of them and provide sufficient trust for the spell to resolve.

So in thinking about how to adapt MAGIC to this smart contract use case, I think the missing piece is how to join two (or more) spells resolutions together as the signatories would each need to be casters, and the resolvers that they know and trust may be different.

The first question, I want to table to a second issue. The blockchain implementations of smart contracts have a shared state to read, the blockchain itself, and thus changes can be reacted to with every minted block. My hunch is that whatever state mechanism an implementation of these contracts have will need to be somewhat case by case rather than generalized, but some more thought is required.

For the second question, one trivial approach I think would be to just have the signatories become resolvers themselves. The contract itself serves as an establishment of trust, and can define to the signatories how to communicate to each other that the required action(s) have been taken. Gateways can be added to the spell chain in order to verify that trust. To come back to our example, a signable token can be passed between devices and sent to the resolvers when the participants of the transaction meet in person to exchange goods.

This picture looks like this:

The transaction

This seems pretty reasonable for the verification of the action(s) of the contract. For the second part, the transaction to complete after the action(s), there's one more step. I'll use money here because it's the simplest example, but the mechanics are the same for other things. In order to facilitate the transfer of money from one party to the other, both parties need to have accounts tokenized with a common business account and payment processor (unless you are the payment processor...).

The service that handles this in the Planet Nine ecosystem is called Addie. The key is that the transfer needs to be signed by the transferrer, otherwise bandits can steal your money. But Addie, and payments themselves interestingly, do not establish trust between the transactors, they establish trust between the payer and the financial system, and give the payer recourse if the transaction goes awry for any reason in the form of chargebacks. And similarly built trust for the payees that they're part of a reputable system by booting bad actors from the platform.

With this in mind, I think it's sufficient for the signatories to negotiate which transaction service they agree to as part of the contracting process. This may be as simple as "we'll use Addie located at gimmeyomoney.com," or something more complex.

The question was asked as to why we should trust the escrow of the machines in this system over more traditional methods of contracting. It's a good philosophical question, but one that I think is beyond the scope of the technical process discussed here. Given human's propensity for putting their faith into random nonsense, introducing computers into the transfer of used air conditioners seems somewhat innocuous.