XSF Discussion - 2017-09-14

peter: Raja hi's you back. ;)

Can someone verify that we formally disbanded the Communiations Team and the Review Team?

dwd seems to think so - lacking any documentation, it'd be good to have a second person weighing in.

ah, I forgot that there was a discussion on a mailing list. I'll continue it there.

is there an archive of board meeting minutes aside from the mailing list?

the website has them, but not after 2015

ah, no

those are council votes and member vote meeting minutes

not board

jonasw: you might know: can we configure the mailing list daemon to have mailing list archives, without accepting new messages? Close the list down, without removing the archive?

Guus, yes

there are a few ways. one would be to remove all members, another would be to set all members to moderated and add a matching moderation/rejection message

that way the list formally continues to exist, anyone (who has permission) can read the archives, and if needed you can resume list operation at some ponit

downside: the moderation/rejection notice thing can turn into backscatter quickly, but if simply discarding all messages is ok, that’d work too

tx

all of this can be done via the webinterface

my two cents is that removing the supposedly inactive teams from the website after two rather experienced members mentioned that they have shut down is probably fine

if someone complains, git revert isn’t hard

but I would probably wait it out too, if I was in your position ;-)

jonasw: I'm modifying the PR as we type, and pointing to that PR in a mail reply.

people can weigh in on that, and if they don't, we'll eventually merge the PR

(but the PR doesn't take care of the MUC/Mailinglist entities, if they're there, so a bit more work might be needed)

done / mailed.

also, I'm out for now

bye

gl

now I’m wondering whether it’d make sense to have loosly defined groups of occupants in MUCs which can be addressed with @foo, like @iteam. possible implementation: people who want to belong to a group publish <member xmlns="...">iteam</member> in their presence. their client will highlight on @iteam. other clients can show that @iteam refers to a specific group of people.

jonasw: ITYM MIX.

whatever

this is entirely independent of the relay as long as it publishes presence

jonasw: I think that the idea has merit, but I'd rather use the affiliation mechanism for that.

meh, probably breaks horribly with MSN

but a JID can only have one affiliation, and affiliations also have influence on the permissions

Damn. We can't have nice things.

jonasw: [xep 317] is there.

(publishing this in presence has the advantage that things like CSI can act on that)

Sigh. Bots?! https://xmpp.org/extensions/xep-0317.html

ha

Is there an XEP to require bots to respond with a link to [xep FOO]?

that looks much like what I proposed

jonasw, Hats were intended as ad-hoc role based access control (sorta).

syntactically anyways

jonasw, You're after self-selecting groups, right?

yupp

jonasw, Self-selecting groups sound like an interesting concept.

(that XEP needs some wording on "MUC service supporting hats MUST NOT forward <hats/> payload in presences sent by clients"

)

dwd, thanks ☺

essentially it’d be publishing a list of words your client highlights on

jonasw, I think XEP-0317 might need killing with fire, if it weren't an amusing bit of XSF lore.

jonasw, Hmmm. Well. It's codifying a <reference/> system, that's for sure. Not so sure it'd be a simple text match, but maybe it would be in MUC.

mmm, using reference for that is appealing

jonasw, I would love that feature. I miss it at work, for example. But it is really useful I think.

jonasw, But anyway, it's a "publish a list in presence" thing, I think, if they're self-selecting, for MUC. For MIX, we could do something more formalised.

dwd, MIX could simply gather that from presence into a pubsub node

then clients don’t have to worry about things

hm, then again, you probably don’t want to have the list to be the same in all rooms

this would be a nice XEP to build on top of MUC, MIX and references.

jonasw, MIX occupants might not have any presence, though.

dwd, yes, and there are other issues with that, so MIX indeed needs a different mechanism for this

jonasw, Oh, and yeah, MIX presence is just broadcast presence, isn't it?

dwd: while we are on reference systems, were you able to get a grip on the reactions mechanism author?

Good morning!

exactly

tux, good morning and congrats :)

Ge0rG, Sort of. Doesn't work as cleverly as I'd thought.

jonasw: thanks :)

Ge0rG, But also our internal document describing it is 0 bytes. :-)

I tried to find out what "SCAM" means in the XSF context, but could not really find anything. (Mostly a resources page on the XMPP wiki; Google is not really helpful here.) Could anybody please enlighten me? Or the newbies via members list? Am I just blind to the relevant paragraph/link?

tux, Summits Conferences And Meet-ups.

tux, it is Summits, Conferences And Meetups team

