The Changelog: Software Development, Open Source - Secure Messaging for Everyone with Wire (Interview)

Episode Date: December 15, 2017

We talk with Alan Duric, Co-founder and CEO of Wire, an open source end-to-end encrypted instant messaging app for voice and video calls. In 2005 Alan co-founded Camino Networks which was later acquired by Skype, and his involvement with internet based voice communications goes back 20 years. We talk about the early days of Skype, why Wire is open source, the importance of encryption, the importance of secure messaging, their polyglot ways, and how they plan to stand apart from other apps like WhatsApp, Telegram, Signal and more.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. And we're hosted on Linode servers. Head to Linode.com slash Changelog. This episode is brought to you by our friends at Bugsnag. Bugsnag is mission control for software quality. And I talked with James Smith, co-founder and CEO of Bugsnag, about team communication around software errors.

Software errors are not engineering-only issues. They're a problem the entire organization faces. I feel like any company that has software at its core, everyone in that team should take pride in what they're building. And I think that it's pretty obvious where software teams and engineering teams in particular would use a tool like Bugsnag or error monitoring in general. But what we're seeing more and more is that if there are customer support teams start using tools like this, they want to have more visibility into the actual problems. We end up with customer success teams, you know, for account managers, for VIP customers care about if their customers have seen a crash. Even one example that we saw recently is sales teams, right? If you are

getting someone interested in your product, they're doing maybe a trial or a pilot program. If your customer sees a crash during that trial or during that pilot program, that could be it. They could be out. And if you're the person who is the account manager or salesperson on that conversation, you want to know, you want to make sure that customer's having a good experience. So yeah, any company that has software, most teams in that organization are going to care about the health and the quality of that software. So as you add more visibility to these software errors to more people, you're going to end up with more communication. How does Bugsnag enable teams to better communicate around error monitoring?

One thing that we I'm always surprised about is how many steps are involved in communication between a customer seeing a problem and that problem getting resolved. And it's almost like a game of telephone, right? So imagine you're a company that has a support team. A lot of the time, the support team can end up being the bad guys here, right? You end up with customer complaints. The support team pick up the ticket. Maybe that gets escalated one level up to the next level of support. That team then has to figure out, hey, is this an actual software problem? Is this a bug?

Or is maybe the customer just misunderstanding how to use the product? In that scenario, there's a disconnect between the customer and the engineer. You know, when I'm building software, I want to know if the code that I'm writing and the software that I'm building is working. Removing this game of telephone between customer, then customer success or customer support, and then the engineering team, and then all the way back again when a problem gets resolved is pretty important. So if your team has ever experienced a communication breakdown when resolving errors in your software, give Bugsnag a try. It's free to get started with a special 45-day extended trial exclusive to our listeners. Head to BugsNet.com slash changelog. You're listening to the ChangeLog, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, editor-in-chief of ChangeLog.

On today's show, Jared and I are talking to alan durek co-founder and ceo of wire an open source end-to-end encrypted instant messaging app for voice and video calls alan was a co-founder of commuter networks which was acquired by skype and his involvement with internet-based voice communications goes back 20 years we talk about the early days of skype why wired is open source why it's important to source, why it's important to be encrypted, why it's important to be secure, their polyglot ways, and how they plan to stand apart from other apps like WhatsApp, Telegram, Signal, and more. So, Alan, where did the idea for Wired come from wire and as you know a secure messaging tool for everyone and the idea for wire came five years ago when us founders of wire met together with janus freeze co-founder of skype and we had an idea there to build a new Skype and we were thinking like

okay if you are building Skype ten years after how would that Skype look like and there we identified three gaps one was related to privacy One was related to user experience. And the third one was related to security of all of the existing messaging solutions. And as you can guess, all four of us founders were related to Skype one way or another. That's interesting. I mean, obviously, we're conducting this call via Skypepe and i think in my history of podcasting i could probably say there's only maybe a dozen if that if that and i've done probably i don't know 600 shows 500 shows across my podcast career where they've done via Skype. And it's interesting to kind of talk to somebody that's played such a critical role in Skype, for one, but then also this desire five years ago to want to do something better.

What's wrong with Skype? What's wrong with this? Not so much Skype as a product, but what's wrong with maybe the type of platform, the type of thing it is, the thing it's trying to do to make wire be something that needs to exist? Actually, beside this privacy part, since Skype is a part of a bigger corporation, their business model may be different than what is our business model. Other part that I personally didn't like was that Skype, which from the very early days had impressive encryption, end-to-end encryption done in a peer-to-peer way. As it changed over the years,

that encryption has been removed from it. So this is basically the main complaint on Skype. Other than that, it's fair to say that Skype is still an amazing tool that does its job very well. And they are possibly there. Another big disadvantage is the fact that Skype has quite a bit of a baggage being present on the market and being one of the leaders on the market for now nearly 15 years. So a number of things that are holding them back relate to some backwards compatibility, etc. So we were lucky there that we could start from the scratch, identify those gaps and go for it.

You mentioned that one of your previous companies, and this, for the listeners, this isn't Alan's first rodeo. This is maybe your third or fourth technology business. Had many successes in the industry. Camino Networks, I believe it was called, was bought by Skype, I think back when Skype was part of eBay. Skype has a lot, when you go back and start thinking about it,

it has a long storied history as a software product and team. And like you said, it has a larger corporation as a part of now. It's had different phases in its life. What was Camino Networks and then why was it bought by Skype? Tell us that story a little bit. So you definitely prepared quite well for this podcast since Camino was sold to Skype roughly 10 years ago. And Camino was developing speech coding and sound processing technology that was tailored for voice over IP networks

