Whether meeting new contacts through a call, a text, an email message, or in-person, they often fall through the cracks because we don’t bother to create a card for them in our address book or CRM. But even if we do, here’s how most cards typically look like.

Why such pitiful cards?

Because creating a card by typing or scanning it, is tedious, laborious, boring, frustrating, error prone, incomplete, inaccurate, inconsistent, conflicted, duplicated, isolated, and most of all, disjoint creating a perceived digital connection when actually there is none, causing painful synchronization and data integrity nightmares which have been lingering for decades. Many have tried to solve these problems which affect everyone but failed because they reinvented the same wheel with the same flawed centralized database architecture when a network architecture is inherently required.

Besides, why should you even be allowed to create somebody else’s data??!! The best practice is to allow you to just use somebody’s data after you requested it, and after it was granted to you by its owner (your new contact).

You meet someone at a café. You decide to hook up. So, you try to exchange your respective contact information with your new contact. She yells her phone number to you while you are typing it so that you can call or text her in order for her to get your number. Since you wish to hook up with each other, you both create a card of each other in your respective address book on your smartphone. After this herculean effort, you now think that you are connected with each other, but are you??!!!

A month later, she changed her number because her phone got hacked. You want to call her. Oops!!! You can’t because she didn’t bother to alert her contacts, including you, about her change. However, you all of a sudden remember that you are connected on LinkedIn. You also remember that LinkedIn announced their “latest & greatest” synchronization utility with address books. However, their synchronization works only with Outlook for the time being (Microsoft being their parent) and you use Apple Contacts app. Nonetheless, you go to her LinkedIn profile, and to your dismay, you realize that she has not updated her phone number in her LinkedIn profile. So, even if you had Outlook, LinkedIn new integration with Outlook wouldn’t have helped you anyway.

The reality is that you are not digitally connected with her. Your address book and hers, including your LinkedIn connections, all live in their own silo. They are all disjoint objects.

That is the sad story about Contact Management that has been lingering for decades regarding the lack of data integrity in our address books, CRMs, social networks, and any other application or form that uses contact information.

What is the solution?

A Web3 Distributed App (DApp) with a comprehensive profile from which you can:

• Build a virtual card for every one of your personas like a dating card, a personal card, and a professional card.
• Every card is not limited to just contact information like printed cards, but includes a slice of your comprehensive profile that defines and characterizes one of your personas.
• With just a click, you can share one of your virtual cards with a new contact, granting access to the information defined in a Smart Contract that establishes your connection with that new contact.
• Like updates to mobile apps on your smartphone, changes in your virtual card will be automatically downloaded to all your contacts - no synchronization is necessary. Unless you wish to disconnect with someone, you and all your contacts are connected and automatically updated forever.
• If your relationship changes with that contact, you can change access to certain fields accordingly. For example, you can revoke access to your mobile phone number by: (a) hiding it, which means that this contact can no longer call you; or (b) masking it, which means that this contact can call you but cannot view or share your mobile number with anyone. Now, that’s really cool!!! And that’s the ideal app for Web3.

Demo of the Prototype of the Connect Function