Kee Jefferys:
Even if everyone who's working on Session went away right now, the system would continue to run because there's no central server bills that we need to pay for. The community operates the nodes, they pay their own bills, and then the incentives that are given to them kind of cover those bills that they're providing.

Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. I am excited to welcome Kee Jefferys onto our show today. Kee is the co-founder and the CTO of Session. Is that right, Kee?

Kee Jefferys:
Yeah. Yeah. Technical co-founder of Session. So spinning a few plates here, helping manage the tech team and deciding what the future things that we're going to work on on the technical side.

Eric Anderson:
Super. So Session is kind of a, how would you describe it? A privacy preserving messenger? Is that the best way to categorize it?

Kee Jefferys:
Yeah, definitely. I think that's probably a good short description. I think Session focuses on kind of reducing metadata to a maximal extent, and that's probably what separates it from a lot of the other messaging applications in the market. So that means that we use techniques like onion routing to hide people's IP address when they use Session, and we have some more advanced techniques to really break the link between a user when they sign up for Session and when they start messaging users on Session so that the network and the application doesn't know anything about the users that are using Session.

Eric Anderson:
This is a little personal anecdote, timely for me. My wife never talks to me about software security, but sent me a message saying the US government now recommends that iPhones and Androids don't text each other to use a different messenger, and she was blown away. She was so worried. This feels like this is a particularly important time for what you're working on. Help me understand how you arrived at the urgency of Session.

Kee Jefferys:
Yeah, I mean we've been building Session for quite some time and the network underlying Session, it's like seven years old now, so I've been working on the project for a very, very long period of time. I think it's always been quite clear to me that as we kind of move more of our conversations that we used to have in real life onto the internet, that we need to ensure that the properties that we have when we're using messaging applications kind of closely emulate what we would get when we have a conversation with each other in real life. So that's kind of where Session was started and that was what we were trying to go for.
And I think as the data collection systems and the corporate surveillance, the government surveillance has become more prevalent, that goal of trying to emulate a real conversation that you would have in real life between two people and the privacy properties that provides becomes more and more important as those systems get more advanced and start collecting more data. So I think we kind of started down this route of executing against this vision a long time ago, but it's only becoming more important as the surveillance state grows.

Eric Anderson:
I think Session has kind of become more thoughtful about this than maybe others. Some people are just like, "We should decentralize everything. That's the answer." Some people are like, "Well, actually there's benefits to centralization." And I feel like you've understood the trade-offs of when to centralize, when to decentralize. Can you articulate for us what you've arrived at in terms of what's the best of on the spectrum of centralization?

Kee Jefferys:
Yeah, I mean we're working off a lot of prior work here. So obviously Session is not the first messaging application that has tried to create a decentralized network or create a peer-to-peer architecture. Before us, there are a lot of messaging applications. Off the top of my head, I'm thinking of Bitmessage or Tox or Ricochet. These are kind of messaging applications that most people would've never heard of because they're more kind of experimental architectures. But I think a lot of what those messaging applications got wrong was that they didn't have a sense of long-term storage in the network. So if you are using a purely peer-to-peer messaging application, basically both users need to be online at the same time to message each other, and that from a user experience perspective is really not great because I want to be able to send a message to you and if your phone is off or you're not online at the time, that you can still, when you open your messaging application, you get the message that I sent you.

Eric Anderson:
There's no asynchronous communication, just synchronous.