so that it could sustain lossy networks, jittery networks. And this was a piece of a technology that Skype was missing because Skype was licensing that software from other company that is that was called the global IP solutions which ended up afterwards acquired by Google and global IP solutions is a company where I was one of the first engineers and started working with Skype basically in 2003 so So I used to joke

that I know Skype when it was still called Skyper. I never knew it was called that. It's interesting to look at the history of commuter networks, then acquired by Skype, then Skype acquired by... There was several different chains

in there for it to ultimately be now owned by Microsoft. And whenever you have an idea, right, a business, an idea, technology go through so many hands, the mission to some degree must get lost. Or its original mission or its original intent somehow get disambiguated. It's just somehow it's it's just it's somehow it's it's blurry you know it's not clear to the maybe the current status and maybe that's why why is here end-to-end encryption it seems like maybe help for me even to to understand this and the listeners too along with us when you're talking as we are now via Skype, what's happening? Are we at risk of our

conversation being overheard by someone else? Is that what's happening? As you said, the encryption has gone away over the years. And what exactly is happening with communication on something like Skype? So risk of a conversation being overheard is realistically small unless you are someone of a particular interest or of a particular high net value. And that information could be sold to someone. However, there is also more aspects to it, such as metadata related to this call. So it is something what is of a concern for businesses. If, for instance, let's say like a small pizza shop, if it is using a tool as a Skype or a WhatsApp, and if their customers are contacting them with that tool, all of that metadata related to fact, who was contacting them, when they were contacting them, et cetera, is at disposal of those large

corporations such as Microsoft, WhatsApp, Google, et cetera. And that information then can be sold directly to their competitors. So let's say like there comes a new pizza shop that is in that area. And they can have easy access to all of the customers, offer them a little bit better value proposition or a little bit cheaper price than what the original one is offering and overtake their customers. And they can do it with a perfectly legitimate way

because this is something what in terms and conditions when you are using those tools is specified that nothing prevents those big corporations from taking it. And in a similar way as well for people that are using it just from a pure consumer side, it can be used for profiling that are using it just from a pure consumer side. It can be used for the profiling on our side.

And you've seen also the cases where people are getting suggestions to be connected to other people that they shouldn't be connected. And it can also create a number of scenarios that are quite awkward and also potentially dangerous. Yeah, for maybe some of the listeners too, they're even like, why are you guys talking about Skype so much? Like, I don't even use Skype anymore.

I'm not a podcaster. I don't have that many conversations. I mean, Jared, what's your opinion? Do you think there's a lot of people unlike us like we record this show and our shows across Skype? Is there a massive user count for Skype? I mean, are we boring people with the conversation on Skype, do you think? I think there's a massive user count for Skype because of what Alan said, which is how long it's been around. Around the 15-ish years.

One of the reasons why we use Skype for podcasting is because of the call quality relative to others. And it has a lot of technology in there around making sure that network glitches don't cause as many problems as they do. There still are issues. But the other thing is most people have a Skype account. That doesn't mean they're using Skype, but it's just been around. It's like AOL Messenger.

Most people have an AIM account somewhere down there. Okay. So that is a barrier that we usually do not have. Sometimes we do. Alan had to install Skype and probably had to dig up his old username in order to make this call with us. So there is a network effect there, but it's not like, you know, it's not the cool kid on the block.

People aren't excited about Skype or using it because they want to. It's just kind of because that's what's always been there and it's been good. And there hasn't been much innovation and competition in that marketplace until recently. And there's a lot now. There's, gosh, I was looking at your website there, Alan, and you guys have a nice matrix,

you know, kind of a feature matrix with other offerings and there's Skype for Business, Microsoft Teams, Slack, WhatsApp, there's Facebook Messenger, there's Telegram, there's Signal. There's a lot of people who are trying to make waves in the chat and voice and video space. The reasons why we invite you on the show, one of the major things is that Wire is completely open source. And so we're not talking with Facebook Messenger today because they're not open source. And we think open source is cool. And especially when it comes to privacy and these types of encryption, we think open source is important. So why are you guys open source?

Why is Wire open source? Tell us about the decision to do that. So the main reason why we went open source is when you have a piece of a software, especially one which is a communication tool, and security with privacy is in its core. I see there of utmost importance to be fully transparent about what you are doing with your software and this is this is something that we owe to our users and we owe to our customers and I usually say to all of my colleagues friends that are not much in the security area why when they are buying security related products whenever they hear that something is a military grade encryption or military grade security and if it is not an open source stay away from it yeah this is something that is, I think, also going to become a norm for most solutions that are going to be coming out on the market.

So this is looking at things from a number of largest world corporations from automotive industry, some of them in the banking sector, some of them in a pharma, which haven't contacted us before we were open sourced. So it was a big proof that being transparent is already paying off quite nicely, and it's going to be paying off even more better times to come. So this is reasoning when looking from a company's perspective. And when looking from individuals' perspective, it is also something that pretty much all of our team members see as employment benefit. And they love that they are working with the open source. They love that they can show to their friends and family what they are working with. They are very proud of it. And also personally for me, this is a big thing because I've been involved in open source now basically for 21 years, starting with a Slackware back in

1996, then through ILBC Codec and a number of other initiatives. And it also helped us a lot to recruit some of the top talent, which told us that for them, this was a decision-making point that we were open compared to some other options that they had in front of them. Well, to a certain degree here, Alan, you're preaching to the choir because we see the value in doing it. We think it's overwhelming to keeping it closed source. But was there internally, your CEO and co-founder, as you mentioned, you have some other founders and some other people who are in leadership at Wire. Maybe you even have a board of directors. I'm not sure how the company is all laid out. But was there, did you have to pitch this?

