On Lightning, Messaging Apps Emerge as Growing Use Case
“Does instant messaging over Lightning have killer application potential?”
Lightning Labs developer Joost Jager asked his Twitter followers this rhetorical when he debuted a demo for his Lightning Network messaging application, Whatsat.
Your average Bitcoiner probably wouldn’t think of messaging as one of Lightning’s killer use cases, at least not before micropayments, streaming payments and the like. For encrypted messaging, they’d likely default to options like Signal, Keybase or Wire.
These are certainly better than mainstream messaging apps, like Facebook’s Messenger and WhatsApp, whose encrypted options are thinly veiled save-faces that don’t offer much material confidentiality. But encrypted messaging needs to go further than privacy, Jager believes; they need censorship resistance too, and this is where Lightning-powered messaging comes in.
“The encryption part is similar, in both systems the message content is private,” Jager told Bitcoin Magazine. “The difference is that there is no central server involved. No single kill switch that could be used to shut down all communications. Or that is used more selectively to deny certain users to communicate.”
Whatsat: A New Approach to an Old Feature
The Lightning Network has supported messages from day one, same with Bitcoin’s base layer. The Blockstream Satellite has been used in experiments around Lightning-driven messages and private text message services have leveraged Lightning payments. But recent tweeks to the protocol now make it easier to attach additional data to a payment and pass it on to other applications using type-length-value (TLV) payloads.
TLV payloads allow people using communication protocols to attach additional, extraneous information onto a data packet. For Whatsat, this extraneous data would be the message that is bolted onto a Lightning transaction.
The update that enabled TLV payloads paved the way for a concept like Whatsat which, alongside censorship resistance, could also make communications more private for end users, depending on how messages are sent or routed, Jager said.
“Chatting over Lightning also makes it much harder to find out who is communicating with whom. It is not required to have a direct (observable) TCP/IP connection between users and there is no central server either that could reconstruct the communication pathways,” he told us.
Lightning-powered messages (or transactions, for that matter) are onion routed, just like information passing through the Tor network. The messages are shunted from node to node, and each node can only identify the node that sent it the information or the node next in queue to receive it.
Now, if one entity runs the majority of the nodes in a pathway then they may be able to unmask the sender and receiver, Jager admitted.
“Privacy and security are relative concepts,” he continued.
In some cases, then, it might be better for users to set up direct payment channels with each other. For example, if a “spy” or “attacker” wanted to deanonymize a user via node surveillance, then onion routing the payment may offer significantly less privacy depending on the route, as described above. In this case, a direct payment channel would be more private. But if the surveilling party were an Internet Service Provider (ISP) and tracking TCP/IP addresses, then onion routing would be more private.
Direct channels could provide absolutely free messaging, however — something that some users might find a negligible benefit compared to potential privacy trade-offs. For instance, Lightning messaging is already a free-to-use service; when one user sends another user a message, they have to attach it to a payment, but the recipient can reject this payment after opening the message (for Whatsat, a return-to-sender message saying that the payment has been rejected serves as confirmation of the original message).
As with Lightning payments writ large, a fee market is likely to develop for this service to route messages when a direct channel is not open. This could be seen as one of the cons, Jager said, but it’s also a trade-off some might be willing to accept for censorship-resistant, confidential communication.
“There is the cost side, but also the benefit side,” Jager explained. “The weight of that is dependent on the awareness of users of the downsides of existing messaging systems. For most people, an imaginary world in which some authority can block two people from talking to each other in real life sounds like scary sci-fi. But it is where the vast majority of the users are at with the current state of messaging in the digital domain.”
Whatsat is currently in testnet, and its source code is on GitHub. But don’t expect a beta from Jager anytime soon. In our conversation, he mentioned that Whatsat is “only a proof of concept,” a side project of his that isn’t associated with Lightning Labs, his employer. It’s his hope that the hobby project will “inspire other people … to start developing” it further.
Sphinx Chat, a Different Approach to the Same Effect
Some developers have begun toying further with Lightning messaging, though not from Jager’s source code, and they’re close to launching a private beta.
Sphinx Chat, for instance, has been in motion for about a year. Project lead Paul Itoi told Bitcoin Magazine that its team cobbled together a prototype for a Lightning hackathon in New York in 2018. At this year’s Lightning Conference in Berlin, it released “a very hacky version to a handful of users on TestFlight,” Itoi told us, but they plan to drop a new beta version in the near future (you can register for the private beta on its website).
The application takes its name from the Sphinx protocol, an upgrade that onion routes Lightning transactions over a Tor-esque network. Whatsat leverages the same protocol to achieve a certain degree of privacy, though it differs from Sphinx Chat in that it will offer free messaging within direct channels in addition to TLV payload messaging. Sphinx Chat is focusing solely on the latter.
“Both are similar,” Itoi told us. “But [Jager’s] is designed to avoid fees since it uses a failed payment to deliver the message. This is currently free on LN. Sphinx inserts the message in the [TLV] and uses keysend to deliver and standard fees will apply.”
TLV still has an extra step to go before it’s production ready for mass messaging, however. For LND, the Lightning instance that Sphinx Chat runs, the team still needs to enable TLV messaging from the receiver’s end; it can receive the data, but it has no way of processing it.
Lightning Labs is tracking and working on the issue on GitHub, but until it is sorted out, Sphinx Chat will rely on specific nodes hosted by Nodl to relay messages (which have been customized to fully support TLV payloads).
“We’ll stay in beta on nodes we’re hosting until those features are officially supported,” Itoi told us.
Once out of beta, though, Sphinx Chat will be totally open-source, he continued. At this point, node operators can establish fee markets for relaying messages, same as with Whatsat. He also sees it as a complementary application to StakWork, a chore app that allows people to complete tasks for sats. For example, workers can be notified and paid through Sphinx Chat
The Future of Encrypted Messaging?
Perhaps the first question that comes to mind with Lightning Network messaging: Why use any of these developments when we already have reliable, encrypted messaging apps?
Jager admitted that this is a definite “con,” since “Lightning is complicated compared to a centralized service.” Additionally, with a decentralized system like Lightning, “it can be difficult to deliver the same user experience that people are used to. An example of this — which is just as valid for payments — is how to deliver a message to a user that is offline.”
Still, there are reasons why someone may prefer Lightning-based messaging options to more centralized alternatives. Because the Lightning Network is decentralized, these options will be more censorship resistant and resistant to service outages that result from single points of failure. Itoi also views this development as indispensable for how it couples payments and communication as a single, permissionless entity.
“The key benefit is integrating the ability to pay and communicate under one identity,” he said. “Our core belief: the privacy and censorship resistance that Lightning provides for payments should apply equally to speech. Using Lightning for chat will accelerate the adoption of bitcoin as a medium of exchange.”
This also opens up avenues for Lightning-powered forums, which would theoretically reduce spam given that, in Sphinx Chat’s case, each message costs something. Chatting also need not be limited to humans, Itoi believes. In the future, he envisions APIs and Internet-of-Things devices sending messages and payments to each other via Lightning (sorry, IOTA).
Like many other burgeoning applications and features being built on Bitcoin, Lightning messaging still has a ways to go. Another question to consider, besides usability, is whether users will be willing to pay to chat. This model is reminiscent of the old days of pay-per-message SMS, though it will certainly be much cheaper. Lightning messaging, depending on how hard it is to route messages, could cost as little as a sat or less.
Still, with the promise of cheap, confidential and censorship-resistant messaging on the horizon (far off as it may be), Jager is optimistic in the future of this incipient use case.
“It isn't said that a Lightning-based messenger can't eventually match the ease of use of existing services,” Jager explained. “There surely is a ton of work to do, but I wouldn't say it is impossible. At the moment, people generally have no problem with existing messaging services … but that is today. The future may be different. Perhaps the existing messaging services change their business model, perhaps some scandal happens in which huge amounts of metadata are leaked … I can't say how this all will develop, but I think it is good to explore alternatives.”
The views and opinions expressed herein are the views and opinions of the author and do not necessarily reflect those of Nasdaq, Inc.