Ver.0.16.0

How to Build Secure Chat With AppFriends and Virgil

By on September 14, 2017 in Uncategorized

We recently wrote an encryption extension to AppFriends, and working together with our AppFriends SDK, we were able to put together a sample end to end encrypted chat app in less than 3 days. You can find the app here.

After we launched our in app chat service, AppFriends, there’s been a lot of interest around how to make the chat content completely private and secure. The team moved quickly and identified what we needed to do:

  1. need asymmetric encryption, and only the user should have the key to decrypt the message sent to him/her
  2. when a message is received, there has to be a way to verify the origin of the message
  3. in a group chat, a message must be encrypted in a way that everyone in the group can decrypt
  4. some of our customers would still want to be able to see the chat content, so the encryption must be an optional feature which can be easily turned on/off. AppFriends should not have any dependency on third party encryption service.

After searching, we decided to use Virgil. For detail information on Virgil, please visit their website. In this article, we are going to focus on how we achieve the goals above.

Goal 1: Total Privacy — only the user has the key to decrypt a message

Step 1: We generate the private-public key pairs in the app on the user’s device.

Step 2: private key is saved in the device’s safe storage only

Step 3: public key is published to our server so that they can be used by others to encrypt the messages

Result: Since the private key is saved only on the device, only the user of the device can have access to it. It means unless the user lost both the device and the password to the device to someone, nobody can decrypt the message encrypted by the public key. Even though the encrypted messages are stored on our server, we or any third party have no way to read them.

Goal 2: Verify the origin of the message

Since the public keys are public, potentially anyone can send a message with your public key and pretend to be you. As a result, it’s absolutely necessary to authenticate the origin of the message.

Virgil provides very convenient API for a user to sign the message with private key before sending it. At the receiver end, we only need to authenticate the signature on the message with the public key to verify the origin of the message.

Goal 3: Group chat messages must be readable by all users in the group

With Virgil’s API, we can encrypt the message with all public keys of the members of the group. The message can then be decrypted by any one of the private keys of the users in the chat group.

There’s a small catch: if a user joined a group chat after there’s already some conversation happened, the newly joined user cannot read the messages that was sent before he joined. We believe this is going to be fine for most applications.

Goal 4: Encryption should be optional, and AppFriends should not have any dependency on Virgil

To make AppFriends not depend on Virgil, we made the encryption function as an extension to AppFriends rather than including it inside AppFriend SDK. We started by defining protocol/interface of the encryption extension, so AppFriends SDK can simply call the extension which implements the protocol/interface, and not care about how they are implemented. Thus, AppFriends is not dependent on Virgil. Potentially, the extension can be done using other services similar to Virgil.

If an implementation of the extension is not provided to the AppFriend SDK, it can just assume encryption is not needed, and simply not send messages through the encryption extension. Our customers who do not need encryption can still enjoy the old services without changing anything.

Room for Improvement

With the current setup, the private key is stored on the user’s device. If the user loses the device, he will no longer have access to the messages he sent/received. We can use multi-factor authentication to allow users to add new device after the old one is lost, but since we can’t recover the private key, the old messages cannot be decrypted anymore.

Thank you for reading! If you have any comment or suggestions, please let me know. Also let me know if you are writing or need a chat function in your app.

Happy coding!

Mistakes Apps Make When Building Their Social Layer, Part 1

By on April 20, 2016 in mobile apps, social, user engagement

In the last post, I wrote about the “Stack Fallacy” and why many apps fail going social. The gist of it is that the social layer is really another “stack” sitting on top of the base app, with very different user requirements than that of the base app. You can read up on it here.

In this and the next few posts I’ll highlight a few specific examples of sub-optimal decisions (in terms of engaging users) we see app developers make time and again when building the social layer for their apps. This post will discuss why app makers specifically need to reconsider the ubiquitous “comments after articles” UI, while later posts will talk about the perils of over-censoring users, and the problem with limiting what content users are allowed to share.

Comments after articles. 

Comments_block

Photo credit: Moodle

