MobyMask is the first demonstration of a new crypto primitive and the kinds of interactions it makes possible: Delegatable, which allows any contract to easily enjoy webs of off-chain invitations and invocations, with on-chain redemption and revocation for enforcement.

You can watch a video presentation of MobyMask here.

“All men live enveloped in whale-lines. All are born with halters round their necks; but it is only when caught in the swift, sudden turn of death, that mortals realize the silent, subtle, ever-present perils of life.”  — Herman Meliville, Moby Dick

The internet today is not unlike the oceans of 1800s Nantucket, where those that “reside alone and riot on the sea” slaughtered masses of whales for great fortune. Now the sea is our social media feeds. Simply send a Tweet with the word “MetaMask” and you are met with a different type of phisher, likely a bot sporting a familiar-looking username like @metamask095 or @RealOfficialSupp0rt.

Phishing has gotten so bad that now 80% of all tickets MetaMask receives through its support are users reporting phishers. MetaMask maintains our own phishing list and warns users when visiting reported domains, but we struggle to keep up with the influx of reports, and the social platforms where phishers roam free are failing to solve this issue.

What if we could harness the power of the community that is already reporting scammers around the web every day? Better yet, what if we could label these fake accounts so that the next person doesn’t get fooled into thinking they are interacting with an official support handle?

For this year’s ConsenSys Cypherpunk Hackathon, I decided to take on the phishers with a project I’ve called MobyMask. Unlike the singular Moby-Dick, MobyMask becomes more powerful as more people join to form a web of trust using a new solidity library I made called Delegatable. Delgatable lets you sign off-chain messages that grant powers to other people. These powers are non-transferrable (dare I say soulbound?). New members are able to invite other members to report, and all reports are transparent enabling accountability via a single revocation that can disable all invitations by a suspect member.

It doesn’t look like much, but it does a few things that no other web3 dapp is doing today.

With MobyMask, users can report phishers by entering the accused Twitter handle (more types are easy to add). You can also declare others to be definitely not phishers, and you can also grow the network of phishing reporters by inviting people you trust, by generating an invitation link. All reporters can invite additional reporters, and all invitations can be revoked, which will cancel all memberships that were previously invited by the recipient, and invalidate any of their outstanding report messages.

The idea is that we can spread the right to report as widely as we reliably can, keep the system transparently accountable, and allow countless phisher detection strategies to aggregate together into a shared database. I believe this could lay the foundation for the most responsive phishing detection system in the world, because it can incorporate any number of strategies, allows instant reporting, while also retaining perfect auditability and accountability.

These phishing reports are easily validated off-chain, and so while the system is controlled by  an on-chain registry, we can maintain an arbitrarily large off-chain phishing list with no transaction fees, and caching their values, and cross checking them against the chain for revocations periodically.

That’s right: Users could store these phishing reports so we could have a p2p anti-phishing network with virtually no transaction fees. The blockchain only becomes necessary when a user wants to revoke one of their invitations but is concerned about having that revocation censored by someone in the network. This is very similar to patterns known as verifiable claims or Decentralized Identifiers (DIDs), but with an anchor of trust on-chain.

Not only are all the phishing reports useful off-chain, but the reports are also batchable, it’s easy in the UI to queue up any number of phishing reports in a single transaction, which makes it cheaper to prove your reports, since they are all validated with just one signature.

Since all of these reports can be off-chain and batched by users who are invited with a simple invitation link, I was finding the wallet connection to be too large a burden to put up front on a newly invited phishing reporter. Since the whole point of this project is to rapidly distribute a responsive phishing detection network, any hurdle was one to eliminate.

To postpone wallet onboarding until a wallet is actually required, I made an onboarding library I’m calling LazyConnect. It wraps the couple of buttons that actually require the blockchain, so that users are able to do as much as possible before they get a wallet, backup, or any ether for transaction fees.

It’s not too pretty yet, but it has CSS classes for easy customization, and it can allow many users to never need a wallet, or postpone getting one until they have a better reason to. I felt like this was even more important to make possible with the Delegatable framework, since it makes it so easy to create invite links and MetaTransactions, enabling far more user experiences without needing a wallet in the traditional sense.

In today’s proof of concept, a wallet is needed to revoke invitations and also to submit reports, but by creating “phishing clients”, we could eliminate the need to submit every report on-chain, and then a wallet would only be needed to revoke invitations, and even then there would still be a possibility for someone to subsidize those reports since all actions in MobyMask are MetaTransactions (and can be submitted by someone else paying the gas).

The project isn’t quite ready to be useful for stopping phishers just yet. We’re also going to need:

• Systems that draw from the database to help warn users faster.
• Systems that make it easier for users to report in the context where they encounter phishers.
• Systems for auditing outstanding phishing reports, facilitating conflict resolution (Someone you invited is in a disagreement! Review and revoke if needed, or your membership could be revoked!)
• Ideally we would integrate reporting & new member invitations all over the web.

In the case of a dispute in this system, I suggest we help users see when someone they’ve invited has made a report that is in conflict with someone else’s report, and make it easy to review that conflict and revoke their invitation if they disagree. The incentive is to act quickly, because if someone who invited you reviews the same conflict and finds your invitee in the wrong, it could be your invitation that’s revoked!

We also have multiple opportunities for optimizing the underlying tech.

Here’s a diagram of the libraries and tech involved in the current MobyMask proof of concept:

With a bit more work, we could make self-hostable MobyMask clients that aggregate these off-chain phishing reports and gossip them, allowing the phishing report network to grow without needing most reports to go on-chain. The blockchain becomes an anti-censorship insurance policy: The only things that definitely benefit from it in this system would be publishing revocations that are otherwise being censored from the network. Besides that, it’s not unlike a verified claims system:

Longer term, here’s what it might look like to have a version that might be lightweight enough to be fully peer to peer, using local counterfactual forks of local Laconic Network light clients for caching just the relevant data from the blockchain:

Beyond that, we should also allow users to subscribe to any number of “roots of trust” for phishing reports, and other kinds of metadata, too. Phishing reporting is a huge deal, but is also just a first use case for building out the infrastructure to enable the Delegatable pattern.

If you’re interested in Delegatable framework that I used to build this system, I’ve published a blog post about it more specifically here.

If you’d like to join me and help build this out, we’re hiring.

edition://0xD7640b32F4b91BbF498B4cC686B6B7C2e82B84cB?editionId=0