Re: [Standards] Proposed changes to OMEMO's use of PEP

[Evgeny Khramtsov]

Fri, 24 Mar 2017 17:03:36 +0100
Andreas Straub  wrote:

> If anything, we should maybe think about adding explicit 
> server-side support for OMEMO. I would be interested to hear what the 
> wider XMPP community thinks.

As a server developer I don't like the idea and don't want to implement
this in ejabberd, because I'm against OMEMO until basic problems with
it are resolved (like full-text search, problems with losing
keys/devices, etc).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Andreas Straub]

Hi,


I'm curious which server-side support for OMEMO you have in mind. Care
to elaborate?


So there are a few things about the PEP-based approach that are not 
ideal. The devicelist contention that the proposed change aims to 
address is really only one example of several scenarios where the client 
has to carefully manage the data in PEP by itself because the server 
doesn't act as anything more than a key/value store for our purposes.


It would be cool if we could have the server enforce some of the 
business logic for us, so that the client doesn't have to. Basically, 
the server would not only manage the devicelist more intelligently but 
also actually act like a X3DH key server[1].


Mostly, this would just entail offering more "atomic" primitives than is 
possible with PEP, e.g. publishing prekeys individually rather than 
having to overwrite the entire bundle. It would also only hand out any 
prekey once, so no two initiators could end up using the same prekey to 
build a session with the responder. The server could also assign device 
ids to new clients to prevent collisions there. Having some server-side 
constraints like this in place just makes life easier for the clients.


Some details would still have to be figured out, like whether we want 
the server to require some kind of proof from the client that it's 
actually "allowed" to publish/modify the data (signatures with the 
identity key or something?), or how to handle removing stale devices. 
But in essence, server-assisted OMEMO wouldn't look  all that different 
from what we have currently at all.


So as you can see, this wouldn't actually be a very complicated thing to 
implement, it's really just a few different IQ get/sets and some simple 
constraint checks. The bigger issue is going to be deployment, which is 
of course why we went with PEP in the first place...



[1] https://whispersystems.org/docs/specifications/x3dh/#roles
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Matthew Wild]

On 24 March 2017 at 16:03, Andreas Straub  wrote:
> In summary, I understand that the current behavior can seem strange at
> first, and I'm certainly not opposed to improving this in some way, I really
> don't think this proposal is the way to go here. It breaks the protocol. If
> anything, we should maybe think about adding explicit server-side support
> for OMEMO. I would be interested to hear what the wider XMPP community
> thinks.

As a server developer, I'd be +1 to such a move.

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

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Jonas Wielicki]

On Freitag, 24. März 2017 17:20:31 CET Florian Schmaus wrote:
> On 24.03.2017 17:03, Andreas Straub wrote:
> > If anything, we should maybe think about adding explicit
> > server-side support for OMEMO.
> 
> I'm curious which server-side support for OMEMO you have in mind. Care
> to elaborate?
> 
> And thanks for your extended discussion of PR #458. I agree with
> everything you wrote. Sadly the PR did not include any motivation and I
> don't remember the exact details from the discussion at the summit.
> Hence I still would love to hear the rationale behind it.

+1 to all of this (except that I wasn’t even at the summit and it would be 
great if I could still follow the discussion).

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Florian Schmaus]

On 24.03.2017 17:03, Andreas Straub wrote:
> If anything, we should maybe think about adding explicit
> server-side support for OMEMO.

I'm curious which server-side support for OMEMO you have in mind. Care
to elaborate?

And thanks for your extended discussion of PR #458. I agree with
everything you wrote. Sadly the PR did not include any motivation and I
don't remember the exact details from the discussion at the summit.
Hence I still would love to hear the rationale behind it.

- 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] Standardise Colours used in XMPP clients

[Georg Lukas]

* Tobias M  [2017-03-24 08:39]:
> Quite a complex problem you choose to solve there. Ideally you want a
> colour palette where the colours are as much different to the user as
> possible.

There are three principal approaches:

1) dynamic based on # of participants - best color separation in small
   MUCs (I remember seeing an algorithm for successively adding new
   maximally-distinct colors for new participants, though I can't find
   it now)

2) dynamic based on participand JID/nickname - color separation might
   end up good or bad.

3) fixed static palette with a small, limited number of colors. Android
   is using this approach  to
   create 14 distinct high-contrast colors for contact tiles - color
   separation might end up good or bad.

