Re: [Standards] Easy XMPP

[ValdikSS]

Well, now we have more or less good protocol, suitable for all modern use cases 
for IM. In my opinion, we should improve clients now.

On 05.02.2017 10:46, Evgeny Khramtsov wrote:
> Sun, 5 Feb 2017 08:31:45 +0300
> ValdikSS  wrote:
>
> You described the situation with jabber clients. They suck indeed, even
> Conversations has ugly UI (try push-to-talk for example) and doesn't
> have A/V features. But I was asking about XMPP as a protocol in general.
> But whatever.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Evgeny Khramtsov]

Sun, 5 Feb 2017 08:31:45 +0300
ValdikSS  wrote:

> You want to know why? For many years XMPP was a protocol not suited
> for modern mobile devices with unstable network connection. Messages
> could be easily lost (and you had to ask for receiving
> acknowledgement yourself in another message), battery consumption was
> very high. XMPP also was barely usable on multiple devices. While we
> had Message Archiving XEP since 2004, Message Carbons XEP since 2010
> and Message Archive Management (MAM) since 2012, most desktop clients
> still lack support of these functions giving you frustration when you
> want to access previous conversation history that was made on another
> device.
> 
> Everything has changed when Daniel Gultsch created Conversations.
> That's a modern XMPP client for Android which has support for most
> current XEPs. Finally we get mobile XMPP client that is usable,
> reliable, supports history sync and doesn't noticably shorten battery
> life and is a proper competitor for other proprietary mobile IMs.
> 
> Still, the situation with desktop clients is unpleasant. Only one
> client has Message Archive Management support (Gajim), only one has
> support for outdated and rarely configured on the server side Message
> Archiving support (Vacuum IM). Not even mention Gajim UI problems
> that you can see previous conversation history only in "history"
> menu, the chat window contains conversation history only of that
> exact machine. Till now there's no client for OS X with MAM support.
> Also should note that Gajim lacks MAM support for MUC.
> 
> Not even mention SPIM and other mostly-server-side problems.

You described the situation with jabber clients. They suck indeed, even
Conversations has ugly UI (try push-to-talk for example) and doesn't
have A/V features. But I was asking about XMPP as a protocol in general.
But whatever.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[ValdikSS]

On 16.01.2017 20:32, Evgeny Khramtsov wrote:
> But IM companies don't choose XMPP. Whatsapp was initially build on top
> of XMPP but now it's something different. New services like Slack and
> Signal don't use XMPP neither. So seems like XMPP is not that featured
> protocol even though there are "server packages, libraries and support".

You want to know why? For many years XMPP was a protocol not suited for modern 
mobile devices with unstable network connection. Messages could be easily lost 
(and you had to ask for receiving acknowledgement yourself in another message), 
battery consumption was very high.
XMPP also was barely usable on multiple devices. While we had Message Archiving 
XEP since 2004, Message Carbons XEP since 2010 and Message Archive Management 
(MAM) since 2012, most desktop clients still lack support of these functions 
giving you frustration when you want to access previous conversation history 
that was made on another device.

Everything has changed when Daniel Gultsch created Conversations. That's a 
modern XMPP client for Android which has support for most current XEPs. Finally 
we get mobile XMPP client that is usable, reliable, supports history sync and 
doesn't noticably shorten battery life and is a proper competitor for other 
proprietary mobile IMs.

Still, the situation with desktop clients is unpleasant. Only one client has 
Message Archive Management support (Gajim), only one has support for outdated 
and rarely configured on the server side Message Archiving support (Vacuum IM). 
Not even mention Gajim UI problems that you can see previous conversation 
history only in "history" menu, the chat window contains conversation history 
only of that exact machine. Till now there's no client for OS X with MAM 
support. Also should note that Gajim lacks MAM support for MUC.

Not even mention SPIM and other mostly-server-side problems.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Winfried Tilanus]

On 15-06-16 13:04, W. Martin Borgert wrote:

Hi Martin,

> Here in English: Germany and probably other countries like to make
> anonymous SIMs illegal. Relying on phone numbers would make anonymous
> "Easy XMPP" illegal, too, which is probably not a goal.

For the EU-definition of personal identifiable information, it doesn't
matter if the sim is anonymous or not. The legality of the use of phone
numbers here, is subject to many subtleties and can't be judged in general.

Winfried
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Sam Whited]

On Wed, Jan 18, 2017 at 7:53 AM, Brian Cully  wrote:
> Whether they know about it or not, people do need to have encryption. 
> It’s a complicated, esoteric thing that they shouldn’t have to know about but 
> do silently benefit from. In the dreaded car analogy: how many users discuss 
> limited slip differentials? Does that mean there shouldn’t be engineering 
> resources behind it?

I took "encryption" in this context to mean "end to end encryption",
and I disagree. I don't want end to end encryption in most situations,
I want searchable history that I can query on the server and sync to
any new devices. Where "I" in this case am assuming the role of "some
random user who just wants to chat and be able to go back and find the
date of an event their friend sent them".

I'm certainly not arguing that e2e encryption is useless or that we
shouldn't throw resources behind it, but we should stop assuming it's
needed 100% of the time for all users and use cases.

(to take this analogy too far, this is the best video I've ever seen
explaining the topic: https://www.youtube.com/watch?v=yYAw79386WI)

> It’s a similar thing, in my mind, with federation. IMHO, it’s 
> dangerous to put so much information in the control of a few huge 
> organizations, and federation is a necessary, but not sufficient, way to 
> alleviate that. It’s more than just whether or not users knowingly care, it’s 
> engineering ways to help keep them safe and in control of what they share and 
> with whom.

I do agree with you here for the general users case here, but also
bear in mind that one use case is "don't share anything with anyone
not allowed on this server", at which point federation probably isn't
necessary (and may be a bad thing).

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Evgeny Khramtsov]

Wed, 18 Jan 2017 08:53:14 -0500
Brian Cully  wrote:

> Whether they know about it or not, people do need to have encryption.
> It’s a complicated, esoteric thing that they shouldn’t have to know
> about but do silently benefit from. In the dreaded car analogy: how
> many users discuss limited slip differentials? Does that mean there
> shouldn’t be engineering resources behind it?

The analogy with cars is absolutely inadequate, that's the problem a
lot of crypto guys run into. Typical IM user doesn't have such severe
consequences as from a car crash if someone reads his message. Most of
the time IM messages possesses no sensitive data, especially for users
chatting with friends and relatives (the use case we want spread,
right?). For those sending sensitive data encryption is required.
I personally don't need e2e encryption, because I don't want all its
drawbacks: I don't want to lose all my archived messages if I lose a
phone, I don't want to read crap instead of messages from the resource
unsupporting e2e, I don't want to mess with key storage, I don't want to
choose which protocol to use (OTR (several versions), Axolotl, Olm - XSF
repeats the same mistake as with file transfer here).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Brian Cully]

