[Juser] KDE IM Requirements

Sam Whited sam at samwhited.com
Tue Feb 13 22:11:38 UTC 2018

First let me say that they need to trim their list down if they want serious recommendations; as it stands now they will not find any system that does everything, and many of their requirements are contradictory or are geared towards centralized services (despite one of their requirements being that they don't want a centralized service). That being said, I think XMPP does fairly well:

> FOSS server implementation
> Ability to host our own server

This would seem to exclude everything but XMPP, IRC (already excluded presumably), and Matrix.

> FOSS clients available for desktop (at least Linux/BSD + Windows) as well as mobile

Gajim and Dino (among others) should run on Linux/BSD and Windows (although I have had trouble convincing Dino to build on FreeBSD, YMMV).
Conversations, Monal, and ChatSecure exist for the major mobile platforms.

> Full-featured, patent-free and stable API for writing clients (e.g. for Plasma Mobile) 

There are libraries for most major languages that, to my knowledge, are patent free. libstrophe and loudmouth are popular in C land (which I guess is what QT people would want?).

> Open governance (user/dev community is setting direction of software, spec, and/or service), not tightly controlled by a single company

Sounds like the XSF.

Matrix falls out of contention for this reason (their funding and governance model has always been unsustainable, and is now even more so, but that's what you get when you reinvent the wheel to play with trendy web tech and try to make money from it right away instead of building a community to sustain the protocol first).

> Free of charge


> Defined protocol specification (i.e. not implementation-defined, independent client/server implementations don't need to reverse-engineer and chase some other codebase)


> Can be used without having to sign up for an account (unless good bridge to IRC exists)

https://xmpp.org/extensions/xep-0175.html allows this; I've used it in multi-user chats before and it works quite well. See for example, the Prosody support room: https://prosody.im/chat/ (or from your own client at xmpp:prosody at conference.prosody.im).

> Anonymity: When using an account, all details (names, e-mail addresses ...) are optional and hideable, no SIM requirement

Since they'll be running their own server they can of course configure their rooms this way.

> Modest bandwidth usage both for server and client

This will depend heavily on the server and clients picked, but should be fine. It's not directly related, but https://xmpp.org/extensions/xep-0286.html gives a few suggestions for keeping bandwidth usage low; I don't know if any servers follow them though.

> Only limited impact on KDE server and sysadmin resources

Only their sysadmins could answer this, but I've found Prosody and Ejabberd rather easy to get setup.

> Legal to use in all countries with KDE contributors or users

That probably doesn't have much to do with the chat system or protocol unless it's owned by a specific company that's banned from doing business somewhere (which XMPP is not, as previously mentioned).

> Uses a port that is usually open even on public networks

You can run XMPP over 443 (or even over an HTTP transport, if you're so inclined) quite easily. Sysadmins can see https://wiki.xmpp.org/web/SRV_Records for details on configuring SRV records to point to 443.

> Federated (i.e. if KDE hosts our own server, we can still communicate with people on other servers)


> Migration path from current solution 

There are many IRC bridges available that could probably help with this.
https://spectrum.im/ and https://biboumi.louiz.org/ spring to mind.

> Usable from Tor or similar

It's TCP, so this shouldn't be a problem. If they want a hidden service it's a bit trickier, but can be done.

> Permanent history across mobile and desktop clients out of the box, including messages sent while offline

Yes, Gajim, Dino,and Conversations at least support this. Other clients may or may not. This is accomplished with https://xmpp.org/extensions/xep-0313.html if they're interested.

> Ability to open a channel at the oldest unread message

I am not sure if anything does this, but a client could easily be modified to do so. This may be one we fall short on.

> Ability to mute notifications from specific channels

This depends on the client; I am not sure what the various popular clients do here.

> Listing of all public channels in a namespace, with search function

MUC supports this, and the various Desktop clients at least can do it. I do not think Conversations does.

> Good bridge to IRC exists (stable and reliable, no need to set up individually for each channel, media shared get turned into a link on the other side, ideally with each user on the other side represented individually instead of just one bot representing everyone on the other side)

I can't comment on the stability or user friendliness of the bridge, but there are several. See "Migration path from current solution" above.

> Bridges to other solutions which are popular within KDE (Telegram, Matrix, Rocket) exist

I am not sure; Bridges never work very well, but I suspect they exist. Spectrum supports several protocols, I am not sure about the examples mentioned. I suspect we fall short on this one too.

> Ability to enter and use full name and email address (all optional) and be searchable by them

We do support vcards; I am not sure about search. That might be something servers offer. Search isn't all that compatible with their desire for a federated network though unless they're willing to search individual servers.

> Easy way to share files (A solution that puts files automatically on share.kde.org and embeds them from there works only if we have people willing and able to implement that feature into a desktop- as well as mobile client)

Yes, HTTP upload should make this easy.

>     Search for shared files

We don't have this, you'd have to do it on share.kde.org or propose a specification to do it and add it to clients.

> Private groups: Possibility to create channels that are accessible only upon invitation (also restricting access to that room's logs and, if available, files).


> Ability to define admins/moderators/roles for channels with ability to ban users


> User avatars


> Ability to notify a whole channel and/or highlight / pin a specific message for the whole channel

No, there was discussion about this a while back but I don't think any clients adopted the idea.

> Ability to set a channel topic


> Ability to highlight / notify individual users (even) if they have muted a channel

I am not entirely sure what this means; some clients probably have a "only notify me on highlights" option though.

> Integration with Phabricator and Bugzilla available or creatable

Definitely creatable, I have no idea if one exists.

> Stickers are available

The specs exist, but movim is the only client to implement them as far as I'm aware.

> Channels can continue to exist if their creator leaves or deletes his/her account

This is a configurable option on all the major servers.

> Encrypted communication possible

This is too ambiguous to provide any useful recommendation (but the answer is likely "yes" regardless of what they actually meant).

> Telegram- or Slack-like GUI available (e.g. user avatars next to messages, whitespace between messages)

Dino maybe? They might not like that because it's GTK+. The state of desktop clients is pretty lacking. I'm also not entirely sure what this means.

> IRC-like GUI available (high information density, fully tabular layout), unless there is a good bridge to IRC

Also not entirely sure what this means, but yes, there are bridges and there are clients that mimic various popular IRC clients (Poezio / IRSSI).

> Well integrated with Plasma (uses standard notifications, no x-embed tray icon, uses native file dialogs, etc)

I am not aware of any Plasma based messengers, but I don't use KDE so maybe someone else can point them at some.

> Good accessibility

Sadly, we fall down quite badly here, but no worse than the competition as far as I can tell. I have tried to work on accessability in my own projects, but not requiring any accessibility aids, I might not be the best person to make a call on this.

> Good performance and usability in large (500 users) and very active (>60 messages per minute) channels

That probably depends on the client, but it should be fine; 500 users isn't that large.

> Good performance and usability for users that are active in lots of channels (30+)

Same as above. Depends on the client. Probably fine.

> Low resource usage (so most likely no web or electron apps)

Yes, there are desktops available.

> Availability of a web client

Yes, there are web clients available.

> Availability of a CLI client that can be ran on a X/Wayland-less server and used via ssh and similar

Mcabber, poezio, Profanity, etc.

> Easy way to insert Unicode emoji into a message

Most DEs provide a way to do this. Clients may provide a button themselves; Converations does, and I think Dino lets you right click to insert emoji (by virtue of having a GTK+ text entry field).

> Reply to (quote) messages with reference to the original message

We do not have this. Quotes are normally prefixed with a > like an email; some clients even style this. The specs exist to do references, but so far most clients don't appear interested.

> Ability to react to a maessage with an emoticon (and multiple reactions with the same are added up)

We do not have this. Again, specs are available, but clients haven't implemented it.

> Ability to edit messages to e.g. correct typos (with clear indication that a message has been edited)

Yes, with limitations (some clients don't let you do it in multi-user chats, others do). Support is generally spotty between different clients but there is a fallback behavior for clients that don't support it so you won't msis messages.

> Support for multiple accounts within the same client, being able to log in with multiple accounts at the same time

Yes, most major GUI clients do this. The CLI ones tend to take the approach of having you run two distinct instances of the client but that's what tmux is for.

> Ability to broadcast messages across many channels, for example, to announce a meeting starting now

Servers generally provide a way for admins to do something like this.

> Ability to annotate images within the client, such as doodle on them, highlight or add messages to images (So that there is prompt and easy feedback on mockups for example)

I am not aware of any clients doing this.


More information about the JUser mailing list