I think there are two important issues with hats/notify-strings/whatever in presence: 1. it helps a MUC service / user's server to determine "important" messages and to push them to CSI-inactive / Push enabled clients. 2. this is another data leak in E2EE scenarios

Ah, thanks :D

tux, Outreach work team, basically.

tux: https://wiki.xmpp.org/web/XSF_Summits_Conferences_And_Meetups_workgroup

Ge0rG, don’t do it with E2EE unless you can encrypt whole stanzas *shrug*

jonasw: you know my position on E2EE :P

:)

I indeed do

That page even mentions "SCAM", but Wiki search for SCAM only returns this page: https://wiki.xmpp.org/web/SCAM/Material

so, "jonasw> Ge0rG, don’t do it with E2EE" - full stop.

Ge0rG, E2EE in MUC contexts is not my department

tux: there is also a wiki category "SCAM". Somebody should add a descriptive text to it.

Ge0rG: if its fine with you I'd just add the link for now

Ge0rG, Thanks for volunteering, Somebody.

(link to scam team page)

Ge0rG, can you rename and redirect the "XSF_Summits_Conferences_And_Meetups_workgroup" page to "Summits, Conferences And Meetups (SCAM) workgroup" or something?

then it’d turn up in the search more reliably

(I heard you have wiki powers)

dwd: I was trying to motivate our new member, actually

Also, it's a "Work Team", which has a formal meaning within our bylaws.

Ge0rG, ah, then while renaming fix it to Work Team too :)

We should probably create a parallel "Special Interest Group", too, in order to have an open group without executive powers.

dwd: we should watch out that we don't end up with more groups than we have active members.

I've just done this for now: https://wiki.xmpp.org/web/SCAM/

tux, good start, but trailing slashes are uncommon in wiki URLs

also, try a #REDIRECT instead (<https://www.mediawiki.org/wiki/Help:Redirects>)

(Why does the wiki engine not remove the trailing slash from the URI? -.-)

tux: because you added one?

/es are kind of funny in mediawiki

/ is just another character to mediawiki

it doesn’t care

while it cares way too much about capitalisation

I see.

Okay ,I should have moved the SCAM/ page instead of creating another one

the SCAM redirect is done, but I cannot get rid of SCAM/

you might need Ge0rGs superpowers to remove SCAM/

yes, &action=delete gives a permissions error

Ge0rG: can you please remove SCAM/ ?

tux: done as requested

Ge0rG: thanks :)

would it be possible to add https://wiki.xmpp.org/web/T-DOSE_2017 to SCAM ?

edhelas: at your service

Guus, you just got a mail from Jean-Paul Saman to know what is the status

if there is people that lives in Belgium, NL or Europe in general and are interested about a nice little event in Eindhoven in November please have a look at the T-DOSE 2017 page on the wiki :)

Guus, regarding the logo, if you check this: https://xmpp.org/images/promo/xmpp_server_guide_2017.pdf it looks OK there. Are there two versions of the logo or the author of that PDF updated the logo himself?

SouL: unsure

I was sure that I saw the logo like you say on Github, but didn't want to say anything until I could find a proof

SouL: I'm traveling. Please comment in github

hi, I'm working on my PR for pubsub#multi-items in the 0060

what do you think of "The service supports the storage of multiple items per node and requires the pubsub#max_items configuration item to be exposed to the user, and allow sensible values."

edhelas: I don't see how max_items can indicate that there is no maximum (unlimited items)

I think it's missing

should we add that feature as well ?

what about setting it to zero ?

it it's made mandatory with multi-items, it should be there for sure

also max_items use underscore (_) while multi-items uses dash (-), should be made coherent

hum it's max_items which is not coherent with others, too late to change probably

max_items is not even in https://xmpp.org/extensions/xep-0060.html#features with others :(

should I add it ?

I'll add it

edhelas: max_items is not enough by the way ? If I have max_items > 1 I have multi-items right?

I guess you should yes

it will be reviewed by council anyway

yes but it's a feature exposure

if you have max-items exposed, I don't know if you can support more than 1

multi-items ensure that

edhelas: if max-items = 10 we know that we can support 10, and we should have a value for unlimited

or basically we change max-items and we say that it should be here if the server doesn't support more than one

looks like redundant to me, but I may be missing something

goffi, what if the node is not even configured, or not existant ?

how can I know if the service can handle more than one ?

edhelas: oh you want this to be exposed by the service, not the node, OK

max_items don't make sense for a service indeed

