On 16 January 2017 at 16:28, Peter Saint-Andre <[email protected]> wrote: > On 1/16/17 7:00 AM, Evgeny Khramtsov wrote: >> >> Mon, 16 Jan 2017 14:29:42 +0100 >> Georg Lukas <[email protected]> wrote: >> >>> The goal of Easy* was to write down the things that can easily be >>> done today. However, few client developers are sufficiently >>> motivated, aware of Easy* or competent in the UX domain. Just to pick >>> a random example: Gajim, the most actively developed (or user >>> visible) desktop client, is a nightmare to configure for a user who's >>> new to XMPP. >> >> >> Easy configuration is not the only problem. All XMPP clients has really >> terrible UI. What I'm wondering is: don't client developers see their >> UI sucks? They never saw popular clients' UI (Viber, Skype, etc) or >> what? OK, I can understand that the majority of clients are targetted >> on advanced users, but in that case no easy onboarding is required and >> XMPP will never be a popular protocol. So all Easy_* initiatives are >> pointless at this point. > > > Recently I tried Signal because it was mentioned in another thread on this > list. Although I'm sure folks could quibble with various aspects of Signal, > it was very easy to get started and it's very secure. It's also built by > maybe 6 people working at a non-profit organization in San Francisco - a lot > fewer people than are active on this list! > > If someone like Sam's friend told me they wanted to find a secure messaging > service, I'd tell them to just use Signal. > > So, at this point, I wonder what we're doing here. :-) > > I fully understand that XMPP can be useful for organizations who want to > develop or deploy their own messaging systems, either on-premises or > integrated with an existing system like an e-learning platform - there are > server packages you can download, libraries you can develop on, companies > you can contract with for support or consulting, and overall it's pretty > secure. > > However, why run a public XMPP service? Why try to convince normal end users > to switch to XMPP? Are companies still offering dedicated email services? > Even ISPs got out of that business years ago. > > As the administrator of jabber.org, I've been thinking for the last few > years that it might be useful for jabber.org to offer a large, secure, > privacy-respecting, easy-to-use messaging service with dedicated clients > ("just download the Jabber app!") and always-on end-to-end encryption. The > stumbling block for me has been that I'd need to create a small non-profit > orgnanization and find people to staff it, but I'm always too busy with my > $dayjob to get this going. (I'd also need to brand it as JABBER™ and make > hard choices about which XMPP software to use and which not to use, and > probaby stop being executive director of the XSF to prevent a conflict of > interest.) But Signal has beaten me to the punch, and as far as I can see > they've done a great job of it. So hats off to them! > > Thus I repeat the question: what are we doing here?
There's a number of implications to this. One could, indeed, build a "closed" service around an XMPP service and use a bundled client restricted to that service. I'm sure it'd work just fine. You could set your own security policy over it, because it's your domain to do this with. What XMPP gives is the ability for someone else to do the same - and still talk to their friends on yours. This is a powerful thing, and I think we really underestimate how important it is, because it's part of XMPP that works sufficiently well as to be almost transparent to the user. Even when different security domains can remain entirely autonomous in policy. And don't kid yourself that Signal is some kind of a charity - they're doing multimillion dollar deals and setting lawyers on people, after all. Bear in mind they won't allow others to use their encryption protocol as-is without enforcing the GPL on the implementation, for example. And as a single service, that's a single place for a foreign power to require complete metadata collection. The XSF has a huge disadvantage by remaining entirely implementation-neutral (to a fault, as I've pointed out before) - and we should be, perhaps, a little more discerning about what we list on the website, for example. And federation's very existence - as well as being a genuinely useful feature - makes a lot of things harder (like, for example, onboarding or friend-discovery). But just because something is hard, does not mean it isn't worth doing. So what am I here for? To work on the hard problems, because I believe they're worth solving. Dave. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