Kee Jefferys:
Exactly. Yeah. I think that's where Session thought, "Okay, how can we design something that provides that asynchronous messaging but also is decentralized in its construction?" So that's where we have this idea of kind of swarms, which are these, there's this network of 2,300 nodes, which is running all over the world and run by community operators. And then when you send a message on Session, it gets stored on kind of a subset of those nodes, which is like five to seven of those nodes, and then that allows you to fetch messages that was sent to you while you are offline for at least 14 days since the message was sent.
So you have that asynchronicity, you have the ability to fetch messages that were sent to you when you were offline. So that was a big thing for us when we were thinking about the design of Session that it would support or feel like a traditional messaging application like WhatsApp or Slack or Discord where you can get your messages back, but also that it doesn't have a central server like those services. There's no single central server where all of the messages go to and you're interacting with that node directly so that it gets a lot information about you. It's kind of leveraging this idea of a decentralized network but still providing some of the storage guarantees as well. So we've kind of split the difference. We have a highly decentralized network, but then we're also able to provide the storage as well to users.

Eric Anderson:
What you're describing reminds me a bit of the transition to HTTPS in the browser. There were sites that were HTTP and some were HTTPS and Google and others would kind of encourage people, they put the padlock on, they did other kinds of things to try and nudge you towards more encryption, but eventually they just said, "We're not serving traffic unless there's encryption." Basically, once the tech got easy enough, it could be enforced almost on people. And it sounds like what you're saying is that there used to be more trade-offs, but you're creating an environment that's privacy preserving or secure that behaves like Slack or behaves like a messenger people are used to.

Kee Jefferys:
Yeah. And I think that really only became possible once we could add incentives to the network as well. If you think about these other messaging applications like a pure peer-to-peer messaging application, they're actually quite secure when both users are online and sending messages to each other, but the user experience is quite poor and the reason that you can't just store messages on the network is that that's actually burdensome for the participants in the network. If you have to have a set of nodes that were community-operated that stored messages, you would run into issues where they don't want to store that data because they're not kind of incentivized to store that data.
And that's kind of where the idea of an incentivized network comes in as well. So we have a native cryptocurrency and I know a lot of people are scared of the word cryptocurrency, of course, and associate it with scams and stuff, but what Bitcoin and Ethereum do is that you could stake to a node or in the case of Bitcoin, you can mine Bitcoins basically providing compute to the network doing these proof-of-work hashes and then getting paid a reward to do that.
And you can do that in a completely decentralized way. You don't need a central operator to be involved there. So Session is kind of applying that idea of building out a decentralized network of nodes which have to perform a task, which in this case is storage and routing of messages and then rewarding them for doing that. So that means we can have a highly performant network which provides this service to all of the participants and then they also receive a reward for that. So it's kind of a combination of some of the encryption technology from messages before us, but then some of the incentive models which are used in blockchain technologies and combining those to kind of achieve this goal of a messaging application, which feels like a centralized messaging application but is actually decentralized on the back end. And I don't think that that was really possible before Bitcoin and Ethereum pioneered these designs of having nodes in the network which are useful and can do work for the users that are using the network.

Eric Anderson:
Yeah, no, that makes sense. I spend time more in venture capital and to put that in startup speak, you've turned this one-sided network to a two-sided network right before everybody who participated in the network did so to exchange messages. And so if messages needed to be exchanged when nobody was exchanging them, there was no incentive to be in the network. And now it's a two-sided marketplace where there's others who come to the network purely for the incentive and in so doing provide a resource to the other half of the network who just wants to send messages. Now that we kind of understand what Session is, how it works a little bit and some of your inspiration, take us maybe into the, I don't know if business model is the right word, but at one point you decided this should be open source, which it's possible to do kind of privacy preserving things without being open source. What led to the open source decision, how important is that to the value proposition of the service and network?