or maybe it does, not sure actually

ralphm, here ?

goffi, afaik, max-items is not a feature exposed by the service, but just a configuration variable

that's why it's max_items and not max-items

multi-items actually tell that info to the user and force max_items to be set above 1

edhelas: but we need to know how many items, if it's multi-items but with 2 items max, it's not useful for e.g. a blog

this is something different, I'm talking about the service features again here

that doesn't change the point

Guus, your logo thing is a cannot unsee

what you are requestion is exposing max_items to the node metadata, like the title or the number of subscribers

*requesting

goffi, I'll add that in the metadata

edhelas: it's also a service thing, if I create a new node, I need to know if I can store more that 5 items for instance

this all "authorisation" thing is quite buggy in the 0060

"if I create a new node" => there's no way to know if you are even allowed to create a new node, or publish in it

0060 is based on a "fail to try" pattern

this would require to expose the access model

I don't see harm in that

https://github.com/xsf/xeps/pull/500/files

edhelas: it's missing a way to indicate "no limit"

goffi, https://github.com/xsf/xeps/pull/500#issuecomment-329440142

edhelas: OK good

jonasw: welcome in my world of cannot unsee.

“16:08:43 SamWhited> Because we have a lot of different clients and servers and enough interoperability problems without denying every element that has some clients proprietary extension in it.”, funny you say that, I’ve found a bunch of bugs in various implementations by doing exactly that. ^^

Not that I would use it in release mode, but for debug it’s a fantastic tool.

Link Mauve: what are you talking about? Looks interesting (I have not message from SamWhited in my logs, but I may be missing a part)

goffi: http://logs.xmpp.org/xsf/2017-09-12/#15:05:02

goffi, it was about making a strict XMPP parser, which checks that no foreign element or attribute is set on known elements.

https://hg.linkmauve.fr/xmpp-parsers

I already found many issues in many different implementations, both clients and servers.

Astro

the world’s small

Link Mauve, do you do your DNS yourself?

jonasw, no, I use the domain crate.

I see, anyways, I PM’d you with some issues I found, you may want to raise them with your provider

Also, xmpp-parsers itself doesn’t handle any connection, it only parses XML into Rust structures.

ahhhh

different thing

I was talking about DNS for linkmauve.fr

Oh, then yes I do. ^^

The author of https://www.bleepingcomputer.com/news/security/this-spam-service-will-charge-25-to-stop-spamming-you/ seems to be very interested in XMPP <https://www.bleepingcomputer.com/author/catalin-cimpanu/> I wonder if we should contact him and involve him a bit in SPAM.

Fixed, I forgot to bump my SOA, so my secondary didn’t receive the newer revision.

Ge0rG, sounds like a very great idea! Nice to read this also "the easiest way to reach Catalin is via his XMPP/Jabber address at campuscodi@xmpp.is."

SouL: yeah, I was positively impressed.

Iam making a protocol for time series data. I am seeking feedback to see if I should make an XEP of it. It is available at http://opensource.clayster.com/lwtsd/Communications/lwtsd/

Ge0rG, yes we should

will you do it?

(it is work under progress)

or in progress :-)

stefandxm, The best way to seek such feedback is to submit it to the XSF as a protoXEP.

dwd, yeah. but its quite a lot of work to rewrite it to xep format so I'd like some comments before committing to that

stefandxm: I note you added an element starting with xml (xmlschema), which is generally reserved for the XML spec itself (see XML 1.0 §3)

ty. ill fix that

Marv!

iam also struggling with my xml schema expertise in specifying "type" information. i tried to use xs:facet as xsd itself is doing but i couldnt get it through the parser

stefandxm, ugh, your server (opensource.clayster.com) doesn’t support HTTPS. :/

but the parser seems broken in mono so it might be valid

link mauve, i know.

jonasw: I will after reading all his articles

stefandxm, I’m having a hard time to figure out what the specifciation does and how it works in the end. A few examples would be useful

jonasw, did you check the graphs in http://opensource.clayster.com/lwtsd/Communications/lwtsd/#operations-overview ?

yes, but those don’t show me why you’d use that specification for what

but yes, examples are coming

and what those resources are etc.

they are abstract so it may be that ;-)

possibly :)

examples would be great

yeah. coming

Work in progress, thanks for sharing this early!

also, in the protocol definition it doesnt make sense to "sell in" the protocol itself. but its a bit tough to read from scratch i know that

in the commercial side we make tutorials and stuff for the protocols but it doesnt make sense to add to the protocol itself

