#PIDGIN VS TRILLIAN CODE#

#PIDGIN VS TRILLIAN CODE#

If apps are open source, one can see the source code and even compile one's self. One can use tools like Wireshark to confirm where data is going. Yes, downloaded apps can be malware, but it's a lot more easily discoverable. I'm not going to run my own Matrix server so that requires me to trust a Matrix server with access to my Facebook. It seems like a puppeted bridge requires me to send the messages to the Matrix server who then has a login to my FB Messenger to read/write messages there. I haven't used it so some of this may be wrong and I'm happy to accept corrections. Portal rooms, plumbed rooms, bridgebot bridges, Bot-API bridges, puppeted bridges, double-puppeted bridges, server-to-server briding, and sidecar bridges.

Maybe I'll look into it more, but it feels messy and complicated at first glance. It certainly isn't impossible to adapt this to a design like libpurple/Adium/etc, but it's an awkward fit and is likely to fail to support features which don't fit into that model, like chat messages being edited or deleted by the other party in the conversation.

Newer IM networks like Telegram are usually designed from a mobile-first perspective - the Telegram client protocol is designed around the concept that the server has a definitive view of history across all chats, and the client synchronizes portions of that history to local storage to display it. There was no real support for server-side message history, multiple clients, mobile clients, or offline messaging, so third-party clients often just implemented their own local history instead.

'Old-school' IM networks like AIM were simple to work with from a client perspective - you connect to the network, you send and receive messages, and that's it. Modern IM networks aren't a great fit for libpurple because they fundamentally work differently.

Pidgin vs trillian