XSF Discussion - 2017-11-28

yeah, nice rules: 60% of members are in council now, so council will vote for council forever

what?

I’m pretty sure that’s incorrect

indeed.

https://xmpp.org/about/xsf/members.html we have many more members

even though that page needs updating

(preparing a PR)

jonasw, I checked https://wiki.xmpp.org/web/Membership_Applications_Q4_2017

those are slightly more than nine.

zinid: there are four application periods per year, you need to take them all together

zinid, reapplication is needed yearly, not quarterly

ah

so where is the full list?

so in Q4, at least four dropped out and up to one will be added

I linked it, zinid

https://xmpp.org/about/xsf/members.html

jonasw, is this page up to date?

I am updating it with the new council and board election right now

otherwise it is

ok, I didn't know you can reapply only once a year

if someone could double-check I didn’t mess up here, then I’ll merge it: https://github.com/xsf/xmpp.org/pull/385

whatever, I actually have a question about processing empty values in data forms

for example, the type of the <field/> is 'jid-single' and the value is <value/>

what to do in this situation?

empty string is clearly not a JID

Mmmmmmm, yeah, that's somewhat ambigous IIRC

yeah, and if we forbid empty values, then how to clear the field?

<field><value/></field> == empty string and <field/> == NULL or something like that

zinid, that’s simply invalid if the field is <required/>

otherwise, I’d treat it as absent

there is: > Note: Data provided for fields of type "jid-single" or "jid-multi" MUST contain one or more valid Jabber IDs, where validity is determined by the addressing rules defined in XMPP Core (see the Data Validation section below).

jonasw, absent meaning you should ignore it, or set it as "not set"?

since <value/> violates that, I’d treat the field as absent or unset

There's also the case of submitting a partial form.

which is either an error if the field was <required/> or leads to some defaulting if it wasn’t

jonasw, I'm not talking about required, it's obvious in this case

zinid, well, if it’s not <required/> surely the business logic of the form already knows what to do if the field is missing?

jonasw, indeed, what to do? keeping the field values untouched in the database or remove it?

*value

I’d NULL it

I actually tend to think you should not set <value/> at all if you need to erase it

possibly

<value/> == <value></value> == ""

which isn’t a valid JID

Nope

So you get an error back

so both empty <value/> and no <value/> at all violate the note I quoted above

another issue: the type is 'jid-multi' and you got <value/><value/><value/>

I hate XEP-0004

nah, we just should clarify it

the xep is okayish

IMHO

and cut it in two pieces

psi sends <value/> inside jid-multi field, I have even work-around for this in the data form parser

so, most likely, to keep backward compatibility we need to treap empty <value/> as no <value/> at all and should set internally the field to default value (e.g. NULL)

*to treat

simply put, treat this situation as a "default value"

Georg, Kev, could you please provide a snippet for https://xmpp.org/about/xmpp-standards-foundation.html ?

test

Guus: 👍

tx

rx

is there a way to know if we already voted?

Memberbot will tell you, I believe, when you say hello to it.

yup, it will

> (14:41:04) Memberbot: You have already participated in this election. Would you like to recast your votes? (yes / no)

right, thanks

Ge0rG, jonasw, I plan to provide a field (optional or required, determined by the service) to specify the name of the inviter, what do you think?

sorry, I lack context. where would you provide that field?

jonasw, user invitation

Sorry :D

and where’d that field be?

Such that we can provide something like "You were invited by X to join..." on the invitation page

Ad-hoc command

Filled out by the inviter

hmm

the issue with that type of names is that they can easily be spoofed

Ge0rG had some thoughts on this type of spoofing in the context of invitations IIRC

Sure, it's not a security feature :)

it could be misleading though

Well, you have to send the URL to somebody, if the user trust this URL then there is no problem

(because it trust the mail, SMS, ...)

You can think of it as security feature if somebody tries to manipulate/replace the invitation URL ;)

