Live data from Hacker News

Facebook Messenger XMPP is going away

developers.facebook.com

141–150 of 203 posts

Re: Facebook Messenger XMPP is going away

#141
post #109

Can anybody tell me, why the SIP chat protocol is so under used? https://www.ietf.org/rfc/rfc3428.txt -based on open standards (SIP) -supported by most VoIP servers (so we have full interoperability between vendors such as Cisco, Huawei, Siemens, Voipswitch, Mizutech, Jitsi and others) -simple and extendable -lots of free services, free/open source software. You can also host your own or integrate into your company P…

>-simple and extendable It's the first time I hear anyone describe SIP as "simple". If you printed out all the SIP specs, you'd probably have a pile close to a meter high. Among the protocol crowd (including IETFers) SIP is often regarded as an example of protocol design having gone off the rails in a spectacular fashion. It has been repeatedly beat in the market by proprietary protocols that do things better (e.g.,…

Yes, the SIP protocol is not so simple. However a lot of well working implementations already exists (source code, libraries, ready to use software). The core messaging in SIP (RFC 3428) is extremely simple to add as it is just a single method (MESSAGE).

Adding presence and other funny things with the SIMPLE protocol family is another subject. (However the basic presence is also very simple ...the complications comes when you wish to add file transfer and other fancy things).

But these can be used as an extra so at least the for chat you are fully interoperable with all other vendors.

Re: Facebook Messenger XMPP is going away

#143
post #62

I just wanted to comment on how evil facebook is, but I've decided not to. I think there are enough people here who think the same. What facebook is doing is probably just an example of "Embrace, Extend and Extinguish" [0], though, I understand that their decision is not the same what microsoft did back then. So to my point: Do you really think facebook is doing this only out of pure 'evilness'. They were probably fa…

I read through some github discussions in the tox github page, and I can't really shake the feeling that they don't know much security. Someone had a question about the protocol design and about how secure it was, and the dev just linked to NaCl and said "read the source here and you will see that tox is secure".

It didn't really boost my confidence in their protocol design...

Re: Facebook Messenger XMPP is going away

#144

Earlier quoted context omitted.

i suggested this because i believe xmpp to be superior to irc.

I would like to believe the same. The prosody folks are awesome btw (as an alternative to ejabberd). But there are still open issues. One big one, compared to all the FB/Google/etc. offerings is the ability to have a usable chat log. Current xmpp implementations/standards are more or less useless if you happen to use more than one device and want to look something up/want to see what you wrote to your brother yesterd…

Mam is exactly what I am waiting for too.

It should be in prosody 0.10 [1] (not stable yet) but I did not yet have a change to test it.

(And XEP-0313 is still quite new and experimental)

[1]: https://code.google.com/p/prosody-modules/wiki/mod_mam

Re: Facebook Messenger XMPP is going away

#145
post #19

Earlier quoted context omitted.

It's worth noting that XMPP was based on XML. New hotness is JSON, or maybe even compressed binary protocols.

I don't know if you're being ironic about JSON. Note that jkarneges, who comments elsewhere in this thread, is the creator of Psi [1], arguably the best XMPP-focused messaging client. The value/burden of XML has always been a topic of debate for XMPP. In retrospect, I think it contributed to its lack of appeal, though the extensibility and readbility (ehm, arguably) it provided were unique back then. I've long wonder…

If you're looking for a happy medium between the readability of JSON and XML and the efficiency of ASN.1 and protobufs, take a look at canonical S-expressions[1].

There's an advanced representation, which looks like this: (message (header (sender "Billy Joe Bob") (sent "2015-03-26T12:02:00Z")) (body "Hey guys! Let's meet up for lunch!")). It's possible to encode any byte string using Base64 or hex. It's also possible to encode types with data: (message (header (sender "Billy Joe Bob") (sent "2015-03-26T12:02:00Z")) (body [text/html]"

Hey guys! Let's meet up for lunch!

"))

While there are multiple advanced encodings for the same data (e.g. foo or "foo" or |Zm9v| or #666f6f#), there is a _single_ canonical encoding for any datum: the messages above would be (7:message(6:header(6:sender13:Billy Joe Bob)(4:sent20:2015-03-26T12:02:00Z))(4:body35:Hey guys! Let's meet up for lunch!)) and (7:message(6:header(6:sender13:Billy Joe Bob)(4:sent20:2015-03-26T12:02:00Z))(4:body[9:text/html]42:

Hey guys! Let's meet up for lunch!

)).

A huge advantage of this canonical encoding is that it's amenable to cryptographic hashing and signing; a weakness of JSON is that one has to layer requirements atop JSON itself (e.g. alphabetising object properties) in order for two parties to be able to hash the same datum and get the same value.

Another advantage of canonical S-expressions is that it's straightforward to define a mapping between them and HTML: "This is a nifty paragraph.

