XSF Discussion - 2020-06-12

How long do you guys think it's gonna take for matrix to completely replace xmpp? Just wondering

Lol

queen_tilfaar‎ this is not even asymptotically to eternity

Hey guys. To dup myself from the ejabberd room. Do I understand correctly it's impossible to use emoji in the MUC nickname?

It's forbidden, but not always impossible.

I would some 🍺 there :-D

And the wrong combination of things slip through, you can cause s2s drops.

My recommendation is to preemptively assume fetal position under your desk and cry for a while.

Zash: so you are disagree with last comments from there https://github.com/processone/ejabberd/issues/1896

I can look in a bit. We should also do a writeup of what Prosody (trunk) does

What is the final date when MUC will be deprecated in favor of MIX where I believe 🍺 is allowed? =)

rion: xmpp:ejabberd@conference.process-one.net?join

Wasnt there a website for that?

rion, check what https://tools.ietf.org/html/rfc8266 says about this

rion: XEP-0045 is good for a lot of years!

When someone makes a MUC→MIX bridge, that's when all our problems go away. :)

rfc8266 doesn't mention beer :-/

Well from very quick look at rfc8266, emoji do no look something forbidden.

I imagine you also have to look at https://tools.ietf.org/html/rfc8264#section-4.3

ah this hidden section..

Kev, the newsletter says about Smack: "Among additional support for more than a dozen new XEPs, the new release will contain a new architecture for modular transports, as well as a modified API that applies the builder pattern to stanza types.", is the term "modular transports" from Smack and if so can you explain a bit to help me (us) translate

Zash: well ok. Doesn't really mater in fact. I just added KDE emoticons support in Psi and now have all the EmojiOne here. It was just interesting how I can apply it :)

pep., was that a question for me?

Ah sorry

Smack, Smacks..

Wait smacks is something else?

mod_smacks.

well there is mod_smacks

Anyway, confused..

and of course the linux kernel's Simplified Mandatory Access Control Kernel (SMACK)

flow, so any hint for us translators? :p

What does that mean

pep., in the past, when someone added support for a new xmpp transport to smack, what he/she usually did was "cp XMPPTCPConnection.java XMPPBOSHConnection.java"

but that copied a lot of transport agnostic functionality to, and hence duplicated code

with the modular architecutre, you can plug in transport implementations into the same ModularXmppConnection, like rfc6120 TCP, BOSH, WebSocket, etc.h ✏

pep., does that help?

Ok so you've "just" made the transport code a bit more modular :p

"just", hehe, I think it is one of the most fundamental reworks of smack's core in the last two decades

(Not diminishing the work, just trying to understand)

Ok

sure ;)

sm-acks (acking of stream management) vs smack (the xmpp lib) ?

rion, simply put, emojis are not allowed in localparts. FYI, there is a test corpus with valid and invalid JIDs in jxmpp, e.g. https://github.com/igniterealtime/jxmpp/blob/master/jxmpp-strings-testframework/src/main/resources/xmpp-strings/jids/invalid/main#L46

flow, thanks yeah that helps

flow: well that's ok. I'm interested in the resourcepart

rion, ahh, MUC nicks, correct?

yep

rion, do you have an unicode code point for me?

I tried this 🍺

not sure about numbers

U+1F37A

rion, is valid in resourceparts

so it's just ejabberd

This codepoint was assigned with unicode 6.0 in 2010, so ten years ago. So if you talk to an implementation from 2009, it may rightly reject the address

jabber.ru has ejabberd 2.3 iirc.

hmm, wasn't there something special about xep45 nicks

<nick> in muc is "discouraged" according to XEP

fyi https://github.com/processone/ejabberd/issues/1896

I believe cromain is wrong saying that "emoji class is not accepted for resource", The Unicode So category, where most emojis are reside, is, as far as I can tell, allowed in resourceparts

but please follow the traces in the XEP yourself: rfc7622 resourcepart is OpaqueString profile of PRECIS FreeformClass → rfc7564 § 4.3.1

Ge0rG, MattJ, Kev, please check your inboxes re message routing sprint

jonas’: thank you very much.

I don’t expect this to work out, and if it doesn’t, I’ll try to reschedule with more time ahead and with more potential timeslot input from the participants.

I'm also very sorry for not giving feedback in a timely fashion.

with my current scheduling background it might be better to do this whole thing on-list, though.

ejabberd doesn't support 7622 BTW, just 6122's Resourceprep. (No idea whether that should already allow emojis.)

Which combo of stringmangling RFCs was 6211?

Prosody is also on some older variant

6211? Cryptographic Message Syntax?

m/rfc6[12]{3}/

I don’t know that command

Zash: RFC 3454 + Appendix B in RFC 6122, I believe.