marc: I think it depends on how you implement it.

marc: if it is an additional url parameter that contains the plaintext name, it's rather Meh.

Ge0rG, that's up to the service

marc: if you only attach a token to the URL and the user's JID is somehow obtained from the server via the token, it's a bit better

The XEP defines the field

How the invitation page is implemented is out of scope of this XEP

marc: I see merit in defining the OOB behavior as well

In my current implementation the name is fetched from a database via the token

marc: so your XMPP server must also be a web server.

Ge0rG, well, providing a web page is also optional

My first implementation just uses the xmpp URI

and generates a QR code

Works nicely without web site etc.

marc: so where is the inviter's name displayed, then?

marc: does it also work nicely without an XMPP client?

Ge0rG, the name is displayed on a web site, if you provide one

Ge0rG, what works nicely?

marc: the QR code

the QR code is display in the xmpp client

but you could also just send the xmpp uri via SMS or ...

marc: and then?

marc: how does your friend open an xmpp: URI without an XMPP client?

Ge0rG, add a link with a download URL for a xmpp client ;)

marc: why not just use easy-xmpp-invitation? :P

Ge0rG, what's easy-xmpp-invitation?

ah I see

your website template

Ge0rG, that's nice but why should it be required by the XEP?

I prefer a web site for invitation which displays the QR code, provides information about clients etc.

But why should this be required?

marc: how do you generate the url for the web site where the inviter's username is displayed?

Ge0rG, the name is fetched from a database not included in the URL

You could include it in the URL

If you like but I don't care how that's implemented

marc: you send me a QR code with xmpp:.... How do I know the URL of the web page?

Out of scope IMO

Ge0rG, either I send you a URL or a bare xmpp URI

marc: where do you get the URL from?

In best case you're next to me and just scan the QR code from my display of my mobile phone

Ge0rG, the URL is generated by the server and sent back to the inviter

marc: so the response to the ad-hoc command is an xmpp: URI and a web link?

or either?

Always a token

And, if provided, a URL

the xmpp URI can be generated by the client

So the client needs to construct the xmpp: URI from the token?

Yes

And the server could send back an easy-xmpp-invitation URL or a mod_invite URL or some other black magic?

Ge0rG, it can send back a URL to some web site, yes

Sorry for the many questions, I'm trying to understand the protocol.

marc: will that be a generic website or a personalized one?

I thought it is not that complicated and straightforward :D

marc: life is full of corner cases.

Ge0rG, depends on the server / service

marc: so if your server sends personalized links, your client can forward the web URL and be good, but if my server returns a generic URL, and my client forwards only that, it's worthless?

they could also provide a URL to some porn web site if they like ;)

besides of the porn, of course.

Ge0rG, sure, of course the web site should include the xmpp URI, QR code etc

Otherwise this web site wouldn't make sense

marc: it could be a generic registration form or the ToS

No, that's not good

Well, you could do this, of course

But then the token is useless :D

marc: that's my point.

marc: so the XEP needs to specify that the returned URL is a personalized one that also contains the token (or a different token with the same functionality)

Ge0rG, we could also make the token optional and the server can send a URL of some generic invitation web site

marc: you don't need a XEP for that, do you?

Ge0rG, if you would like to have a standard for clients to request an inviation URL you do

Otherwise, where do you get this URL from? Search on the web?

Guessing?

I'm not saying that this is the best "response" from a service but it is better than nothing :)

marc: I'm saying that it's worse than nothing, if it is expected to be a specific URL

the client needs to decide based on what it receives.

if it receives [URL=https://yax.im/register, token=deadbeaf], it doesn't know whether it must send on both or only the URL

so the URL needs to provide the same functionality as the token

besides, it might be useful to return not just a token but an xmpp: URI, because the server might be better suited to construct it than the client

then the server could return xmpp:free-hosting.com?token=deadbeef to a client logged in as user@legacy.free-hosting.com

Sure, the server can also return the xmpp URI

Ge0rG, but the URL can still be optional, right?

marc: yes. The URL should be optional, I just would like to prevent "smart" server operators entering a generic URL there

Ge0rG, yes, but we can not avoid it anyway ;)