Kee Jefferys:
I think open source is critical to any messaging application which is trying to prove its security. I know WhatsApp isn't open source and they claim that the messages are encrypted and there are ways to kind of verify that claim by kind of reading packets so you can kind of get a sense of what is happening in the underlying code, but you can't fully review the WhatsApp source code. So they could be doing something malicious in their source code, maybe they encrypt for the other person, but then they also have a side key which they also encrypt for, which is then readable by the government for example.
That's the reason I think that open source is really important and also because people can come along and review your code as well, you can get it audited by people in a public manner so that everyone can check and verify the code that's running on the devices is what they say is running on the devices. And then also the decentralized nodes that are operating in the network as well. Those nodes are also running open source software as well, so you can verify what is happening when a message is sent to the network and then stored there. So the combination of all of that is really important.
The other thing is I think open source gives you a way to be resistant against attacks from malicious governments or people who might want to force you to put a back door in the application because if you as a developer are forced to put a back door into the application, you have to do that in an open source way, which is easily detectable by the community of people who are verifying the source code. So from both perspectives, I think open source is really, really important and open source not just on the clients but on the servers as well. And that's something that we made a decision like day dot that this entire stack is going to be open source.

Eric Anderson:
That makes total sense. I think one of the things I've tried to figure out is there a way to verify the open source code is what's operating on the clients in the servers? Are there ways people can kind of prove that the deployment path is also kind of intact?

Kee Jefferys:
That gets a lot trickier depending on how people have installed the application. So for example, if someone installs Session via Google Play or the iOS App Store, it's obviously not completely within our control, the distribution method, because it's possible that, for example, we upload a certain build to Google Play or Apple and then Apple kind of surreptitiously replaces that build when the user downloads it. We do have some protections for that in terms of we have a foundation, a non-profit foundation, called the Session Technology Foundation and there's a member from that foundation who signs every release so you can check the signatures from that release, which is essentially the release that was intended to be distributed to people. You can check the signatures on that to make sure that they match. So if it was replaced in the middle, the signatures wouldn't match anymore. The practical issue here is not many people are checking the signatures on every release to make sure that everything is kosher.
So you can get into verifiable builds, which are another process where you have a deterministic build, which is created by the source code. So if you know the source code, you can say that this deterministic build matches the source code that you looked at. That process is very tricky in practice because build systems aren't built implicitly to be deterministic. They have a lot of, for example, if you put a timestamp in a build that then changes the hash that you would produce for the deterministic build. So you need to make sure that the build process is locked down, I suppose, from a perspective of not adding in information that changes every build. So we're not kind of at that stage yet, but those are some of the tools that you can use to kind of verify the Session code that's running on your device matches the code that is on the open source repositories.

Eric Anderson:
No, that's better than I expected. And I think it's not necessarily maybe that every consumer can verify or has the aptitude, but presumably you would hope that there's like a 1% of the population folks who really do care and they're the canary in the coal mine, so to speak, for the average consumer, I imagine.

Kee Jefferys:
Yeah, that's kind of definitely the security model that Session operates under now. It's just, not to sound too negative on the idea of people getting verifiable builds or being able to verify the things that happen on their device, but you can imagine a situation where the builds that we publish and the builds that go out to 99% of users are the builds that match the source code. But then for example, if Apple or Google just replaces the build for one user and that user doesn't check, then you have a security issue because they can be running any code. So even if you have 1% of people checking the builds, if they're only replacing the build for one person and that person doesn't check, then you have a security issue there. So these are kind of the issues that you face when you're deploying software like this to millions of users.
And there just are practical considerations that people need to take into account and Session is not unique in this perspective. Apple could just as easily replace the builds for a Signal user or another user, and then there's other software which can just maliciously target your device itself. So they may not be modifying the Signal code or the Session code on your device, they just get access to your whole device and then when you open the application, they're just screen logging or they're pulling messages from the database. It's hard to protect against everything. You just need to define a threat model and work to that threat model. I feel like that's what Session is doing and it's definitely handling some of the more easy to exploit cases, but yeah, you can only get so much when you're dealing with devices that are distributed by manufacturers that you don't control or you're distributing builds through release systems that you don't fully control.

Eric Anderson:
Yeah, characterize the open source for me today. Is this community driven? You accept pull requests, people can suggest ideas, or is it kind of more the Android model where Google publishes things into the ether and you take it or leave it?