> On 17-Jan-2017, at 10:49, Evgeny Khramtsov  wrote:
> 
> Tue, 17 Jan 2017 09:29:09 -0600
> Sam Whited  wrote:
> 
>> Of note: security didn't really enter into it from her perspective
> 
> Exactly. Regular users aren't concerned about security and encryption.
> They don't even know if Whatsapp has any sort of encryption. Yet, every
> third discussion on this list is about encryption. Look at the tail
> of the XEPs list: there are 6 encryption related XEPs out of 18 (i.e.
> 30%) WTF? Whom are we building network for?

Whether they know about it or not, people do need to have encryption. 
It’s a complicated, esoteric thing that they shouldn’t have to know about but 
do silently benefit from. In the dreaded car analogy: how many users discuss 
limited slip differentials? Does that mean there shouldn’t be engineering 
resources behind it?

It’s a similar thing, in my mind, with federation. IMHO, it’s dangerous 
to put so much information in the control of a few huge organizations, and 
federation is a necessary, but not sufficient, way to alleviate that. It’s more 
than just whether or not users knowingly care, it’s engineering ways to help 
keep them safe and in control of what they share and with whom.

-bjc

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Dave Cridland]

On 17 January 2017 at 15:31, Sam Whited  wrote:
> On Mon, Jan 16, 2017 at 10:05 PM, Peter Saint-Andre  
> wrote:
>>> And if your business plan doesn't involve federation, why bother with
>>> the additional overhead and complexity?
>
> I don't have a good answer for this, but it's worth asking why most
> email and phone / SMS providers federate. Is it just because there are
> laws saying they have to (in the case of the telephone network), or
> because a critical mass was formed that expected to be able to call
> anyone else regardless of the network before the phone companies /
> email providers realized they could avoid the overhead and trap people
> by not doing so? I'm not sure. I've always assumed email became the
> primary identity provider for the internet because it was federated,
> cashing in on that kind of popularity
>

Pretty much the latter.

There were plenty of email systems, and some had the kind of
percentages of the market that would make Facebook drool with envy -
CompuServ, for instance, had a global reach and a vast market share.

But they were all forced to federate (via SMTP), since to do otherwise
meant their users would go elsewhere for other email, and who wanted
to run multiple email programs?

> In general I agree though; there are some business plans where
> federation makes sense, and others where it doesn't. In general it
> doesn't make a lot of sense in the enterprise case (although even
> there we [HipChat] get requests quite often to allow eg. contractors
> to chat with people without having access to the organizations account
> or without having to have users for them in the organizations LDAP,
> SAML, or other identity provider). I personally think federation is
> the best way to accomplish this and keep everyone on separate security
> domains, but still allow them to chat. The usual disclaimers apply:
> views are my own, etc., etc.
>

Well, I think you've hit the nail on the head there - federation is
needed to communicate between autonomous security domains. If the
domains are not federated, then either they do not communicate or else
they are not autonomous.

>> Although I like federation, I'm no longer convinced that it is necessary for
>> most people. For example, in services like Slack and Hipchat everything is
>> room-based, and that fits well with MUC/MIX. But authorization for someone
>> to join a room happens via means other than server-to-server federation
>> (e.g., set up a private room and invite the external person to that room
>> directly). Yes, this kind of workaround isn't exactly elegant, but it mostly
>> works for most people.
>
> I tend to think of this the way I think of email or telephones
> (again). In my mind most people do need federation (everyone would be
> angry if they were a Deutsche Telekom subscriber and suddenly they
> couldn't call their friends who used AT), but a few people (a
> company with a private, internal phone network) maybe don't need it
> because it's not necessary for their business (just like most people
> who use HipChat or Slack may not need federation since only people in
> their business should be able to talk to one aonther). But I think
> we're saying the same thing and just disagreeing where the majority
> lies?
>
> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Evgeny Khramtsov]

Tue, 17 Jan 2017 09:29:09 -0600
Sam Whited  wrote:

> Of note: security didn't really enter into it from her perspective

Exactly. Regular users aren't concerned about security and encryption.
They don't even know if Whatsapp has any sort of encryption. Yet, every
third discussion on this list is about encryption. Look at the tail
of the XEPs list: there are 6 encryption related XEPs out of 18 (i.e.
30%) WTF? Whom are we building network for?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Sam Whited]

On Mon, Jan 16, 2017 at 10:05 PM, Peter Saint-Andre  wrote:
>> And if your business plan doesn't involve federation, why bother with
>> the additional overhead and complexity?

I don't have a good answer for this, but it's worth asking why most
email and phone / SMS providers federate. Is it just because there are
laws saying they have to (in the case of the telephone network), or
because a critical mass was formed that expected to be able to call
anyone else regardless of the network before the phone companies /
email providers realized they could avoid the overhead and trap people
by not doing so? I'm not sure. I've always assumed email became the
primary identity provider for the internet because it was federated,
cashing in on that kind of popularity

In general I agree though; there are some business plans where
federation makes sense, and others where it doesn't. In general it
doesn't make a lot of sense in the enterprise case (although even
there we [HipChat] get requests quite often to allow eg. contractors
to chat with people without having access to the organizations account
or without having to have users for them in the organizations LDAP,
SAML, or other identity provider). I personally think federation is
the best way to accomplish this and keep everyone on separate security
domains, but still allow them to chat. The usual disclaimers apply:
views are my own, etc., etc.

> Although I like federation, I'm no longer convinced that it is necessary for
> most people. For example, in services like Slack and Hipchat everything is
> room-based, and that fits well with MUC/MIX. But authorization for someone
> to join a room happens via means other than server-to-server federation
> (e.g., set up a private room and invite the external person to that room
> directly). Yes, this kind of workaround isn't exactly elegant, but it mostly
> works for most people.

I tend to think of this the way I think of email or telephones
(again). In my mind most people do need federation (everyone would be
angry if they were a Deutsche Telekom subscriber and suddenly they
couldn't call their friends who used AT), but a few people (a
company with a private, internal phone network) maybe don't need it
because it's not necessary for their business (just like most people
who use HipChat or Slack may not need federation since only people in
their business should be able to talk to one aonther). But I think
we're saying the same thing and just disagreeing where the majority
lies?

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Sam Whited]

On Tue, Jan 17, 2017 at 6:29 AM, Holger Weiß  wrote:
> * Peter Saint-Andre  [2017-01-16 09:28]:
>> If someone like Sam's friend told me they wanted to find a secure messaging
>> service, I'd tell them to just use Signal.
>
> I wouldn't, because Sam's friend would likely end up with an empty
> roster.  Why?  Because IM vendors don't federate.

Of note: security didn't really enter into it from her perspective,
and all my friend really wants to do is send text messages; I actually
*did* tell her just to use Signal (she doesn't need to know or care
that under the hood I'm using a different protocol to communicate with
her than she is with all of the other people she texts on a day to day
basis).

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Dave Cridland]

On 17 January 2017 at 14:34, Holger Weiß  wrote:
> * Vitaly Takmazov  [2017-01-17 17:10]:
>> 2017-01-17 15:11 GMT+03:00 Holger Weiß :
>> > I don't want to install
>> > I don't want to be
>> > I want to
>>
>> XMPP will never have successful project until community members will
>> not think what *user* wants to install, to be, and wants to have :)
>
> Users want to be able to chat with anyone no matter what client they're
> using.  I'm all for thinking from their perspective; but that won't make
> XMPP federation 'successful' either, because economics.
>

