[liberationtech] Why Skype (real-time) is losing out to WeChat (async)

Randolph D. rdohm321 at gmail.com
Tue Dec 25 23:17:00 PST 2012


encrypted chat is here http://interface.sf.net  please help to compile it
for android in its simplehost.
Am 24.12.2012 07:10 schrieb "Nathan of Guardian" <
nathan at guardianproject.info>:

>
> I know in the LibTech and broader global activist/NGO community, there
> is still quite a bit of focus on Skype. However, during my recent time
> in India with the Tibetan community there, I have seen Skype, on mobiles
> at least, almost thoroughly replaced by WeChat, a WhatsApp/Kakao clone
> made by TenCent, the same Chinese company who created QQ. To my personal
> horror, we have gone from a somewhat secure Skype with a questionable
> backdoor policy, to a non-https, China-hosted service who is a known
> collaborator with the Chinese government.
>
> The only I thing I felt productive to do (other than scream and pull out
> my hair) was to think about why this is happening from a user
> perspective. Why is a text messaging/push-to-talk model winning out over
> an instant messaging/VoIP model, in places like Africa and Asia,
> regardless of known increased risk and decreased privacy and safety?
>
> Other than the typical "users are dumb" answer, I think there are some
> deeper useful factors to consider. Overall, I think we are seeing that
> when smartphones are plentiful, but bandwidth is still a challenge, we
> need to think about communications in a more asynchronous model than
> real-time. I don't think this community should get too caught up in
> building "Skype replacements". I think more we should think about what
> features otherwise great, secure apps like Cryptocat, RedPhone,
> TextSecure, Gibberbot, etc are missing to make it possible for them to
> replace the functionality and experience users are expecting today.
>
> Why Skype/real-time is losing
>
> 1) Noticeable impact on mobile battery life if left logged in all the
> time (holding open sockets to multiple servers? less efficient use of
> push?)
>
> 2) Real-time, full duplex communications requires constant, decent
> bandwidth; degradation is very noticeable, especially with video
>
> 3) App is very large (a good amount of native code), and a bit laggy
> during login and contacts lookup
>
> 4) Old and tired (aka not shiny) perception of brand; too much push of
> "pay" services
>
> 5) Requires "new" username and password (aka not based on existing phone
> number), and lookup/adding of new contacts
>
> 6) US/EU based super-nodes may increase latency issues; vs China/Asia
> based servers
>
> Why WeChat (and WhatsApp, Kakao, etc) async are winning
>
> 1) Push-to-talk voice negates nearly all bandwidth, throughput and
> latency issues of mobile.
>
> 2) Push-to-talk is better than instant messaging for low literacy,
> mixed-written language communities; The "bootstrap" process for Skype is
> very text heavy still
>
> 3) Apps feel more lightweight both from size, and from network stack
> (mostly just using HTTPS with some push mechanism)
>
> 5) Shiny, new hotness, with fun themes, personalization, and focus on
> "free"
>
> 6) Picture, video, file sharing made very easy - aka a first order
> operation, not a secondary feature; chats are a seamless mix of media
>
> 7) Persistent, group chat/messaging works very well (since its just
> async/store and forward, its very easy to send many-to-many)
>
> 8) Identity often based on existing phone number, so signup is easy, and
> messaging to existing contacts is seamless
>
> 9) More viral - you can message people not on the service, and they will
> be spammed to sign up for the service
>
> Anyone want to call b.s. on this theory? Is my thinking headed in the
> right direction? Should we try to turn Gibberbot into a more-secure
> WhatsApp/WeChat clone?
>
> All the best from the Himalayas,
>     Nathan
>
> --
> Unsubscribe, change to digest, or change password at:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20121226/ad1d4a4b/attachment.html>


More information about the liberationtech mailing list