<story><title>Pidgin working on implementation of Facebook Messenger protocol</title><url>https://hg.pidgin.im/soc/2015/jgeboski/facebook/</url></story><parent_chain><item><author>cbhl</author><text>Have you &lt;i&gt;seen&lt;/i&gt; XMPP? Chat is so much more than just text now; it&amp;#x27;s &amp;quot;voicemail&amp;quot;, and &amp;quot;photos&amp;quot;, and &amp;quot;videos&amp;quot;, and &amp;quot;stickers&amp;quot;, and &amp;quot;Western Union&amp;quot; and &amp;quot;voice calls&amp;quot; and &amp;quot;video calls&amp;quot; and so much more. Plus, XMPP, is, like, XML.&lt;p&gt;Open protocols and federation are cool and all, but XMPP is not the protocol that will let someone be competitive in this space.&lt;p&gt;(Disclaimer: I work at Google. This is my opinion. I do not work on Hangouts.)</text></item><item><author>jkarneges</author><text>This really ought to be the other way around. If Facebook wants to be accessed by popular client software, then it should expose its service using standard protocols. So Facebook pulls XMPP and the community reacts by rewarding them with a custom integration? How are we supposed to get ahead here?&lt;p&gt;I know Pidgin is a pragmatic project, not a political one, but this doesn&amp;#x27;t sit well.</text></item></parent_chain><comment><author>heavenlyhash</author><text>Having recently started working on a chat client that was intended to speak first-and-foremost XMPP, I have to agree: XMPP is... it&amp;#x27;s decades out of date and missing a number of absolutely critical, central ideas that are essential to making stuff &lt;i&gt;work&lt;/i&gt;.&lt;p&gt;Examples:&lt;p&gt;- unique message IDs?  Absent.  XEPs kind of provide; but I can&amp;#x27;t tell you which of the three or for relevant ones are the &lt;i&gt;most&lt;/i&gt; relevant (AMP IDs from XEP 0079? Stream Management from XEP 0198?  Acking from XEP 0184?  Something from Carbons or MAM in 0313 or 0280?  You know, if you wanted some light reading...).&lt;p&gt;- multi device?  Oh.  My.  God.  It&amp;#x27;s bananas.  The spec behavior is that whenever a client sends a message, the server is supposed to consider that one the most alive, and then route all future messages &lt;i&gt;&lt;/i&gt;&lt;i&gt;exclusively&lt;/i&gt;&lt;i&gt;&lt;/i&gt; to that one.  So you send a message on your phone?  Yeah, your desktop is just going to &lt;i&gt;silently stop receiving messages&lt;/i&gt;.&lt;p&gt;- there&amp;#x27;s a concept of &amp;quot;message carbons&amp;quot; to deal with this.  This involves re-sending all your messages back to the server after you receive them, with special instructions to send them back again to your other clients.  The amount of redundantly redundant XML involved is eyewatering.&lt;p&gt;Combine that multidevice behavior (messages can get randomly routed anywhere at any time) with the wild-west nature of message delivery acks, and you can see how ridiculously difficult this makes the basic idea of &amp;quot;all clients should see the same picture&amp;quot;.&lt;p&gt;Overall, the XEP process, conceptually, is a great example of open extensibility.  The trouble is, so much of this stuff is &lt;i&gt;core&lt;/i&gt; to sane message delivery semantics that it really, practically speaking, causes huge problems when it&amp;#x27;s all considered &amp;quot;extensions&amp;quot;.  Stuff like message IDs fundamentally shouldn&amp;#x27;t be an extension because it&amp;#x27;s just too critical that all minimum-viable clients agree.  You just can&amp;#x27;t build higher level stuff without that.  XEPs are great.  A community process for extensions should exist.  It just needs to exist for extensions, not subsume the total set of realistic minimum viable features.&lt;p&gt;I want an open chat protocol.&lt;p&gt;I thought XMPP might be the one.  Then, as the parent comment jibes, I actually looked at it.  Tried to write something with it.&lt;p&gt;XMPP is not prepared to be the one, in any sense at all except for legacy support.  I have all the respect in the world for all the folks who put effort into trying to make an open chat standard, but... honestly, we need a stronger foundation than this.</text></comment>
<story><title>Pidgin working on implementation of Facebook Messenger protocol</title><url>https://hg.pidgin.im/soc/2015/jgeboski/facebook/</url></story><parent_chain><item><author>cbhl</author><text>Have you &lt;i&gt;seen&lt;/i&gt; XMPP? Chat is so much more than just text now; it&amp;#x27;s &amp;quot;voicemail&amp;quot;, and &amp;quot;photos&amp;quot;, and &amp;quot;videos&amp;quot;, and &amp;quot;stickers&amp;quot;, and &amp;quot;Western Union&amp;quot; and &amp;quot;voice calls&amp;quot; and &amp;quot;video calls&amp;quot; and so much more. Plus, XMPP, is, like, XML.&lt;p&gt;Open protocols and federation are cool and all, but XMPP is not the protocol that will let someone be competitive in this space.&lt;p&gt;(Disclaimer: I work at Google. This is my opinion. I do not work on Hangouts.)</text></item><item><author>jkarneges</author><text>This really ought to be the other way around. If Facebook wants to be accessed by popular client software, then it should expose its service using standard protocols. So Facebook pulls XMPP and the community reacts by rewarding them with a custom integration? How are we supposed to get ahead here?&lt;p&gt;I know Pidgin is a pragmatic project, not a political one, but this doesn&amp;#x27;t sit well.</text></item></parent_chain><comment><author>jkarneges</author><text>Standards tend to run behind the state-of-the-art, but that&amp;#x27;s not a reason to avoid them. For example, the iPhone continues to support SMS for interaction with non-iPhone users, even though the iMessage protocol is richer.&lt;p&gt;If Facebook valued compatibility with as many different products as possible, then they would keep XMPP support. The issue is not about features or XML. Most likely, it&amp;#x27;s about them wanting full control over the end-user experience: &amp;quot;We recommend people access Facebook Messages on the desktop via Facebook.com or Messenger.com.&amp;quot;</text></comment>