The economics actually work in favour of federation for smaller
outfits. It's only successful ones that benefit from its absence. But
survivorship bias, etc.

Similarly, server selection suffers from being a market for lemons, if
we're going to do economics.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Holger Weiß]

* Vitaly Takmazov  [2017-01-17 17:10]:
> 2017-01-17 15:11 GMT+03:00 Holger Weiß :
> > I don't want to install
> > I don't want to be
> > I want to
>
> XMPP will never have successful project until community members will
> not think what *user* wants to install, to be, and wants to have :)

Users want to be able to chat with anyone no matter what client they're
using.  I'm all for thinking from their perspective; but that won't make
XMPP federation 'successful' either, because economics.

Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Holger Weiß]

* Peter Saint-Andre  [2017-01-16 09:28]:
> If someone like Sam's friend told me they wanted to find a secure messaging
> service, I'd tell them to just use Signal.

I wouldn't, because Sam's friend would likely end up with an empty
roster.  Why?  Because IM vendors don't federate.

So, appreciating Signal for technical reasons while at the same time
considerung federation a non-essential UX factor doesn't really make
sense to me.

Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Holger Weiß]

* Peter Saint-Andre  [2017-01-16 21:05]:
> Although I like federation, I'm no longer convinced that it is necessary for
> most people. For example, in services like Slack and Hipchat everything is
> room-based, and that fits well with MUC/MIX.

Yes, Slack and HipChat probably work well for internal team chat.  But
for the general IM use case (served by WhatsApp, Viber and friends), I
see the fact that we don't have ubiquitous federation (like we do e.g.
for phone/SMS) as a UX desaster.

I don't want to install a bunch of messengers just to be able to contact
everyone.  I don't want to be at the mercy of my app vendor's business
strategy.  I want to choose one out of a bunch of competing clients and
providers without loosing my contacts when switching.  And then there's
the privacy-minded people who don't feel comfortable with all metadata
being available on a small number of central systems.

Don't get me wrong.  I don't see us getting anywhere near ubiquitous
federation, and as long as it isn't ubiquitous, federation does indeed
not buy people much.  But this is solely due to (missing) economic
incentives, it's not a technical question.  So I think we shouldn't let
Moxie and other players with similar incentives talk us into believing
otherwise.

Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Dave Cridland]

On 17 January 2017 at 04:05, Peter Saint-Andre  wrote:
> The world I work in has mostly migrated away from on-premises software, to
> cloud services that are public or semi-private. I recognize that some
> organizations simply can't go there - they have regulatory reasons or
> security policies for not allowing any data outside of their trust
> boundaries (e.g., military systems, some big companies, some smaller
> companies in specific industries like aerospace or medicine). However, such
> organizations are in the minority.
>

I don't think it's a clear-cut divide between cloud-and-closed and
self-hosting-and-open. It hasn't been with email, which has been a
functioning mixture across both dimensions, which Microsoft Exchange
handling self-hosted and closed, and the majority of providers being
cloud and open throughout its history.

So suggesting that "the world [...] has mostly migrated away from
on-premises software" is implying a dichotomy the evidence of which
isn't borne out by history.

Yes, the vast majority of people, and most organisations, will be
served best by using a specialist provider. But a single provider? I'm
far from convinced that's a positive outcome for anyone except the
rare winner.

> Although I like federation, I'm no longer convinced that it is necessary for
> most people. For example, in services like Slack and Hipchat everything is
> room-based, and that fits well with MUC/MIX. But authorization for someone
> to join a room happens via means other than server-to-server federation
> (e.g., set up a private room and invite the external person to that room
> directly). Yes, this kind of workaround isn't exactly elegant, but it mostly
> works for most people.
>

It's a model that works very well for Slack and HipChat, and that they
have managed to make palatable to their users. In fairness, it can
work very well for users - the low-friction of handing someone a URL
is very useful, and serv{ice|er} developers should learn from this -
but I don't believe that it's genuinely in the interests of the users'
or their organisations to operate this way.

And for providers, too, it's a disaster. We only see the handful of
success stories and it's easy - although utterly fallacious - to think
that if one group of six people can knock together a successful IM
system then anyone can. But that's just not true. Enormous luck is
involved, and the path to glory is littered with failed IM services.
They don't fail, for the most part, due to some technical flaw, or
imperfect UX, they simply fail because the numbers of success stories
are predominantly limited by the whimsy of users. It turns out it
needs thousands to try to make a new IM system for one or two to
succeed.

> As to Signal, they appear to be a not-for-profit and to have not taken VC
> money. Thus it's not clear to me that they plan to sell their overall
> service to an acquiring company - the usual model these days. Perhaps they
> do want to sell their technology or consulting services around their
> technology as a way to become self-sustaining, but that's more of a
> lifestyle business (with its own myriad challenges!) and not necessarily a
> path to selling out. (BTW, if I had gotten serious about doing something
> like this with jabber.org, people might be saying the same thing about that
> initiative!)

I think "selling out" is a term that's become somewhat meaningless
over the years, but I've assumed it to mean that someone places
financial considerations over principles and/or the public good.

But while Signal is a not-for-profit, and indeed has not taken VC
money, the levels of cash are very high - just in terms of known
grants and donations it's in excess of $3 million, and split 6 ways
across four years that's not a lifestyle business anymore (well, maybe
it is, but it's a great lifestyle). That's not including the financial
gains from licensing deals with Facebook, WhatsApp, and Google.

The mere fact of making money isn't the real issue here, however - my
main concerns here are the legal stance and apparent willingness to
resort to lawyers to defend their novel interpretation of "open
source".

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Peter Saint-Andre]

On 1/16/17 10:40 AM, Dave Cridland wrote:

On 16 January 2017 at 17:32, Evgeny Khramtsov  wrote:

Mon, 16 Jan 2017 09:28:41 -0700
Peter Saint-Andre  wrote:


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.


But IM companies don't choose XMPP. Whatsapp was initially build on top
of XMPP but now it's something different. New services like Slack and
Signal don't use XMPP neither. So seems like XMPP is not that featured
protocol even though there are "server packages, libraries and support".


I'd say MUC and Federation.

MUC's just not the right model anymore. (Hence we need MIX).

And if your business plan doesn't involve federation, why bother with
the additional overhead and complexity?

Individual services more or less operate on a business plan that's the
antithesis of federation - they want to get everyone using their own
service. Signal's is similar, but they want to get a sufficient
critical mass on their own service to then sell the (now proven)
technology to others.

Businesses simply buying an IM service, however, want to be able to
talk to their supply-chain, customers, and so on. So federation can
still be a selling point.


I'm still pondering all of this.

The world I work in has mostly migrated away from on-premises software, 
to cloud services that are public or semi-private. I recognize that some 
organizations simply can't go there - they have regulatory reasons or 
security policies for not allowing any data outside of their trust 
boundaries (e.g., military systems, some big companies, some smaller 
companies in specific industries like aerospace or medicine). However, 
such organizations are in the minority.