(1) doesn't provide stability across clients / sessions and will end up
with similar colors on large chatrooms, (3) provides the best contrast
but will end up mapping different contacts to the same color, kind of
refuting the purpose. Therefore I consider (2) to be the best way to go
forward.

> The more colours you have in your colour palette, the more likely
> you’ll have very similar colours, which some users can’t distinguish.

If you have less colors than users, you will end up with an N:1 mapping
that no users can distinguish. The color is always merely a hint, and we
aim for a 90% solution.

> Furthermore a sensible colour palette for nicknames depends on the
> colours of the chat theme. If the chat theme has a light green
> background it probably rules out some colours that would work fine in
> a white background chat theme.

Yes, this is true. There is no general solution to this, and it's
already complicated enough to create a scheme that works well on black
and on white backgrounds. I think that Jonas' proposed approach of
first generating good colors that work on neutral backgrounds, and then
mixing them with the theme's background-inverse is sensible here.


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: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Standardise Colours used in XMPP clients

[Jonas Wielicki]

On Freitag, 24. März 2017 08:37:57 CET you wrote:
> > On 22 Mar 2017, at 18:53, Jonas Wielicki  wrote:
> > 
> > During the Chemnitzer Linux Tage, Georg, Daniel and I had some discussion
> > on the topic of how to generate "randomised" colours for use in XMPP
> > clients. Uses include but are not limited to: Nicknames (this is already
> > done by many clients, but inconsistently), Individual roster entries,
> > User accounts, MUCs and MIXes and so on. That idea alone isn’t new.
> > 
> > The idea is to standardise how those colours are generated accross
> > clients.
> > The advantage is that a user can quickly recognise all of their contacts,
> > no matter which device they’re on. The recognition of colours is way
> > faster than names. Combined with geometrical features like length of
> > name, it often, from my experience, is a sufficient identifier to be
> > unique even in crowded MUCs.
> > 
> > So we threw together our thoughts on that matter in a wiki article
> >  > >. Georg came up with using the
> > YCbCr colour space for sampling the colours, and we’re pretty happy with
> > the results so far. It’s trivial to adapt the lightness of the colours to
> > the environment.
> > 
> > We’d like to have input from other client developers. We think that this
> > is a good idea which can subtly improve user experience; implementations
> > which already have a "randomised" colouring can easily upgrade.
> > 
> > 
> > We would like to have input from other client developers, especially on
> > those things explicitly marked as "open for debate", but other
> > suggestions for an easy-to-implement colouring scheme are also welcome.
> > 
> > 
> > We might turn this into a ProtoXEP at some later point---although I’m
> > personally not sure this is XEP material.
> 
> Quite a complex problem you choose to solve there. Ideally you want a colour
> palette where the colours are as much different to the user as possible.
> Each user has a different impression on what colours are different and what
> look the same, 

Which is why we will uniformly sample a space of hues covering most hues. 
That’s as good as it can get, I think. (Of course, it’s possible that Georgs 
and mine colour perception is way off and everyone thinks that YCbCr BT.2020 
way better represents nearly equally light colours than YCbCr BT.601 does. In 
that case, everything may be lost, really. But I sure hope that’s not the 
case!)


> considering things like colour blindness or dyschromatopsia
> . 

Indeed, colour blindness is an issue. I have thought about that and came to 
the conclusion that it is not trivial to solve, due to the different types 
which exist.

What is theoretically possible is to exclude some part of the colour space to 
cater for red-green-blindness. I’m not sure if it makes sense to have this 
feature at all for the more severe (and rare, to my knowledge) types of 
disabilities(? Note: English is not my native language. Let me know if my 
choice of words is insulting or in any way inappropriate here!).

We had thought about specifying a "red-green-blind" profile of the algorithm, 
but we would like some input from people who know more about that type of 
disabilities before proposing anything.


> The more
> colours you have in your colour palette, the more likely you’ll have very
> similar colours, which some users can’t distinguish. Ideally you want as
> many different colours as you have members in the room, so they are most
> distinguishable. However, what happens if people join/leave. If you
> generate a whole new palette all occupant colours change, but you would
> want occupant colours to be stable. 