But I'm trying hard *not* to look into this right now :-)

Friday clock-out-o-clock is not the time for that, indeed.

Neustradamus, Please stop constantly asking me to test your memberbot PR for you. I have already explained I'm very busy and will not do it. You need to test it yourself, and clearly describe the benefits, or drop the issue.

dwd: Please read the comment.

Neustradamus, Yeah, it tells me I have to test it. But firstly, I don't have to, and secondly, you tell me you haven't, and it's your code.

this sounds like a bug in Psi, fwiw.

Shell, Possibly; but the memberbot now accepts "yes" and "no" case-insensitively in all responses, so it's irrelevant, I think.

If someone can confirm my solution, it will be nice, I would like a merging before next voting period... It will be nice to have before Gajim integration: https://dev.gajim.org/gajim/gajim/-/issues/9768 (cc lovetox).

But "Yes" or "No" both work in the current master of memberbot.

Neustradamus : dwd is thinking that your change is no longer needed, as someone else already made a similar change.

Well, the change doesn't do what it says it does.

It claims to be influencing what the bot is asking clients to send, and it doesn't, it's only the display label that's being changed, unless I'm incredibly dense.

So the right thing to do seems to be to close the PR, to me.

From what I read in the Github comments, others came to the same conclusion.

Guus: No, it is not completely solved, the other PR adds support of Yes/No, but the problem is that the HTML code is not correct.

Neustradamus, You're suggesting that the spaces *outside* an anchor make a difference to how Psi interprets the encoded URL parameters, is that correct?

rion: ^

rion: https://github.com/xsf/memberbot/pull/4 ✏

but why

Neustradamus: I'm sorry. From your PR descriptions it's never possible to understand what it's about. Please stop making PRs

Context: Psi with auto-capitalize first letter of sentence (the feature is requested in Gajim too) Currently, when we click on "yes", we have "yes", and when we click on "no", we have "No". My PR permits to have "same": "Yes" and "No", all people are happy.

It is clear, you can test directly with the test memberbot from dwd: memberbot@dave.cridland.net.

rion, don't say that or he'll go back to just demanding things from people :P ✏

rion: https://github.com/xsf/memberbot/pull/4#issuecomment-643006808 + https://github.com/xsf/memberbot/pull/4#issuecomment-643301118, it is not clear?

Neustradamus, But your PR doesn't do that.

I understand nothing.

Or rather:

Neustradamus, Firstly, your PR doesn't change anything - the spaces you've added are around the links, not what Psi is asked to send in the URLs, and

ahhhh, Neustradamus your PR adds spaces around so that they don't get capitalized in psi? what?

Neustradamus, Secondly, the patches that pep. and I already did mean that "Yes", "yes", "YES", and so on are all treated identically anyway, so it no longer matters whether Psi (or Gajim) capitalise the first letter or not.

https://github.com/xsf/memberbot/pull/4#issuecomment-643301118 After my change you have now "same": yes: you will have now "Yes" no: you will have always "No"

Neustradamus, have you tested with all the latest changes? It shouldn't matter anymore if Psi capitalises or not

Currently, you will see the difference, when you click on: yes: you have "yes" no: you have "No"

If it does then we should fix this instead of working around it

Neustradamus: I guess I start understanding. You want to disabled auto-capitalization feature in Psi. correct? If so there is an option for this somewhere.

Neustradamus, is it the case in all clients?

Neustradamus: options.ui.chat.auto-capitalize set it to false

Yes no problem without the auto-capitalize feature, it is "yes" and "no".

so solved!

If you enable auto-capitalize, and it doesn't capitalize, isn't that a bug?

Neustradamus, so it's not a memberbot issue?

I have specified in the ticket: - You can test with Psi and auto-capitalize function: "Psi -> Options -> Messages -> Input -> Automaticaly capitalize the first letter in a sentence". ✏

With your "fix": doesn't capitalize => bug

Neustradamus, yes but why should it matter for memberbot what Psi does here. Maybe help fix the auto-capitalization issue

In psi.

rion: it is not solved, the problem is always here with auto-capitalize the first letter of a setence, but it is solved with my fix.

Well guys already told you the fix is invalid. And I agree.

If you want to switch off capitalization of specific contact you have to go to our issue tracker and request something like "implement BLOCKlist for the capitalization feature"

We will see with Gajim and the same feature if it is a problem with Psi or Gajim or memberbot

Neustradamus, great!

Please report back

rion: I do not want to disable this feature for a contact

I think that you do not understand and you have not tested with you XMPP client

Neustradamus, But... the memberbot now doesn't care if you capitalise or not (or, if Psi does). So what's the problem you're trying to fix?

The problem is only for one choice

The difference is about the click on "yes" or "no"