Was there an advocacy internally? Was there debate around whether or not to do it? Or was it a no-brainer for everybody involved? Excellent question. And of course, you are on to something. Since also among our investors, there wasn't unanimous decision and sympathy towards open source.

There were also some concerns from one part of them that haven't been working with open source before. And there was also a bit of a skepticism how market is going to respond to it. But they were still very supportive. And after really good argumentation was presented for open source, we all decided together to go for it. And ever since, they were extremely pleased with results of going open source. And I'm also glad that we expanded a network among investors that are now strong supporters for open source. It's interesting in hindsight to look at the way that open source has been a benefit. And this may not be something that seems very clear to everybody listening or to those who are newer to the idea of open sourcing everything, so to speak, is that you've been able over you know the co-founders and investors

in wire to say open source is the way that's a hard thing for some people to really get and i think even for us jared like our cms is open source and when we were first thinking about you know that technology building that you know the the thing I think we often hear is like, well, that's, that's awesome that you did that, but you know, you've given away, you know, your everything essentially. And I don't, I don't see it as that. I see it as like what Alan is saying, here's this full transparency. We have nothing to hide and all it does is get us all the benefits. Alan, is that how you see open source?

You said before in the pre-call how big you are in open source. Is that part of the reason why you're so big on open source? Absolutely. And my previous jobs, I was fortunate enough that I could have start Kodak

that is called ILBC from a business idea around it to make it also first as a part of a freeware open source it and thanks to that experience we've seen how it helped to enable something what was massive afterwards. If you look a little bit back some 15, 20 years ago, you needed to spend quite a bit of money to license speech coding technology that was working reasonably well on internet. And companies like Skype, they didn't have at that time a possibility

to use some of those codecs that were free or that were licensed then from a global IP solutions in a way that was not prohibiting them to grow from the start. I don't think we would have had today free calls practically everywhere on mobile phones, on desktop, video calls, etc. This helped in a great manner quite a bit of innovation that was happening afterwards in the field of internet communications, messaging space, voice over IP,

etc. And in the same way, I see things happening in security and also open sourcing some of the critical components there inspiring a number of other developers out there, inspiring also a number of other companies to create good solutions, secure solutions, and ultimately then at some point of time hopefully gaining the same adoption rate as we gain on the speech coding side with the webrtc being open sourced from google at um at some point of time and as you may know most of the code that was open sourced at the very beginning for WebRTC was, again, a global IP solutions code that Google acquired. I'm glad you said that because I wanted to make sure that we, if not gone deep here, because maybe now is not the right time, but mentioned that ILBC is Internet Low Bitrate Codec, which ultimately became WebRTC.

It was initially released. This is all based on Wikipedia. So this is free information. We'll link in the show notes. But initially, this was 2004, written in C, and uses a three-clause BSD license, but is now owned by Google and was ultimately turned into WebRTC. So all this work that you're seeing that helped you have faith and believe in open source was this initial codec, which became WebRTC. So for those listening, that's a massive

amount of history and a huge lesson for Alan to learn around this thing. I mean, that's just so crazy to hear that backstory. And today we have WebRTC. It's just amazing how that thing there for you is what gives you faith and started your faith in open source and what has ultimately helped you build WIRE. Absolutely. So that's been an incredible journey and really proud of it that ILBC became a seed for this, what afterwards turned into something really spectacular, used by billions of people. And also at the time, back in 2001, when I was taking ILBC to IETF to standardize it, people thought that I'm crazy, that ITF would never take it. But I was fortunate as well to have some of the visionaries there at ITF that accepted it. And then after that, we took Kodak to another standardization community or a cable apps and it got also accepted there and it

wouldn't be accepted there if it wasn't free and if it wasn't open source and from that point onwards it set the standards for any kind of speech coding technology and video coding technology that wanted a high adoption rate. That's amazing. Let me, for the sake of conversation, let me play the bear for a minute with you, Alan, because as you said, internally, it was not unanimous. And so no doubt you had interesting conversations with your colleagues and leadership at Wire around this. And one of the major points brought up by people who are skeptical of open sourcing, I think, is a legitimate skepticism with regard to ripoffs. Ripoffs happen.

And the more successful you are, the more they can happen. In fact, just recently I was reading about a crypto coin wallet called Coinami, which I think is an Android-only thing now. And I was just reading about their history a little bit. These things interest me, and they were open source. I think it was GPL'd even. And their Android application was all open source on GitHub. And they were doing it all in the open, which makes a lot of sense for a crypto wallet as well. Because talk about you want to know what the code is doing.

Similar to an encryption type of a secure chat, you want to know what's going on under the hood. And so it made sense for them to be open source. Well, what happened was other people who were being very capitalistic decided they were going to just take that code, rename it, rebrand it, and put it on the Android store. This is not an isolated incident. We see this happening over and over. The Coinami folks ended up, they stopped open sourcing. They decided it wasn't worth it for them anymore. I believe that repo is still on GitHub, but it hasn't been updated in a few years,

and they've marked it as inactive. And so they've continued to develop the code base closed because they had these problems. Was this a potential reason not to open source discussed at Wire? Because surely if everything you do is in the open somebody could just take all of your code and all you're doing and rebrand it and compete with you definitely uh something uh what uh what has been brought up by our investors as a concern and

definitely a valid concern and as you've seen in the case that you described, we have also a couple of more cases, unfortunate cases like that where really awful stuff has with the open source. And I'm glad that those are only exceptions. And I hope as well that there are good legal ways. And I know that there are how to protect those companies that have been ripped off in this way. That legal system should protect it and as well I'm pretty sure that community and the opinion makers and the ones are strong influencers towards the customers of such solutions that they make sure that people