marc: but we can make it illegal via the XEP

:D

Ge0rG, btw, I think your easy-xmpp web site should auto-detect the operating system / browser and suggest a client :)

marc: I think you are right, which is why I wrote that into the TODO

ah nice ;)

didn't read it

too bad :P

I've just updated the Board mailing list. It's now current members + Council Chair + ED + Secretary.

... ED ...

Ah, Exec. Director?

Thanks Kev

Guus, so I’m not the only one having to re-think each time they see the abbreviation "ED"

"each time" <-- you've seen it before then? :)

ha well I found a fool proof spam prevention system that would work for xmpp too, it's terrible, but it'd work

our support got a ticket at work from a user who wasn't getting our emails because they have a spam prevention system that replies to the email with a link the sender has to click to allow the email through, or whitelist the address, or something

Guus, members list

so for unsolicited chat or subscription requests, server could message the user an http link that needs clicked before allowing it through... :/

moparisthebest: that's basically the same as the proof-of-work model we talked about, except less automated

where is this discussion? must have missed it

that could be the fallback if a PoW message gets sent but the potential spammers client doesn't support it

moparisthebest: I'm not sure where or when; it was a while ago. TL;DR if you get a message from someone you don't know, send their client a relatively expensive problem they have to compute and respond to before you'll show the message to the user

I actually think this would work better in xmpp vs email, this user wanted the person at our company monitoring the system.noreply@ourdomain.com email to click the link...

yea the combination might be good

I've got a TODO to write up a spec for that actually; I should do that this weekend.

you should :)

*SHOULD :-)

with a message a link fallback, servers could sanely turn it on before client support was widespread

actually, my TODO was for using it with IBR2, but the same challenge could be reused for both probably

and you don't need to specify what happens with the link, if that happens you expect human intervention, servers might whitelist automatically, have a captcha, or whatever

What part of this needs a spec?

the automated proof of work part

the sending a link would not

Holger: the link part doesn't, but if we want clients to automatically respond to PoW challenges from the server that part needs a spec

Ah the client responds without automatically? What happens to people with old clients?

s/without//

Holger: that's why you include a link to a captcha or something in the body. Old clients show that, you can click it and complete a human challenge instead

They click the link

Ah.

Just like joining MUCs on Jabber.ru, which I think does this with clients that don't support their captcha forms (you get a link to the same form on the web)

and here you go: https://xmpp.org/extensions/xep-0158.html#challenge-hashcash

Later in the document: "A challenger MAY provide a text question in the <body/> element of a challenge stanza for clients that do not support CAPTCHA forms."

oh hey, would you look at that, been done

