See the Browser Plugin discussion which may be a better way to implement this.

Note: the branding for this idea has yet to be determined. For now, I’m using “Simple Send” as a project code name.

Initiative Committee

@Pawel Mastalerz @David Gold @Luke Stokes @Eric Butz @George Worrell @Kaitie Zhee

Introduction

The cryptocurrency community is fragmented into silos and walled gardens where each solution provider, be it a blockchain, token, or service, has a primary focus to increase their own user base, even if that means stealing users from other projects in the industry. Few have the vision to think beyond “crypto” into the larger world of global finance and the unbanked billions. As a non-profit Decentralized Autonomous Consortia, FIO is uniquely positioned to be a champion for wallet interoperability to make all of crypto easier to help bring about crypto mass adoption.

“A rising tide lifts all the boats.”

Integrating a usability solution can be seen as an overhead cost by product owners. Yes, improving usability is important, but rarely urgent. Improved usability does not translate directly into guaranteed revenue, so it doesn’t get prioritized within an already packed development roadmap. In addition, there’s a decision paralysis involved with selecting a solution among competing wallet naming standards. Picking a loser means wasted resources on an already speculative bet.

Open

What if you, as a product owner, didn’t have to choose? What if you could integrate one solution and get all of them, including new ones in the future that don’t currently exist?

FIO Send (the ability to send cryptocurrency to a human readable address like luke@stokes) is the most basic shared functionality of a human readable wallet naming solution, as noted in previous research. If we start there, additional features can be added in the future. All major wallet naming protocols support a simple lookup for determining a mapping from a human readable address to a native blockchain public address. The FIO SDKs and APIs could be extended or modularized to support these other protocols making our protocol integration much more valuable for our customers while showcasing each solution in one experience for our customers' users so that the best, most useful and valuable protocol can rise to the top. If Simple Send leads to the mass adoption of an alternative to FIO Send, then we still accomplished our Foundation mission to make crypto products easier for everyone.

As one of my previous employers often said:

“If you help enough people, you don't have to worry about money.”

We’ve seen enough shilling for individual solutions within our industry. What will happen when we start working together? What if engineers from competing protocols and wallet naming solutions directly contributed to this project because they care about usability and the end user?

With that said, I do think the FIO Protocol will be recognized as a superior solution due to its additional features such as fee-less native blockchain public address mappings, decentralized private payment requests, contextual transaction meta data, and more to be developed in the future like multisig routing, key recovery, DID integration, Travel Rule solutions, etc.

Who is the Customer?

• Product owners at cryptocurrency and blockchain solution providers with crypto-enabled endpoints and user-facing interactions which include sending cryptocurrency.

What problem of the customer are we trying to solve?

• High risk with uncertain return committing development time and resources to integrating one wallet naming protocol solution among many competing standards with no clearly defined “winner.” Though it may help the overall usability of the industry, there is no guarantee the solution chosen will create revenue for the company unless they are just chasing integration bounties with no concerns of user adoption. They want one integration which supports all wallet-naming protocols that is exist now and will exist in the future.

Why is it important this problem is solved?

• Cryptocurrency mass adoption is inevitable, but the user experience is holding it back today. Budgets are tight, development roadmaps are full, and picking a solution that does not gain wide adoption can hurt your brand.

How will this product/initiative solve this problem?

• A single integration with interoperable support for every wallet naming solution on the market decreases the risk of selecting the wrong solution and increases the value of the development burden required to integrate the solution. It creates a new paradigm of the industry working together to gain new ground instead of just capturing users from each other’s products and services.

What KPIs will you track to determine if you are solving this problem?

• Number of product owners we directly convert to integrating the FIO SDKs and APIs because of this universal approach. We can test this KPI before building the solution by pitching the idea to them and asking how much it influences their interest in committing to the integration.

Proposed Functionality

API

Server side code would be developed to provide an API that can interact with all existing wallet naming service providers such as PayString, Unstoppable Domains, ENS, Cruxpay, and potentially also individual chain specific solutions. This code would be run by the FIO Block Producers as trusted, token-elected validators, but could be run by anyone. This would involve including the ability to make outbound calls from the supplied code to other wallet naming solution providers so that get_pub_address can accept any valid wallet naming string and return a native blockchain public address. By solving this at the API server level, FIO node operators would be able to capture statistical data on the usage of each solution and aggregate it via the Foundation for Interwallet Operability to provide valuable (anonymized) usage data to the industry.