We can generalize this feature to “comment sections after individual pieces of content”. This is a very popular user interface – you see it in news apps, in food apps, in fluffy puppy apps – pretty much every app that wants to do social puts in comment boards as their first feature. So why is this less-than-optimal UI for engaging users? Let’s say you have a news app and over the past month your app has uploaded 1,000 articles and there is 1 comment posted after every article. That’s 1,000 comments – nice! The problem is, when any one user visits your app, she probably only reads 1-2 articles, in which case she only sees that 1-2 comments have been posted. The fundamental tenet of social is that users like to do what they see other users doing. Conversely, they are less likely to do things they do NOT see other users doing. So if a user only sees 1-2 comments posted, at best she comes to the conclusion that leaving comments is not a normal thing to do in your app, so she also does not leave comments. In this case, you’ve bloated your app with a feature people don’t want. At worst, she may conclude that your app is not very popular, because if a large amount of user interaction is positive social proof for your app, then the lack of interactions is negative proof, and she may actually leave your app. In this case, your social feature actually decreased engagement.

“But wait”, you might say, “Facebook and Instagram use comment board UI and they are wildly successful!” So what gives?

Facebook users start out much more likely to engage because Facebook is a close network of friends where people post for people they know. When users comment on a post or a picture, they are engaging with their friend, more than they are engaging with the content itself. For most apps, which are not inherently social, commenting does the opposite – it engages with the content rather than with someone you know, so the initial impetus to engage is much lower. Instagram generalizes Facebook’s engagement model through “influencers”. Each Instagram account is essentially a personal “channel” where an influencer cultivates friend-like relationships with followers and distributes targeted content to them. Comment boards are not what’s engaging users for Facebook and Instagram – the structure of their community provides the impetus to engage, and comments are simply the end result.

Our suggestion. Unlike FB or Instagram, most apps distribute content for a general audience, where the impetusChannels_home_licensed to engage is far lower at the start. In these cases, we suggest aggregating user posts so users perceive communication and engagement as normative and popular things to do in the app, and that in turn creates motivation for further engagement. When we were designing the AppFriends plugin, we consciously made a decision NOT to provide comment boards after individual articles. Instead, we give apps public chat channels that aggregate user messages based on topic, so they do not dilute engagement among individual pieces of content.

We also suggest adopting influencer-curation models like Instagram – in fact, almost any app can do so. Every app has power users, and you can empower them with the tools to curate content and engage with other users. AppFriends chat channels, for example, can be created by power users who take ownership of their own channel and personally engage with followers.

Other things you can do include building features that capture “passive” user engagement: i.e. activity feeds that show users what other users are doing in the app, whether or not they actually post something. Or showing “number of views” that tick up every time someone views a piece of content, so whether or not anyone comments or likes, their interaction with the content is recorded to provide social proof to other users.

Stay tuned for the next post in our series on bad social features, this time on the perils of censoring your users. If you have comments or suggestions, please email me at kejia.tang@appfriends.me. We’re always looking to learn from the experience of app makers in engaging users and building social.

 

The “Stack Fallacy” and what most apps get wrong about social

By on March 18, 2016 in mobile apps, social, user engagement

I was reading the following article about DropBox and the Stack Fallacy, and it struck me that this is exactly the problem that AppFriends is solving with our in-app social layer: Big Companies and the Stack Fallacy.

A quick summary: in a technical stack, there are a number of layers sitting between the foundational server and the end customer. The “stack fallacy” was adopted by a number of VCs to describe companies who underestimate what it takes to build the layer above their own core business layer. This happens because companies lower in the stack believe that since they build the foundations of the higher layers, they know everything you need to build that higher layer. This is a fallacy because as you go higher in the stack, customers’ needs change, and without knowing what the end customer wants in that layer of interaction, you cannot build successfully. Examples include Google trying to go from search data to social networks and Oracle trying to compete with Salesforce. Conversely, going lower in the stack often does work (i.e. Google going into cloud storage), since the company is already a customer of that lower layer, and understands what needs to improve.

So back to social. AppFriends is a plug in social layer for apps, and by providing front end UX/UI in addition to backend hosting, we’re essentially solving the “stack fallacy” that a lot of apps have in relation to the social layer sitting atop their app. There are countless examples of apps that tried to add social features but weren’t successful. This isn’t because social doesn’t work or the app developers aren’t skilled – on the contrary, the app developers may be extremely skilled in building their app, whether it is a sports app, a travel app, a music app, etc. However, social features are really a higher layer sitting on top of their app – user expectations of social are different than their expectations of the core app, and what users want out of social is often quite different than what they want out of the underlying content or commerce or utility app. As a result, the customer knowledge required to build this higher layer is also different.