stay away from solutions that are basically a classic reports no it is it is a hard way and we know that it's that there are gonna be the cases when such things are gonna be happening but on every negative case I trust we have another 10 positive cases where we we need we need to continue pushing in the same direction and we need also there to help those ones that got hurt during this effort. this episode is brought to you by digitalOcean, who just launched Spaces, a beautifully simple object storage service designed for developers who want a simple way to store and serve a vast amount of data, such as hosting web assets, storing user-generated content such as images and large media files,

archiving backups in the cloud, and storing logs. Just like you use S3, Spaces has an ecosystem of S3 compatible tools and libraries that can be used to manage your space and it's available independent of DigitalOcean servers. You don't need to use anything else but just Spaces if you want and to make it easy to try for both new and existing DigitalOcean customers, you can get started today with a free two-month trial of Spaces by going to do.co.changelog. And for new customers only, you'll also receive a $10 credit to use for DigitalOcean droplets or other services. Once again, do.co.changelog. And by GoCD.

GoCD is an open-source continuous delivery server built by ThoughtWorks. GoCD provides continuous delivery out of the box with its built-in pipelines, advanced traceability, and value stream visualization. With GoCD, you can easily model, orchestrate, and visualize complex workflows from end to end. It supports modern infrastructure with elastic on-demand agents and cloud deployments, and their plugin ecosystem ensures GoCD will work well in your unique environment. To learn more about GoCD, visit gocd.org slash changelog. It's free to use

and has professional support for enterprise add-ons available from ThoughtWorks. Once again, gocd.org slash changelog. So Alan, WIRE has a lot of competition, which is great. There's lots of companies and individuals trying to provide solutions in the chat and video and voice space, and we need that. There are many alternatives. There's even many open source alternatives. In fact, Telegram and Signal are both open source.

Somewhat interestingly, or at least it's interesting to me, Adam actually found Signal and said, hey, we should do a show on Signal. And I had already invited you on, and I said, oh, well, we should do a show on Signal. And I had already invited you on and I said, oh, well, we're doing a show on Wire. And it was just kind of like almost simultaneous discovery, only I beat them by maybe a day. And so we thought about having Signal team on because they're doing very similar things. So curious what sets Wire apart from the competition, even amongst those who are security focused and open source as well? What's the why or secret sauce?

When you look at the current landscape, on one side, you have applications that are secure using end-to-end encryption, such as a signal or a WhatsApp. But a Telegram, I would also have some reserve because their default mode is not end-to-end encrypted. And according to different sources, most of conversations on Telegram are not really end-to-end encrypted. But nevertheless, when we look at the applications such as Signal, WhatsApp, that are general purpose applications and that are easy to use and that are secure, they are not applications that are meant to be used for the businesses you don't have their possibility to add someone to the group or take out someone of the out of the group administer that you don't have the group calls and the number of screen sharing and the number of other functions that you would expect in a business environment So this is one side of the landscape. Then you have the

other side of the landscape with the business tools such as Slack, Microsoft Teams, or Facebook Workplace, which are tools that are not really secure, that are not really using end-to-end the encryption and also in addition those are tools that are not easy to be used by people that are not in IT world and there are not tech savvy and the wire is really they are addressing this sweet spot so that it can be used by consumers. So with Wire, you can have a consumer profile and then you can have your business profile in the same way that, for instance, you would do it with your email client, whether it's Apple Mail or Outlook. You can have one account there, which is your private account, and then you have the other account there which is your private account and then you have the other account which is your business account and you can nicely keep those apart if you want and

this is this is basically a unique with a wire that you can use it both for a business and for your private use and that it is super secure and it is really super simple to be used. It is, as we say, like a general purpose application. And as you know, in the past, there have been a number of really super secure tools like PGP email but they were really cumbersome to be used and then companies and people that really needed to use it or that they depended on it they were usually usually falling back to solutions that were easier to use, but they're not necessarily secure. One point that you emphasize on the website, which maybe I need more

explanation because I'm not very familiar with and perhaps other people as well, is that you're Europe based. And so there's European privacy laws in place. Can you explain why that's relevant and important when you're picking a tool like this? So European laws from privacy point of view are more protective of the consumers and more protective for businesses. There is a really high threshold that needs to be passed in order to get any kind of very confidential information, especially when compared to the US or some other jurisdictions. And also, I guess part of that too is being Switzerland-based. Why is it specific to mention Switzerland?

I know that it's pretty well known for having a Swiss bank account. You hear that in the movies and it's this thing like, oh, you can't get me here. It's this neutrality kind of thing. Is that part of the tail end to Gérard's question to you? Up to a certain extent, but it is really what it is there why we choose Switzerland for our

jurisdiction was that at that time privacy laws were even more favorable than European Union laws and now Swiss and EU privacy laws are on pair so over a time European laws as well emerged further and are protecting consumers and businesses in the same way as one does. And the other reason also why we went for Switzerland was that there is a favorable regime with respect to keeping your intellectual property. I guess one thing we can probably dive into a little bit further is is what you really mean by secure and mainly for breaking it down for everyone else to really understand that because on your matrix that we mentioned in the previous section it says secure equals everything secured with end to end, which people may say that quite a bit. Maybe it means one thing for someone else.

