As part of the open-source community working to build the future of payments, we here at Ripple Labs believe transparency is the key to our collective success in building a new ecosystem. Everything we do exists to enable and support developers to quickly and easily build on the Ripple protocol. Part of that enablement is knowing what’s around the corner so you can plan accordingly.
We want you to develop on Ripple without lingering doubts about platform changes that may have an impact on your project, so to that end we’d like to provide a quick overview of the features our engineers have been hard at work cranking out.
Exact release timing for these features is still to be determined, but it’s soon. You may say, “When is soon?” – we don’t know exactly, but we’ll be sure to announce when they’re ready to go. Many of these features will ultimately be abstracted into APIs that will be readily accessible for testing from the Ripple Developer Portal. Of course, you’ll be able to play around with many of these features through the Ripple Client. Upon release, keep an eye on the blog for technical deep dives by Ripple Labs engineers who built the features.
Also known as “M of N”, the multisign feature promises to unlock a multitude of use cases on Ripple including two-factor authentication, escrow services, corporate governance applications and more.
If a Ripple account is designated as a multisign account, a quorum (number can be set within the client) of accounts must sign a transaction before it can succeed. Each signer can also be provided with a set weight in the event that some sign-offs have more significance than others. Similarly, multisign can be applied for voting yes or no on transactions that need to achieve a quorum.
On the ledger, there will be a Signer entry that specifies the signers of the multisign account. Each of these signers will have an associated account and weight that will be used when determining whether or not quorum has been achieved.
Services are of particular importance to gateway operators, as they can connect inbound/outbound bridges, merchants, and hosted wallets to Ripple clients. Outbound bridges allow funds to be sent to entities off of the Ripple network by associating an external account identifier with a user’s Ripple wallet address through use of the Federation URL.
Currently, the most common outbound bridges are used to send bitcoins off of the Ripple network. To get money out, gateways can configure an Outbound Bridge Profile that includes information on where the money is going.
The manifest provides crucial information about the service to clients, including the profiles that are supported. While the manifest is providing a description of the service (what it’s called, what it does, etc.) various profiles actually handle communication amongst clients and services. There are profiles to get account details, transaction histories, submit payments, and more.
We can’t wait to see beautiful collaborations between service providers and new clients. These interactions are the building blocks of an open and evolving payment system so don’t hesitate to share what you’re working on in the comments.
In our next episode, we’ll share some details on Peer-Assisted Key Derivation and Smart Contracts. See you next time!