generally it sounds like something I could use myself, but I’m having a hard time to get a quick grasp on what it does

but xml examples is coming

its a generic data manipulation for time series data ie data that has a originated time. like sensor data

it has operations for write and read and subscriptions

the subscriptions work with triggers (and filters to be in another namespace). but it doesnt push the data it only informs new data is available

then the consumer needs to re-subscribe within a read to get new notifications

in general, it may be sensible to look at RSM (<https://xmpp.org/extensions/xep-0059.html>), maybe you can re-use some syntax from there

i dont see how i can apply it in a generic sense

i want to support paginating in both total data set and within resource data set

since each resource may include n points

That's where RSM is generally useful, provided you have stable ids for every data point within a set.

it wont

you may also consider the data as being volatile

Then how will you do pagination?

by seeking and time frames

Time range?

stefandxm, if you treat the exact timestamp as ID, you have what you need for RSM, afaict

but there may be many points on exact same timestamp

^ what jonasw said

Not inherently ordered then?

so the source will have to store them as unique. which is not impossible but then you get modification/upsert hell

(within the same timestamp)

so the id will most likely not be an id in real life scenario

for me an id should be an id and not a seek index

so for say a schema where the schema has not changed the id solution makes sense to me

but not for the data points were ids are not required

Fair enough, which is also why MAM has separate start / end timestamps to be used in conjection with RSM

conjunction

the "volatileness" of the data in the data source makes it imo impossible to make seeking/pagination 100% without overhead. but in an application that can be addressed

but ive never seen a generic approach that works for all applications

unless you want to remove the "volatileness". which is often doable but not always (demands a lot more resources/memory in the data source)

btw. this is a moving forward from our side to replace the retracted xeps by peter waher named sensor data, control and the numberless iot events

and make it more generic and suitable for applications not using "iot"

the biggest challenge i see with this protocol is making the schema for resources easy to be implement but still extendable. thats why there is a simplified schema and a xmlschema (the element i will rename)

If i'm not mistaken the major concern with peter's IoT XEPs was them not being very XMPP idiomatic

personally i have many concerns with them

but since they are history its no point to argue about them imo

course, that's more a thing of preventing history repeating itself

stefandxm: what is a "schema for resources"?

yeah and thats why we are not sure if going via xsf is the perfect fit. but as long as we try to do it generic and xmpp-ish iam willing to give it a try :)

flow, describing data types and capabilities

ie if a resource is an int or a string and if you can read it, write to it and what filters it supports to reduce noise in subscriptions

I don't see the challenge exchanging data without prior knowledge about the structure, amount and type of the data

And I assume by "capabilities" you mean something like "remote control"? If so, that's also mostly solved by ad-hoc commands I'd guess

nah, just the stuff i wrote above really

but they may be done by writes with user specified types

for me data schematics is always a challenge :-)

but imo i managed to get it rather neat. but i am not sure everyone will agree hehe

ok. i believe i updated the xml* thing with new names (now extended schema)

are there security concerns with loading up unknown/untrusted schemas that you get sent?

I don't really know anything about it, but I'm wondering if you could maliciously replace some XMPP schemas or something

jonasw: "Consistent Color Generation" --> "Consistent Nickname Color Generation"

or "User"

Ge0rG, there are other use cases for that, such as roster groups

jonasw: as it is, the name lacks context.

Ge0rG, comment on that on-list, so I don’t forget when I prepare an update

jonasw: I think that having a too-specific qualifier beats no qualifier.

I saw it as more generic, like you said, roster entries, bookmarks, etc

but yea name doesn't matter

moparisthebest: names DO matter.

xep names don't matter that much to me

moparisthebest: they matter to client devs

just curious now, why?

moparisthebest: it is already hard enough to find relevant XEPs

mop: there are concerns with dtd schemas

mop, so they are defaultly prohibited by most parsers

stefandxm, are those the type of schemas you are talking about sending or not?

these are not

these are XML Schemas (xsd)

but if you chose to follow dtds then you may have problems

what if I send a schema for, uh, MAM or something but that I maliciously changed, would that overwrite the correct MAM schema?

i guess that should be a topic yes

how to properly localize the namespace to the session

and that might even be specific to XML libraries or whatever

or rather just not allow it to replace any existing schemas known to the client

and only use them for the session

just might need to be considered

yes

very good suggestion

i shall fix

I guess the only danger is if there is not a safe way to do this with any library or XML in general, then the design is inherently insecure and you can't be sending schemas around

