Skip to main content

Contact Codes™

Contact Codes would make it quick and easy for any individuals or organizations to exchange all kinds of relevant, accurate, contact information. Then, the same service could be used to provide secure login and password recovery.

Solution: We would provide new codes for free through a public site on the web. Contact codes would be relatively short, unique codes, designed to be easy to enter through electronic devices. The codes could come with web addresses to retrieve the associated contact information. The web site would be optimized for mobile devices, and we could also provide mobile apps.

Unlimited Applications: Associated information could include actual name, physical address, phone number, email address, and links to profiles on Facebook, Twitter, Snapchat, etc. It is important that we would not limit the associated information to any specific kinds of contact information. This lack of such a limit would allow these codes to be used for all kinds of contact information, including kinds which have not been invented yet, but will be in the future.

Multiple Contexts: For convenience, we could provide multiple codes for separate sets of contact information (for example, business versus personal, or close companions versus casual acquaintances). That way, users could have fine grained control to provide others with easy access to only the contact information that is relevant within a certain context.

Privacy Note: Contact codes are not intended for securing private information. They are only designed to be used for information that would already be considered public.

Technical Details: Web links would be verified by a verification code. The user would login to the Contact Codes site or app, and add a link to a public web page somewhat under their control known as a channel (such as a profile page on a social network). Contact Codes would provide a verification code to verify that link. The user would use their access to the channel in question, to post the verification code within the content of the page. Contact Codes would automatically check the page in the background, and verify that it contained the code. (HTTPS could also be used in this process, to verify channel).

For offline contact information, a third party service would setup a provider for each type of contact information. The provider would provide a channel for each user. The provider would require the verification code from the user, then the provider would conduct their own offline verification, before adding the verification code to the verified channel. For example, a mailing address provider might send their own verification code by mail, and require the user to enter it to verify the mailing address. A phone number provider might send their own verification code by phone. (These channels could also have REST services).

Also, Contact Codes could have support for one or a very few certain reasonably well established channels built in--such as, perhaps, email addresses.

QR Codes: We could also include associated QR codes (special 2D barcodes) for added convenience, so that users could access the web addresses by snapping a photo of the QR code instead of needing to manually enter the address.

Physical Materials: The addresses and QR codes could be printed on business cards, letterheads, and other materials. We could possibly partner with third party printing services, to help facilitate easy access to physical materials containing the codes.

Online Directory: We could provide a reverse lookup directory so users could use some contact information to find the rest. When a user added a channel, we might provide them the option to make that channel support reverse look-ups. For example, a use may want to enable their real name to be used to lookup their personal profile, but they may not want to enable their Snapchat to be used to lookup their business profile.

Offline Support: We could store copies of the directory of contact information for everyone, on each users' device, so they could access the information while their device was offline, and synchronize to get updates when they come back online. We would find a way to do it that would not take up too much storage space.

Note: Please pardon the usage of some highly technical terminology in this article.

Secure Login: Identification would be provided as a combination of contact information in certain channels. A provider could associate a channel with an OAuth service. (For example, Facebook OAuth provider and associated Facebook Profile). Then, contact code users could choose which channels they wanted to trust for inbound authentication to manage their contact code. Then they could use an authenticated session with a chosen provider to authenticate with Contact Codes for managing the code associated with the validated channel for that provider.

Password Recovery: Besides inbound authentication, secondary channels could be used for password recovery. A user could choose a certain combination of verified channels and verification providers they trust for password recovery. For example, they may require a combination of email address and text message verification, from "Acme Verifications, Inc." Contact Codes would use the providers to re-verify those channels. (When the reverse-proxy in Contact Codes requests the channel URL, it could verify "Acme Verifications, Inc." as the Organization name in the Subject of the validated HTTPS certificate.)

Third Party Services: Contact codes could provide services to third parties of brokering secure authentication and password recovery. The third party could choose which channels and providers they would require. Once a user has established a secure session with contact codes, contact codes could confirm to the third party service (using OAuth) that password recovery or authentication should be allowed. Since Contact Codes would be free for users, perhaps these services is where this product could be used to earn money.


Popular posts from this blog

Shared Project Manifesto Version 2

Contents: Introduction Launch Trade Reward Develop Vote Harvest 1. Introduction IP (Intellectual Property) is a great asset but it is hard to produce well. We hypothesize that a market to facilitate shared projects would make it easy to produce IP better. The Shared Project Model The market contains projects. Each project has one admin and a number of traders and developers. One user can have any combination of roles at the same time. For example, a user may be an admin and also a trader, or a trader and also a developer. Projects Users Admin:  Provides ideas in exchange for control Traders:  Provide incentives in exchange for growth Developers:  Provide IP in exchange for incentives 2. Launch When somebody came up with an idea for an IP product, they could create a project for it on the market. That person would be the admin. The market would record the time the admin launched the project. That lasting record could provide for the admin

Contact Codes Lite™

CCL (Contact Codes Lite™) would be a software product to help people exchange many kinds of contact information much more easily. CCL would do this by providing users with relatively simple contact codes . The users could distribute the codes to many people in many ways. Then, a person who received a contact code could use it to retrieve the original person's contact information through CCL. For example, many people still exchange business cards. Retrieving various information from the cards can be time consuming and error prone, especially when there are many cards. Also, when somebody updates their information, the information from the card is no longer valid. Other good examples for usage of contact codes include: On a slide in a presentation In email signatures On name tags In applications that provide limited space for profile information Whenever you want to provide easy access to many different contact options without listing each The main thing that would make


Directives go in, apps come out.™ An app to get software created without managing developers How it works: Go to AppDirective and become a CodeBoss™ Provide a simple description of your problem to  launch a directive Sit back and enjoy reviewing and approving contributions AppDirective uses advanced technology to get the software developed that you want, without you ever needing to hire a developer. Note: This app is currently about halfway built, at the time this is being posted. We plan to have it completed soon. Until then, please leave a comment or contact us  to become a boss. Q&A: Q: How do I get recognized for being original? A: When you launch a directive, you stake a claim to your app idea on a first-come, first-served basis. AppDirective™ keeps an unchanging public record that you deserve credit for claiming the idea at that time. Q: Does launching a directive protect my legal rights? A: No. Directives do not provide any legal protection

Please Comment

Have you ever heard of a similar idea? What challenges might an idea run into? How might you like to be involved? Comment to add your voice to each idea.