Although I like federation, I'm no longer convinced that it is 
necessary for most people. For example, in services like Slack and 
Hipchat everything is room-based, and that fits well with MUC/MIX. But 
authorization for someone to join a room happens via means other than 
server-to-server federation (e.g., set up a private room and invite the 
external person to that room directly). Yes, this kind of workaround 
isn't exactly elegant, but it mostly works for most people.


As to Signal, they appear to be a not-for-profit and to have not taken 
VC money. Thus it's not clear to me that they plan to sell their overall 
service to an acquiring company - the usual model these days. Perhaps 
they do want to sell their technology or consulting services around 
their technology as a way to become self-sustaining, but that's more of 
a lifestyle business (with its own myriad challenges!) and not 
necessarily a path to selling out. (BTW, if I had gotten serious about 
doing something like this with jabber.org, people might be saying the 
same thing about that initiative!)


Peter

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Evgeny Khramtsov]

Mon, 16 Jan 2017 19:55:42 +0100
Georg Lukas  wrote:

> Actually, I see xmpp as a possible solution here for multiple
> reasons. 
> 
> There is a hype about Slack right now, but Slack is rather expensive.
> If we could provide a similar UX in top of self-hosted XMPP, that
> would be a good selling point. 
> 
> Furthermore, big companies are often bound by compliance requirements
> (archival duties, on site storage, etc). This is another selling
> point. 
> 
> IMHO all we need here is a server package / consultancy to roll out
> the implementation, a usable set of clients for mobile, desktop and
> the web, and a compelling 2FA authentication mechanism. 

I tend to agree with Peter (if I understand him correctly): what you
suggest is building/offering some sort of service on top of XMPP (which
is out of scope of XSF). And I don't think this can be done by XMPP
community either, because the community is very separated and have
different points of view.
I think we have already built XMPP network for enthusiasts, there is
nothing more we can do. But we got stuck at this point. For example,
even "community favourite" Conversations is moving towards service
oriented software as far as I know: I guess simply because there is
nowhere to move within the community.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Guus der Kinderen]

What I am doing here, first, and foremost, is having fun. Having gotten
that out of the way: the discussion so far revolves around the use-case of
a single user, wanting to do IM with friends. Undoubtedly that's an
important part of the ecosystem (on which we can and should improve) but
I've seen much value in XMPP in other settings too. XMPP offers a mature
ecosystem in which to develop custom data-exchange driven systems, even
when those are not oriented to instant messaging.

On 16 January 2017 at 19:08, Evgeny Khramtsov  wrote:

> Mon, 16 Jan 2017 17:59:21 +
> Dave Cridland  wrote:
>
> > That's not what I said, I said that federation was an important
> > feature.
>
> You have said exactly that:
> > And if your business plan doesn't involve federation, why bother with
> > the additional overhead and complexity?
>
> Which means it doesn't make sense to deploy XMPP if you don't need
> federation.
>
> > But anyway, I'll rephrase: businesses want to communicate with their
> > supply-chain and with their customers, and want a communications
> > platform that allows this.
>
> You repeated, not rephrased.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Peter Saint-Andre]

On 1/16/17 11:55 AM, Georg Lukas wrote:



Evgeny Khramtsov :

Well, my company (ProcessOne) has been doing this since 2002 or so.
We are trying to convince customers that XMPP is a worthy
technology, but it is becoming harder and harder to do.


Actually, I see xmpp as a possible solution here for multiple
reasons.

There is a hype about Slack right now, but Slack is rather expensive.


They have a lot of users, who don't seem to mind paying for it. Perhaps 
the market has decided that it's good enough to use hosted services like 
Slack and Hipchat?



If we could provide a similar UX in top of self-hosted XMPP, that
would be a good selling point.


IIRC, the Kaiwa folks have already done this:

http://getkaiwa.com/


Furthermore, big companies are often bound by compliance requirements
(archival duties, on site storage, etc). This is another selling
point.


That's true, but the market is relatively small.


IMHO all we need here is a server package / consultancy to roll out
the implementation, a usable set of clients for mobile, desktop and
the web, and a compelling 2FA authentication mechanism.


That's not an insignificant amount of work, and IMHO it would require a 
small, focused team (a la the Signal team). In other words, you're 
talking about starting a company or a non-profit organization, which 
means finding money, hiring a team, making hard business and technology 
decisions, etc.


Peter



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Georg Lukas]

 Evgeny Khramtsov :
> Well, my company (ProcessOne) has been doing this since 2002 or so. We
> are trying to convince customers that XMPP is a worthy technology, but
> it is becoming harder and harder to do.

Actually, I see xmpp as a possible solution here for multiple reasons. 

There is a hype about Slack right now, but Slack is rather expensive. If we 
could provide a similar UX in top of self-hosted XMPP, that would be a good 
selling point. 

Furthermore, big companies are often bound by compliance requirements (archival 
duties, on site storage, etc). This is another selling point. 

IMHO all we need here is a server package / consultancy to roll out the 
implementation, a usable set of clients for mobile, desktop and the web, and a 
compelling 2FA authentication mechanism. 

Georg 
-- 
+++ Sent from Mobile +++ https://op-co.de/ +++
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Evgeny Khramtsov]

Mon, 16 Jan 2017 12:00:26 -0600
Sam Whited  wrote:

> Perhapse *this* is the problem we (the XSF) should focus on: building
> for an enecouraging the larger companies to use XMPP, and eventually
> to federate and be interoperable. If we can show these companies that
> there's some concrete benefit to it (bearing in mind that there may
> not be), it could accomplish our goals of having everyday people who
> don't care about federation use a federated network much better than
> focusing on small free services and clients.

Well, my company (ProcessOne) has been doing this since 2002 or so. We
are trying to convince customers that XMPP is a worthy technology, but
it is becoming harder and harder to do. I think it's virtually
impossible for a non-profit organization such as XSF to spread the
technology among large customers. Initially there was hype (most likely
due to GTalk), but now there is no hype.
Also, there are a lot of open-source enthusiasts on the list and seems
like they are setting the trend for XSF movement (unlike, for example,
WhatWG). In this case, obviously, XMPP will be built for this
enthusiasts, because it will solve their problems (obsession with
encryption is an example), but not the problems of large/commercial
services (which, seems like, isn't even be understood).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Dave Cridland]

On 16 January 2017 at 18:08, Evgeny Khramtsov  wrote:
> Mon, 16 Jan 2017 17:59:21 +
> Dave Cridland  wrote:
>
>> That's not what I said, I said that federation was an important
>> feature.
>
> You have said exactly that:
>> And if your business plan doesn't involve federation, why bother with
>> the additional overhead and complexity?
>
> Which means it doesn't make sense to deploy XMPP if you don't need
> federation.
>

No, two distinct cases. I'm still being unclear, sorry.

One was using XMPP as the basis of a service you *offer*. The other
was using XMPP as the basis of a service you *use*. Use of XMPP
generally makes sense, if you want to host your own (for security
reasons or whatever). And that does happen - there's plenty of
communities of autonomous organizations. Even if you don't want
federation, deploying an XMPP server can make sense - the vast, vast
majority of Openfire deployments don't federate. And I'm pretty
comfortable in asserting there's more of these than any other server,
though I lack the evidence.

Building your own service, however, is different - because federation
introduces complexities and overheads, it's an overhead that you're
paying. And if you explicitly don't want to federate - and why would
you, in order to run a walled-garden? - then it's a complexity that's
not worth paying.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Peter Saint-Andre]