I would think there is a safe way but I just don't know at all

there is secure ways

tbh i never considered someone would do it an non-secure way

but i think it should be clarified

in any way this is a more secure way than following URIs

as long as the xmpp server is secured

and you only use the schema in the entity to entity session

jonasw, you know about http://tools.medialab.sciences-po.fr/iwanthue/ ?

Tobias, you linked that, yes

ah..k :)

Yay, it looks like the psi and psi+ devs got resurrected and released a new version last month!

moparisthebest: ive added a note on it now

Excellent :)

problem with xml schemas are basically the same as the xml itself. its vulnerable to parse it and its vulnerable not to use it hehe

another thing along these lines; ive been thinking about the maxOccours in the schemas

it would make sense to add a sensible max rather than having unbounded

esp in the requests

this way its possible for the server to protect the receiver. but it also would mean that basically the clients should tell the server what namespaces they want to filter

today for instance ejabberd has a max stanza size but its impractical to have it statically defined

having it defined on say namespace level and client would be a solution

or namespace, entity (jid) and namespace

jonasw, That's weird. I was talking about the existence of this algorithm about an hour and a half before you submitted that.

the coloring algorithm?

It was discussed in here several times over the last months

Yes, I know.

I was demonstrating the difference between Gajim and another XMPP client, and Gajim colourizes - I mentioned there was this algorithm knocking about as well.

I hope that the proto-XEP will ignite discussion. Hope dies last.

I think that jonasw is aiming at a Ph.D. in sensible XMPP client design.

iam missing the [] Compensate for f.lux on the site

stefandxm, compensating for flux/redshift is definitely out of scope ;-)

(a) that’s time dependent and (b) tricky

I think that f.lux compensation should be done display-wide, not in an XMPP client.

dwd, ha, so I can count on your +1 ;)

Unless there is an XMPP client that can go back into 1955.

am i the only one finding it confusing to talk about IM UIs as "xmpp clients"? :)

stefandxm: those are different things!

Jabber client is the right term, of course.

i remember the discussion from the summit this spring. i still find it confusing to have a protocol organ for a message bus discussing/voting on UI matters

re-instate the JSF to discuss IM-specific matters for maximum confusion!!!k

and i cannot see how the expertise can be shared between systems protocols and ui design

so far ivent met a single proffesional ui designer than can do system protocols and vice versa

stefandxm: which is a very pointed explanations of why all Jabber clients suck.

i think the clients can be good but not all uis

adium has a great ui but sucky xmpp client

stefandxm: I'm not a professional UI designer, but I know a little bit about UX and I am pondering about jabber client design a great deal of time

jonasw: "Jabber Software Alliance" or "Business Jabber Alliance" or some such.

swift im has a horrid ui but a great xmpp client

stefandxm: now you made me curious, what's wrong with swift?

it only supports one account and its ugly :)

Incorrect and subjective.

incorrect in what way?

It supports multiple accounts

oh?

Hidden away tho

how?

haha speaking of uis

Command line flag iirc

stefandxm: I think that "ugly" is highly subjective and only a very small influence on the UX

it doesnt have a "help" either

I’m confident that JabberCat will be awesome ;-)

georg, an ui that doesnt follow the native look will always be ugly in my book

+1 stefandxm

stefandxm: web is the new native.

stefandxm: no --help ? whats this then https://q.zash.se/f445feffd14b.txt

zash was talking about the ui

Ge0rG, noooo

stefandxm: I think the goal is to be simple enough to not need a built in help

my point is: the look of widgets is secondary to proper usability.

Number of accounts to open windows for (unsupported)

multiple windows?

not a shared contact list?

Ge0rG, the look yes, but the feel not

jonasw: true.

But I'd rather have a Qt-based client on windows that doesn't drop messages than a native one that can't fulfil basic IM expectations

Qt is close to native on any platform

closer than any web client at least

jonasw: Always close, but always feeling slightly off

Zash, but over the uncanny valley, I thnik

As someone who grew up with GTK+, all Qt apps look off to me

on linux iam ok with Qt looking app. on osx its horrid

stefandxm: I also think that multi-account support is a power user feature only needed by 1% of Zimpies.

georg, i dont think tahts true :)

stefandxm: but having support for multiple accounts makes the UI much more complex

if you really need it you can always use a xmpp->xmpp transport right? :)

i dont know anyone that has only one im account

Ge0rG, multi-account is tricky, but I think I found a reasonable UX solution for jabbercat