Right, we are after a 90% solution here. The idea is that with a mixing 
function like SHA-1, the colours hues will be uniformly distributed (unless 
someone attempts to collision-attack using nicknames). This makes it as good 
as it can get. Don’t forget that the colour isn’t the only geometrical feature 
of the nickname which is immediately and easily recognised. The rough shape of 
the name will also be recognisable, and will in most cases add the few bits of 
visual entropy needed to distinguish participants with, due to colour 
unavoidable collisions, similar or equal colours.


> Furthermore a sensible colour palette
> for nicknames depends on the colours of the chat theme. If the chat theme
> has a light green background it probably rules out some colours that would
> work fine in a white background chat theme.

Coloured backgrounds will be tricky. We suggest in the article that it might 
make sense to mix the generated colour with the inverse of the background to 
improve contrast in such cases. In many cases it will be sufficient to mix in 
some black or white to improve contrast between background and colour.


> An interesting site regarding colour palette 

Re: [Standards] Standardise Colours used in XMPP clients

[Tobias M]

> On 22 Mar 2017, at 18:53, Jonas Wielicki  wrote:
> 
> During the Chemnitzer Linux Tage, Georg, Daniel and I had some discussion on 
> the topic of how to generate "randomised" colours for use in XMPP clients. 
> Uses include but are not limited to: Nicknames (this is already done by many 
> clients, but inconsistently), Individual roster entries, User accounts, MUCs 
> and MIXes and so on. That idea alone isn’t new.
> 
> The idea is to standardise how those colours are generated accross clients. 
> The advantage is that a user can quickly recognise all of their contacts, no 
> matter which device they’re on. The recognition of colours is way faster than 
> names. Combined with geometrical features like length of name, it often, from 
> my experience, is a sufficient identifier to be unique even in crowded MUCs.
> 
> So we threw together our thoughts on that matter in a wiki article 
>  >. Georg came up with using the 
> YCbCr 
> colour space for sampling the colours, and we’re pretty happy with the 
> results 
> so far. It’s trivial to adapt the lightness of the colours to the environment.
> 
> We’d like to have input from other client developers. We think that this is a 
> good idea which can subtly improve user experience; implementations which 
> already have a "randomised" colouring can easily upgrade.
> 
> 
> We would like to have input from other client developers, especially on those 
> things explicitly marked as "open for debate", but other suggestions for an 
> easy-to-implement colouring scheme are also welcome.
> 
> 
> We might turn this into a ProtoXEP at some later point---although I’m 
> personally not sure this is XEP material.


Quite a complex problem you choose to solve there. Ideally you want a colour 
palette where the colours are as much different to the user as possible. Each 
user has a different impression on what colours are different and what look the 
same, considering things like colour blindness or dyschromatopsia 
. The more colours 
you have in your colour palette, the more likely you’ll have very similar 
colours, which some users can’t distinguish. 
Ideally you want as many different colours as you have members in the room, so 
they are most distinguishable. However, what happens if people join/leave. If 
you generate a whole new palette all occupant colours change, but you would 
want occupant colours to be stable.
Furthermore a sensible colour palette for nicknames depends on the colours of 
the chat theme. If the chat theme has a light green background it probably 
rules out some colours that would work fine in a white background chat theme.

An interesting site regarding colour palette generation, with scientific 
background, I’ve found a couple years ago is 
http://tools.medialab.sciences-po.fr/iwanthue/ 
 . Don’t know if you guys know 
about that.

Cheers,
Tobi

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

Re: [Standards] Standardise Colours used in XMPP clients

[Georg Lukas]

* Jonas Wielicki  [2017-03-22 18:54]:
> So we threw together our thoughts on that matter in a wiki article 
> . Georg came up with using the 
> YCbCr 
> colour space for sampling the colours, and we’re pretty happy with the 
> results 
> so far. It’s trivial to adapt the lightness of the colours to the environment.

Initially I was using the HSV space, but the generated colors have a
high degree of brightness variance, making some nicknames hard to read.
The higher complexity of YUV gives us a better way to generate colors of
equal brightness.

Generally I'm in favor of using widely-awailable algorithms instead of
creating something new, but I'm no color space expert.
Regarding the SHA1 discussion, my gut feeling is to go with CRC32 (as
used in ZIP), because most runtimes provide that already and it is
faster to calculate.

> We might turn this into a ProtoXEP at some later point---although I’m 
> personally not sure this is XEP material.

While this is not technically a protocol, it is an interoperation /
usability thing and I'd like to make it at least an informationan XEP.


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: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___