On 1/16/17 10:32 AM, Evgeny Khramtsov wrote:

Mon, 16 Jan 2017 09:28:41 -0700
Peter Saint-Andre  wrote:


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.


But IM companies don't choose XMPP. Whatsapp was initially build on top
of XMPP but now it's something different. New services like Slack and
Signal don't use XMPP neither. So seems like XMPP is not that featured
protocol even though there are "server packages, libraries and support".


I didn't say that huge consumer-oriented services use XMPP, but smaller 
and specialized ones often do.


Peter


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Florian Schmaus]

On 16.01.2017 17:28, Peter Saint-Andre wrote:
> 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!

Thanks comparing apples with oranges. Their people work possible full
time on Signal. I wonder if there is any FOSS XMPP client with more than
1-2 full time developer(s). All FOSS clients I'm aware of, besides
Conversations, have 1 spare time main developer.

> If someone like Sam's friend told me they wanted to find a secure
> messaging service, I'd tell them to just use Signal.

Please don't.

> 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 jabber.ccc.de case has shown how fragile the ecosystem gets if we
are focusing on a few big XMPP services and tell users to use that
service(s). I am not sure if I would put effort into creating another
service of this kind. I'd say we teach people to run their own XMPP
service. It just™ has to be as easy as setting up a new TV. But of
course, I know that this is a long road until we are there.

- Florian




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Evgeny Khramtsov]

Mon, 16 Jan 2017 17:59:21 +
Dave Cridland  wrote:

> That's not what I said, I said that federation was an important
> feature.

You have said exactly that:
> And if your business plan doesn't involve federation, why bother with
> the additional overhead and complexity?

Which means it doesn't make sense to deploy XMPP if you don't need
federation.

> But anyway, I'll rephrase: businesses want to communicate with their
> supply-chain and with their customers, and want a communications
> platform that allows this.

You repeated, not rephrased.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Sam Whited]

On Mon, Jan 16, 2017 at 10:28 AM, Peter Saint-Andre  wrote:
> Thus I repeat the question: what are we doing here?

I agree with most everything Peter said, that being said, I also agree
with most of Dave's response (although I don't personally have any
problem with OWS, and use Signal myself as my SMS client). I do think
it's important to get people using a federated system, they may not
know or care what federation is, but it will benefit them and everyone
else in the long run, even if they don't understand the consequences
of using or not using such a system.

When we have these discussions, we tend to conflate "the open source,
individual, volunteer run XMPP nodes" with "XMPP". We can't make the
small open source shops (clients or services) do better except by
submitting patches and making requests; they might not even want to do
better or consider it "better". When we advertise things as "XMPP"
we'll always end up directing "normal" everyday Joe's and Janes to
services that are designed for technically minded people who already
know what XMPP is and how it works. There are things we can do to
mitigate that when it inevitably happens (eg. being more selective
about what clients we recommend, providing simple instructions that
explain that xmpp.org isn't what they wanted and show them how to set
up an account on a reliable server ,etc.), but these sorts of things
are really just bandaids and don't really fix the underlying problem.

In my mind the take away is that there are much better alternatives
than most of what our community provides, and I don't necessarily
think it's a problem the XSF can (or should) solve. We can provide a
bit of help on occasion, but it's not our job to maintain every client
in existance.

If what we really think is important is federation (and not just
complaining that we don't like it when companies make money), then
maybe we're addressing the wrong problem. Instead of focusing on the
community and the individual users, maybe we should be focusing on the
companies (WhatsApp, Slack, etc, note that I'm only focusing on IM
here, I know nothing about IoT or any other use case for XMPP):

On Mon, Jan 16, 2017 at 11:32 AM, Evgeny Khramtsov  wrote:
> But IM companies don't choose XMPP. Whatsapp was initially build on top
> of XMPP but now it's something different. New services like Slack and
> Signal don't use XMPP neither. So seems like XMPP is not that featured
> protocol even though there are "server packages, libraries and support".

Perhapse *this* is the problem we (the XSF) should focus on: building
for an enecouraging the larger companies to use XMPP, and eventually
to federate and be interoperable. If we can show these companies that
there's some concrete benefit to it (bearing in mind that there may
not be), it could accomplish our goals of having everyday people who
don't care about federation use a federated network much better than
focusing on small free services and clients.

This is in some ways an equally hard problem, but it's not one that
I've seen a strategy for, so maybe it's time to try something new and
think about it (or maybe it's been considered in the past and I just
don't have enough history, in which case I'd love it if someone could
provide some background).

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Dave Cridland]

On 16 January 2017 at 17:57, Evgeny Khramtsov  wrote:
> Mon, 16 Jan 2017 17:40:11 +
> Dave Cridland  wrote:
>
>> Businesses simply buying an IM service, however, want to be able to
>> talk to their supply-chain, customers, and so on. So federation can
>> still be a selling point.
>
> Could you elaborate on this? I don't understand what supply-chain and
> customers businesses want to talk with when buying some IM service.
> This is important, because without federation XMPP is not worthy, as
> you said above.

That's not what I said, I said that federation was an important feature.

But anyway, I'll rephrase: businesses want to communicate with their
supply-chain and with their customers, and want a communications
platform that allows this.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Evgeny Khramtsov]

Mon, 16 Jan 2017 17:40:11 +
Dave Cridland  wrote:

> Businesses simply buying an IM service, however, want to be able to
> talk to their supply-chain, customers, and so on. So federation can
> still be a selling point.

Could you elaborate on this? I don't understand what supply-chain and
customers businesses want to talk with when buying some IM service.
This is important, because without federation XMPP is not worthy, as
you said above.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Dave Cridland]

On 16 January 2017 at 17:32, Evgeny Khramtsov  wrote:
> Mon, 16 Jan 2017 09:28:41 -0700
> Peter Saint-Andre  wrote:
>
>> 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.
>
> But IM companies don't choose XMPP. Whatsapp was initially build on top
> of XMPP but now it's something different. New services like Slack and
> Signal don't use XMPP neither. So seems like XMPP is not that featured
> protocol even though there are "server packages, libraries and support".

I'd say MUC and Federation.

MUC's just not the right model anymore. (Hence we need MIX).

And if your business plan doesn't involve federation, why bother with
the additional overhead and complexity?

Individual services more or less operate on a business plan that's the
antithesis of federation - they want to get everyone using their own
service. Signal's is similar, but they want to get a sufficient
critical mass on their own service to then sell the (now proven)
technology to others.