" could be represented as ((p (class foo)) "This is a " (em nifty) paragraph. (br)). There are other possible mappings between S-expressions and HTML, of course, but I like that one. Another might be (p (/ (class foo)) "This is a " (em nifty) paragraph. (br)).

[1] http://people.csail.mit.edu/rivest/Sexp.txt

Re: Facebook Messenger XMPP is going away

#146

Earlier quoted context omitted.

I don't know if you're being ironic about JSON. Note that jkarneges, who comments elsewhere in this thread, is the creator of Psi [1], arguably the best XMPP-focused messaging client. The value/burden of XML has always been a topic of debate for XMPP. In retrospect, I think it contributed to its lack of appeal, though the extensibility and readbility (ehm, arguably) it provided were unique back then. I've long wonder…

XML is horrendous. Especially to parse/scrape. JSON on the over hand is a breeze.

Only if you don't understand XML.

* XML has a formal, class-based description language (XML Schema) with strong typing, polymorphism, and - best of all - self-descriptiveness.

* Languages like Java have a seamless, bidirectional mapping to XML Schema.

* XML has a rediculously powerful and elegant transformation language (XSLT) which makes scraping, selective data extraction and processing trivial.

The problem with XML is that people who require instant satisfaction are not willing to invest the time to understand it, and the mature tooling ecosystem around it.

The XML ecosystem solves problems, and contains solutions to problems, that the JSON / JavaScript ecosystem can only dream of, and is hell-bent on partially re-inventing.

If you need strong-typing and self-descriptiveness, you're out of luck with JSON. Binding JSON to a strong-typed language like Java or Haskell is a total ball-drag compared to XML + Schema.

Re: Facebook Messenger XMPP is going away

#147
post #145

Earlier quoted context omitted.

I don't know if you're being ironic about JSON. Note that jkarneges, who comments elsewhere in this thread, is the creator of Psi [1], arguably the best XMPP-focused messaging client. The value/burden of XML has always been a topic of debate for XMPP. In retrospect, I think it contributed to its lack of appeal, though the extensibility and readbility (ehm, arguably) it provided were unique back then. I've long wonder…

If you're looking for a happy medium between the readability of JSON and XML and the efficiency of ASN.1 and protobufs, take a look at canonical S-expressions[1]. There's an advanced representation, which looks like this: (message (header (sender "Billy Joe Bob") (sent "2015-03-26T12:02:00Z")) (body "Hey guys! Let's meet up for lunch!")). It's possible to encode any byte string using Base64 or hex. It's also possible…

> there is a _single_ canonical encoding for any datum: the messages above would be (7:message(6:header(6:sender13:Billy Joe Bob)(4:sent20:2015-03-26T12:02:00Z))(4:body35:Hey guys! Let's meet up for lunch!))

This reminds me a lot of bencode, with the advantage for bencode that it doesn't need any fiddling for non-printable characters: no more base64, no more hex.

Re: Facebook Messenger XMPP is going away

#148

Earlier quoted context omitted.

I don't know if you're being ironic about JSON. Note that jkarneges, who comments elsewhere in this thread, is the creator of Psi [1], arguably the best XMPP-focused messaging client. The value/burden of XML has always been a topic of debate for XMPP. In retrospect, I think it contributed to its lack of appeal, though the extensibility and readbility (ehm, arguably) it provided were unique back then. I've long wonder…

I don't see why I can't use XML, JSON, MsgPack or YAML. Couldn't the parsing be a pluggable component? Just set a standard on how data is structured and let third-parties figure out how data is parsed.

And that would improve the XMPP adoption and experience by ... ?

Are you saying mom and dad aren't using XMPP because the message is sent using XML based stanzas? Facebook is ditching XMPP because of the X?

It doesn't matter?

Re: Facebook Messenger XMPP is going away

#149
post #3

Is there any other way to work with Facebook Chat, now that XMPP is gone?

Supposedly this? https://github.com/jgeboski/bitlbee-facebook I think this one already uses the Graph API directly.

This looks very good, did someone try it out?

Re: Facebook Messenger XMPP is going away

#150

Earlier quoted context omitted.

This is what we get when we embrace closed platforms. Free Software gets you nice, simple, easy to use services and closed platforms will always manipulate you for their needs. This is why I want to make a Free Hardware cell phone. I have made one wireless product already and wrote the frequency hopping stack myself, but something like a phone needs better data rates and a more advanced protocol. Still, I dream of a…

> Free Software gets you nice, simple, easy to use services While there are many upsides to free software, usability and user friendliness were never one of them. Hackability, sure. But most people don't care, let's be frank. I will use Hacker News because it works despite being proprietary software.

Hacker News is not proprietary software. It's open source under the Perl Foundation Artistic License 2.0 (FSF compatible). It's even written in Arc Lisp, which is nifty.

Some of us do care.

Post reply on HN