Ge0rG, sure. but adium does it neatly

stefandxm, I know a lot, all my non-nerd friends

jonasw, they dont have google etc?

What? I feel I'm a normie now, with just one XMPP account.

stefandxm, google doesn’t have any usable XMPP anymore

i run google hangout, work jid, private jid and icq through one im client

jonasw, yes they do

All my gmail contacts appear as offline

not mine

i use it daily

How? Is still usable on the gmail page?

SouL: gmail f***ed xmpp.

SouL, yes and with hangout app (included in android)

stefandxm: you are the power user.

Whaat? That's new to me.

its been like this since ever

Your contacts had to do something, or what, stefandxm?

they never removed xmpp support

SouL, don’t let yourself be fooled, gmail federation is broken-ish

SouL, no

federation is not working no

I need a gmail-xmpp using volunteer please, for testing https://github.com/pfleidi/yaxim/issues/201

but its still xmpp and works great for chatting

I may have a multilple accounts, but I only use one, the rest are for testing and stuff.

Most of my friends only have one too.

Ah man, there's no federation... Then there's nothing new :)

Ge0rG, you may add me if you want. stefan@skogome.net

stefandxm: is that gmail-hosted?

yes

stefandxm: thanks, give me a minute to boot my other android.

but you need to be friends

so its traditional xmpp

stefandxm: I don't have a mac unfortunately, so I can't check adium.

pidgin also works

i run pidgin on linux for same reasons as i run adium on mac

but pidgin!

pidgin is great ui. but sucky xmpp client =)

all xmpp clients suck. Especially the Jabber ones.

Which one(s) suck less?

mutt. Oh, wait.

i havent been able to start swift im on linux

dependency hell

Ge0rG, mutt with that french xmpp<->imap gateway?

(and it didnt compile)

jonasw: I don't even want to imagine _that_.

:D

Ge0rG, heard of deltachat?

.oO(deltachat in front of imap<->xmpp gateway :-O)

stefandxm: https://github.com/swift/swift/blob/master/BuildTools/InstallSwiftDependencies.sh

IMAP is pretty cool, why else would they be trying to kill and replace it with some JSON garbage?

... works for me.

for extra fun

Holger, i dont use any of those distros

so would give Unsupported system if i tried

or wait, it had a || there

I always find it odd when people who use interesting exotic distributions complain about difficulties building and installing software :)

it might work now then

but last time it didnt

jonasw, why?

wait there is an imap/xmpp gateway?

jonasw, i think the more you know about linux the more problem you will have with dependencies

I must know nothing then.

stefandxm, just curious, which distro?

linux mint kde on this one

quite horrible tbh

that's just ubuntu with some extra repos pretty sure?

but i gave up on debian experimental after the third broken upgrade in a year >D

moparisthebest, true and not true

oh, actualy, Holger 's script has a LinuxMint entry, same as Ubuntu

i know

i commentented on it above :)

but linux mint versions are not interchangeable

same as with debian of course

Isn't the purpose of Debian experimental to be horribly broken?

+1

sure is

but only way to get updated packages

yea, I used Kubuntu for about 10 years but 16.04 broke everything so bad I switched to Arch and have been rather happy with that for a year

breaks less than debian unstable from what I gather, but still newest everything

tux, me too.. for a long while =)

there are three flavors of debian: rusty, stale and broken.

Did you consider KDE Neon, moparisthebest?

by the way: I just verified that a current PSI+ can be built with Debian Stable. I'll do a backport pacakge in the near future.

tux, you’re a debian developer?

SouL, ah KDE neon, I tried it and it was still a bit too broken, and that was before they discovered they didn't enable PGP package signing and also left their package repo open for anyone to upload files to... :)

SouL, that would be https://www.kde.org/info/security/advisory-20161114-1.txt

jonasw: nope, never really got around to do that, but I know how to build debian packages

moparisthebest, I downloaded it two months ago and it is what I'm using, since I was using Kubuntu too, before.

did they start signing packages with PGP yet?

otherwise I'd stay far away just for security reasons

glad it works well now though, I tried around July 2016

Gmail is weird. it reflects my own presence to me.

Isn't that standard behavior?

Holger: I mean the presence of my own full JID, not of my other sessions

Ge0rG: "The user's server MUST also send the presence stanza to all of the user's available resources (including the resource that generated the presence notification in the first place)."

Or am I missing something?

Holger: whoops. Then it's just the first time I notice this. Thanks for clarifying