Maybe it means another thing for you. But you've got an entire page dedicated to describing what you mean by secured with end-to-end encryption and protected by European privacy laws, which you described as more robust and more comprehensive. Can we kind of walk through some of the information shared at wire.com slash security? You got end-to-end encrypted, independently audited, multi-device messaging. These are pretty interesting things. I think that people don't really break down unless they have to break them down. So to say that new encryption keys are used for each message. So if one's compromised, a key has minimal impact, or how you can use several devices.

Can you start breaking down some of the end-to-end encryption details that you all employ? So basically, you already hit all the most important aspects of this being really secure. So with end-to-end encryption, you are rising various combinations for someone in order to know everything that we are talking, they would need to break into every one of us devices. So like exploiting the wire network would not give them anything because wire network keeps all of this information encrypted and not only that if someone would like to exploit

this data from outside, but also if we have someone inside WIRE that would like to take advantage of their position being an employee at WIRE, they cannot take that advantage because all of the data that we have is pretty much useless. So here, what is really important is that you are putting this barrier or exploit very high.

And imagine like if you are a bank with millions of customers or if you are a legal office also with thousands of customers in order to get data that is currently being obtained with exploits that are happening that you've seen recently with Deloitte or KPMG or even Slack some time ago. You have all of those users' information at your hand once when you get into their cloud. So, of course, when someone from the outside wants to take advantage of a specific platform, they are likely to go for that one where it's very easier to get into it so using equivalent like if your home is

protected with the video surveillance it it has doors that are the most sophisticated ones using all of those anti-burglar features. If your home is also being surveilled by security, and then there is someone else's home who is not being surveilled by security and doesn't have video camera surveillance, and it has just the simple doors that are easier to break in and the value of stuff that would be found in two of those homes is similar of course burglars are going to go there where it's way easier and where there is a way less risk to get it. And similarly, as mentioned, like if we have customers that have a very sensitive data

that their businesses depend on or that even their lives may depend on, they are not left at mercy of our employees in our company, because even if they were the ones with bad intentions, they wouldn't be able to extract much from the data that we hold there. So this is also a difference in our approach towards the data of our customers. For instance, some of the companies take it and they say that data is a new oil. For us, data that our customers have could be more seen as nuclear waste. That's an interesting perspective. Exactly.

And we know that we need to handle it with a care and we handle it with a care that our architecture and everything is addressing it. So data as oil regards to, let's just take customer chats, chat messages, text is, you know, is bad for me as a customer. If you're using that oil, right oil to power revenue through some other mechanism. But it's powerful for me if you're feeding back into my user experience, if you're improving the product with my data, which I've put into the system. So one of your rivals, a centralized business rival is Slack,

which is dominating the small business and startup and really the developer sphere with regards to just usage. The joke now is you have too many Slacks and so everybody invites you into their Slack and you don't want to join another Slack because you already have 18 Slacks, by the way. Change log Slack, check us out.

So we have one. And ease of use and some of the features provided by centralization are really nice. And so we have this age-old compromise between security and ease of use, or security and rich feature set. With Wire, you're saying it's easy to use, it has a rich feature set, and it has security, there's no compromises. I'm taking that right off your features page, it says no it has security. There's no compromises. I'm taking

that right off your features page. It says no compromises. Surely there's some compromises. There has to be, you know, you're giving up something, right? Are there things that Slack can do that you just can't do with wire because of the architecture of the centralized data stores? Some of the features which Slack is developing are easier to develop if you don't need to think about end-to-end encryption. But I'm pretty much sure that they are quite aware of all of the potential hazards that the hack into Slack would cause to their users. And I'm pretty much sure also that they are working on end-to-end encryption and in the same way as, for instance, big food and grocery supermarkets like Safeway in US, they have like normal food section and then they have a healthy food section. And as awareness about hazards of security exploits is rising, everyone is going to have

their own, within quotation, healthy food section, whether it is Microsoft or if it is Slack or anyone else. So this is one of my predictions for the next couple of years for the market of business communications. And their first goal is to move business users away from email because also email is one of the weakest links or the weakest link in the chain so for a sensitive corporate information people should never use email and when compared further with slack i seriously doubt that it can improve quite much user experience data that you get by digging any company's charts and information, which is a chart.

I would be very keen on seeing really some of those use cases and see how it is really improving productivity or a user experience. I think the interesting thing here is that we have seen, you know, in Twitter and Facebook, we've seen some rogue employees do some things that has been detrimental to their brand to some degree, in large degrees, you know, doing things on their way out their last day of work you know so in your case where you say with wire um the fact that the encryption is happening elsewhere not so much that if you take over wires network that you don't have access to

all the keys in the kingdom you have you know maybe a limited access or something where you can't really go into the individualized clients and things like that. So you're in a position where that seems to be a foundational DNA of how you move forward with developing product. Can you describe, I think you kind of touched a little bit on it where you said Slack could do something, but then you could also do it as well. you thought about it from a certain perspective. Can you kind of walk us through what that looks like to have that as a foundational DNA of new feature development to operate in a way that remains with the integrity of keeping things secure?

Excellent question and also a very difficult question, so I hope I'll be able to explain it in a simple words. So basically what is happening with the end-to-end encryption, we have cloud communication model fundamentally changing. So for instance, some of the core functionality that relies on a cloud, let's say like a search in a Slack. Search is happening in the cloud. For us, search cannot happen in the cloud on the content of the conversations, simply because everything is encrypted and we have no clue if a certain message that passed through our cloud is for instance a call that I'm making to you if it is a text message if it is a just acknowledgement of the message that you sent to me and you are getting a back delivery receipt or if it is a file that was sent or a screen that is being shared for all those messages you