Kee Jefferys:
It's a very collaborative right now. So all of the repositories, so we have a release for Android, iOS, and desktop, and each of those has its own GitHub repository where people can file issues, people can submit their own pull requests, and those are then reviewed by the different teams that work on Session and can be merged in. So it's a very collaborative process. Everything goes up as a pull request as well, which will sit there for a couple of days. Developers will do their code review process in open as well, so it's kind of fully trackable by the community what's happening, and they can get as involved as they want. So yeah, I mean we're trying to do everything in open and as transparent as possible.

Eric Anderson:
And then there's a lot of efforts now maybe you could fit Session within the broader world of, we've talked about encrypted WhatsApp, but there are other kind of messengers that are trying to be privacy preserving and then also social networks. Help us understand how you see Session's role in all that. Presumably this should be the preeminent messenger, at least, for privacy preserving. Tell us kind of how you see the universe taking shape and where Sessions plays a role.

Kee Jefferys:
So in terms of we don't focus so much on competing with social media applications. We're really focused on being a messaging application, and there are a lot of different messaging applications as well that are used for different contexts. So I would say the vertical that we are most focusing on is kind of the Signals, the WhatsApps, like the Telegrams of the world, which are typically used to message friends and family and maybe a larger groups as well, but are not really used in the same way that Discord or Slack would be used in terms of a work context, for example. So if you were to compare Session with say Signal, I think there's three main differences. First, Session doesn't require a phone number to sign up, so it just uses public private key pairs. So you just generate this key pair and that becomes your identity on the network.
It's like a long 66 character identity and you can send that to other people, they can scan a QR code, and then they can start messaging with you, which is big for a number of reasons. Firstly, you don't face the same issues with SIM swapping attacks, for example, where someone gets access to your phone number and then that means that they can get access to your Signal account or your WhatsApp account because they have access to your phone number and everything is linked to your phone number in Signal and WhatsApp. I mean there are some protections around that, but we did see an attack against Signal from this exact reason using a SIM swapping attack or it was actually the SMS service provider for Signal. So when you sign up for Signal, they send you an SMS and it has a code and then you have to put that into Signal and that kind of verifies the link between your phone number and your Signal account.
So Session doesn't have any of those issues. It also provides a lot of anonymity as well because your phone number is typically linked to some sort of real-world identifier. In a lot of countries, you need to provide a passport or a driver's license to get a SIM card. I know that that's the case in Australia at least, or they may have your credit card on record, for example, because you're paying your phone bill. So your phone provider can at least map between that phone number that you're using for that messaging service and your identity on the messaging service itself. So Session is a lot more secure from that perspective and a lot more private as well. The second thing is we're decentralized, so Signal and WhatsApp, they both have central servers where all of the messages are stored. When you send a message to another user, it goes through a Signal server, it's stored there, and then the other user retrieves it.
So that from a perspective of there's essentially a single point of failure there. If Signal decides to stop running their servers, then Signal no longer works. It's not like there's a decentralized network of nodes which can come in and step up to that challenge if some of them are shut down, then you have new nodes come onto the network to serve the network. And the third thing is we use onion routing as well. So when you send a message, you are not actually sending the message directly to the server. You have a number of hops between you and the decentralized node that you're sending the message to, and that hides your IP address from the system as a whole so that there isn't a link between your IP address and the message that you sent.
And that's pretty big as well because you can imagine even though Signal and WhatsApp do a lot of work to hide the metadata in the system by encrypting messages, they still have the IP address of every person who interacts with the Signal server from a sending perspective, and then everyone who's receiving a message from Signal is interacting with their IP address. So onion routing is kind of quite similar to a VPN where you of add multiple hops between you and the service to break that link between your IP address and the message you're sending. And then the same thing on the recipient side as well, when they fetch a message from the server that is also using onion routing as well. So those are kind of the three main differentiators that people are usually most interested in. There's a lot of other design stuff that we do behind the scenes, but those are the ones that are most easily described.

