In 2004 Ryan Fugger conceived the idea for a payment system based on lines of trust between friends. Basically participants would only owe money to friends and have friends owing money to them, but since these trust lines could be traversed in path, they would end up being able to send and receive money to and from anyone in the world, and then they could just clear their debts locally. The name Fugger gave to this system was Ripple (then later a shitcoin was born and bought the name from Fugger, don't confuse the two things). Before 2011, Ripple had some centralized implementations (Like Ripplepay, from Fugger himself, and Villages, which exists today still and has more of a local-community approach instead of aiming to be a global payment system) and a very-much-discussed prototype of peer-to-peer protocol. The protocol was never implemented because no one could solve the problem of the atomic commit in a satisfactory manner. Then Bitcoin appeared and interested shifted (not that the Ripple community was huge, but I have the impression that as Bitcoin got famous people interested in money-on-the-internet started paying more attention to it), that explains why the name was sold: the project was abandoned. Since then, every once in a while some new project popups up again rehashing Fugger's idea, but generally nothing happens (the last one I saw was something called Offst which seems to have a working peer-to-peer implementation). However, none of these projects solve the atomic commit problem.

The Atomic Commit Problem

Alice has a credit line with Bob and Bob has a credit line with Cynthia. Alice wants to send a payment to Cynthia. Alice must "prepare" a payment with Bob, then Bob must "prepare" a payment with Cynthia. Only them both prepared payments must be actualized. How to do that in a decentralized environment? Bob can go offline, Alice can collude with Cynthia and lie to Bob, Alice can go offline. Worse problems and attacks can happen in a longer path.

Bitcoin Lightning Network

The Lightning Network inventors don't seem to have been influenced by Fugger's ideas, but they've came up with something similar with their forwarded HTLCs: on Lightning, Alice's prepared payment to Bob and Bob's prepared payment to Cynthia resolve in an atomic commit, because they rely on a "secret commit code", either the network works and the secret is transmitted from Cynthia to Alice through Bob or it doesn't work and the payment is cancelled. Payments that are left half-committed are impossible because they are invariably resolved on the Bitcoin blockchain, which is public. No mutual credit payment system can do anything like that.

Trustlines Lightning

Since the Lightning Network is a network that is fully functional today, thousands of users, multiple implementations; and Bitcoin is only true money, it makes sense to build a "mutual credit" trust lines network that reuses the Lightning technology and is interoperable with it. By doing so, we not only gain in ease of entry, nice standards to build upon and in a battle-tested software stack with solutions for node interaction and routing, for example. We also gain in that the atomic commit problem is solved.

Mea culpa

Actually no, this is wrong.