in addition to the list Eike gave in his other mail, which I fully agree with, 
the following are mandatory: 

- Has to run everywhere. Means: desktop, mobile, server, *BSD, Linux, Windows, 
Mac ... Maybe doesn't have to run on a smartwatch or toaster, but I'd prefer 
to be able to also chime in from a box I am ssh-ed to. 

- Not a strain on bandwith. I travel a lot, also abroad, where data is limited 
and/or expensive, thus the lower the bandwith usage, the better. 

- Not excluding people. We should keep in mind that various people would like 
to contribute, including e.g. people with disabilities.The solution should 
work with technologies such as screen readers or the likes. 
Plus: geographical restrictions, we e.g. have collaborators in China or Russia 
(new laws), so using technologies that are banned in some countries can be 

- Privacy. Should be either fully under KDE control, or hosted by a trusted 
third party. Support for things like Tor would be beneficial. No mandatory 
disclosure of information to third parties  (names, location etc.) 

- Open Source. (Just in case of the "free" having been meant as free in beer, 
which it should be as well, or free as in freedom): Open protocol plus a 
reference implementation of both client and server as FOSS would be great. 

- Migration path is mandatory, moving over to a new place and/or product from 
one day to the next is not only likely to be super shaky, but also likely to 
split the community into two halves  (seen e.g. when reddit decided to move 
their chat system in a very short amount of time, or when Debian moved 
networks. Both are now roughly halved and at least with Debian it has been 
like that for the better part of a decade)

In general I'd prefer something with an open protocol and, bonus points, a 
range of possibilities to connect (web, native desktop and mobile clients, 
...) already available. Then I think most people should be able to somehow 
participate, regardless of circumstances. I don't think we should cater a 
specifc group, neither, quote, nerdy people nor, quote, people < 20 years old. 
All have valuable people in it.

Finally I am 100% certain that we won't find a solution which covers all 
points seen as mandatory, so maybe we should just collect potentially 
interesting points and have people vote on a scale of 1-10 on how important 
these are for them. Then based on that we could see what solution (or 
solutions, since some do allow bridging in between) are the best compromise.

Kind regards, 


PS: on the importance of emojis and (animated) stickers: I can see why people 
want them for friends and family, I love the sticker packs I have on Telegram. 
But why it is mandatory in a somewhat more professional environment is a bit 
beyond me, people also still use e-mail despite it neither supporting stickers 
nor emojis  (Well, unless html mails, but thank god that at least there we 
agree that it is an abomination) 

Am Mittwoch, 9. August 2017, 00:19:32 CEST schrieb Thomas Pfeiffer:
> Hi everyone,
> now that hopefully most of the emotional arguments in fiery support of one
> protocol or another have been exchanged, I'd suggest we move things towards
> a practical approach and ask ourselves:
> What are the requirements that KDE has for an instant messaging / chat
> system for it to be viable as our main channel for real-time communication
> for the foreseeable future?
> Here is what I could come up with, feel free to add new requirements or
> challenge the ones I'm listing.
> Must-have:
> - FOSS clients or at least API available for desktop as well as mobile
> These clients must
>  - have a UI that someone who is < 20 years old and cares about the looks of
> a UI would use (or if those don't exist, we need to have people willing and
> able to write them before switching)
>  - run smoothly on computers that can run most other KDE software, without
> eating all of their memory
> - FOSS server implementation
> (this might look like a nice-to-have for some, but if we'd require everyone
> in KDE to use it, it's not optional)
> - Ability to use without having to create a new account just for that.
> We could force contributors to sign up for something, but we'd increase the
> barrier of entry if we'd make it mandatory for everyone who's just curious
> about what's happening in KDE.
> Identity would suffice, as everyone who does anything with KDE has an
> Identity account anyway.
> - Permanent logs across mobile and desktop clients without the need for
> users to set up anything.
> That means ZNC does not count unless we implement it in a desktop as well as
> mobile client in a way that is completely friction-free for users
> - 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
> - Support for a decent set of Emoji (not just the ones you can create using
> ASCII chars).
> Using Unicode to display them is probably okay, as long as users can choose
> them from a menu in the client instead of having to paste them from
> KCharSelect.
> This, too, might sound like nice-to-have for many, but not having them would
> cut us off from the younger generation. Yes, they use them even in a
> "professional context". Believe me, I'm seeing it in action every day at
> work.
> - User avatars
> Again, must-have if we want to reach the younger generation
> - Uses a port that is open even on educational networks
> - Channel listing
> So that every public channel can be easily found
> Nice-to-haves:
> - Bridge to IRC
> For the transitional period or for people who just refuse to change their
> habits
> - Full name display
> Makes things feel more trustworthy
> - Integration with our development tools such as Phabricator
> - Web client
> Very handy if you are at a device which isn't yours and quickly want to
> check up on things
> - Stickers
> People love them when they have them, but they survive without them.
> ---
> I'm sure I've forgot many things, but this (already quite long) list should
> give us a good start.
> Looking forward to a productive discussion,
> Thomas

Reply via email to