So the only issue right now is to have an android client who is capable to use xep-0160 or chatty/libpurple to use xep-0313 otherwise the two clients can’t talk each other in offline mode, is it right?
So what i whould like to know when you try atalk if he handle the offline conversation with chatty or if he do not support xep-0160 too, in alternative do you know if chatty will support xep-0313?
I’m start to understand why people just use whatsapp and telegram 
I recently discovered the desktop version of Signal, which I now have running in Kubuntu. I like it a lot, with the only drawback being it will communicate only with other Signal users, meaning no SMS or MMS.
I’m assuming the desktop version will run on the L5, but I’d love to learn there will be a version of Signal for the L5 which functions like the Android app and allows me to communicate with my non-Signal-using contacts.
However, the desktop version is written with the electron framework which has as a direct consequence that (video) calls are not possible. Anything else works quite well though as far as i can tell.
I would also chime in with the hope that Signal might be able to run. It took me six months top drag most of my contacts from WhatsApp to Signal. I don’t know thLibrem at it will be so easy to get them to Librem.
Yes these centralized services do have the advantage of being mobile-first, unlike XMPP that had to retrofit a lot of functionality, and waiting for clients to catch up, and lots of different people coding things differently, leading to issues and incompatibilities (see Moxie of Signal fame and his rant about federated services on the Signal blog a few years ago).
atalk, first impressions: I can’t even get it to reliably connect or send or receive messages, or even have a UI that responds to my taps and swipes. Stick with Conversations lol.
As far as Offline messages vs MAM, probably the best combination is to have offlines messages + message carbons support in clients, so that there can at least be some synchronization of messages between clients. MAM is a nice bonus and libpurple will have it… one day… Most XMPP servers support Offline messages and don’t use the workaround I used to redirect all messages to the MAM, so everything should be fine overall.
Still getting some glitches in OMEMO chats between various clients and Chatty, it’ll take a while to figure all those bugs out,…
Don’t assume it. The desktop version is compiled for Linux on x86-64 architecture, so unless it’s recompiled for arm, then it won’t work on the L5. I’m not sure if the Signal devs have indicated they will do so or not, ro what the challenges involved are (due to the desktop version being based on Electron…)
The ideal of course would be an actual version using libhandy or origami rather than an electron monstrosity…
Having offline messages + carbons support what kind of experience will bring between chatty and conversation? i mean will the message sent to an offline contanct will be sended when he came online even with some delay or there is some other kind of issue compared to mam?
What kind of glitches do you suffer in omemo chats?
In both chatty and conversation how do you know if your conversation is unencrypted, encrypted with otr or omemo?
@rinokeros
For me the situation is reversed. I’ll not use Signal as long as they ask for my phone number, and I will not use Signal before I can choose my server, esp. not in the Amazon cloud, but run by the local Internet cooperative. Also, their desktop client stinks: It’s based on Electron which I don’t like. OTOH, I don’t care much about Matrix, because XMPP works fine for me. On L5, I’ll either use Chatty or Dino or Gajim or Profanity. Let’s see…
Any opinions on this?
Never heard about it, but seems really interesting, i whould like to have more info about them because while their source code are on github i see no info about who they are and what’s their business model
At first glance… JavaScript non native client, which first makes me question inputting passwords on their servers for my accounts + question if omemo is secure.
Second glance, desktop app screenshot looks like an electron app.
EDIT: confirmed, it is an electron app, and also this note from their wiki:
This server provides a social network Web interface XMPP which will be the intermediary between the browser and the XMPP server that contains the user account.
In other words, not interested…
They are also offering a free xmpp registration we can use with any xmpp client, what do you think about it? do you value not secure or this could be a good option for people without their own server?
@patrixl i made you some questions few posts ago if you don’t mind to reply, thanks
I believe one of the original goals of Conversations was to be an “always on” messenger. In fact until recently they never really indicated contacts or own status, if I remember correctly, prefering to act like WhatsApp/etc in that you send message without caring if someone is online, offline, away, etc.
this of course causes issues when Conversations actually goes offline and can’t receive messages… Which should be rare but can happen (go on a flight, drain battery, turn off phone, etc).
Chatty will handle being offline fine and can retrieve offline messages.
so depending on circumstances, some messages might get lost sometimes… Message carbons will help, e.g. in my case I keep a XMPP client always on at home, but since my server also has MAM that’s less of an issue. So basically, YMMV 
Glitches… hard to describe… I need to come up with a more “formalized” testing method, otherwise I just know what sometimes some clients aren’t getting OMEMO-encrypted messages. It’s better than it used to be, but libpurple still has issues I think. Sorry to be so vague… like I said I need to formalize my testing and submit some actual bug reports.
In Conversations, there’s a padlock icon at the top of the chat window that tells you if you have OMEMO activated. Unencrypted messages while that padlock is “locked” will also be highlighted in red with some text telling you it’s unencrypted.
Pidgin (desktop XMPP client) has only the title bar of the chat window saying OMEMO, with no other indication. Some messages do appear when an unencrypted message comes in to the effect that the message is unencrypted even though the conversation is supposed to ne encrypted.
Chatty… Doesn’t have much in the way of UI for OMEMO yet. In my tests, I’ve manually installed lurch by compiling it from source. It does seem to enable a setting to enable/disable OMEMO in the “Chat details” settings of the conversation, but that toggle doesn’t seem to do anything at the moment. Still a work in progress it seems.
Sure, there’s a multitude of XMPP servers out there open to the public, nothing wrong with Movim having their own XMPP servers as such. Librem.one is supposed to get one at some point as well, I think?
A list of public XMPP servers: https://list.jabber.at/
Otherwise, Movim doesn’t really fix any of the issues we are encountering here, that of having a reliable XMPP client with OMEMO encryption that is cross-platform and reliable AND available on the Librem 5 (their app isn’t, their desktop app is electron so not immediately working on the L5 AFAICT).
Plus they add an extra layer of potential overhead and “man in the middle” by having a server act as the gateway between their official client and XMPP servers, that is if you use their client to connect to any server (whether Movim servers or other servers).
Thank you for your replies.
So if i well understood the message carbon could help in a situation where i send from chatty to conversation client while he is offline, when he come back he have a chance to receive the message, but that’s not sure, because offline message or mam are the correct way to handle it
Darn! So Riot has its (substantial) drawbacks. Movim appears alright, but fails in other respects. Other options seem even worse.
It seems to me the whole messaging thing via the L5 is a bit of a mess.
While waiting for a viable xmpp solution, I will just make do with sms/mms, I guess.
Building on the existing Email-Chat standard implementation’s core-library (and thus future https://www.coi-dev.org/ extensions) might be an option, too.
Due to its backwards compatibility with standard email clients, it has by far the broadest reach, anyway.
And the required plug-in is ready to get packaged for Librem 5’s “Chatty” app: https://source.puri.sm/Librem5/chatty/issues/96.
The only thing that is missing is something like jitsi-meet-sdk voice and video chat support in Chatty. Legacy peers could then even use a web-link to join talking (audio/video), in case the peer’s email(-chat) client doesn’t have any jitsi webrtc support integrated.
@patrixl reading this https://github.com/siacs/Conversations/issues/3520 seem this feature is not required on client side but server side, that mean chatty-conversation offline message should work ootb?
Thanks internet, where different sources state different facts
Only one thing will help - experimentation.
I’ll let you know more tomorrow.
Lol
Thanks for the experimentation, now i’m really curious to know it, i hope ofc chatty conversation offline feature will just work on both side