Businesses simply buying an IM service, however, want to be able to
talk to their supply-chain, customers, and so on. So federation can
still be a selling point.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Evgeny Khramtsov]

Mon, 16 Jan 2017 09:28:41 -0700
Peter Saint-Andre  wrote:

> 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.

But IM companies don't choose XMPP. Whatsapp was initially build on top
of XMPP but now it's something different. New services like Slack and
Signal don't use XMPP neither. So seems like XMPP is not that featured
protocol even though there are "server packages, libraries and support".
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Dave Cridland]

On 16 January 2017 at 16:28, Peter Saint-Andre  wrote:
> On 1/16/17 7:00 AM, Evgeny Khramtsov wrote:
>>
>> Mon, 16 Jan 2017 14:29:42 +0100
>> Georg Lukas  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: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Peter Saint-Andre]

On 1/16/17 9:50 AM, Georg Lukas wrote:



Peter Saint-Andre :

So, at this point, I wonder what we're doing here. :-)


Signal is a single company


It's a not-for-profit organization. Not exactly a for-profit monster 
like Google or Facebook.



providing a centralized product.


How important is the centralized aspect? The clients are open-source and 
can be inspected to determine the level of security and privacy.



I think
what's missing the most for our user community is the federation and
the choice of clients.


Few real people care about those things.


While I agree with you that they have achieved
significant results with a bunch of people,


~6 people is a small bunch.


this only shows that we
can get at least as good, if we just concentrate our efforts.


But we haven't done a good job of that. What's that definition of 
insanity? "Doing the same thing over and over again and expecting 
different results", right?



A single decision by Moxie or a single court order in some country
can make Signal unavailable to a large part of its user base.


That does concern me.

I'd argue that truly decentralized technologies (no servers or services 
involved at all) are even better than a federated model. But those are 
really hard to build.



Email and the web have survived the last decades, while centralized
services came and went away (anybody remembers AOL? MySpace?).


Good point.

Peter

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Evgeny Khramtsov]

Mon, 16 Jan 2017 09:28:41 -0700
Peter Saint-Andre  wrote:

> Thus I repeat the question: what are we doing here?

As I understand: the guys here want to get more people involved into
XMPP network, because they have virtually nobody to talk with :) Most of
the time they are forced to use Whatsapp and they don't like it, LOL.
But I'm surprised folks on the list started to understand that XMPP
software sucks, that's really a progress over 15+ years :)

I personally don't use jabber to communicate with people beyond my job.
I just don't have a decent jabber client which can be somehow compared
with what I'm using: Whatsapp, Viber and Skype. While I of course can
ask my friends to install XMPP software (they already have 100+ IM
clients on their phones, so who cares), I myself don't want to use
shitty software just because it's decentralized/secure/etc.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Peter Saint-Andre]

On 1/16/17 7:00 AM, Evgeny Khramtsov wrote:

Mon, 16 Jan 2017 14:29:42 +0100
Georg Lukas  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?

Peter

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Georg Lukas]

Sam Whited :
> I recently ran an experiment with a non-Technical friend where I gave
> them some prompts, and then answered direct questions without hand
> holding them through anything and more or less recorded a transcript
> of what was said and what they clicked on.

This is exactly what client developers need to do to see how bad the experience 
is. I've learned a lot from such experiments in the past, and tried to cover 
the results in Easy*. 


> Maybe just having a "Get Started" link in big bold text right at the
> top of xmpp.org would help a lot.

That's an awesome idea! Please do it! 

I've tried to create such a landing page for newcomers with 
https://yax.im/i/#ge...@yax.im but it needs a bit more polish and especially a 
curated per-platform client list in which Easy Onboarding is implemented. 


> they were
> suprised that on first launching gajim it didn't walk them through
> adding an account and instead just immediately gave them popups about
> plugins that needed updating.

And then you get the account creation "wizard" that's almost impossible to 
operate, even for seasoned xmpp users. 


Georg
-- 
+++ Sent from Mobile +++ https://op-co.de/ +++
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Sam Whited]

On Tue, Jun 7, 2016 at 10:04 AM, Georg Lukas  wrote:
> in the last weeks we've seen that XMPP is too hard for the WhatsApp
> generation. Instead of blaming them for not understanding federation, we
> should make it as easy as possible to use XMPP (IM) in a secure fashion.

I recently ran an experiment with a non-Technical friend where I gave
them some prompts, and then answered direct questions without hand
holding them through anything and more or less recorded a transcript
of what was said and what they clicked on.

The first prompt was "I'm using XMPP to chat, you should sign up forn
an account and add me!"

The important parts of the next 5 or so minutes before they gave up were:

- Google "xmpp"
- Click on xmpp.org
- Say out loud "where's the download button?"
- Dig around on xmpp.org for a few minutes
- Give up

Maybe just having a "Get Started" link in big bold text right at the
top of xmpp.org would help a lot. People who know that's not really
what xmpp.org is for would ignore it.
Of course, the prompt was arguably misleading, but I suspect that's
what a lot of people are given in introduction to XMPP and don't
understand that the XSF has nothing to do with what they want other
than writing the standards that back it.

Beyond that I also gave them a more specific prompt to sign up at
jabber.at (it wasn't the smoothest onboarding flow, but they got there
in the end) and then told them to "download an XMPP client" at which
point they remembered the "clients" page from xmpp.org, went back
there, looked around until they saw something that said "Windows" (it
ended up being gajim), downloaded and installed that, and then sat
there and couldn't figure out how to make an account. When I prompted
them to "look for the accounts menu and hit add and enter the details
you got on jabber.at" they were able to figure it out, but they were
suprised that on first launching gajim it didn't walk them through
adding an account and instead just immediately gave them popups about
plugins that needed updating.

All very unscientific and told us what we already know, but it's
always fun to do this none the less.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Evgeny Khramtsov]

Mon, 16 Jan 2017 14:29:42 +0100
Georg Lukas  wrote:

> https://wiki.xmpp.org/web/Easy_Onboarding  

And regarding Easy Onboarding itself. Can't we reuse existing user
databases via Oauth? A lot of users have accounts with "contact lists"
in Facebook, Google, etc. I recall there is OAUTH SASL RFC, can't we
use it?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Georg Lukas]

Kevin Smith :
> It’s worth noting that I think you mean the ‘Public/unaffiliated
> Internet XMPP IM use case”. Lots of XMPP use is either pre-provisioned
> or off-Internet, or both.

Indeed. If you have some catchy name for it, I'll gladly apply that label to 
make my intentions more clear. 

>> https://wiki.xmpp.org/web/Easy_Onboarding
> 
> Apart from brief bits I disagree with (hiding password generation from
> the user), I think pretty much all of this can be achieved by a
> sufficiently motivated client already.

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. 

We really need to stop being a communication protocols org and start caring 
about UX. Writing down these things, and motivating client developers to 
implement them, is a task we finally need to face and act upon. 

There are ideas going beyond the Easy* series, like what Sam recently proposed 
for a centrally maintained list of public servers with tldr ToS. Such a list is 
obviously a group effort, and it needs protocol and client support. 