The problem I see with proof-of-work is that spammers have access to lots of CPU cycles (that typically aren't really theirs), and real users don't

It's true, it doesn't stop botnets, it just stops every person with a laptop from being able to register hundreds of accounts and then send spam with them all day

Especially mobile users don't.

So you'll flatten a user's battery a bit, and you'll cost a spammer some miniscule amount of money on a botnet or captcha-solving platform

*slows down (not stops)

It still forces them to use a botnet or captcha-solving platform, which is more work. And most users will rarely have to do this, only spammers would need to do it regularly

Pretty sure the user's battery will drain before the spammers deem it not cost-effective

I suspect anyways; I bet most "normal" people only communicate with people on their roster, and if we drain a users battery because their phone is in a botnet I'm pretty okay with that

SamWhited, we had CAPTCHA on register.jabber.org, it didn't stop them, just slowed them down - doesn't solve much at the end of the day

Slowing them down is really the only point; it's the best we can do

Let's slow them down by retracting subscriptions from known spammers.

it wouldn't drain a mobile users battery at all, except a tiny amount once when they send a message to a new user they haven't sent one to before, right?

moparisthebest: there is a little problem there: PoW is much more energy-expensive on a mobile CPU than on a GPU cluster.

and if botnets do indeed bother and implement this, you can just fall back to manual human-intervention-required link challenge

Ge0rG, but it happens once per new message to new user max?

so like, maybe 30 times over the course of an entire xmpp account's life?

maybe other people are far more popular than I am idk

Ge0rG, depends on the PoW

memory-hard proofs come into mind

scrypt or something

and yea you could do something that is harder on gpus, yep scrypt

jonasw: right, because OOM isn't a thing on mobile :P

Ge0rG, it is, but using lareg amount of memory is expensive on GPUs

(and on FPGAs)

jonasw: we aren't talking about bitcoin mining parallelization here

or whatever-scrypt-coin

where large is something like ~100 MiB already, depending on the type of operations

You can't expect an old Android phone to provide 100MB (plus JVM overhead) to calculate a PoW

I would expect that to work actually

I bet firefox needs more

firefox gets swapped out then, I’m fine with that

jonasw: "Bug report: my browser gets killed when I add a friend"

an old android phone can't run conversations either so who cares

I think this is insane.

your browser gets killed always anyways on those machines.

this is crazy, yes

We'd have to think about that, but the point is that we can think of something that's not too bad for mobile users but still does the job

then you disable it on your client and solve http links by hand Ge0rG ?

I can’t really use my broswer + any other app on my Galaxy S3.

moparisthebest: no, I just switch to WhatsBook.

with WhatsBook, you need mutual subscription first anyways?

are you thinking this is something that would happen often?

I thought we had that as a possible sensible solution, too

jonasw: You don't.

Holger, hm, when we discussed this a few weeks ago, I think the consensus was that you need it, but w/e

moparisthebest: unless we make PoW prohibitively expensive for normal users, spammers won't be slowed / stopped by it.

jonasw: I remember someone claiming that and me not finding a single commercial messenger that actually does that.

jonasw: And I think it's unusable as a general solution.

Though admittedly this PoW idea sounds even worse.

If memory consumption and GPUs turn out to really be an issue it could also use an algorithm that relies on cache locality

Ge0rG, bcrypt and scrypt would like to disagree with you

they were explicitly designed to be not so bad for normal users, and prohibitive for bad guys

funny question, couldn’t the PoW be solved by a users server?

Yes, this would be interesting :)

new DoS way

you’d quota that of course etc., but for the occasional adding of a contact…?

mathieui, it would encourage server admins to lock down their servers better :)

like, 3 PoW / day / user, 60 PoW / hour in total or so

jonasw: that's an interesting idea; sounds like a possible DoS, but servers could be smart about it and say "this user is generating too many PoWs, what are they doing?"

SamWhited, exactly

that’d solve the mobile issue

that only helps good public servers being abused to send spam

moparisthebest: https://bitcoinware.net/collections/gridseed-dual-ltc-and-btc-miner

but, good thing to help I guess

moparisthebest, and it will slow down bad servers just as well

it also gives servers an interesting metric on users sending a lot of subscriptions/new messages

That only works if the server supports the PoW thing though; otherwise you still have to issue it to the client (or issue a captcha)

and if the server is overloaded with PoW, it could simply forward it to the client.

it would be better to have users do PoW to pay for their server.

SamWhited, ofc.

So if a spammer has spun up their own server, you still have to support the original model

Ge0rG, so xmpp spammers are going to buy super expensive miners, and try to use them for xmpp PoW ? seems unlikely

"the original model", SamWhited?

jonasw: sending a captcha/PoW to the client, I mean

you’d send it to the user, the server can decide to intercept the PoW request and handle it by itself or forward it to the client

moparisthebest: spammers will either distribute PoW to their botnet, where you will be paying for the PoW, or rent some gigahashes.