yes = yes, no = No

Do you see the difference between yes and No?

Neustradamus, And as far as testing your patch goes - you can surely do that yourself instead of insisting that I (or anyone else) does so?

Neustradamus, To be clear: The memberbot does NOT see a difference anymore.

Neustradamus, Because Alex and pep. and I spent some time ensuring that was the case.

dwd, I say let's wait on his investigation with gajim :P

Maybe both Psi and Gajim need fixing.

Can you add my little changes in memberbot/chat_voting.py? Take few minute, and confirm it...

-> https://github.com/xsf/memberbot/pull/4/files

Neustradamus, But you can, surely?

Neustradamus, Why do i have to?

If you allow me a short baguette interlude: Neustradamus, t'es en train de corriger le problème au mauvais endroit. memberbot envoie la même chose à tout le monde, le problème ici est juste dû au fait que Psi capitalise. Comme tu proposes, regarde Gajim pour voir comment ça marche avec et peut-être qu'on pourra en tirer d'aures conclusions :)

Neustradamus: if you want I can add a different logic when text is pasted but not typed manually. But it's something for Psi 3.0 (in a couple of years)

rion, vanitasvitae: this website? https://www.moparisthebest.com/mix/

dwd: I have not a test memberbot.

rion: Have you added the test-memberbot? You have seen the problem?

moparisthebest: lgtm =)

Neustradamus, So make one. Create an XMPP account somewhere and point the script at it. And if you can't do that, we have to assume you are not competent to make any code changes to it.

But you have one here, it is easy to update some lines, no?

pep.: Do you understand that one is good and one is bad? ✏

Neustradamus, but it's not memberbot's fault

Neustradamus: I don't use capitalization. It's better have a habit to press shift manually. Otherwise you will start forgetting doing this everywhere.

I'm starting thinking Psi doesn't need this feature

rion, The auto-capitalisation or Neustradamus?

I feel like the opposite feature would be nicer, to undo the useless capitalization added by phone keyboards

dwd: good question

Zash, that's an issue with the sending clients :P

That you can see the main Psi developer can not test it... Because it does not use.

pep., therefore memberbot needs to handle it!!!1!

Zash, would you undo the (almost) systematic capitalization I do when writing from poezio?

I mean at the beginning of a sentence

pep., uNDO? wHEN YOU CAN REVERSE CAPS! ✏

:P

You can look the diff: '<a href="xmpp:{0}?message;type=chat;body=yes">yes</a> /' ' <a href="xmpp:{0}?message;type=chat;body=no">no</a>)</p>')

There is a space before "no" and there is no before "yes"

Neustradamus, Yes, I did. It doesn't change the URL, which is (we hope) what Psi uses to decide what to send.

Can you add directly, one example on 4: ' Would you like to recast your votes? (' '<a href="xmpp:{0}?message;type=chat;body=yes">yes</a> /' ' <a href="xmpp:{0}?message;type=chat;body=no">no</a>)</p>')

My PR solves...

If what Neustradamus writes is actually true, that would be a very weird bug in Psi...

(beside the weird feature of auto-capitalizing text that was not even typed in)

Well "yes" being at the beginning of a sentence I'd say that's on purpose?

But body semantics etc..

No problem for "no" but there is a problem for "yes", and the difference is only the missing space between "yes" and "no" parts.

Neustradamus, no, the "only" relevant difference is that "yes" is at the beginning of the message I'm guessing. ✏

Neustradamus, *if* your PR has any effect at all, that would definitely be a very weird bug in Psi.

Surely some clients strip spaces so that probably wouldn't have any effect on them :P

But body semantics etc..

pep.: yes it is same :)

- https://github.com/xsf/memberbot/blob/master/memberbot/chat_voting.py#L256 - https://github.com/xsf/memberbot/blob/master/memberbot/chat_voting.py#L264 - https://github.com/xsf/memberbot/blob/master/memberbot/chat_voting.py#L270 - https://github.com/xsf/memberbot/blob/master/memberbot/chat_voting.py#L276

Neustradamus, the issue is not memberbot, period.

I think we've brought enough points here today to show you that

pep.: I think that we have progressed, it must be solved before next voting period.

It is solved from memberbot's side

My PR has been merged?

Memberbot does not need changing.

🍿

This is fascinating.

I do like the efforts being made in https://xmpp.work/ and people are probably going to hate me for mentioning it, but someone has to do it. - The privacy policy (https://xmpp.work/privacy-policy/) is extremely hard to find (only link I found is in "Add Service Provider" -> "Sign Up"). Thus violating Art 12 (1) GDPR. - The privacy policy does not state the identity and the contact details of the data controller. Thus violationg Art 13 (1)(a) GDPR. - The privacy policy does not state how long Matomo tracking data is stored. Thus violating Art 13 (2)(a) GDPR. - The website uses Matomo in a way where tracking cookies are set without users consent. Thus violating Art 5 (3) ePD. - Additional hint: The privacy policy does not state if and how long server logs are stored. Assuming they are, this would be a violation of Art 13 GDPR. If no server logs are stored, it doesn't hurt to mention that.

