We need an end to dating apps that’re swipe-fest interactions with black-box matching engines.

Modern dating apps are centralized as hell and have an incentive to keep people single and on the app’s subscription via a black-box matching engine. It's also very tiresome for users to endlessly swipe or tap through pictures of strangers. Another problem is that users have to expose their dating profile to hundreds or thousands of strangers, while somehow making it personal enough for a prospective match to see a potential connection. Furthermore, these points can lead to single people to portray a less-true version of themselves online in order to market themselves better for the algorithms, not their natural image or personality - ultimately causing lower long-term success rate of relationships leading from app matches.

Our app, Wingman, has increased privacy. It keeps all profile details confidential during the matching process until the final moment, only exposing an absolute minimum set of data required for matched persons to make contact at the final stage. It’s also far more transparent as the matching method is open source.

There are also better chances of relationships developing long-term as matches are suggested through real life ‘pre-vetted’ opinions from wingmen’s more genuine, objective, honest representations of their single friends instead of the singles marketing themselves as what they think the world wants to see instead of their natural self. Social onboarding ameliorates this dishonesty.

Our app also causes a long distance social network effect, it makes it easier to find vetted matches through greater degrees of freedom than a person’s (wingman’s) immediate social circle.

User Perspective Overview: Our app users are termed 'wingmen' and are responsible for adding profiles of their friends who have a single relationship status (‘singles’) into the app via an onboarding form. They meet their friend in real life and fill in the form together or on their behalf. The singles’ basic details about themselves (we call these ‘properties’ such as height, weight, age) and a contact email are collected. The singles don’t ever have to touch the app. The single’s preferences of any potential matches' properties are then also recorded, and also to what degree of importance each preference has. There are 4 degrees of preference: ‘Must have,’ ‘can’t have’, ‘preferably yes’, and ‘preferably no.’ The first two are hard filters for causing match failure. The latter two add to increasing or decreasing match-scoring respectively in the matching algorithm. There is also a ‘no preference’ option for each property. Once the wingman has onboarded all the friends they wish to, the collection of singles becomes their ‘inventory.’

At this point, a wingman bumps into another wingman in real life with the app, they scan a QR code to connect. Through 1st, 2nd…N degree connections between wingmen a social graph develops. Note the connected wingmen cannot directly see each others’ inventories. After connecting with other wingmen, a wingman clicks on ‘manage friends’ to search for matches for their inventory. This causes all their inventory combined with all inventories of their connected wingmen network to be sent to a secure compute environment where a matching algorithm executes on the sent profiles. The details of any matches from other singles in their wingmen network are returned, but they do not receive profile details of singles that are not a match.

The wingman can then finally share the contact details (email) of the match with their single friend, for peer to peer messaging to occur outside our app.

Solution Overview: Fully decentralized mobile dating app that uses ICP as an intermediary backend and SGX for a confidential matching engine to compute matches for users without compromising profile information of users to everyone. Inputs are encrypted with an attested SGX public key, and are only decrypted inside the enclave during the matching process.

ICP stores three hash maps: (1) The encrypted profiles of all singles added globally by all wingmen on the app (2) The social graphs of connected wingmen created via their QR invites (3) The friend invites (QR codes) for each wingman.

We use ICP permissioned database for hash maps, ICP reverse gas for using the backend, and we use ICP HTTP API as a ‘free RPC’ essentially.

Data Flow:

Upon signup, a referral code is added to the third hash map for that wingman user. It is updated/regenerated after each successful wingman connection using ICP randomness.

When a wingman completes filling in the onboarding form for each single friend, that data is encrypted with the SGX public key and sent real time to be stored on hash map 1 in ICP.

A wingman clicks ‘find matches’ for a single friend selected in the app, this sends the backend an instruction to execute the matching algorithm combining data it already stores in hash map 1 and 2. This gives the algorithm a subset of singles that spans all their inventory and inventory of wingmen they 1st degree connected with, and inventory of wingmen they 2nd degree connected with, and ones the 2nd degree connections in turn connected with, and so on until N-degree… . All profiles are encrypted with the SGX public key, so the profile data can only be read inside the secure enclave.

Only basic details are returned to the wingman for any matches found: first name, initial of last name, and a contact email. This is a minimum set of info for the single person to make contact with the match. The single person uses their own messaging system to reach out as this app is p2p.

Why ICP? Internet Computer lets us have a decentralized permissioned database without any gas! This means that we don’t even store the encrypted profiles, they are shared from client to client using ICP as a backend. Why SGX (enclaves / verified compute)? We deployed a Vultr baremental with SGX enabled, this reassures users that their profiles cannot be viewed by us or the public, and can only be used in a very restricted domain (ranking profiles when matching single people).

What can we ONLY do with ICP?: It's the randomness for QRs, it's the privacy for the permissioned on chain database, the HTTP proxy (basically a free RPC), and it's the reverse gas which is exclusive to ICP in our use case.

We use EGo as a framework for building confidential applications using Intel SGX enclaves. It allows us to run Go applications inside secure, isolated environments, ensuring data and code confidentiality.

The matching algorithm is open sourced, and viewable by the public. Most common dating apps we are aware of have proprietary matching engines where the game can be rigged to keep singles in the app for longer subscription periods and make higher profit, unfairly. With wingman it’s fair as the matching assessment is replicable.
The profiles of single-relationship-status-friends are only shared to a matchmaking wingman where there is a genuine high chance match between their single and another single, not to all users of the app to browse. Data only exposed when needed.
Messaging between matched-singles is taken off the app, not gate-kept or centralized to the app creator’s control.
The app is unique because in real life if you know two people that are a really good match and they should meet in your opinion, you just make an introduction, right? The point of our app is you want to get the longer distance connections that aren't so obvious via network effects.

Compromise 1) The name and visual brand design may come across as sounding like it's about ‘getting your buddies laid’ and ‘scoring.’ This is because the word ‘wingman’ has connotations with persons going out to a club to wingman. The team sees a better explanation of the social phenomenon our app tries to achieve more like the Asian mums or the where families are helping their kids out with setting up dates and good matches of their children with other families children within their real life social circles. We had to stick with wingman brand due to the 5 day deadline.
Improvement (1) For now, we expose an email address as a way for matched singles to be paired. Unfortunately this may seem as spam by the single persons when it hits their inbox. An upgrade would be to use a dedicated third party mail service to send emails to matched pairs of single people e.g. from ‘[email protected]’…etc. Therefore it wouldn’t be seen so much as spam email. We could also consider the email coming from the wingman’s email address and both singles are cc’d - akin to a softer intro from a chaperone. We could also display blockchain based messenger service address options instead of email but that limits adoption to crypto natives only if enforced, perhaps it can be optional as part of the single’s onboarding form in the future.
Improvement (2) We haven’t built a wingman-network management section of the app. E.g. for removing existing wingmen to wingmen connections beyond direct connections for whatever reason. We only built the ‘connect with a new wingman’ via QR functionality thus far. ICP’s permissioned database is useful as if a wingman removes a connection to another wingman for themselves, they also get removed from the other wingman’s network automatically.
Improvement (3) We could make the choice to expose attributes contributing to a successful match optional at the discretion of the singles being matched, as a global setting in their app. Makes firstdates intrigin