The technical specification for these API calls would be rather straight forward consisting of a single call to look up a native blockchain public address for a specific chain code and token code using a wallet naming string such as “luke@stokes”, “lukestokes.eth”, or “lukestokes.crypto”. The response would include the native public blockchain address or an error.

Native Blockchain and Native Wallet Naming Solutions

In addition to existing wallet naming solutions, Simple Send could be extended to support blockchain and wallet specific naming solutions. An example being Bitcoin Cash’s Cash Account. If there was ever a naming collision between two different native blockchain or native wallet-specific naming solutions, FIO’s domain functionality can resolve the issue. If a wallet (“ACME Wallet”) or a blockchain (“ACME Chain”) had it’s own solution where I could be “lukestokes”, for example, the Foundation could reserve the domains “acmewallet” and “acmechain” and burn their private keys (so no one owns them) so that any Simple Send enabled product or service could still send to lukestokes@acmewallet or lukestokes@acmechain. The domains would remain private so no one can register addresses on those domains and the SDK would have a list of known special domains which indicate their own native blockchain naming solution.

Next Steps

1. Document all the formats for all major wallet naming solution providers for both requests and responses.

2. Design a format that most closely resembles the combination of each, or an adapter pattern that converts between them as needed.

3. Build a prototype.

Risks and Challenges

• As other solutions evolve, we’ll have the extra burden of maintaining our own code SDKs (for FIO) while also keeping our SDK and API in sync with the latest stable version of other solutions. This additional developer burden will require adding new active worker proposals for this effort. Ideally, they could be funded in part by the other wallet naming solution providers who would like to be part of this solution and by industry leaders who believe in our vision and want to support the open source cryptocurrency developer community.

• A security incident in one solution may be interpreted as a security incident in the FIO infrastructure since the FIO SDK/API was involved.

• API lookups have a bootstrapping problem. How can a thin client trust they are accessing the right blockchain data and how do they validate it for integrity? FIO has already been thinking about this problem with FIP 14. We can explore extending his solution to validate other API endpoints as well.

• Some wallet or exchange integration partners may not be interested in including more code that increases their code audit requirements.

• The code quality of other naming solutions is unknown and including it into our integration tooling may introduce security risks.

• The actual technical burden of supporting each solution over time may be much greater than the simple code example demonstrated above.

• The FIO Community and token investors may not agree with this approach and see it as a threat to their investment in the FIO ecosystem which could be seen as helping to support a “competitor.”

• Even with this solution, potential customers to our product may not see it valuable enough to integrate (but, if that’s the case, they most likely wouldn’t integrate FIO by itself either, so we’ve lost nothing).

• Please add to this list! If you’re a crypto product owner, why wouldn’t you add this to your development roadmap?

Future Considerations and FIO Specific Benefits

I (Luke Stokes) would be remiss to not include some commentary about my fiscal responsibility as the Managing Director to the Foundation for Interwallet Operability.

If the Simple Send project is successful, we could move further to support additional features within multiple wallet naming solutions as described previously. As a modular SDK, Simple Send would have in it, as optional modular additions, the ability for integrations to start including additional functionality, even FIO specific functionality. As the SDK is already built into more products and services, we can introduce to those teams the revenue sharing potential of onboarding users to FIO either through our dapp (very easy) or through a direct integration. This is the beauty of a decentralized business model running autonomously on a permission-less, globally distributed blockchain.

The PR value of Simple Send can’t be understated. This is what the industry needs, and I think the media will respect that. This won’t have to be positioned as “FIO Simple Send” or something specific to “us” or “our” tribe. This is a story about the whole industry coming together to do what’s required to prepare itself for mass adoption. As major industry players like PayPal or Venmo include support for cryptocurrency, if they provide lookup APIs, Simple Send can include those too. With each new entry to the market, this solution grows larger and overcomes the network effect. Everyone wins.

Collected Feedback from Wallets on the Concept:

[moved to google doc]

Related Initiative: https://fioprotocol.atlassian.net/browse/WP-86

Collecting feedback here: https://docs.google.com/document/d/1T-BTrtm1f7V6l-cjPLyZoNYZ2lMVMYXnKWi711-4ZRs/edit#heading=h.7887nlarvhb