I’m not sure what you mean

I don't think they really have botnets now, just register on open servers and spam until banned

moparisthebest: please stop arguing. The PoW battle has been lost.

Ge0rG, not sure

there is no golden solves everything problem, you can only annoy them a bit, slow them down for a bit

if you have a botnet, you’re probably better off putting that computing power into $cryptocoin

instead of trying to spam

it's an arms race :P

moparisthebest: we can make life really miserable for mobile users and slightly annoy spammers.

you still haven't said how it would hurt mobile users at all?

jonasw: you need orders of magnitude more power for viable commercial mining

Right, if you have a botnet to spam with we can't stop you right now, but we can slow down your botnet so that you send less spam and possibly make it prohibitively expensive for the people who spin up a single server in their basemenet to send out spam

are you mistakenly thinking this would happen on every message or something?

And we can do it without affecting users at all, I suspect

*well behaved users

how often do you add or message new users? how often does a normal user do that? I'm thinking very rarely

moparisthebest: just to repeat my argument: if you make it sufficiently hard for spammers, it will be prohibitive for normal users.

and again that's just wrong Ge0rG

Ge0rG: we're disagreeing with that argument. Why do you think it would be prohibitvely expensive for normal users?

I doubt we’ll reach an argument here

we need data

moparisthebest: okay, suggest a number of scrypt operations a user needs to perform for an initial contact.

maybe some google scholar-ing on how botnets operate nowadays?

Spammers send lots of messages to people that aren't on their contact lists, normal users don't. That asymetry is what we're targeting.

SamWhited: we can target that with simple statistics, without annoying anyone.

Ge0rG, whatever takes about 4ish seconds on say a samsung galaxy s4

Ge0rG: where and how do you get those statistics?

SamWhited, I agree that I think this is the best place to solve this problem

"Q: My app crashes (or crashes other apps) when adding a contact. A: Don't worry, I know that you don't often add contacts."

yea you wouldn't make it crash

also, shouldn’t this discussion move to spam@?

Holger: that's why we have to do research and find something that won't OOM everyone but is still relatively tricky

Too many rooms.

Holger, I still claim that users on devices with this low amount of memory are used to that

We can add that to our response then.

Okay, just to get some numbers. "I managed to pull around 5.6KHash/sec on my Nexus 7 with all four threads." from https://rumorscity.com/2014/01/07/how-to-mine-litecoin-with-android/

Proof of work aside, it's very easy to identify accounts sending to a lot of non-contacts. Spammers will switch to subscription requests, but it's equally easy to spot (new?) accounts sending lots of subscription requests, and this is uncommon (not impossible for a legitimate user, just uncommon)

Indeed.

So we are at ~20 KHashes for a first-contact

MattJ, you mean easy if you run a server with lots of users I guess?

Easy on any server

MattJ, you assume that the server isn’t malicious

or, easy for a public server to spot new users of it's server

I find that assumption incorrect

MattJ: I agree, server operators should be doing that

jonasw, that is an assumption in this case, malicious servers are a different thing

yea explain how my private server with 4 xmpp accounts can see any of this data, easily or not

But that's not a problem we have today

MattJ, it is

I think

And malicious servers won't respond to PoW requests?

Holger, if they don't do the pow or click the link and do whatever is there, no requests get through to the client?

fighting spam at the source is of course most sensible, but hard in a distributed system

so, it's not a problem

Holger: they will respond to PoW requests, and that's the point. It will slow them down because they'll be responding to *lots* of them.

and if they do pow and too much spam still gets through, turn off pow and go back to manual links

also: if a server implements the PoW thing, it could "wall" the subscriptions unless it’s mutual

make them play an html5 punch the monkey game and beat a high score to whitelist their jid :P

(e.g. "user A and user B want to communicate, B’s server does not implement PoW, B adds A, A sees nothing; A adds B because they know about it: the subscription is established")

