Journal Abandon de Messenger par MS

Posté par . Licence CC by-sa
Tags : aucun
20
11
jan.
2013

\o/

Ave,

Selon Ars Technica, Microsoft arrêtera le service Messenger à partir du 15 mars prochain, forçant la migration vers Skype. On se souviens avec émoi des migrations vers linux empêchées parce qu'il manquait MSN Messenger et ses kikoololeries ! Et ce malgré les efforts considérables de projets comme aMsn.

Est-ce l'effet GTalk ou simplement la volonté de MS d'unifier ses technologies de messagerie après le rachat de Skype en octobre 2011 ? Est-ce que la base utilisateurs va suivre massivement cette migration vers un logiciel client moins fonctionnel ?

À noter que Skype a un support XMPP depuis 2011. Choix forcé par celui de Facebook. La situation est claire, XMPP est le standard de facto de la messagerie, et on ne peut que s'en réjouir !

http://arstechnica.com/information-technology/2013/01/microsoft-messenger-service-not-going-anywhere-just-yet/#p3n

  • # Messagerie...

    Posté par (page perso) . Évalué à 6.

    Ce qui m'inquiète c'est que du côté de XMPP, GTalk a quand même bouffé énormément de parts de marchés et que la plupart des utilisateurs s'y connecte depuis gmail ou l'appli gtalk android. Ça veut dire qu'ils pourraient décider d'ajouter des features non standards très facilement ! Et puis on voit par exemple de très bons outils comme le Google Hangout pour les conférences, sauf que je n'ai pas vu de clients libres natifs, obligé d'utiliser son navigateur et leur serveur. Bref, tout cela m'inquiète un peu.

    Du côté MSN, je sais pas trop s'il faut s'en réjouir, si ça permet de renforcer la position de Skype qui est quand même bien pire que MSN d'un point de vue ouverture…

    • [^] # Re: Messagerie...

      Posté par (page perso) . Évalué à 3.

      Ça veut dire qu'ils pourraient décider d'ajouter des features non standards très facilement !

      Certes, mais XMPP est basé sur XML contrairement à MSN.. si des extensions il y a, ça reste nettement plus facile à parser/implementer que de se taper tout par rétro-ingénierie comme avec MSNP

      Du côté MSN, je sais pas trop s'il faut s'en réjouir, si ça permet de renforcer la position de Skype qui est quand même bien pire que MSN d'un point de vue ouverture…

      Je reve d'une gateway XMPP pour skype.

      • [^] # Re: Messagerie...

        Posté par (page perso) . Évalué à 3.

        Je reve d'une gateway XMPP pour skype.

        Ça existe spectrum le fait, mais c'est un sale bricolage avec une surcouche au client proprio.

        À une époque on avait parlé d'une rétro-ingénierie réussie, qui avait permis de commencer un client libre, je ne sais pas ce qu'a donné cette histoire…

      • [^] # Re: Messagerie...

        Posté par (page perso) . Évalué à 9.

        XML en soi ne garantit pas que la rétro-ingénierie soit plus facile. Si un champ consiste en une seule chaîne de caractère imbuvable qui contient plein d'informations imbriquées les unes aux autres, ça ne change rien par rapport à un format binaire.

  • # Envoie ce commentaire à 10 de tes amis

    Posté par (page perso) . Évalué à 10.

    Avec toutes les chaînes mails qu'il y a pu avoir indiquant que MSN va devenir payant/va s'arrêter/va tuer des lapins, même pas sur que les utilisateurs de ce réseau prennent cette annonce de fermeture au sérieux :)

  • # XMPP : OSEF ?

    Posté par . Évalué à 7.

    S'ils adoptent XMPP mais ne permettent pas de discuter avec d'autres serveurs que le leur, ça n'apporte pas grand chose : on reste prisonnier de leur réseau. Ils pourraient bien continuer à utiliser un protocole maison, à ce compte-là.

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: XMPP : OSEF ?

      Posté par (page perso) . Évalué à 7.

      Non, c'est plus vicieux encore : ça alimente une certaine confusion, et ça leur permet d'encourager des mises en œuvre tierces qui favorisent le développement de leur système fermé.

    • [^] # Re: XMPP : OSEF ?

      Posté par (page perso) . Évalué à 8.

      Ils pourraient bien continuer à utiliser un protocole maison, à ce compte-là.

      Pas vraiment, ça permet de renforcer l'image de sérieux d'XMPP et de le vendre plus facilement. Si tu dis à un décideur pressé que tu lui propose un truc basé sur les même technologies que Facebook, Google, Skype et Microsot, il sera plus vite d'accord. En plus, certaines de ces société ont tendance à publié le code qu'elles produisent, ça peut donc faire un nouveau serveur (ou client) XMPP plus adapté à certains cas, ou l'amélioration d'un serveur existant.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Bon ben c'est le moment

    Posté par (page perso) . Évalué à 7.

    De passer à XMPP :)

    Je rédige une dépêche ce week-end pour expliquer un peu où on va.

    • [^] # Re: Bon ben c'est le moment

      Posté par . Évalué à 0.

      Pourquoi ne pas créer de paquet debian aussi ?
      Et un paquet slackware serait le bienvenu…

      • [^] # Re: Bon ben c'est le moment

        Posté par (page perso) . Évalué à 2.

        quelqu'un s'en occupe (pour Debian), ça fait longtemps qu'il veut faire un paquet, mais il a été débordé jusque là.

        Moi je ne peux pas faire les paquets en plus du dév, j'ai déjà suffisamment de boulot comme ça, mais je peux aider s'il y a des soucis…

        Il y a déjà un paquet Arch sur AUR.

  • # XMPP est le standard de facto de la messagerie

    Posté par (page perso) . Évalué à 2.

    Vraiment?

    La plupart des projets libres utilisent IRC et l'Elite ne jure que par les tribunes.

    http://devnewton.bci.im

    • [^] # Re: XMPP est le standard de facto de la messagerie

      Posté par (page perso) . Évalué à 7.

      On distingue souvent la messagerie instantané du chat public, le premier permet de connecté deux personnes, le deuxième beaucoup plus en même temps. Même si IRC permet de la communication uniquement entre deux personnes et XMPP la communication à plus que deux, le premier est bien plus orienté chat public et le second messagerie instantanée.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: XMPP est le standard de facto de la messagerie

        Posté par (page perso) . Évalué à 3.

        Oui, mais c'est vraiment dommage d'avoir des protocoles et des clients différents. XMPP pourrait tout faire, mais il semble vraiment mauvais pour le chat public.

        http://devnewton.bci.im

        • [^] # Re: XMPP est le standard de facto de la messagerie

          Posté par (page perso) . Évalué à 2.

          En terme de protocole, XMPP est capable de faire tout ce qu'IRC permet de faire, en mieux. Mais les clients XMPP principaux ne privilégient pas les salons et je comprends que certains préfèrent un bon vieux client IRC pensé pour la conversation par salon et rien d'autre.

          À noter qu'il existe des passerelles dans les 2 sens : on peut se connecter à un salon MUC Jabber par le protocole IRC avec le plugin qui va bien et on peut accéder à des salons IRC depuis un client Jabber. Le truc pénible c'est qu'IRC est plus restrictif sur certaines choses, en particulier les nicknames (pas d'espace, pas de caractères spéciaux).

          • [^] # Re: XMPP est le standard de facto de la messagerie

            Posté par (page perso) . Évalué à 5.

            L'interface de chat de groupe de Thunderbird, identique pour IRC et XMPP, est basique mais acceptable. Après c'est toujours inutilisable comparé à une tribune.

            http://devnewton.bci.im

          • [^] # Re: XMPP est le standard de facto de la messagerie

            Posté par . Évalué à 3.

            xmpp permet de se connecter sans signup lourdingue ? Sur irc, tu choisis un nick et tu te connectes au serveur, t'es pas obligé d'enregistrer le nick, et il est libéré quand tu te déconnectes.

          • [^] # Re: XMPP est le standard de facto de la messagerie

            Posté par . Évalué à 3.

            Tiens, en parlant de passerelle, j'en profite pour demander si quelqu'un connaît une solution de passerelle pour se connecter à IRC via un client XMPP, mais avec un fonctionnement de type BNC : en gros, un client IRC tourne sur une machine en restant connecté à un (ou plusieurs) serveurs IRC, et il est lui même serveur XMPP pour retranscrire tout ce qui se passe.

            J'utilise déjà des BNC pour IRC, mais là mon idée, c'est de pouvoir utiliser un client XMPP, pour que dès que je me reconnecte, je puisse retrouver l'historique antérieur à ma connexion, envoyé par le serveur. Ce qui permettrait aussi de rendre les connexions/déconnexions un peu plus "transparentes" lorsque je suis en 3G, par exemple.

        • [^] # Re: XMPP est le standard de facto de la messagerie

          Posté par (page perso) . Évalué à 3.

          XMPP pourrait tout faire, mais il semble vraiment mauvais pour le chat public.

          En quoi ?

  • # Alors

    Posté par (page perso) . Évalué à 6. Dernière modification le 11/01/13 à 10:13.

    1) MSN utilise XMPP donc rien de nouveau ;) => http://blog.process-one.net/on_msn_live_messenger_adopting_xmpp/
    2) Skype, Google Talk et Facebook sont largement plus utilisé que MSN aujourd'hui, si je me connecte sur mon ancien compte MSN, j'ai: 0 contacts online sur 54 …

    • [^] # Re: Alors

      Posté par . Évalué à 0.

      MSN, j'ai: 0 contacts online sur 54…
      J'ai remarqué aussi chez moi… (enfin ce n'est pas toujours zero mais plus grand monde en tout cas…)

      Skype je suis contre mais malheureusement il y a du monde là…

  • # Clients alternatifs ?

    Posté par . Évalué à 1.

    Du coup, quid des clients alternatifs ?

    Parce que jusqu'à présent avec MSN/WLM, ça fonctionnait très bien avec Pidgin.
    Mais pour Skype ? Obligé d'utiliser le client officiel ?

    Je vois que sur les commentaires précédents on parle d'XMPP, mais concrètement ils ont un serveur XMPP accessible via n'importe quel client comme Facebook, ou bien c'est Skype qui est client XMPP juste ?

    J'arrive pas trop à trouver d'infos sur le sujet, et le proxy du taf aide pas.

    • [^] # Re: Clients alternatifs ?

      Posté par . Évalué à 2.

      Pidgin a un module Skype, mais c'est un truc assez foireux qui nécessite d'avoir le client officiel et qui fait tout passer par lui.

      • [^] # Re: Clients alternatifs ?

        Posté par . Évalué à 2.

        Oui j'étais au courant de ce plugin, mais bon ça perd son intérêt s'il faut passer par le client officiel, étant donné que le but c'est justement de s'en passer, au moins pour la partie chat.

    • [^] # Re: Clients alternatifs ?

      Posté par (page perso) . Évalué à 5.

      Ca change rien pour les clients alternatifs à court terme : seul le client Messenger devient "blacklisté" en mars. Le réseau Messenger reste actif jusqu'en 2014 et utilisable par les autres clients, à commencer par Skype lui-même.

      • [^] # Re: Clients alternatifs ?

        Posté par . Évalué à 1.

        Oui, c'est tout à fait vrai.
        Mais ceci dit, il ne faut pas se leurrer, les quelques contacts que j'ai encore sur MSN utilisent probablement le client officiel et à partir du moment où il sera blacklisté ils ne se connecteront plus et resteront sur Skype, ce qui m'obligera forcément à changer.
        Et quand bien même, le problème finira par se reposer ensuite quand le réseau MSN sera définitivement fermé.

        A ce moment là, point de salut, tout le monde sera obligé d'utiliser le client officiel s'il n'en existe pas d'autres.
        C'est pas complètement un drame en soit puisqu'il tourne sous Linux, mais faut en avoir envie entre l'interface lourdingue et le coté boite noire.

        • [^] # Re: Clients alternatifs ?

          Posté par (page perso) . Évalué à 2.

          Oui le problème se posera quand le réseau Messenger sera fermé.
          Cela dit, Microsoft avait ouvert une passerelle XMPP au dessus du réseau Messenger il y a 1 an dans une soucis d'interopérabilité : ils vont peut être faire la même chose au dessus du réseau Skype.

          • [^] # Re: Clients alternatifs ?

            Posté par (page perso) . Évalué à 3.

            Sauf s'ils avaient ouvert la passerelle pour essayer de ré-insufler de la vie au réseau et que suite à son échec leur plan B a été de racheter Skype et de fondre les deux réseaux (jetant l'interopérabilité avec l'eau du bain).

        • [^] # Re: Clients alternatifs ?

          Posté par . Évalué à 1.

          C'est pas complètement un drame en soit puisqu'il tourne sous Linux

          En êtes-vous certain ????? oO
          Permettez-moi d'en douter… :-|

          A mon avis, il va cesser de tourner sous linux et par ricochet ne pourra plus fonctionner sous Android.
          Et je pense que la stratégie de Micro$oft est là et pas ailleurs.

          PS: HORS SUJET : Quelqu'un peut-il me dire comment on souligne du texte ici ?

          • [^] # Re: Clients alternatifs ?

            Posté par . Évalué à 0.

            A l'heure actuelle, oui, il tourne.
            Je n'en ai pas gardé un super souvenir, il manquait des fonctions à l'époque et il avait quelques bugs.

            Ceci dit la remarque est pertinente, si Microsoft décide d’arrêter le dev de la version Linux, ça va être plus compliqué à utiliser. Peut être via Wine ou une VM ?
            Concernant Android par contre, je doute un peu. Il y a beaucoup d'utilisateurs, et arrêter le support pour Android serait se tirer une balle dans le pied.

    • [^] # Re: Clients alternatifs ?

      Posté par . Évalué à 1.

      Note qu'on a un peu le même problème pour QQ
      (le client non-libre en version anglaise ne fonctionne que sous Mac/Windows, le client non-libre sous Linux n'existe qu'en version chinoise, et toutes mes tentatives d'utiliser un quelconque plugin libre pour Pidgin ont bloqué mon compte !)

      Si quelqu'un a une solution, je suis preneur !

      • [^] # Re: Clients alternatifs ?

        Posté par . Évalué à 1.

        Il y avait bien le site web, qq.me si je me souviens bien…

        Pas terrible mais si le but est seulement de se passer du client natif, ça aide.

      • [^] # Re: Clients alternatifs ?

        Posté par (page perso) . Évalué à 6.

        Si quelqu'un a une solution, je suis preneur !

        Arrêtez de parler avec les chinois, de toute façon on ne comprends rien.

        http://devnewton.bci.im

  • # Protection de la vie privée

    Posté par . Évalué à 3.

    Il faut rappeler que même si XMPP semble savoir été adopté par les gros acteurs de la messagerie, ceux-ci imposent de laisser transiter en clair TOUS les messages échangés !

    Et par TOUS je veux dire:
    -ceux provenant de leurs utilisateurs
    -ceux provenant des utilisateurs d'autres serveurs XMPP

    A titre d'exemple, n'étant pas certains pour les autres, les serveurs Gtalk de Google interdisent les connexions serveur à serveur (S2S) qui demandent le chiffrement des communications. Du coup, une bonne partie de mes correspondants reste injoignable par ce biais.

    • [^] # Re: Protection de la vie privée

      Posté par (page perso) . Évalué à 3.

      Il faut rappeler que même si XMPP semble savoir été adopté par les gros acteurs de la messagerie, ceux-ci imposent de laisser transiter en clair TOUS les messages échangés !

      Si ils n'utilisent pas SSL/TLS, dis qu'il n'utilisent pas SSL/TLS, mais ne dis pas qu'ils imposent les communication en clair. À moins qu'ils t'interdisent par contrat d'utiliser OpenPGP et toute autre méthode de chiffrement de bout en bout.

      • [^] # Re: Protection de la vie privée

        Posté par . Évalué à 1.

        vrai, mais cela concerne la volonté de ne pas donner accès à ses messages aux fournisseurs des services de messagerie impliqués dans la communication, qui peut effectivement se traiter en chiffrant directement les messages avant que les clients ne les envoient aux serveurs. Après tout on peut toujours penser naïvement que les fournisseurs de service n'abuseront pas de leur position pour exploiter malhonnêtement ces données. Et on peut toujours se retourner par voies légales contre ces fournisseurs si c'était le cas.

        Le cas que j'évoque concerne la communication entre serveurs: si le serveur A de mon correspondant décide de refuser les communications chiffrées aux autres serveurs et que le serveur B de mon fournisseur passe automatiquement en mode non chiffré pour communiquer avec les serveurs imposant cette condition, moi qui ai choisi de chiffrer mes communications entre mon client et le serveur B ne sait pas qu'entre ce serveur A et le serveur B mon message passe en clair. Et si une personne mal intentionnée se place entre A et B il peut avoir accès à tout.

        PS: pour être honnête, parce que j'ai conscience que j'ai été très efficace dans ma répartie et que cela ne se voit pas du tout, je me suis planté: j'avais bien en tête un chiffrement de bout en bout, mais j'ai "oublié" qu'une fois sur le serveur du fournisseur, la communication était déchiffrée… mais bon, ca passe non ?

    • [^] # Re: Protection de la vie privée

      Posté par . Évalué à 3.

      A titre d'exemple, n'étant pas certains pour les autres, les serveurs Gtalk de Google interdisent les connexions serveur à serveur (S2S) qui demandent le chiffrement des communications. Du coup, une bonne partie de mes correspondants reste injoignable par ce biais.

      C'est pas juste pour ceux qui ont un certificat auto-signé ? Je ne sais pas du tout, c'est comme ça que je m'étais expliqué la chose pour mon serveur.

      Please do not feed the trolls

    • [^] # Re: Protection de la vie privée

      Posté par . Évalué à 8.

      En même temps, si tu veux de la vraie confidentialité, il faut faire ton chiffrement de bout en bout, de client à client (avec GPG ou OTR). À partir du moment où ta discussion transite en clair sur le serveur de Google, ça ne change pas grand chose qu'elle soit chiffrée ou pas entre ton serveur et celui de Google.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.