Interledger 2020

DISCLAIMER This is an opinion of just an individual and it is not a representation of the community. I don’t write much about Interledger itself here, so please refer to interledger.org for more detail. Also, I’m not a native English speaker so there might be some strange expressions or wrong grammar. Please just forgive me and please point it out by comments.

Motivation

Recently I have been contributing to Interledger.rs which is an implementation of Interledger Protocol written in the Rust language. In the #rust channel1 of the Interledger slack, Rust 2020 became a topic. The thread comprises of many articles that are written by people in the Rust community, describing what they think the Rust language and the community should be in 2020.

Here, I try to write my vision of Interledger 2020, which describes what I think we’ll need in 2020 to expand the Interledger throughout the world.

My Interledger 2020

As my conclusion, the following is what I think is the most important in 2020.

  • Fiat currency gateways that application developers can easily use the Interledger network via.

I’ll explain what it is and why I think this is important as follows.

Our Goal and the Gap

As we all know, our ultimate goal is to connect ledgers all over the world and make payments universal. Although some of the early adopters such as Coil, Puma Browser, etc. are using the Interledger already, that idea has not been realized completely yet and payment systems are still siloed each other. Really unfortunate.

Let’s think about why. Is Interledger still just an idea? No, we already have the core protocols and practical implementations such as Rust, Java, and JavaScript (TypeScript) although we might need to improve some of these2.

So the possible reasons might be:

  1. People don’t even know the Interledger.
  2. People don’t understand what the Interledger and its value are.
  3. People have difficulties in adopting the Interledger.
  4. People don’t dare to adopt the Interledger.

I think 2 is not a big part of the problems because even if they have difficulties in understanding what the Interledger is, once they understand it, they would agree that the universal payment method is a good idea. Actually, I have seen many people saying: “Wow, that’s great”.

So the problems might be 1, 3 and/or 4. If there are difficulties in adopting the Interledger, advocating enthusiastically would be in vain because they eventually would not be able to build something upon the Interledger. We must understand what is the difficulties and remove the obstacles first of all. Apart from that, we should dig into the reason for 4 as well.

Also, we have to clarify who the people are. It doesn’t mean actual users that send or receive payments on the Interledger network. It means developers and I think there are two types of developers.

  1. Application developers
    • People who want to build applications that utilize the Interledger payments.
    • They might NOT want to operate Interledger nodes on their own.
  2. Gateway developers or operators
    • People who want to integrate their ledgers to the Interledger network.
    • People who want to provide scaffolds to the Interledger network.

Depending on the type of developers, the difficulties would differ.

Breaking Down the Gap

Application Developers

So what makes building applications upon the Interledger difficult? I think it is that application developers don’t want to operate interledger nodes on their own. Although we have tried to improve the experience, running nodes still requires a bunch of considerations about their local financial laws regarding KYC, AML, etc. Application developers just want to build something, they don’t want to think about complex restrictions and they don’t want to violate the law. So we should split this responsibility into other parties and I would call it gateways that are described in Gateway Developers.

In addition, we have to furnish:

  • super easy to use SDKs
  • decent documents on the SDKs
  • a testnet where all of the implementations are connected

Of course, we have provided and written but it often goes outdated and developers frequently ask us “How to use this? It causes errors🤷‍♂️”. Although we have a testnet of Xpring that is already online today, we should try to bring all the connector implementations there. Also, it seems that providing easy SDKs and documents on it is a high priority of Xpring and I agree that it is the right direction to go. We just need to keep it going and improve more and more to sophisticate.

Gateway Developers or Operators

A gateway is a party that maintains accounts for the actual users of the Interledger network. It accepts connections from the users or their applications and allows the users to send/receive payments. The users would use an Interledger ready wallet application but it is just manipulating accounts on the gateway. So KYC should be done by the gateway operator when creating the accounts and the wallet application doesn’t need to maintain or care about balances, KYC information or anything related to laws. That said, this is what I think it should be. We might have to organize a task force to ensure that running gateways is legitimate or whether there are any other suitable models.

Regarding gateways, we should not forget that what application developers really need. They need fiat currency gateways because everyone wants fiat currencies (I know some people don’t want but let’s just forget the exceptions here). What makes people happy is fiat currencies😂 at least for now even if some people including me believe the potential of crypto assets.

On the other hand, gateway developers might need to integrate their own ledgers into the Interledger network, which means that they have to write their own settlement engines. Writing settlement engines needs a deep and comprehensive understanding of the Interledger Protocol suite and node implementations. Hence we have to prepare nice documents on it but currently, RFCs are defined separately and fragmented so it doesn’t seem easy to grasp the entire structure for newcomers. I think we should refactor the RFCs to be integrated or we should try to provide more understandable guidances. Although we have refactored the interledger.org website, it doesn’t seem sufficient because it is basically a change of the design in my opinion.

Besides, for gateway or node operators, it still involves hardships to run nodes. For instance, they would:

  1. not want to operate Interledger nodes by CLI.
  2. need nodes that are scalable/elastic.
  3. need stable and well-tested node implementations.

We should improve these as well.

Not Adopting Purposely

Although we believe connecting ledgers is helpful, meaningful and makes the world better, some ledger operators or payment system providers might not dare to adopt the Interledger. Why. It is because they are trying to dominate the market? Possibly yes… but let’s imagine that all the players are trying to do so. Holy moly, all the systems will become siloed, which is definitely not what we want.

I’m not so sure what is the best approach for this but at least, we should listen to their opinions. We should talk to them. We should find out what are the matters that prevent them from joining the Interledger network. So I think proactively approaching payment system providers, for example, traditional banks and so forth, is important for us. Actually, I don’t know whether we have tried this, so please forgive me if we already have.

Conclusion

As written above, I explained that the following is what we need in 2020:

  • Fiat currency gateways that application developers can easily use the Interledger network via.
  • A comprehensive GUI to operate Interledger nodes.
  • A scalable and stable node implementation.
  • A legal team to make the Interledger network legitimate.
  • A working testnet that consists of all of the implementations.
  • Comprehensive documentation of the protocols.
  • Conversations with payment system providers, listening to their opinions.

That said, I think the most important part is fiat currency gateways. It could be the initiator of the adoption of the Interledger for application developers. If people become using the applications, more payment service providers would be interested in connecting their ledgers to the Interledger network.

I think it is rather just because we lack the considerations for developers or people; what they want, than because of protocols or implementations.

Please note that this conclusion is based on an assumption that we’ll use the Interledger network for every ledger. I’m not assuming the Interledger is used only for large amount payments like enterprise-level ones.


  1. You can get invitations here. [return]
  2. We might need to improve BTP and some upper protocols, scalability, and stability. [return]
comments powered by Disqus