>> https://wiki.xmpp.org/web/Easy_Roster_Invitations
> I’ve only scanned it, but it doesn’t look immediately stupid on
> scanning, and I think writing up a XEP would be a good way to get
> further comment.

That's the danger of thread necromancy 

http://xmpp.org/extensions/xep-0379.html has been published and didn't receive 
much feedback yet. It still needs a followup to move the token generation and 
approval to the server, but I haven't had the time for that yet. 

As a corollary, I've started https://github.com/ge0rg/easy-xmpp-invitation 
which can easily be hosted by server operators or client implementors to 
support the onboarding. 

Georg
-- 
+++ Sent from Mobile +++ https://op-co.de/ +++
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Kevin Smith]

On 7 Jun 2016, at 16:04, Georg Lukas  wrote:
> I think we can improve significantly for the XMPP IM use case (I have
> not much expertise in other use cases), if we simplify the things that
> can be simplified, make them consistent between clients, and give the
> whole thing a catchy name like "Easy XMPP" or "Modern XMPP" or somesuch,
> that will be applied to conforming implementations.

It’s worth noting that I think you mean the ‘Public/unaffiliated Internet XMPP 
IM use case”. Lots of XMPP use is either pre-provisioned or off-Internet, or 
both.

Doesn’t detract from the need to do it, mind.

> Many people come to XMPP because they want to chat to some existing XMPP
> user.  Therefore that user should have an easy mechanism to get their
> friends onboarded, via some out-of-band mechanism (like a URL). That
> onboarding should include client installation, account creation, adding
> the first roster item, and optionally forwarding of "common buddies"
> from the existing XMPP user: https://wiki.xmpp.org/web/Easy_Onboarding

Apart from brief bits I disagree with (hiding password generation from the 
user), I think pretty much all of this can be achieved by a sufficiently 
motivated client already.

> The above is a set of high-level ideas that apply to the whole process,
> an in-depth look into a potential implementation (still far from a
> proto-XEP) can be found in https://wiki.xmpp.org/web/Easy_Roster_Invitations
> 
> The last one contains some open questions regarding the complexity of
> the protocol and the possible entities where it should be implemented.
> I'd like to have a discussion of these before I make my first attempt at
> writing an XEP…

I’ve only scanned it, but it doesn’t look immediately stupid on scanning, and I 
think writing up a XEP would be a good way to get further comment.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Daniele Ricci]

On Mon, Jan 16, 2017 at 11:18 AM, Kevin Smith  wrote:
> Just jumping in on the point of ‘standards…simply do not exist’ is very much 
> untrue for the client certificate auth point above.

Indeed, just lack of clients implementing it (IIRC there are just 1 or
2 clients capable of doing that, besides Kontalk).
Our implementation is a bit "custom" anyway:
https://github.com/kontalk/tigase-kontalk/blob/master/docs/server-internals.md#pgp-key-based-authentication

*Some* of those other extensions are described here:
https://github.com/kontalk/specs
(sorry, some stuff is still WIP)

-- 
Daniele
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Kevin Smith]

Thread necromancy.

> On 8 Jun 2016, at 18:59, A. Bikadorov  wrote:
> you may wanna have a look at the Kontalk project which already has a client 
> implementing
> some simplifications you are proposing:
> - server list + automatic server selection (and option to override)
> - account creation by telephone number and user name (with SMS or Call 
> verification)
> - no password: authentication with a client certificate
> - contact creation via sync with Android address book
> 
> All these mechanisms don't follow any standards as they simply do not exist. 
> But unifying
> anything here and having multiple clients with interoperability can make IM 
> with XMPP a
> lot better. [Disclaimer: I'm involved in this project]

Just jumping in on the point of ‘standards…simply do not exist’ is very much 
untrue for the client certificate auth point above.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[W. Martin Borgert]

Pardon, this was meant to sent privately :~) Usability issue in Horde,
I assume, or lack-of-brain problem between keyboard and chair.

Here in English: Germany and probably other countries like to make
anonymous SIMs illegal. Relying on phone numbers would make anonymous
"Easy XMPP" illegal, too, which is probably not a goal.

And: What is XEP-PARS?

TIA!

Quoting "W. Martin Borgert" :


Hi,

eine private Bemerkung und eine Frage:

Quoting Georg Lukas :

2. Use of phone numbers: unfortunately this is an unsolved problem yet.


Da demnächst anonyme SIM-Karten in Deutschland (und vermutlich auch
anderen Staaten) outlawed werden - egal wie erfolgversprechend man
das einschätzt - wäre mit Telephonnummern als Id auch anonymes
"Easy-XMPP" illegal. Das kann das Ziel nicht sein.


- XEP-PARS: creation and full handling of links with preauth element


Was ist das für ein XEP? Hast Du einen Link für mich? Danke!

Cheers

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___




___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[W. Martin Borgert]

Hi,

eine private Bemerkung und eine Frage:

Quoting Georg Lukas :

2. Use of phone numbers: unfortunately this is an unsolved problem yet.


Da demnächst anonyme SIM-Karten in Deutschland (und vermutlich auch
anderen Staaten) outlawed werden - egal wie erfolgversprechend man
das einschätzt - wäre mit Telephonnummern als Id auch anonymes
"Easy-XMPP" illegal. Das kann das Ziel nicht sein.


 - XEP-PARS: creation and full handling of links with preauth element


Was ist das für ein XEP? Hast Du einen Link für mich? Danke!

Cheers

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Georg Lukas]

Thanks very much for the feedback, everyone! I'll try to address the
points in a single mail.

1. "Silo creation": the goal is to make the Easy* proposals backwards
compatible, so that interop with legacy clients is well-defined. The
specifications are all open, so everybody can implement them in their
clients and servers. I'm painfully aware that XMPP developers often lack
the time or are underfunded, but maybe a nice "Easy XMPP" conformity
badge can motivate some folks...

2. Use of phone numbers: unfortunately this is an unsolved problem yet.
Hashing of phone numbers offers little protection, and bloom filters
apparently don't scale. There is no solution yet to run a secure central
"phone book" for automatic lookups, an opt-in solution probably won't be
used much (cf. buddycloud-friend-finder) and decentralized /
one-server-only solutions break global discoverability while reinforcing
silofication. Besides, if the lookup server does not verify every single
element a user publishes, it opens the door to impersonation attacks.

Personally, I'd like to see how far we can improve the UX without
relying on phone numbers or central lookup servers.

3. Adding more devices to the account: this one really needs more work.
Modern cloud services offer "remember me on this device",
device-specific passwords, multi-factor authentication, etc.; then there
are also client certificates (which have a horrible UX on the web and
are not used by anybody). It looks like we first need to extend the
authentication mechanisms to get away from simple JID+password. Then we
have to figure out secure ways to "clone" a user account from one device
to another.


So far, I have implemented the following Easy XMPP ideas in yaxim
(not yet on Google Play):

 - Easy account creation @yax.im with auto-generated passwords
 - XEP-PARS: creation and full handling of links with preauth element
 - NFC / NDEF sharing of own JID (with PARS) and contacts/MUCs
 - Creation of invitation links to HTTP landing page, e.g
    (PARS token removed)

