Possible to set moderators who can view the ip addy of other users in a chat room, and silence, kick / ban - and set parameters like ip subnet blocking, cidr blocks and server blocks via hostname?
(self hosted version is what I am considering)
I am still looking for a replacement for the old real-chat program to self hos chat rooms, but have found virtually every system since lacks these kinds of moderation tools, or they have so many bugs that they are easy to exploit and ruin a chat system when people should be banned.
I really like that you added self-hostable options after the decentralized info on the home page. Makes me want to look deeper into this.
I still remember writing an XMPP-Client and IRC-Client servers which were widely used across our organization. Later on, we developed our cloud-based chat application with mobile apps. Then we had support for xmpp/irc for those chat apps, eventually dropped the xmpp/irc support too. I think the reason is major players (Google/FB) dropping the support for xmpp and at the same time evolution of many cloud-based chat apps.
XMPP is well standardized and documented. If it could have been TEXT based instead of XML many developers could have adapted (IMAP protocol still being widely adopted).
I don’t know to what extent the name Movim confuses people, but when I read the name in the title of this post, before I read the rest I too expected something related to vim.
If rebranding it as Mov.im is an option, since you already own that domain name, I suggest considering doing so. Though I guess there is a risk then that people think of the QuickTime file format instead?
I don’t know what impact such a rebranding would have on search results rankings but among all possible rebrandings, if any were to be considered, I would think it would have the least impact at least. And also would involve a low amount of work since other domain names and such still make sense.
ConverseJS mostly focuses on Chat, Movim is also doing social features (checkout the website for more info https://movim.eu/) such as publications, comments, sharing…
There's also video-conferencing support. But the biggest difference is that Movim is a "light-client", most of the work is done server side, the browser is just showing the result, you can reload the page, close the tab and come back 1h after the session will stay open.
I think this uses ConverseJS. Converse is not a full featured client on its own, and will require your own websocket-enabled proxy most of the time since BOSH is rarely enabled.
Most people attribute it to the lack of standardisation regarding server implementations, or "which XEPs can I support" but normally when those situations happen a single set of things takes off because it's highly polished or packaged as a bundle.
It feels like we were -nearly- there with regards to decentralised IM, but then suddenly we regressed to walled gardens and now I have 10 applications on my phone to communicate with people, each with their own account and very little cross over.
It used to be very popular. For quite a while Pidgin was my main or only chat application.
I think it started to die when Google decided the XMPP spec was not good enough for them and deviated from it, eventually abandoning it completely. Then, came Facebook and almost everybody people knew was there so it was convenient.
I wish it would come back though. OTR encryption was fairly easy to setup and under my control.
> I think it started to die when Google decided the XMPP spec was not good enough for them and deviated from it
It was my impression that Google dropped XMPP support not because of the spec being "not good", but because they saw now advantage allowing the federation, since nearly nobody else federated with them, while it comes with a cost.
The XMPP specification is open and in large parts malleable, nothing would have stopped Google from participating in improving it.
XMPP is still used in many places, including in online gaming https://xmpp.org/uses/gaming.html. Unfortunately without the federation support (which can be explained in those specific cases).
federation with xmpp doesn't need to be configured. it is automatic. all you need to do is to send a message to someone on a different server. i am not on google, so i used this all the time to talk to people on google. until they stopped.
to get advanced features, google would have had to create a client that uses those features. much like they created the chrome browser.
i guess there just wasn't enough value in doing so. and there were to few people like me who communicated from the outside.
Because there are too many clients with a wide range of supported/unsupported features.
The only solution out there that supports cross platform JINGLE is AstraChat[^1], which is closed source and commercial, but they lack OMEMO and Carbons.
Conversations on Android has both OMEMO and Carbons, but no audio/video or p2p transfer files.
Pidgin, Empathy, Gajim, etc are lacking behind with features, though Pidgin can be made reasonable up to date, still without JINGLE[^2].
XMPP seems to be moving away from that as it is impossible to do reliably with the current brokenness of the internet. The current hotness involves uploading the file to the XMPP server and then just providing a https link to the other client(s). The contents can be encrypted but client support is spotty. So sometimes you have to trust the server. Still way better than the old thing.
I am personally not at all sad if my IM client can't do audio/video. Just let me send a damn text message and have it come out at the other end reliably.
> XMPP seems to be moving away from that as it is impossible to do reliably with the current brokenness of the internet. The current hotness involves uploading the file to the XMPP server and then just providing a https link to the other client(s).
Could be even more cool if you could just post a file to a group chat and it would be shared via BitTorrent behind the scenes.
> I am personally not at all sad if my IM client can't do audio/video. Just let me send a damn text message and have it come out at the other end reliably.
I agree. I can hardly see why texting and voice calling is always meant to be done with the same app.
There is BeagleIM (https://beagle.im/, macOS) and SiskinIM (https://siskin.im/, iOS) - fully open-source, with OMEMO, carbons, MAM, file upload and audio-video calls using Jingle.
> Because there are too many clients with a wide range of supported/unsupported features. The only solution out there that supports cross platform JINGLE is AstraChat, which is closed source and commercial, but they lack OMEMO and Carbons.
So why won't somebody just make a great XMPP client with all the features, make it closed-source and commercial and earn money from it? They could make 3 versions: enterprise with some enterprise features (like CRM/LDAP integration etc), standard and adware - I would gladly buy the second or use the first if the ads were unintrusive and not personalized with my personal data like messages text or contacts.
People make instant messengers, why does everybody have to invent their own protocol? Is XMPP actually so hard to implement?
I'm fairly certain Gajim supports most of the standard XMPP features one might expect from a client [0]. I use it daily. Granted Jingle audio/video is not working in a cross-platform fashion but I'm fairly certain file transfer through Jingle does. HTTP file transfer is also fairly straightforward if your server supports it. My problem with Gajim is that it's not a turnkey solution. You need to adjust settings, maybe use a BOSH proxy if you're behind restrictive firewalls, manually enable OMEMO and deal with trusting and enabling keys. For instance I occasionally miss OMEMO encrypted messages (as in they cannot be decrypted) send from Gajim on a specific device. On the other hand Conversations does a much better job at hiding all this manual labour from the end user to the point that I can tell anyone: "just install Conversations; login into that server; done".
Pidgin is quite lacking as far as Carbons and OMEMO is concerned. Last time I checked you need to install custom plugins, issue text commands to configure the plugin, issue different commands to trust/distrust OMEMO keys etc. It's a lot of work which is probably partly due to the fact the libpurple tries to handle a lot of different protocols using a more-or-less transparent API. It does a fairly good job with most protocols (including proprietary ones through plugins; like hangouts [1]) but unfortunately its XMPP support is not really up to modern standards without effort (much more so than Gajim).
Dino is good and I think they solved some OMEMO compatibility issues they had. But it's Linux only. This is not necessarily bad since they can do much better work by focusing on a specific platform, both functionality- and aesthetics-wise. It's too bad there isn't anything comparable on Windows/Mac.
Services need to be able to iterate quickly to deliver features that other services have, introduce new ones that give them a competitive advantage, and improve UX, all at the same time. Federation and standardization do not help in achieving any of that.
There is nothing wrong with XMPP, it's not a technical issue.
XMPP is a lot like email. There is no money in it and it has warts simply due to the fact that it is a widely implemented standard. You use it mostly because it is a well developed standard with lots of support. I don't know what it would mean for it to become "popular". How would you tell? All you can know is what your friends are using. An IM protocol is a silo...
There is a lot of interesting XMPP stuff happening right now with respect to the currently hot topic of privacy which could affect XMPP popularity.
There are over a hundred known public XMPP servers last I looked. Due to Let's Encrypt those servers are now encrypting the server to server and client to server links in a meaningful way.
The encryption from Signal has been integrated into XMPP with OMEMO. This suddenly makes XMPP a lot more interesting in terms of privacy. The clients are mostly moving to OMEMO end to end encryption which as a nice bonus eliminates the user awkwardness with the last thing (OTR):
I wonder how much XML itself had to do with it; I've written clients for IRC and MSNP, and those (at least for earlier versions of the latter) are simple text-based protocols which are very easy to parse. I know people say "just use a library", but that doesn't help when you need to debug what you wrote and thus read the protocol messages yourself.
Also, clients. https://conversations.im/ is good for Android . https://dino.im/ looks like a promising Desktop client but where are the iOS clients? Stuck in XMPP dark ages from what I've heard.
In the last year I had to re-implement one of the libraries for working with XMPP on another platform. It's horrible and not pleasant to work with at all.
I guess most of the developers that worked with it had a bad time. That would be my bet why it hasn't taken of.
IMO we need something simpler, websocket and JSON based. Less standards, less use-cases - for example I don't think xmpp should take care of vcards, nickname and tons of other things I forgot about. Programmer should be able to grok it realtively quickly and then specifics of your application should take longer to understand instead of having to spend ages on XMPP first and then ages on your specific hacks around it.
> IMO we need something simpler, websocket and JSON based.
Why JSON? JSON is the packaging format of this decade but remember when XMPP was conceived XML was the packaging format of that decade.
Maybe CBOR would be more appropriate. No need to encode binary data (signatures, encryption) in base64 wrappers and more efficient encoding of frequently used stuff (no need for Whatsapp-stype FunXMPP).
For the sake of simplicity. Because JSON is native to web. And web is the biggest platform you have imo. It's annoying that you have to bring in XML parsing libraries if you want to implement XMPP in javascript environment.
This is my experience as well. Compared to for example IRC where you can just open a TCP socket and send ascii as it. I think a more simple protocol would lead to more integrations. It doesn't have to be as simple as IRC. One problem is that implementing audio/video p2p streaming is still super complicated. So we should probably only support text messaging as a first spec. And make separate and isolated audio/video spec!? A good start would be to take WebRTC as is and make a very simple protocol on top of it. And also make use of web push notifications. So the stack already exist and is fairly standardized. We just have to wrap it up in a very simple abstraction/protocol ontop.
> nothing is stopping you to build a layer of compatibility
I don't have 10 engineers. It's already super complex. Adding extra layer will just make things worse. I reckon custom solution would be simpler for majority of use cases.
there are Java, Javascript and Swift libraries for XMPP
> I don't have 10 engineers. It's already super complex
The point is XMPP is a solved problem, you can simply use what you need of it, making it json over websocket won't make it anyway easier, you would use a library anyway
Creating protocols just for the sake of it, it's the reason why this comic exists https://xkcd.com/927/
p.s.: Movim, afaik, solves that problem for you
When you use Movim, it acts as an intermediary between the user's browser and an XMPP server. All the data that is sent and received by these two parties are managed by the Movim core, some of them are also saved in a database (for cache purposes).
From the browser perspective, all communication with Movim is done using WebSockets (except for the "default" page loading). These sockets are proxied through your web-server to the Movim daemon. On the XMPP side Movim connects using pure TCP connections (like any XMPP client).
Link me a JavaScript library that works cross platform on both iOS and Android with unified interface in React Native. Ideally it's maintained and if you are asking me why I wrote it, it's also because there was nothing available 2 years ago.
Majority of JS XMPP libraries depend on the DOM for xml parsing - see strophe.js for example. This won't work in all JSC runtimes.
> The point is XMPP is a solved problem
Ye, which problem exactly? All of them are solved partially. Let me give you example, imagine you have a platform where users can chat in chatrooms (as simple as it gets really). On your platform you have a username and you are supposed to communicate with others with your username. You'd think xmpp is perfect! Nope, you'll have to fork the xmpp server for this use case. Why? Well, because XMPP standard supports nickname changing, which means in a context of a platform it would allow nickname spoofing. So you need to modify and add some security rules on top of it. "Solved problem" of course...
as other have already said, Xmpp.js works quite well
If it's Javascript it's already cross platform
> Ye, which problem exactly?
communicating via XMPP in a standardized way
> All of them are solved partially
And a new protocol based on half backed technologies would change that, how exactly?
> On your platform you have a username and you are supposed to communicate with others with your username.
On any forum or BBS I've been part of in my life, I've always used a nick, that changed over time.
> Well, because XMPP standard supports nickname changing, which means in a context of a platform it would allow nickname spoofing.
That's a feature, not a bug.
In 1995 I could change my nick on IRC, in 1997 I could change my nick on ICQ, I still can change nick on Skype today (my artists friends do it on facebook all the times)
Anyway, nick spoofing on XMPP is hardly a problem and it's not an XMPP fault.
Have you ever tried to search for "someone has been impersonating me with FB messenger" on a search engine?
> "Solved problem" of course.
XMPP it's a solved problem, your chat where nick cannot be changed is your problem.
Every implementation of standard protocols requires work, HTTP is a solved problem, but edge cases still exist.
Name one standard federated protocol that could help you with that and make it simpler, please.
The same reason email is the last resort for contacting someone online these days: centralized services can offer better UX, including antispam. Users didn’t care about federation or interop, which is why the default now is Facebook Messenger.
When you can receive messages from anyone, you will receive huge amounts of spam.
The need to capture users (and all the info you can about them) and claim territory is a lot of why we don’t have as much focus on standards anymore in web protocols.
So, as with many of the rest of the web’s problems, it’s spyvertising’s fault.