Eric Anderson:
And do you find that attracts a certain audience? The last bit, the anonymity portion kind of reminds me, I don't know if you remember, there's these books, Ender's Game, it's kind of a popular sci-fi book from the '80s, but some of the characters become big writers and kind influencers, but nobody knows their human identity. That seemed like a hard thing to do today on the internet to be kind of, Satoshi I guess pulled it off, but to kind of be anonymous. But it sounds like on a Session you could do something like that. You could kind of create an identity, maybe become influential, but have no one know who or what's behind it.

Kee Jefferys:
Yeah, exactly. I think the Session user base definitely skews towards the kind of cypherpunk privacy maximalist side of things. So yeah, I mean that's definitely the core user base right now is very privacy focused. I think we're just over 1.2 million monthly active users now. So the user base has grown significantly. And I think in the early days of Session there were a lot of trade-offs to the systems that we were providing or the systems that decentralized network provided in the way that the clients were implemented. I think Session is becoming more mainstream now because the clients are getting easier to use. The decentralized network is getting faster. So I mean eventually we want to get to a point where Session feels no different from any other messaging application so that people can just jump on and use it as if they were using any other messaging application.
And that kind of means that you move from a user base of more hardcore privacy maximalists to a larger user base of just general users. But I think it tends to be the case that these new censorship resistant technologies tend to get adopted by cypherpunks and privacy maximalists first, and then you see more general users come in at a later point. And that's kind of the story of Bitcoin for example, grew in that same way. A lot of the users very early on were very idealistic like libertarian type people. And then you saw as the technology developed over time, got more adoption, you started to see more general users coming in using Bitcoin.

Eric Anderson:
One other risk is maybe users would have adopting a new service is like, is this thing going to be around in five years? GroupMe was a popular messaging app in the United States for a bit and they kind of ran out of capital or steam. And as a user I was like, "I think these guys are done and I don't know what to do with my groups on here." But eventually Microsoft bought them and I think kept them alive. But does the open nature and the kind of third party incentive system give a certain amount of resiliency to this offering? I feel like even if you, Kee, gave up on it, maybe this thing easily outlives you given all the incentives are just kind of in place.

Kee Jefferys:
That's the concept as well. Even if everyone who's working on Session went away right now, the system would continue to run because there's no central server bills that we need to pay for. The community operates the nodes, they pay their own bills, and then the incentives that are given to them kind of cover those bills that they're providing plus some reward. So even if everyone was to go away, the network would continue to function, which is great. It means that the system is kind of resilient to long-term as well.

Eric Anderson:
And then if I stand up a node to serve some messages, there's a minting process where I garner some currency over time, and then as long as I feel like there's some value in that currency, I feel like I'm being compensated for my node uptime.

Kee Jefferys:
Yeah, exactly. So right now there's essentially a block reward, which is paid per block, which is 16 and a half tokens, and those tokens are split between all of the nodes on the network. So if there's more nodes, the nodes receive less of a reward. If there's less nodes, the nodes receive more of a reward because they're kind of sharing in that 16 and a half tokens that are created per block, which means that the network scales depending on how many nodes there are. So if the node count goes down, the reward is higher for the nodes that remain on the network, which means that it can kind of fluctuate the amount of nodes that are on the network. And yeah, there's always a system providing incentive.

Eric Anderson:
There's like surge pricing.

Kee Jefferys:
Yeah, yeah. Well, we haven't talked about monetization yet, but the idea is also that this isn't currently existing, but Session will add a system called Session Pro as well, which will be a premium feature for the network, which essentially provides you larger files to the network, more profile customizability, these kind of cosmetic and user experience features, which are kind of geared towards power users. And what happens there is that there's essentially some value which is being collected via premium subscriptions or premium network fees, and then that value is flowing back into the network to ensure that that incentive system continues to run. So if Session grows in users and more users are subscribing to that premium service, there's essentially a sync as well of tokens that are being taken out of circulating supply and being put into this pool or being put into the block rewards, which are then paying back to users.
So you can imagine if the incentive system was just one-sided and was always kind of inflating the token supply, eventually if the token price goes down to such a degree, people don't want to run a node anymore because there's just new tokens being created, then the nodes would slowly leave the network and then you would be left with either a poor quality of service or not that many nodes in the network. But because there's this system or this proposed system of bringing value from the users that use the system and pushing that back into the network, the network becomes sustainable over time. And that's not something that the foundation has to govern, it's just like a set of features which are put in and that users can choose to buy in. That value eventually goes back into the network. So we thought a lot about the long-term sustainability of things as well.

