Comment by im2w1l
10 years ago
Why was it hard to deliver messages to iphone using p2p? I mean I guess they couldn't open ports and listen for messages, but that should have been true for plenty of NATed systems too right?
10 years ago
Why was it hard to deliver messages to iphone using p2p? I mean I guess they couldn't open ports and listen for messages, but that should have been true for plenty of NATed systems too right?
The problem was the avalibity when the sender was offline. You send a message from your iPhone to your friend who has an Android. Your friend doesn't have reception, and after sending the message you kill Skype b/c of the battery drain (otherwise it is being part of the p2p network).
Your friend now gets reception and will get your message... between a minute and a couple of hours. Most likely when you turn your phone back on, as the p2p network was not designed to store and propagate offline messages.
Meanwhile someone at Whatsapp built a key value pair on a server and if you had reception, you got the messages immediately and reliably. Oh, yeah, because the read and unread message states in Skype also propagated via the p2p network and also got took a while to arrive...
I'm really surprised that Skype didn't just build a separate system for mobile. It seems even a simple evaluation of the facts (needing hundreds of engineers to alter an already stable product) pushes things more to the server side than the P2P side.
hindsight is 20/20. It would be quite easy for a team of developers and product managers to get together to discuss "how we take what we have and extend it to cover the new use case" rather than "what is the best approach for the new use case".
1 reply →
We did acquire GroupMe with the same thinking: take that startup with a good group messaging product and integrate them into Skype.
Except this never happened, GroupMe is still a standalone app and pretty much a standalone team. I am not sure why we didn't or could't integrate them, the Microsoft aquisition of Skype, and the subsequent integrating with Lync (and the birth of Skype for Business) probably had higher priority.
Reusable components is a mantra within software engineering. People deciding on product direction want to reuse what's available and has been tested: known quantities increase confidence levels. Unfortunately, the reuse in the large vs. reuse in the small dilemma gets lost in the decision-making. At a certain job level, applications become components represented by geometric shapes on a whiteboard or electronic diagram. At that level, components look like good candidates for reuse.
Unfortunately "the devil is in the details". Reuse, in this case, hurt the messaging app because of a fundamental difference between connection and connection-less communication. I'm sure the engineers working on the messaging app understood the problems. But, they were most likely not a key part of the decision chain.
1 reply →
Guessing it was because both phones need to have the app open at the same time. Skype's main p2p tech was built for the real-time synchronous chat use-case (like AIM), as opposed to the chat-log in the cloud use-case (like Slack).
Exactly. In hindsight we should have just built a separate messaging layer with a server backend like everyone else was doing.
However Skype had no history of running servers. Just keeping the login servers up and running (a handful of them) was enough of a challenge.
Plus when the company's success and revenue was driven by the P2P team and they said the same layer will work for messages... there was no one strong enough to argue.
And when it was obvious that Skype messaging was sub par, the company just went in denial. "We aren't really competing with Whatsapp, because they don't do video" got us another year or two of not doing too much about the root cause.
It was after the Microsoft aquisition when some MS architects told the engineers upfront that p2p and realtime messaging - forget about it.
I hope everyone within Skype used it as your main communication tool. If you did, the problem would have been so obvious. Not so long ago, it was revolutionary to be able to send messages to someone even when they were offline. However, once someone implements it every other chat app had very little time to do that. IMHO, there is nothing inherent about big companies from reacting quickly. It usually boils down to the culture of the company that's the cause. Call it "Bias for action" or "Ask forgiveness, not permission" or whatever you want to call it - a company (big or small) that allows people to go quickly fix an issue or try another solution instead of talking endlessly about it, well aware that there is a chance for failure, is the one that's likely to succeed.
13 replies →
I'm not sure if this story has been told this plainly elsewhere, but it probably should. I know plenty of people who got very paranoid of Skype after MS bought them.
I think the denial is the important lession here.
Plenty of people knew it didn't fly, and it couldn't have been that hard to fix it if you really wanted to do it, if you were prepared to drop p2p. But still it was a hard descision to make.
Why do you think it's like that?
1 reply →
Thanks for sharing. I can definetly see how that happens.
We used Skype IM for a long time (inertia). It wasn't just the iPhone. Skype message delivery was erratic on all platforms. It got better, but even now there are occasional delivery delays when I chat with someone who hasn't switched over (we use Slack now).
Yes, there are still traces of the p2p code. Most of messaging has been migrated to server based back ends, but there are still some hybrid solutions in place.
Funny thing the company DNA, P2P is still haunting Skype.
The windows client still has funny bugs like:
1. You receive a message from someone.
(wait a few hours)
2. You open this tab/read the message
3. The number of unread messages counter doesn't update.
3 replies →
Your is a perfect example of the original posting and the comment you are replying to. People have such a hard time acknowledging what they don't know.