you have no clue really and what is happening there so search cannot be done in the core also a number of other functions such as a sync across different devices depend heavily on endpoints. So you have a hybrid logic where most of the intelligence is moved towards the endpoints, but there is still some intelligence that is in the cloud. And we've seen this in the past, in a communication networks, for instance, you had intelligent network in telecoms where all of the intelligence was in the cloud. Then with the rise of a Skype,

we had the peer to peer distributed, fully distributed model, where all of the intelligence moved back to the endpoints or to the peers of the network, to the peer of the network. And now Pendulum is again swinging. So it went to cloud. Everything was moved to the cloud. All intelligence is in the cloud. And now Pendulum is swinging again and going more towards the endpoints, and we have this hybrid model. So with this in mind, as mentioned, any feature that you are developing, it needs to be developed

in a quite different way than if you do not encrypt the data. So it has some overhead. It has tougher testing, tougher test automation, et cetera. But we are committed to it, and we know that this is the right way forward. Do you believe that the consumers will come with you on the way forward? Because a disturbing trend that I see, and heck, I even see it in myself sometimes, even knowing all the implications and the problems with privacy, is we all want it until it's inconvenient. And even the smallest inconvenience, we just throw it out the window. Not even inconvenient.

There's or we have a shiny feature that that is, you know, dangled in front of us. And we say, oh, that's really cool, especially now with a lot of the, you know, applying a lot of the machine learning to our to our historical data and and the neat things that you can do with that. You know, positioning yourself very much as the secure way to message. As you said, the pendulum has swung back and forth, but won't you see it potentially swinging away from you as consumers continue to sometimes, you know, frustratingly choose convenience slash features over privacy? You have a fantastic point there, and we are quite much aware of it, so I also Like to see it from a couple of perspectives one is related to awareness and this sociological or

Anthropological view on it is quite important. And there needs to be more awareness of all of the issues that are happening with abuse of our privacy. And I also like to compare awareness and the knowledge of the hazards of a passive smoking some 20 to 30 years ago when I was a kid to all of the hazards of exploits of our privacy today. In the times to come, we'll see, I'm pretty much sure also some of the massive lawsuits over this happening if this doesn't start changing because the basic problem there is who's watching the watchmen and we know that companies like facebook and google heavily depend on products that are free to consumers and And we know that it is not free because the consumer is the product. And how they can increase their valuation

because all of them are publicly traded companies. They are already serving 1 billion of people that have 98% of the wealth. So the only way to heavily increase their profitability is by exploiting our privacy further. And also with these profiles that are made of us based on our usage of their services, what those profiles are going to be used for. other people's profiles because you know my profile is also created by a pattern of usage with my other friends co-workers etc and other sites also can play with my profile and mess it up heavily. So those are the things that we'll be seeing in the future that can impact our life in a great manner. And unfortunately, there is no good way to make sure that those massive abuses do not happen. This episode is brought to you by our friends at TopTal, the best place to work as a freelancer or hire the top 3% of freelance talent for developers, designers, and finance experts.

In this segment, I talk with Jeff Mazur. My name is Jeff Mazur, and I'm a TopTal finance experts. In this segment I talk with Jeff Mazur. My name is Jeff Mazur and I'm a TopTal finance expert. And we're talking about cryptocurrencies funding early stage ideas with ICOs and specifically I asked Jeff to speculate on Filecoin. To me it's one of these things where it makes a lot of sense on paper and I think the the white paper is kind of well reasoned and well thought out but we just haven't seen the evidence that it really works. And if you think about a typical venture capital deal, it's much the same type of thing because a lot of times companies will raise money from professional investors, from experienced or early-stage investors for an idea that looks great on paper but before it's still proven to work in reality. And FilePoint is much the same thing. It looks great on paper and it looks like it should work, but it's still proven to work in reality. And FilePoint was much the same thing.

It looks great on paper and it looks like it should work, but it's still too early to say if it's going to prove out to be workable, scalable, and sustainable. And that thing, I believe the token sold out in hours, I believe, less than 24 hours. Wasn't that right? Yeah. They raised a huge amount of money, but they also raised money in a presale from what they referred to as advisors. So there were some venture capitalists and there's some people in Silicon Valley who invested in the project early, which caused some commentary, both positive and negative in the cryptocurrency community.

So if you're looking to freelance or you're looking to gain access to a network of top industry experts in development, design, or finance, head to TopTal.com and tell them Adam from the Change Law sent you. That's T-O-P-T-A-L.com. And for those out there wanting a more personal introduction, email me, Adam at changelog.com. So, Alan, we can't help but notice, we're looking at your design and we're looking at the way that you present the business, which is quite impressive. One thing that I'm impressed by is that domain. So you're talking to a developer audience. We nerd out about the littlest things and domains and domain hacks.

And you got wire.com, four letters, easy to spell, the exact name of your business. How'd you go about getting that? And it had to be expensive. It is expensive. Five years ago when we acquired it, it was visibly less expensive than what it is today and as as you can imagine at that time we had in a same way as we have now big plans big idea big mission and we needed also a big name so from the very beginning we've been very careful about brand building about architecture of the system that that we have built choices that we took there so back in this for instance completely written in Haskell able to scale in a hundreds of millions of users and a

number of things that we're done from the very beginning were done in a very solid way. Yeah, that leads into what we want to talk to you about a little bit was the technology choices around the different things. So when we say that wire is open source, a lot of times with businesses, they'll just open source their clients or their client libraries. But there's tons of open source stuff. So check that out in the show notes. They have the server. They have components.

They have all the different individual clients. And just looking at it a little bit, like you said, the server side is written in Haskell. There's protocol libraries that are written in Rust. You have C libraries. The iOS app is Objective-C and Swift. The Android app is Java. So you're using native languages for their platforms. There's a desktop app, which is an Electron thing, which wraps the web app, which is a React thing.