Eric Anderson:
No, that's amazing. Yeah, give liquidity to currency holders. Switching topics a bit, Kee. So we're going through what feels like an AI revolution. There was kind of a crypto bubble or revolution, and now we're in an AI bubble or revolution and you've continued on, if you want to call it the crypto path, do you have an itch to get into the AI world or do you feel like people underappreciate what's happening in crypto land?

Kee Jefferys:
The AI piece is interesting here because I think the AI models essentially have created a lot more demand for data. And if you can get access to messaging data and pass that into an AI model for training, you can imagine that that would be massive to increase the amount of data because these AI systems essentially scale with the amount of compute and data they use to train on. And oftentimes data is the easiest or the cheapest thing to grow, and it's hard to make your model better. You basically just need to pay a bunch of AI researchers who are really smart and can optimize the model more, or you need to buy a bunch of compute, which is in itself expensive because of the power cost and then the cost of developing better compute and then buying that compute from the providers. Whereas there is a lot of data which is created every day by users.
And if you can get access to that data and feed it into your model, that is often the cheapest way to scale your model to get better results. So I'm worried about the incentives that creates for private companies to collect user data and then feed that into models. So I think Session is kind of, it's not in response to that, but it does make a situation much better to users because you can't grab Session data, it's end-to-end encrypted, the nodes on the network only see a certain portion. You can't use that data to then train AI models. And I think that's going to become a concern for a lot of people as we move into the next five years. And there's this increasing demand for data.

Eric Anderson:
A significant portion of Reddit's revenue is selling texts to the model providers. So yeah, I think about that every time I write something on Reddit, I'm helping open AI or somebody.

Kee Jefferys:
The scale on messaging applications is just so much more data being produced than these public websites like Reddit. Think about how many Reddit posts you would make per day versus how many messages you send over a messaging application. So if they could get access to that data, it would be such a useful training source. And as well, the model right now with large language models is kind of a chat model. So if you can actually bring real chats that people are having, you can really make the LLM much better in providing a natural human chatting experience. If you got access to everyone's private messages or groups, you could bring that data in, would have a lot more source material, which is not on the public internet.

Eric Anderson:
Yeah, you're right. I mean I think about the number of things I type in the keyboard. Vast majority is in the messaging app, a tiny bit to Google's search, and that's kind of it. The current landscape of messaging seems a bit crazy. There's a lot... SMS kind of dominates, at least, in the US. I feel like in Europe and other areas, they've moved on to more, I don't know if proprietary is the right word, but other networks. But even in the US we kind of have hijacked SMS. It's a lot of iMessage. Understanding the dynamics of that feels like important to Session success. Where do you see the world headed in terms of messaging? Hopefully it's more Session, but what are the things at play here? How do you make sense of why people choose what they do for messaging today?