maybe whoever owns it isn't under GDPR jurisdiction?

golabu, thanks for reporting this

moparisthebest, they are

moparisthebest, where would that be?

everywhere except EU I guess

If the website would not list job offers in EEA you could try to argue that (even without geoblocking) if the data controller / operator is really not located in EEA.

But as soon as the website targets EEA (which it does by listing job offers in EEA) GDPR applies.

I'm afraid we can only defer to the website author as we don't have access to this..

looks like there is only 1 job listed in India and the rest in the USA though?

moparisthebest, I don't think JC will argue that this shouldn't be under GDPR anyway. The XMPP community being rather EU-centric (be it good or bad)

That'd be sad

looking at the job listings you wouldn't think it was EU-centric, they are all USA except the Indian one :)

Anyway that's not the point. Not sure why we need legislation to run after services to provide a privacy policy that states what it does with the data. GDPR or not.

I don't even see a place to put data in there? do you mean just the job listings?

dunno, JC stated in the mail to operators that people could register themselves on the website

I haven't tried

But then matomo etc., you don't even need to register I guess

golabu: thanks, intjko these are sensible things to improve. I've asked the maintainer of the site (which is not the XSF) to have a look.

> looking at the job listings you wouldn't think it was EU-centric, they are all USA except the Indian one :) Given that it is live for just a couple of hours, that hardly is a trustworthy accurate reflection of the future listing.

golabu: thanks for the feedback, I'll try to incorporate it next week

jcbrand, 👍️

also sidenote: opkode.com (which I assume is your personal website) also uses matomo with tracking cookies but without user consent or any kind of privacy policy.

I'll disable Matomo for xmpp.work. Would have been nice to keep track of visitor numbers, but it's to much effort to comply with the cookie tracking regulations.

It's not representing anyway, as I could imagine that many users block tracking per default and send a DNT header (at least for me it's self-evident).

> It's not representing anyway, as I could imagine that many users block tracking per default and send a DNT header (at least for me it's self-evident). I would be surprised if a significant amount of users does so. Our particular bubble (and I'm thinking you're overestimating blockers there) is a poor representation of the general public.

dwd: the test-memberbot is offline? rion will test...

To confirm that the bug is in the memberbot

I've shut that machine down for the weekend, yes.

Oh :'(

Kev: Can you reopen my PR, I will not create an identical PR... Thanks in advance.

And I confirm you, the problem is solved with.

> I would be surprised if a significant amount of users does so. Our particular bubble Guus: I do refer to our bubble of course, because that are the ones that use XMPP I'd say. If you don't care about freedom and privacy I don't see why anybody should use XMPP.

do people still use DNT? did any company in the history of the internet ever actually respect it? https://www.fastcompany.com/90308068/how-the-tragic-death-of-do-not-track-ruined-the-web-for-everyone

moparisthebest: No, I do not know any major tracking company that does. Only privacy respecting service providers with a properly configured Matomo seem to do so. And for that it's good to have, because not every individual caring about privacy does block JavaScript by default (or so?).

Jeybe, some people argue and are happy / encourage that XMPP be used by capitalists companies that have for primary goal to pay their shareholders, and as a fact don't consider freedom nor privacy as a first choice (or at all) :)

It's actually a feature often not to consider privacy

Just think about their business model for a moment

pep.: So you refer to proprietary chat solutions build upon XMPP, like the chat system of League of Legends for example?

Or Zoom ;-)

For example

So they do hire for XMPP devs explicitely?

Jeybe: yes, us evil capitalists who try to exploit poor clinicians do. Other evil capitalists also do, including many who fund the XSF.

Jeybe: in fairness, there's also a lot of evil organisations who aren't capitalists who use, and hire for, XMPP.

pep.: purposefully misrepresenting other people's positions isn't a good look

misrepresenting?

You include yourself in there if you think you fit in

That sentence could very well be written absent of moral judgement

(I do judge though)

> jcbrand, 👍️ > also sidenote: opkode.com (which I assume is your personal website) also uses matomo with tracking cookies but without user consent or any kind of privacy policy. Matomo allows for explicit opt-out, and also you could simply have your browser activate the do not track flag it honors that too

Also if the problem is gdpr even if it tracks data it's anonimised so it could perfectly fit in a compliant site privacy policy

Really maybe you should tone down your enthusiasms guys, sometimes

(because it's often misplaced)