This is why in addition to being a backend host, AppFriends provides out-of-the-box social UX/UI that is thoroughly researched, tested, and also continuously iterated based on users’ social behavior. Social, community, in-app chat, message boards – none of those magically make users more engaged. Building UI that understands what users want out of social and how they interact is critically important. This is why AppFriends takes care of the social layer, front end and backend, so our customers can focus on building the best sports/music/travel/anything app in the app store.

Fotosearch_k10089149

Moderating Community

By on December 1, 2015 in mobile apps, social, user engagement

In our rush to build community and create social interaction, moderating sometimes get overlooked. When we introduce a great social UX, we get so excited about the spike in user engagement, the vibrancy of interaction, the perfect strangers bonding over app content, that when trolls emerge and discussions get hostile, we can get caught off guard, overwhelmed, and not know what to do. While AppFriends comes with robust word filtering and manual tools for banning bad actors, human moderators were still required for version 1, and we and our customers learned some important lessons from that experience:

  1. For apps: If app owners want their apps to “go social”, they need to do it with their eyes open. Flaming, spam, and abuse will inevitably creep in when you allow users to communicate and post content. While all of us versed with social networks know this, most of us have never been moderators so we don’t see the dark sides of major online communities. When we start moderating our own app communities then, we can get caught off guard as to how vicious bad actors can be. This can be demoralizing, even if the rate of bad actors in your app isn’t anything more than what’s normal. App owners need to be mentally and emotionally prepared in advance for the task of moderating their app communities.
  2. For AppFriends: we learned that relying on human moderators is not enough. We had built in tools for human moderators to control their communities, but ironically, the success of our product led to faster growth and more lively communities than we or our customers anticipated, and our customers were not able to keep up moderating 24/7. This is why for version 2 (releasing February 2016), we put in community moderation, where individual users can mute abusers and users who are muted X number of times are auto-suspended upon further review. This allowed users to control their own experience, while still leaving final judgment to app admins.

Allowing your user communities to interact can bring powerful benefits like greater enthusiasm, retention, appreciation, and evangelism for your app, but it’s important to keep vigilant while keeping perspective when dealing with bad actors. Don’t get discouraged by a few bad apples, but definitely keep them in check!

Retention

Mobile apps that retain users the best

By on October 5, 2015 in mobile apps, social, user engagement

We talked in our last post about the importance of user retention and engagement – it doesn’t matter how quickly or cheaply you can acquire users if none of them stay on your app. But how do you engage your users and keep them coming back?

I think it’s instructive to look at the top apps. From top app charts, you’ll see that the majority of top apps are apps that connect people – social media, messaging, or utility apps with a strong social component like Yelp or Tinder (“utility app” = app that is a tool for accomplishing some specific task). We heard a talk the other day where a product lead at Spotify said showing new users the playlist of a current user during onboarding is one of the single most effective ways to retain that new user. If you look closer at a specific social category, i.e. messaging apps, you’ll find that they have double the 1 month retention rates of the average app, growing to a 5.6x advantage in 12 month retention rates.

This is the power of connection and community, where app users can engage each other rather than relying on the app admin to bomb them with push notifications

Now, you might think that with these results, every app would be a social app. Yet from our experience building 30+ apps ourselves and using several hundreds more, I would say that most apps are content and utility apps with either no social component, or a throwaway comment section at the end.

But there is no reason that should be the case. While not every app should be social (although a social flashlight app would be hilarious – “shine a light on your creepiest places and post up a picture!”), many apps have a latent community of users. Content apps, for example, often have users who are very passionate about what they’re consuming (i.e. sports, news, fashion, etc). There’s no reason why that community cannot be activated with the right featureset and UX. And if that featureset can take advantage of what makes messaging apps so darn sticky, that’d be even better.

Over the next few weeks we’ll tackle some specific examples of building a social community, and also take a deeper look into what makes messaging apps so engaging. Stay tuned!