hey SCAM team members, we have a booth at the POSS, Paris Open Source Summit

http://www.opensourcesummit.paris/

the stand will be on V29

Guus, Daniel...

europeans, join!

Interesting, this afternoon I thought about how nowadays one must also take the hash colour into account when creating a nick name, then I thought about how to ensure that every colouring scheme is identical and now there is this: https://xmpp.org/extensions/inbox/colors.html

Though I have mixed feelings about the color inversion - maybe have to try this out on a demonstrator.

Or maybe the luminosity (Y) should be adapted instead.

Is it customary to reply to the XMPP extension proposals?

tux, sure, feel free

adapting luminosity would be more a heuristic, mixing with the inverse does work, I have sapmles

ack

(esp. adapting Y doesn’t work for coloured backgrounds)

I just felt more natural to do these conversions in the YCbCr colour space

that’s quite tricky I’m afraid

because YCbCr is not additive

RGB is, which is why the inversion-and-mixing thing works

true

jonasw: in 5.4 the formulas don't give values for KR and KB

tux, no mixing: https://sotecware.net/files/persistent/colors-xep/unmixed-bg.svg mixing: https://sotecware.net/files/persistent/colors-xep/mixed-bg.svg

i am curious when this is wanted at all?

does people want nick name colorization in chats?

stefandxm, yes, they do

and also for avatars its great

Are there any algorithms for identifying words with similar 'shape'?

wont it just be a huge christmas tree?

jonasw: I see, thanks for the sample :)

i remember i tried it on irc back in the days and it was dreadful

Zash, I doubt it

stefandxm, the xep also specifies that there MUST be a switch to turn it off, so...

stefandxm, well persistence and standardization would help, all my clients color nicks, but differently across clients and even in the same chat, sometimes

tux, you can mention the missing constants on-list

stefandxm: Setting a good luminosity is key.

they’re easy to find anywhere on the internet though

jonasw: ack

stefandxm: looks fine to me: https://www.zash.se/upload/28QwkNpsRR5s.png

thats horrible to me :)

maybe, but in a "we want to ensure everybody does the same thing" specification they should be mentioned.

because when you apply highlights and notifications they get drowned our have to be even more shouty (as in your example)

so yesterday, to avoid highlighting them needlessly I'll change the name, gajim set both Buus and Be0rG to the same color and on glance I was confusing them

moparisthebest, with XEP-XXXX, you can at least be sure that it will always happen, if it happens ;)

doesn’t happen though, they have very different xorred crc32 values

jonasw, that might be interesting, have sample color lists for say, this muc?

or maybe #archlinux on freenode, some concrete real-life examples

moparisthebest, can do

may do soon

I have it implemented for avatar surrogates in my client, but I obviously can’t easily show you a screenshot of my roster ...

We really need some easy-to-setup test account with fake roster entries and fake presence.

The discussion on whether there should be nick coloring is not really relevant, though. The thing is happening and the best reaction is IMHO to give it a good direction early on. (As with the proposed XEP.)

also I'm a little colorblind so I hesitate to comment on actual colors, but I'll be able to tell if they look different enough for me, and others can look as well

The decision is only if there should be a common scheme or if things just go wild.

well, things are going wild right now

moparisthebest, uuuuh

this optionally adds a common scheme :)

if you’d be willing to see how well the color blind profiles work, let me know ✏

until now I only have one sample (with a red/green blind person)

sure jonasw , I'm not sure what I have is exactly called, but I see like, certain browns as army green, not positive

that could be a light red/green defiency

we should talk later, I’ll be off for half an our or something

yep, I looked up the exact word one day but have forgotten :)

back

moparisthebest, https://sotecware.net/files/noindex/users.svg

moparisthebest, refreshed with three color columns, which are: plain, red/green-blindness corrected, blue-blindness corrected

I'm blue/purple-ish!

jonasw, how many colors is this?

jonasw: I don't get that thing...

jonasw, why do you care for color-blindness? It's just to quickly identify people right? you don't care if color-blind people don't see the same color as others?

It's not like people were going to compare colors

Or am I missing something?

Colour rotating nickname sets, that will be a thing.

intosi: 👍

pep., the issue is that the deficiencies affect different ranges of the color space differently, so we can do better by avoiding those ranges

pep., I don’t understand the question "how many colors"

it’s as many colors as there are names

up to 2^16 (due to folding crc32 into an unsigned 16 bit integer)

ok

mimi89999, what’s your question?