Kee Jefferys:
I think if you were to ask me 10 years ago whether people were still going to be using email day to day, I probably would've said no, like most people have moved to these instant messaging systems. I would've been wrong about that because people still do use email a lot day to day, not as much as they used to. It's more like a formal communication tool for longer pieces of information that you need to pass along. But if you apply that thought to when is SMS going to die, I think it's going to be around for a lot longer. And you're seeing it metastasize a little bit into systems that the device manufacturers are developing as well. So most users these days say in the US when they send an SMS, they're actually just using iMessage. It's not going over the telecoms providers. And I think Google is moving more in that direction.
I think that they're kind of somewhat collaborating on this RCS system as well. Although I think there's some challenges between Google and Apple there about what they're going to support. I still think that they're not going to be able to compete against native messaging applications, so like WhatsApp, Telegram, Signal, Session, just because I think these companies have a more laser focus on improving the messaging experience. And you can see as well that users who were not onboarded into SMS originally are widely adopting WhatsApp as well. So WhatsApp has 3 billion users now, and it's kind of tied into the SMS system somewhat. You can kind of still send SMS messages through WhatsApp, but if both users are on WhatsApp, then it becomes a WhatsApp message.
So I think people who haven't been onboarded onto SMS originally are kind of more adopting WhatsApp natively. I think we'll see more of that come to fruition and as people kind of start to age out as well of the SMS system, I know a lot of, I guess the term is like boomers. A lot of boomers still use SMS, but I think a lot of the young people realize that the user experience of using say a WhatsApp or a Signal or Telegram is much better than using these kind of native systems that are provided by device manufacturers. So I think we will start to see a move, but I don't think it's going to be as fast as perhaps we want it to be.

Eric Anderson:
And what's the unit of migration, I guess? Is it a single individual? Is it a community? Is it a country? What I'm asking is, I'm in a funny situation now where some individuals I chat with over WhatsApp, some individuals SMS, or Messenger and so when I reach for a message, sometimes I forget which channel I'm supposed to be using for an individual, but then certain communities I'm in all standardized one way or another. And then of course, we've talked about the dynamics of certain countries behaving a certain way due to historic economic incentives, but I wonder if you almost have to think about the dynamics of migration along those lines.

Kee Jefferys:
I think there was this thought that maybe there would be one messaging application that would just monopolize the entire market. Everyone would just use that messaging application because it was the best. What we've seen is not that, and I don't actually see us moving towards much consolidation in the kind of messaging systems that we use. Most people have maybe three to eight messaging applications on their phone, and they're used in different contexts as well. Think about what you use for work, you might use Slack or MS Teams for work. If you're a gamer, you might use Discord to communicate with your online communities, then you might use SMS to communicate with your parents. Then you might use something like Signal or Telegram to be in other communities or to chat with your friends and Facebook Messenger to chat with old colleagues or people that you met in high school.
There's just a lot of messaging applications that people use on a day-to-day basis. And the intuition that everything will centralize into a single messaging application I think is not the case. And I think the reason that that intuition happens is because messaging applications look very simple on their surface. It's very simple to build a very not feature-rich messaging application. I could spin up a messaging application in probably a week and put it on the app stores and people could message each other one to one, but you think about the depth that messaging applications have. Maybe they have an integration with your GRS system at work, like an example of that is MS Teams. Maybe they integrate into your email system or your documentation system so that when you post a link there, it provides a nice preview. Maybe they have a voice chat feature which can support large groups, or maybe they have stickers.
There's just a lot of features that people don't typically think about, and I think it's very hard to build a messaging application which tailors for every use case, and that would be what you would need to move everyone over into a single messaging application. So it becomes a, it's hard to develop something that works for everyone. I think that's the reason that we see the messaging application being fairly sharded into different groups. So when we started Session, I thought that we would very quickly be able to achieve feature parity with some of the larger messaging applications, but I think it's actually a much harder goal to achieve something that works in every context. If people want to find out more about Session, you just Google Session, you'll find us as the first result. And yeah, get involved, download clients. We have clients on Android, iOS, and desktop and just test it out and see how you go.

Eric Anderson:
Great. Thanks, Kee, for coming on and thanks for this cool thing you've built that will surely will outlive you and we all get to benefit.

Kee Jefferys:
Awesome. Thanks, Eric.

Eric Anderson:
You can subscribe to the podcast and check out our community Slack and newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson and this has been Contributor.