There is a <2min example video: https://op-co.de/tmp/easy-qr.mp4

Matching yaxim APK: https://yaxim.org/archive/builds/yaxim-gl-2016-06-15_muc.apk

Kind regards,

Georg


signature.asc
Description: Digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[A. Bikadorov]

Hi,

you may wanna have a look at the Kontalk project which already has a client 
implementing
some simplifications you are proposing:
- server list + automatic server selection (and option to override)
- account creation by telephone number and user name (with SMS or Call 
verification)
- no password: authentication with a client certificate
- contact creation via sync with Android address book

All these mechanisms don't follow any standards as they simply do not exist. 
But unifying
anything here and having multiple clients with interoperability can make IM 
with XMPP a
lot better. [Disclaimer: I'm involved in this project]

Cheers
Alex





signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Florian Schmaus]

On 08.06.2016 15:28, Jonas Wielicki wrote:
> On , someone wrote
>> To allow for password recovery, something needs to be done. One
>> possibility is to ask the user for their phone number or email
>> address. However, users often mistype things, so that the
>> number/address needs to be validated during onboarding.

I think the last sentence needs to be refined to

"However, users often mistype things, so that the number/address needs
to be validated before password recovery is enabled.".

It doesn't has to be strictly during onboarding, and in fact some
services (Google, Facebook, EBay) do the validation long after the
onboarding has already happened.


> On ,
> someone wrote:
>> 1. Should Romeo's client or his server implement token generation and
>> subscription approval?
>>   - A server-side implementation violates RFC6121 §3.1.3
>>   - A client-side implementation is not immediate if the user is
>> currently offline
>>   - A client-side implementation needs to sync tokens between
>> multiple clients
>>   - A server-side implementation needs an additional protocol for the
>> client to request/invalidate tokens
> 
> A client-side implementation seems flaky for the reasons outlined there.
> "violation" of RFC6121 §3.1.3 is at least debatable: one could argue
> that using such a feature is "entering an agreement with the service
> provider".

Right. I think of "MUST" in specifications always with the addition
"except if nothing else has been explicitly agreed on". Of course one
should not strive for exceptions in every case. But a server-side
implementation for such tokens seems to be a good example for a sensible
case where an add-on specification, which is explicitly negotiated,
could overrule a MUST of the base specification.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Easy XMPP

[Jonas Wielicki]

Hi Georg,

On 07.06.2016 17:04, Georg Lukas wrote:
> in the last weeks we've seen that XMPP is too hard for the WhatsApp
> generation. Instead of blaming them for not understanding federation, we
> should make it as easy as possible to use XMPP (IM) in a secure fashion.
>
> In the last days, I've collected some ideas on how to accomplish that
> into a set of wiki pages (initially originating from discussions on xsf@
> which I didn't want to lose).

Thank you very much for that!

I find much of what is written in those wiki articles very sensible.

On , someone wrote
> To allow for password recovery, something needs to be done. One
> possibility is to ask the user for their phone number or email
> address. However, users often mistype things, so that the
> number/address needs to be validated during onboarding. This is
> making XMPP less accessible and onboarding more complicated.

Mobile clients (which are, I feel, those with the most need for a very
very very simple onboarding process) could simply let the user choose
one of the phone numbers associated with the device. A server operator
would in that case have to send a check SMS. "Ideally", the client would
transparently read that SMS if the user allows that, or the SMS contains
a URL which can be opened with either the XMPP client or with a normal
web browser which concludes the verification.


An additional idea I had was on the matter of how to add more devices to
your XMPP account. One way which came into my mind was to use client
certificates throughout the whole setup. But use them transparently.
Treat them as client keys, ignore the whole expiration date and CA
stuff, simply add a white-list of fingerprints or even public keys to
the account on the server side.

To add a new device, the server could generate an authentication code
and send it to an existing device of the users choice (e.g. in response
to an Ad-Hoc command). A complying client on another device would have
an input for such a code (+ JID/Domain). It could connect to the server
and with an additional protocol (or something along the lines of
XEP-0077 with a data form) submit the code entered signed with a freshly
generated private key as well as the public key. Server validates the
signature and auth code and adds the public key to the whitelist.


On ,
someone wrote:
> 1. Should Romeo's client or his server implement token generation and
> subscription approval?
>   - A server-side implementation violates RFC6121 §3.1.3
>   - A client-side implementation is not immediate if the user is
> currently offline
>   - A client-side implementation needs to sync tokens between
> multiple clients
>   - A server-side implementation needs an additional protocol for the
> client to request/invalidate tokens

A client-side implementation seems flaky for the reasons outlined there.
"violation" of RFC6121 §3.1.3 is at least debatable: one could argue
that using such a feature is "entering an agreement with the service
provider".

> 2. Should the invitaiton link only encode minimal information (JID
> and token), or should it contain sender-defined display names for one
> or both parties?
>   - A minimal implementation is fast to implement (see
> Conversations.im) and has less corner cases, but also less user
> comfort
>   - Having a display name that differs from the JID localpart might
> be beneficial to many users, and querying the JID before adding
> them to the roster is challenging

+1 for adding display names.

I don’t want to comment on the third point there right now.

best regards,
jwi




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Easy XMPP

[Georg Lukas]

Hi folks,

in the last weeks we've seen that XMPP is too hard for the WhatsApp
generation. Instead of blaming them for not understanding federation, we
should make it as easy as possible to use XMPP (IM) in a secure fashion.

In the last days, I've collected some ideas on how to accomplish that
into a set of wiki pages (initially originating from discussions on xsf@
which I didn't want to lose).

Some of the ideas can be easily implemented already, other require minor
modifications or a bit of XEP work. After reflecting upon all these
things though I must say that I am surprised how much low-hanging fruit
we've ignored over the last decade or so, letting the Matrixes,
WhatsApps and Semaphores overtake us.

I think we can improve significantly for the XMPP IM use case (I have
not much expertise in other use cases), if we simplify the things that
can be simplified, make them consistent between clients, and give the
whole thing a catchy name like "Easy XMPP" or "Modern XMPP" or somesuch,
that will be applied to conforming implementations.

Many people come to XMPP because they want to chat to some existing XMPP
user.  Therefore that user should have an easy mechanism to get their
friends onboarded, via some out-of-band mechanism (like a URL). That
onboarding should include client installation, account creation, adding
the first roster item, and optionally forwarding of "common buddies"
from the existing XMPP user: https://wiki.xmpp.org/web/Easy_Onboarding

The above is a set of high-level ideas that apply to the whole process,
an in-depth look into a potential implementation (still far from a
proto-XEP) can be found in https://wiki.xmpp.org/web/Easy_Roster_Invitations

The last one contains some open questions regarding the complexity of
the protocol and the possible entities where it should be implemented.
I'd like to have a discussion of these before I make my first attempt at
writing an XEP...


Kind regards,

Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


signature.asc
Description: Digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___