jonasw: What is that svg about?

mimi89999, it shows the colors the ProtoXEP which was announced on standards@ generates for the nicknames in this room

in three variants, from left to right: "normal", "corrected for red/green-deficiency", "corrected for blue-deficiency"

Ge0rG, I agree. I already thought about how to set that up. maybe some prosody docker image with pre-configured accounts

I have a testbed, but it’s rather small, not large enough to effectively test the coloring things

How about scraping sth like Twitter for a nickname set?

Aren't there libraries like faker for python? For stuff like that

jonasw, thanks so, those columns, and again, I don't know if I'm seeing what you are seeing

SouL, you still need to set up accounts etc.

the middle column, is mostly pink/orange

and add clients

jonasw, you, kev, la|r|ma have *identical* orange colors, in the middle column

is that what you see or no

yes, that’s in all columns the case

oh, right

doesn’t matter that much really

the middle seems the worst to me though, almost everyone is pink

moparisthebest, interesting, and possibly bad

is that what you see or not? :)

yes-ish

there are some oranges in there

it's subtely different shades of pink, but, mostly pink

moparisthebest, reload

maybe better, I was going to say all shades of green, but that's mostly at top

no actually I think that is far better

I think too

again just for my eyes might be worse for everyone else who knows

no, I think that makes sense

in case of doubt is green easier on the eyes compared to pink

simply because one is evolutionary more used to green tones and we can distinguish more shades of green

above my head, seems to make sense though

out of those 3 profiles I prefer middle for sure, I preferred left before

moparisthebest, prefer it visually, or from being able to distinguish colors?

seems more distinguishable yes

moparisthebest, great :-)

\o/

the left has a bunch of 2 or 3 in a row of almost identical shades

can you reload once more?

more blue-ish than green-ish ?

maybe, not sure

anyways, thanks for your input

Bunneh, and next two, I hate highlighting random people

the green sticks out more there, to me

more than the shades on the left?

no not in that case

it does seem to have groups of the same color in a row, like groups of 2 and sometimes 3

for alphabetical names that's bad, not sure if there is a solution though

moparisthebest, I thnik that may be a property of CRC32 :/

jonasw, what if you used something else, md5, Adler-32, Fletcher-32 ?

adler32 is worse on those short inputs

(tried it)

18:43:19 jonasw> crytographic hash functinos are generally a bit better 18:44:36 jonasw> but people complain that those are hard to implement / have high overhead 18:44:50 jonasw> and even in those cases there are still close nicknames which aren’t ideal

ahh, salting the CRC32 with 256 bits does something good

moparisthebest, care to reload?

I'm not sure md5 is hard or has high overhead :/

yea hang on

I think that's worse, look at tu-x and next 3

next 2 I mean, also it still has the every few being the same

That graph says otherwise ;)

moparisthebest, I don’t think that’s a bad thing in that special case. they differ by their first letter, so your brain generally can distinguish them well

moparisthebest, re performance: https://sotecware.net/images/dont-puush-me/9n701UwrIuU2NFuTexy7rFpu3Auf7zbQlVsEyFTVqAM.png

so md5/sha1 are an order of magnitude slower than CRC32 on those input sizes

are we talking about the difference in 0.01s and 0.02s for all participants in a typically sized muc ?

because, who cares

moparisthebest, first, implementations may not always be able to cache the colors (daniel brought that up)

I think it might even be less than that?

it’s a factor of three in that region

lowering slowly to 2.5 at the right edge of the reasonable range for nicknames and such

3 times slower than a millionth of a second?

Link Mauve, you here?

Well maybe we should try md5. If it looks better we might want to live with it

daniel, it does, but salting CRC32 with 64 bytes does the trick

and is still fast

unless I'm reading the graph wrong, 3/1,000,000s is technically 3x slower than 1/1,000,000s, but still well within the no one cares range

moparisthebest, reload for md5-based colors

I don’t think it does a lot of good

hmm disappointing I agree it's basically the same issue

sha1 doesn't do better either?

is it not fixable based on low bytecount or can we just throw algorithms at it until one sticks :)

moparisthebest, I think it’s not fixable due to the low amount of colours we can distinguish

but indeed, we need to specify a salt input for CRC32, that improves things massively

jonasw: is there a reason you're using crc instead of sha?

Ah, nvw. Just read your answer to the question.

Though I think that the processing time is not relevant here.

tux: I don't think processing speed matters either here but md5 also wasn't any better so :(

Guus, now I am.