So you're very much picking the technologies that fit into the particular platforms and not going for a cross-platform solution or even a React Native or something like that. And it seems like that plays into your desire for this big play. You took the time, you bought the domain, you spent all that money, you're designing it for this big idea. I think let's start off talking about your native iOS and Android apps. And are we right when we say that the reason that you're using the native languages is because you care so much about the native experience that you'll pay the time and the

labor to get that done? Who makes those decisions and are we sensing what we think we are? Really, really well spotted from your side. So, for instance, on the mobile client's side with Android and iOS, we broke their architecture in a two-tier model where functionality related to UI is written in Java on the Android side and the Objective-C on the UI side and now more and more of a code there they're done in Swift while the second part we call sync engine which does pretty much all of the hard lifting work on the client side so all of the communication towards back and then parts related to synchronizing state across multiple devices and also doing the parts related to encryption, parts also related to speech coding, video coding. So there, this sync engine layer is written in what we found the best to suit also all this logic and the business logic for a specific platform.

So on Android side, we picked Scala. And on iOS side, we picked Swift. And I'm there quite proud that we were one of the first applications in the App Store that had been deployed with quite much of a code base in Swift. And that's also a lot thanks to one of our team members that used to work with Apple for a number of years. So we've been always pushing their boundary and picking up solutions that are giving the best native experience. And you see there with this native experience also comes battery life.

So on that side, it is really important to preserve the battery life as much as possible. And this is also where this native experience is helping us. But however, we are not there fully, as you would say religious. So certain parts we still do cross-platform. So as you notice, Proteus library,

which is basically dealing with core encryption stuff, that one is written in Rust and it nicely runs cross-platform. Or, for instance, this code that you spotted that is written in C, it is related to audio video libraries. And that one also is quite nicely optimized and is running across different mobile platforms. So we've been there quite pragmatic and we took a quite careful thought about the choices that we were making. And basically all of the choices have been done

by my team and me together and there is always a healthy discussions when we have those architecture discussions and they are always fun and they are always mind-challenging. It's so polyglot, it makes me curious how you found and hired your team and how many of them came from your previous companies. Because you hear a lot of times, we're a Java shop, we're a Ruby shop, we do Node. But Wire has to be in so many different places that you just have all these different technologies, which are diverse and some of the very niche. I mean, Haskell, there aren't too many people who would kick off a business with a Haskell server. So tell us about your team and where they come from.

Who are these people? Those are people that are really also, beside being top- top notch coders or technicians, also really intrinsically good and fun people to work with. And a number of them came from our previous startups. So that startup that was sold to Skype once when it became a part of a Microsoft, it wasn't any more fun for those guys to be part of a massive big corporation.

And then by presenting them our mission, a number of them joined from the very early beginning. And also a number of early Skype employees joined us and also a number of employees from my previous startup, Thelio, which was a voice over IP operator in Europe. So with a number of team members, I've been working or my other colleagues have been working for five, 10, even 15, and in one case, even 20 years. So that was the early team, core team. And then when you have a bunch of clever, talented people that are fun people, then you also attract a number of other great guys. So from the very beginning,

we needed a really fantastic backend that scales a lot. And as you know, Skype didn't have much of a backend. So since we placed our team in Berlin and since we had fantastic mission and since we had already a bunch of cool people on board, we managed to get a number of guys that made some clouds back end and they're part of that back and have been written in Haskell and those are guys that were coding Pascal in their spare time and by joining wire they could do their fun work also during

the work hours so it was very easy to recruit a number of those guys and then as you attract those people then you attract also a number of other talented engineers that are working around the world with the rust or with a husk and berlin is really fun place to live at and it is a kind of a melting pot there are coming people from all over the world to live there and in our team that is in berlin with around 50 people in Berlin, we have 25 different nations there, which is just showing you this fortune that we have in a different background, different cultures. It really creates a fantastic environment to work in. Speaking of developers, it appears that you're also reaching out to developers beyond your company borders with an end-to-end integration API.

Can you tell us what this is about and how you hope developers will use it? Thank you very much for bringing that one up. This is something where we'll be focusing quite a lot from beginning of the next year. Current API that we have together with documentation, which we have is still in its early stage. There I beg for a bit of a patience and forgiveness from developers that jump on it right away and i hope as well are going to be rewarded heavily

for that one being among the early ones so what is quite unique about this API is that it's basically extending end-to-end encryption platform. And this is the first one that we know of doing all of the integrations in the highest possible secure way. So that's currently in beta. There's code examples, but you're saying this is kind of in rapid changing phase or active development. Exactly. So there, please stay tuned. And basically, during the first quarter of the year, we'll make it also available API in a number of more programming languages. And as well, documentation, which is a pretty scarce year, will be at the level where it should be.

One thing that I'm struck by, we mentioned it with the domain and the design and the emphasis on the native clients, everything that you're doing seems very intentional. And so one question we often ask guests on this show is, what kind of open source project are they? Because open source is not one size fits all. And especially with businesses,

with open source products, often they're different in their DNA, even though the code is all viewable and the license may be very favorable and all that. But is wire open source, like you can view our source and you can clone our source? Or is it open source like we want everybody

to be working on this together as a community? How does it look from the outside? What do you expect? So in the first phase, it was more about being transparent because in order to attract a number of users to develop on a top of your code and around your code, you need to provide them necessary attention