or A's server sends an https link to user B and when clicked lets it go through

you can rent 500MH/s for three hours for ~3USD. That accounts for 100 Millions spam messages.

if you price a single spam message at 20KH scrypt.

Case closed :)

SamWhited: I got the idea, I just don't see the gain in throttling them to, dunno, some hundreds of thousands of messages per day and CPU core or whatever. Do they really send millions per day right now?

What Ge0rG said.

Ge0rG, "ouch"

moparisthebest: so will you stop now?

right, what will happen is that spam will become a bit more expensive for the customers 🙂

source for MH price: https://www.miningrigrentals.com/rigs/scrypt

Holger: I don't know. More research would definitely be required, I just suspect we could slow them down a bit

and are you sure you can use that for arbitrary scrypt challenges Ge0rG ?

moparisthebest: again, spammers will just use whatever botnet they can get away with.

moparisthebest, if you can’t *now*, as soon as you can use this to make some financial gain (e.g. spam), they will adapt so that it can be used for that

moparisthebest: even when running on desktop Windows malware, you are several orders of magnitude faster than on a mobile device.

possibly, but then you are excluding spammers who don't have botnets

moparisthebest, even a spammer with their own server can easily outperform that challenge

are there challenges that are faster on ARM than amd64 ?

moparisthebest: let's just exclude all spammers by definition. Congratulations, we have won the spam war.

20 kH is not much

I can go back to work now.

Botnets would (hopefully) still be slowed down, non-botnets it might be too expensive. It's not a panacea, but it still seems like it could be a benefit if the idea works.

right there is no panacea

Right. So please pretty please let's focus on the ideas that make it actually worse for spammers than for users.

like this one

or, what is your other idea?

moparisthebest: read up my posts on the operators@ and standards@ MLs.

digitalocean started to provide high performance servers for computational tasks, for the record, I think 500MH/s would be nothing for those

moparisthebest: I've exceeded my time budget for convincing you on pointless scrypt performance calculations, sorry.

moparisthebest: Mine is server-side filtering based on both message contents and meta data. Works relatively well for email.

Ge0rG, I've been following a bit, but iirc most are geared towards running large-ish public servers with lots of data to analyze

and nothing for small private servers

SpamAssassin works just fine for small private email servers.

it does for email, I was under the impression most xmpp spam was too small for it to be effective

there are many theoretical solutions that just won't work out. Like a distributed p2p reputation system.

Holger: I've been wondering about that too; do you have that tied to an XMPP server? How well does it work for the shorter XMPP messages?

Some months ago, 99% of spam was multi-line Russian with multiple links.

Easy to kill, just filter multi-line messages from strangers.

Then, they switched to single-line messages with two pastebin links. Still pretty easy.

sure and it's easy to do stuff like that, doesn't solve everything though, just like PoW doesn't

Those are good things to do as well

moparisthebest: yes, but PoW WILL ANNOY USERS

SamWhited: I think it'll work quite well. Problem is it requires work.

Holger, except that Bayes sucks for short messages

besides I look forward to a future when all messages are encrypted base64 blobs :P

moparisthebest: So all solutions are equally adequate because none are perfect?

Now they send a subscription request + multiline / pastebin

Yah, I suspect zinid is right and it won't work so well for XMPP messages, but I'd love to be proven wrong

zinid: Yes I would definitely not rely just on Bayes.

no, I'm saying you should implement non-perfect solutions because those are the only solutions we have Holger

moparisthebest: you are saying we should implement bad solutions because there are no perfect ones.

moparisthebest: And I'm saying some non-perfect solutions are way better than others. So "nothing is perfect" is not a very convincing reasoning.

I haven't seen a spam message in weeks. Just the subscription requests

Holger, there is very little research for short messages, I recall a couple of papers only, you can search google scholar with "sms spam" query

BTW, my next proposals would be: - revert a pending subscription if a sender is classified as spam - implement a cache of URLs sent by strangers, with counters, and block messages with a count > 3

