91–100 of 103 posts
I miss the days when one chat app could easily connect to multiple protocols. I didn’t care if my friends had AIM or Yahoo or ICQ or whatever, they all showed up as a tab in Adium’s window and a name on its floating buddy list.
[1] https://valyr.io
> messaging apps are all the same, making them easy targets for standardization and interoperability. This is patently false. Look no further than the other comments in this thread. Nobody can agree on what they want out of the messaging experience. Some want a rich experience like telegram and others want a minimal one like IRC. Should this protocol's features maintain parity with the proprietary and centralized ser…
Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability, if you can send most of your messages across platforms, that's still pretty good.
> Let me just make that last point clear: you cannot design a messaging protocol where one party sees emojis and the other doesn't.
Which service doesn't show emojis? Literally every mainstream mobile operating system and desktop browser supports emojis as regular text.
> These extensions could include: delivery receipts => XEP-0184: Message Delivery Receipts optional read receipts => same as above user presence information => XMPP RFC binary serialization for efficiency and extensibility => XEP-0231: Bits of Binary end-to-end encryption => XEP-0373: OpenPGP for XMPP, XEP-0384: OMEMO Encryption, XEP-0378: OTR Discovery WebRTC signalling for negotiating VOIP and video chat => XEP-034…
> How many Matrix servers are out there ? One, that is still in beta (Synapse). Worth noting that Matrix as a protocol and Synapse as a server implementation left beta in June 2019 ( https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-an... ). Matrix is deployed by governments and civic institutions the world over including emergency services. It is literally trusted in life or death situations. While Synapse i…
Check out https://github.com/matrix-construct/construct and join us at #admins:matrix.org
> messaging apps are all the same, making them easy targets for standardization and interoperability. This is patently false. Look no further than the other comments in this thread. Nobody can agree on what they want out of the messaging experience. Some want a rich experience like telegram and others want a minimal one like IRC. Should this protocol's features maintain parity with the proprietary and centralized ser…
I feel like you're overestimating the differentiation and not accounting for the fact that 99% of the population basically just uses the minimal subset of features (sending plain text and images) Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability , if you can send most of your messages across platforms, that's still pretty good. > Let me just…
The tendency is for people to invoke features situationally. If you are communicating with someone who is using rich-replies there is a tendency to also invoke that feature yourself. If people are using emojicons there is a tendency for others to play along rather than use plaintext characters. Feature invocation is situational and relative.
> Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability, if you can send most of your messages across platforms, that's still pretty good.
This has proven to result in an unacceptable user experience throughout the history of messaging. When a system loses social information from the environment it is no longer an effective communication tool. Worse, it is dangerous. If you send me a message and I respond to your message with some thumbs-up emoji, and your platform doesn't support it (e.g. a text-based IRC client) that information gets lost. You believe I have disregarded your message. You may assume I have been rude when the opposite is true. This is absolutely unacceptable UX.
Earlier quoted context omitted.
As a person involved in XMPP development for over a decade, I can tell you why. To date, no one ever developed XMPP chat applications as a product, which can be easily deployed and will work consistently on every platform. Client and server developers were always disjointed, working separately from each other. This lead to great inconsistencies in implementations of even such basic functions like adding a contact. Al…
>...following a set of self-imposed rules instead of developing a set of working standards that would allow XMPP apps to compete with the best messaging apps out there. That is no excuse for doing embrace, extend and extinguish as your Xabber seems to be attempting with the XMPP standard. I can't help but note that the Xabber project has outright rejected OMEMO capability. If you are extending XMPP in incompatible wa…
2. We don't 'outright reject OMEMO capability'. I reject OMEMOdiots who moan excessively because their wishes aren't satisfied on the spot.
Why are not they satisfied? Because XMPP does not have a reliable control of message delivery, no way to remove messages from message archive, no good group chats, no client sync protocol, no way to revoke session tokens, no way to know which messages in archive were read, no way to add reactions to messages, no way to do threaded conversations, and while we're building all that we're constantly attacked by individuals who demand us drop everything we do and urgently add OMEMO so they can feel safe (and do it at our own expense, of course).
We'll provide some E2EE capability, but only after we are finished with everything else that we consider more important than this.
3. Extending XMPP in incompatible ways, I'll cover this a bit.
Do you even remotely imagine an amount of shit an XMPP client (say, a web client with no stored history) built on 'compatible' XEPs must do to display a telegram-like interface, with all the recent chats? How much time does it take? Best result we could achieve in our web version with 'compatible' server and 200 contacts is like 5 minutes. With our custom XEPs, it's currently down to 15-20 seconds, and our goal is to trim it to 3 seconds. Does it break anything with s2s? No. It only adds methods of how a client interacts with a server, that's it. Does it break legacy clients? No, they still can do it the old way, if someone is willing to wait 5 minutes.
Next, we have our group chats. They are powerful: archive search, moderation, anonymous mode, public mode, pinned messages, replies, mentions, extremely agile restriction/rights management. They are very easy to implement (on a client) and provide a nice fallback compatibility for any XMPP client even without support for them. You don't need support on participant server to use it (not as in MIX, to say). You can chat using multiple devices, with legacy clients alongside supporting clients, all working nicely with simple Carbons.
Documentation for all improvements is open, (it's not in english yet, but we're getting there), implementations are open-source and distributed under GNU licenses. No, I don't think your point about extending in incompatible ways is valid.
Probably, the more correct way to call it is that we are forking XMPP. Like, in git. We'll be sending XSF pull requests on every XEP we create - hopefully, one day XSF will come to their senses and see that their platform is fading into obscurity and irrelevance, and that to prevent it from happening they should do something differently.
This is what I’m working on with Aether ( https://getaether.net ). A mass-communication method owned by no one, like email is owned by no one. It’s a modern, decentralised Usenet. I used to call it ‘email for mass communication’ but it confused people, since it’s not based on email, so I stopped calling it that. That’s the goal though. I also gave a talk on it at the Internet Archive last week, if you want a quick in…
I try to find out where the front and backend config files are for quite some time now. They are mentioned in the guide, on your forums, they are not in the program folder or in the app data folder and googling it proved to be quite useless as the name is not unique enough...
Earlier quoted context omitted.
How about Quicksy.im? https://play.google.com/store/apps/details?id=im.quicksy.cli...
Conversations is a relatively nice simple app for just one platform. Imagine you convince your company to use XMPP. What would iPhone users use? That's why i'm talking about this: > a product, which can be easily deployed and will work consistently on every platform.
Actually, I don't know why the ChatSecure guys don't get their software to work reliably. It got a lot better over the past two years, but sometimes I still wonder why a ChatSecure user doesn't read my message. In addition, it is not as easy to use as Quicksy/Whatsapp.
One of my friends uses Monal, but in essence, it is the same story as ChatSecure: It kinda works most of the time and got better over the past two years, but I am still not confident it works reliably.
So for iOS, I have no solution and neither do I know of any _high quality_ XMPP client that supports video calls. But in fact, those issues don't stop me from using it :-)
Earlier quoted context omitted.
I feel like you're overestimating the differentiation and not accounting for the fact that 99% of the population basically just uses the minimal subset of features (sending plain text and images) Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability , if you can send most of your messages across platforms, that's still pretty good. > Let me just…
> the fact that 99% of the population basically just uses the minimal subset of features The tendency is for people to invoke features situationally. If you are communicating with someone who is using rich-replies there is a tendency to also invoke that feature yourself. If people are using emojicons there is a tendency for others to play along rather than use plaintext characters. Feature invocation is situational a…
This is an assumption that bad implementation is the only possible implementation, and it is wrong.
Obviously omitting content from missing features is bad UX - but it's absolutely not necessary to interoperate. It's easy (and should be expected) to avoid this by simply telling the user something from a missing feature has been sent - they can then inquire and get back the lost information / clear up the confusion.
Furthermore if interoperability is implemented on both ends, the sender's client should know to alert the sender before they attempt to use features missing on the receiver's end.
None of this is a difficult issue.
Earlier quoted context omitted.
I try to find out where the front and backend config files are for quite some time now. They are mentioned in the guide, on your forums, they are not in the program folder or in the app data folder and googling it proved to be quite useless as the name is not unique enough...
If you go to Preferences in the app, it will tell you where exactly your specific config files are. You can then copy and paste that path to access the files. Make sure you edit only after app is fully closed, or it will write over your changes from the copy in memory on exit and your changes will be reverted.
Earlier quoted context omitted.
Conversations is a relatively nice simple app for just one platform. Imagine you convince your company to use XMPP. What would iPhone users use? That's why i'm talking about this: > a product, which can be easily deployed and will work consistently on every platform.
Hehe, you are correct. I wondered if you would come back to that point when I posted the Quicksy link ;-) Actually, I don't know why the ChatSecure guys don't get their software to work reliably. It got a lot better over the past two years, but sometimes I still wonder why a ChatSecure user doesn't read my message. In addition, it is not as easy to use as Quicksy/Whatsapp. One of my friends uses Monal, but in essence…
Email info@xabber.com, we'll send you a link to test version of Xabber for iOS. We hope to release it this month. It even has voip calls, for real!