and also attention which they deserve in order to create great value for you and also in a same way to create it for them and as as we are moving further this is where is going to be our focus and also a bit of exclusive information is that for some parts of the code, we are likely to go with a less restrictive license than GPL v3. But I'll be really glad to talk about it more, hopefully in the next year when we talk again. I'm kind of curious, too, to Jared's point. You know, when you're open source, it's not one size fits all. And in a lot of cases, you've kind of come up in a different scenario

where you have deep roots in what we talked about earlier, which was the internet protocol, the internet low bitrate code, ILBC, kind of getting your grassroots into open source there, kind of seeing a big win, garnering a community, ultimately turning into WebRTC. And in this case, it's slightly different because it seems like it's sometimes you describe it as open core or open source and you build a business around the open source you develop.

Is your hope maybe from coming on a show like this where you speak to a pretty diverse audience of developers and highly likely that they really care about open source because they're listening to the changelog, is your hope that, you know, one, you get a lot of new users or a lot of new eyeballs on what you're working on, but also potentially developing a community around it. Because that's the one piece I see missing. And as Jared said, you're very intentional and very clear with your speech and who you are. The community aspect is the one that seems to be missing.

Excellent point. And this is the part that I'm personally quite excited about and also a number of our investors are excited about and also my colleagues. So compared to some of the other secure solutions provider at Wire, also we believe in a federated approach. And also there, what you see in vicinity is that some more of verticals that are emerging need also to deploy end-to-end encryption, such as as automotive especially with the driverless cars connected home digital health etc so our vision there is that messaging platform will be interoperating with all those and they're in a similar way as we had previously a WebRTC. We see that there is going to be a big need for a secure protocol solution that will be connecting

those different islands and further fostering innovation as we are going to be crossing those different verticals. And as you notice and as you've seen, we always love to think big and to think some years ahead of us. And this is something where we are quite committed and excited about this federated approach. Also, again, taking parts of our intellectual property to standardization and then by enabling the whole world around us, create also more business for us and also bring more value to our shareholders and there nothing happens without good community support and we'll make sure that we address community around us in the right way and also to attract a wide community and give them a really exciting platform to work on. You might get a chance to do that in a deeper scale.

I'm reading further into wire.com slash security, which we referenced a couple of times earlier in the show, which we also will link up in the show notes. But down in your transparency area, you mentioned that you're open source, that you're GPL version 3 licensed. But then you also mentioned in that same sentence or in that same paragraph,

a self-hosted server option, which I imagine is intended for someone to install themselves onto their own cloud as they see fit. This is coming in 2018. Can you kind of maybe tee up this horizon, this future that you're building towards? Also, excellent point and point that I'm quite excited to talk about. So this federated approach is something where we see massive value and where we see a big opportunity, not only for a wire, but also for a number of other companies, because we really don't believe in one ring to rule them all.

And we do not think that people are going to be using one solution, whether it is from Facebook or Google or Microsoft or Apple, for all those verticals, for consumer messaging, for business messaging, for large enterprise messaging, for messaging towards the automotive with a connected home, etc. So as you've seen with our backend, it is quite nicely written code is roughly like 30,000 lines of a Haskell code and it should be possible to port it also on a lower footprint devices or servers.

So there I'm really excited about the potential that this is bringing into the future and about all of the innovation that can happen around it. Very good. Any closing thoughts for those listening?

Any ways to get involved? Any inroads? Obviously, you got a Medium blog people could be reading. You've got a couple of different things people can go check out in terms of your code base. That is at github.com slash wireapp.app. We'll link that up in the show notes, of course, but any other places where we can send people to to kind of catch up further on what you're up to? Our Twitter account is definitely

one of the places where you can stay up to date with all of the news that are happening around wire. And the other ones that you mentioned are the ones that are really good for a starting point. an API platform that will be deploying in 2018. And there, especially we value all the feedback related to wire application, privacy policy, terms and conditions, features that are missing, and especially about the things that are

not working well and that can be improved. And Twitter there is a perfect channel to pass it back to us. Excellent. That's actually a nice Twitter handle too, twitter.com slash wire. So you're really

aside from GitHub, you got Wire app on GitHub, but that's okay. You can't have Wire everywhere. Maybe you can. We'll see. We missed it by a little bit on GitHub. There you go. Well, Alan, thank you so much for sharing your time with us and walking us through some of the history to the earlier protocols, the earlier conversation around Skype, that's always enlightening to kind of, you know,

peel back the layers to a tool we've used for years and rely upon. And I have to say, during this conversation, Wired seems pretty awesome, and I can't wait for maybe, you know, some features that are focused towards podcasters that can make our jobs a little easier and secure. So, Alan, thank you so much for your time and appreciate it.

Thank you very much for having me in your podcast and would be delighted to hear a bit more on the requirements. Also, to make Wire your tool of choice for the podcast. Will do, for sure. We'll share all of our dreams and we will hope you make them true. Thank you so much. Alright, that's it for this

episode of The Change Log. If you enjoyed the show, share it with a friend. We're going to snap a podcast, go on Overcast and favorite it. Tweet about it. Smoke signal it. whatever it takes. Share it with a friend. Thank you to our sponsors, Bugsnag, DigitalOcean, GoCD, and TopTow. Also, thanks to Fastly, our bandwidth partner.

Head to Fastly.com to learn more. We host everything we do on Linode cloud servers. Head to Linode.com slash changelog. Check them out, support the show. The changelog is hosted by myself, Adam Stachowiak, and Jared Santo. Editing is done by Jonathan Youngblood. And our awesome music is produced by Breakmaster Cylinder. Head to changelog.com to find more episodes just like this.

Or head to your favorite podcast app and click subscribe. Thanks for listening. We'll see you next week. Thank you.