MattJ: ^

and, again, both of those solutions only work for large public servers Ge0rG

I'm literally the only user of my xmpp server to get any spam

moparisthebest: you know what? spammers are sending messages to non-existent accounts. You could easily set up a honeypot

Ge0rG: I agree, both of those things are a good start and should probably be done (although they also probably need a way of dealing with false positives, but that's a different problem)

moparisthebest: please log on your server messages sent to non-existent accounts

I'm not saying they aren't good solutions for large public servers, or that you shouldn't implement them, I just also want something that makes running your own server practical

Ge0rG, #2 won't work, the URLs can vary too easily

moparisthebest, set spam traps 🙂

MattJ: it's expensive to create a large number of shortened links

Trivial to append #uuid

MattJ: besides, we could HEAD them :P

Trivial to append ?uuid

moparisthebest, i.e. non-unsed accounts, but you publish them everywhere 😉

yea but is that what we suggest to people wanting to run their own servers

start your server, setup SRV records, post non-existant accounts at random places

zinid: Yes, I don't have papers to prove my point. But many of the criteria used for email classification are unrelated to the length of the message body.

Holger, zinid: seems worth trying either way

moparisthebest: you could just block messages from strangers with an URL.

Holger, yes, maybe you can do that, no doubt, although the result is unpredictable

yax.im will send an error response "Blocked due to abuse", so a real sender actually will see a message about being blocked

Ge0rG, what about subscription spam

what about captcha btw?

moparisthebest: see above

also none of this works for encryption

spammers will soon start sending omemo messages :P

Yes that's one of my complaints with E2EE.

moparisthebest: I'm sure they will

I'm eagerly awaiting the day when I can block E2EE on my server :P

Holger, ah, yes, E2EE, hehe

so back around to the original plan of replying with a https link with arbitrary things to solve on it

moparisthebest: yes, let your friends play xbill or whack-a-mole.

or solve a reCAPTCHA.

yes, once, doesn't seem like too much to ask?

maybe we could embed flash applications as base64 inside subscription replies

moparisthebest: you can do all that on your private server

moparisthebest: but it doesn't work well for public services

obviously doesn't happen if you send them an easy xmpp invite url or whatever

mathieui, it's 2017 you mean html5 applications

seems like it'd work equally well for public servers?

public servers just additionally have much more to go on, so maybe it wouldn't always be necessary

Holger: please tell MattJ about the normal-message-to-full-JID thing.

The "some clients do that so servers can't throw the message away" thing?

Some clients do that so servers can't throw the message away.

Well they can but some users will be yelling at you.

Holger: yeah, that thing. Was it just a misuse of Gajim, or was that a really f***ing big problem?

The main problem was some mobile and/or JavaScript libraries doing that by default or something.

Not sure about public clients. Maybe it was just Gajim.

Holger: I'd like to know which clients exactly... :>

I don't remember more than that sorry.

Meh, I'm still going to go for it

I think the real issue is that type=normal is overloaded to do unrelated things.

Right.

Like MAM responses from a remote MUC

And Carbons and ACKs and many other XEPs

And type influences both the meaning and the routing.

Yes on the one hand there's these type=normal messages addressed to individual *devices* and on the other there's type=normal messages addressed to humans, i.e. to accounts.

If now everyone agrees that the latter should be addressed to the bare JID, the problem is partly solved.

But the RFC disagrees, and so does some of the existing client code.

Holger: RFC6121 says you are not required to persist normal full-JID messages.

I'm not sure resource locking is part of RFC

It's part of 6121.

https://tools.ietf.org/html/rfc6121#section-5.1

Bummer.

Holger: I see only SHOULDs there, am I missing something?

but of course that doesn't mean existing code won't break ;)

Yes only SHOULDs.

can an XML attribute value contain newlines?

Ge0rG: seems like expat eats it

but probably better to escape it