XSF Discussion - 2019-09-06

Where is the up-to-date memberbot source code?

Neustradamus, https://github.com/legastero/memberbot/network/members I think

Ah wait, it says archived

Link Mauve has a few patches on top, but it's the only fork apparently so..

Hmm, maybe ask Lance when he wakes

We could have him move it to our org

Leaving forks intact

Because there is a problem (I have auto capitalize the first letter of sentence in my client) and when we click on "yes" it is Yes, it does not work. There is no problem for "no" it is no.

Ah yeah, it only allows "Yes" as "Yes" haha :D

https://xmpp.org/extensions/inbox/buttons.xml !

And this bug is not new.

This is a bottomless pit. First you want "Yes", then you want "YES", then you want "true", then you want "1"...

In the end, you end up with a YAML parser that interprets your answer as a sexagesimal number.

Yes!

"si", "ja", "SIR YES SIR!"

I mean: yes!

Ydw.

The age of an issue is not really relevant.

(but not having it case-sensitive would be a welcome improvement)

> "si", "ja", "SIR YES SIR!" Spanish, German/Dutch, American?

Guus: xml:lang?

👍👎

Thankfully Yes! will get interpreted as 1! which as everyone knows is equal to 1.

Motivate me or someone to fix up the buttons XEP

The return of the revenge of the unintended factorial!

Zash: data forms!

Ad-hoc commands!

pubsub

all of the above, plus jingle!

Donkey!

omg

dataform in ad-hoc command over p2p-xmpp offered via jingle session in pep

Now I'm listening

Ge0rG, will you also allow me to have: はい, ええ, えー, いいえ, いえ, いいや, いや ? :P

or Guus ^ (dunno who was talking about it)

Blamimng Ge0rG for all of this works for me.

"Say yes or no. Please pronounce it clearly, our speech analysis sucks."

Also XEP-0132.

pep., with context dependent answer to actually pick no when you say はい to a negative question.

linkmauve, of course

That's what I expect from locale handling

wasn't there a language where "no" actually means yes?

Uh-oh, I hope I'm not triggering an army of SJWs now.

Ge0rG, that was the essence of my joke. :p

Polish, according to my Google-foo.

In Japanese you answer positively (Yes) to a negative question if you agree with the negation

But it's not just them, I actually also do that in french and english nowadays :x

linkmauve: but I don't understand Japanese.

Ah, too bad.

pep., oh no.

pep.: I do that a lot

In German you have "ja", "nein" and "doch". When asked a negated question, you use the latter two

Ge0rG, yeah there's also « si » in french

("doch" equivalent I guess)

language is complicated. Let's go fishing.

Great, I now have a Pod which can do fishing.

It costed me 5000G and takes [3] space in memory.

Hey, this is interesting. We had someone trying to send s2s spam over a server using anonymous logins (we disallow s2s traffic for anonymous sessions). Now the intended recipient (that would not have received anything) is replying back with StopSpam Question subject messages containing a simple math problem.

Guus: how does the recipient know?

exactly.

maybe your s2s blocker is faulty?

is the intended recipient on your own server?

Pretty sure it's not - I'm guessing that the recipient expected the spam to arrive, didn't, and is trying to make it come through with sending questions to de-block data.

which suggests recipient and sender are the same party.

no, they're on xmpp.jp.

Intelesting

Guus: I'm pretty sure this is not how the StopSpam thing works.

Guus: maybe it reacts to presence, not to messages, and your s2s blocker only blocks the latter?

Can't rule out a bug

but it should

feel free to give it a test on igniterealtime.org

Guus: is that the anon domain?

I don't even know how to login to an anon domain

Ge0rG yes - Smack supports it, afaik

So does Conversations

Enter a random local part

it's a SASL mechanism

Yay, let's crash yaxim!

Thanks for the minutes, Daniel

Hm. It won't let me in.

Because I try SCRAM-SHA1, which is advertised, and which obviously fails

Daniel: doesn't work with Conversations either :(

yes because of the same reason

Guus: your server is broken :P

ohboy

the _spammers_ can get in... 😉

i wonder if i should make it work with anon available && password.isEmpty()

or something

Georg, what exactly happens?

wait, you guys expect anonymous to be the only SASL mechanism that's offered?

Daniel: that would be the obvious hack

Things seem easier if anonymous users are namespaced onto another virtualhost

Guus: Smack's highly complicated pluggable SASL mechanisms plug mechanism uses SCRAM-SHA1

SCRAM-SHA1 fails

> Things seem easier if anonymous users are namespaced onto another virtualhost Yes. Thats what I tested Conversations with

I think in Smack you explicitly tell 'anonymous' somehow

Ge0rG org.jivesoftware.smack.ConnectionConfiguration.Builder#performSaslAnonymousAuthentication

Unsure how the server could help you here.

Guus: Historical thing due to how Openfire didn't have virtual host support in the past?

Openfire does not and will not have virtual host support.

way to complicated to put that in the existing code base. doesn't outweigh simply running two servers. ✏

java.lang.IllegalArgumentException: Client State Indication not supported by server

Sigh.

why is that even mandatory in the code?

CSI - the spec that doesn't have any sensible spec compliant benefits, right?

I think I've a plugin somewhere that will advertise the feature...

Oh, it is not supposed to throw that kind of exception. This was only meant to ensure that the client is connected to the server.

Guus: it would be great if messages got bounced back.

kindly elaborate

Guus: if I send a message, and your server forbids the delivery of that message, it should reply with a message error

But it doesn't look like an anon client is able to send messages or presence to yax.im

hmm, I'm guessing we didn't do that because we didn't want to make spammers wiser

which might be overkill

Guus: you are also breaking things for users.

also, I'm not ruling out that this goes wrong in other places

Guus: same thing with presence.

But at least anon is breaking surprisingly few things.

hmm, you're onto something. The stanza bouncing rules are somewhat awkward.

SENT: <iq id='1dfTY-60' type='set'><query xmlns='jabber:iq:roster'><item jid='georg@yax.im' name='Georg' subscription='none'></item></query></iq> RECV: <iq type="error" id="1dfTY-60" to="1qr03gr14@igniterealtime.org/1qr03gr14"> <query xmlns="jabber:iq:roster"><item jid="georg@yax.im" name="Georg" subscription="none"/></query> <error code="500" type="wait"><internal-server-error xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error> </iq>

Guus: you might also want to fix that: wait/internal-server-error is definitively the wrong response

hehe

this is just "omgwedidntanticipatethis"

oh, there's actually an attempt in the code to cause an 'unauthorized'

but that doesn't get processed properly

here's another one!

SENT: <presence to='openfire@conference.igniterealtime.org/Ge0rG' id='1dfTY-94' type='unavailable'></presence> RECV: <presence to="1qr03gr14@igniterealtime.org/1qr03gr14" id="1dfTY-94" type="error" from="openfire@conference.igniterealtime.org/Ge0rG"><error code="400" type="wait"><unexpected-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></presence>

getting a roster in an anonymous session, would 'not-authorized' be a suitable response?

technically, SASL happened...

not-allowed is documented to apply to _any entity_

not-acceptable?

service-unavailable?

problems found in yaxim: 2 problems found in openfire: 3(?)

One down: https://github.com/igniterealtime/Openfire/pull/1472

I still can't join the MUC, but it seems to be a yaxim bug

openfire@ is a private muc, I think. Try open_chat

Guus: Smack has SCRAM-SHA-1 and SCRAM-SHA-1-PLUS? https://issues.igniterealtime.org/browse/SMACK-749

Guus: if it's a private MUC, why did I get one message from it?

Ignite Realtime products are not in the good category? -> https://github.com/scram-xmpp/info/issues/1

Neustradamus I would appreciate it if you stop following me around with the same question.

Ge0rG I'm unsure if it's private, or simply unlisted, or something else - it's not the regular room that I thought you ment to use, which would be open_chat

I do a search and I have found: https://discourse.igniterealtime.org/t/saslerror-using-scram-sha-1-malformed-request/73391 and the ticket

Guus: it was listed in disco#items

Guus: looks like the room isn't sending a subject.

Guus: https://xmpp.org/extensions/xep-0045.html#order

Ge0rG any pointers to the proper handling of undeliverable presence stanzas?

Openfire is dropping all of them silently

Guus: send back... a presence error!

probably not always

not on unavailable, I'd assume

I'm not an expert in that field, sorry

Quickly scanning the RFC gives me more than that'd be a quick fix

> After the room has optionally sent the discussion history to the new occupant, it SHALL send the current room subject. On some days, I hate XEP-0045

We'd bounce a stanza when it can't be delivered unless it's type=error or type=result.

Wait, SHALL is a synonym to MUST. That makes my hate disappear.

Guus: look, you are violating XEP-0045 there :D

Kev: why don't you bounce type=result?

Relatedly, what do you do if you recieve a malformed error stanza?

Because you never reply to a result?

Yell "garbage in, garbage out!" and deliver it?

Zash: define "malformed"

Actually, the issue I'm thinking of is with a malformed iq-reply, a disco#info response where all the <features> went into the top level stanza and the actual <{disco#info>query> payload is missing.

Thus, having more than 2 direct child tags, which is forbidden

Actually, type=reply can't have more than 1, but still

Ge0rG, if you just discovered that, and now implement that you are only really joined if you receive the subject

prepare for older ejabberd server that dont send empty subjects :)

and in fact prosody didnt do this also once

if you want to test old ejabberds jabber.ru is a good testing ground :)

lovetox: I remember those issues, yeah. How do you "complete" a join then? On self-presence?

Are there still servers that don't add 110?

no a join is complete if you receive a subject

i put a timer, when i receive self presence

means joins on not compliant servers need longer, but not really my problem, they can upgrade their software

yeah because then you can't distinguish between muc history and normal delayed messages

correct ! ✏

and this is for another reason important

servers dont validate delay timestamps on groupchat messages

and if i receive a message with a timestamp by attr = muc jid that means i respect that timestamp as the true timestamp

if i receive a message with a timestamp not set by the server, i save both timestamps, the one i received and one that is potentially set by a user

and because servers dont validate the by attr in delay timestamps

you cant just simply parse the by attr

Do you btw invert the trust model once you start seeing e2ee? :P

you need the subject to determine if its a muc history message

pep., what does that mean "invert the trust model"

Well here you rely on the server doing "the right thing" and users potentially being evil, from what I understand

yes

i dont see how that changes with e2e

In the e2ee world, people don't trust their server (otherwise there's little point)

they trust the server with everything but keeping message content private

So in their view, I guess, the server would be the evil actor and they're be the ones to do the right thing

*they'd

> After the room has optionally sent the discussion history to the new occupant, it SHALL send the current room subject.

Ge0rG that doesn't say that a room MUST have a subject?

It can be empty

yes Guus you should send a empty subject

But it must be

srsly/

yes otherwise how do we differentiate between muc history and live messages?

<delay/> only happens in MUC history right? :P

that you have in your implementation NULL for subject and consider this "not empty", i think is not really the point of the xep

Next up: Clients are technically allowed to send messages with subjects that are not the room subject, iff they also include a body.

pep., delay happens when a client adds it

lovetox, that was a joke

:)

pep.: it was a very evil joke

Zash, yeah also a good point, Gajim should interpret this correctly :)

Ge0rG, I guess that's what the XEP authors thought?

Or predicted, rather

somebody remind me to send a PR to fix that place of the XEP

Ge0rG, That's also how poezio works anyway.. Remember that obnoxious grey color?

grey?

Zash, this.

https://cerdale.zash.se/upload/DW2VdqYztEtF6KJ9/this.png

on poezio

https://ppjet.bouah.net/poezio-grey.png

Never seen that before

This comes from the fact that <delay/> is only used in MUC history (right?). Also why poezio doesn't do highlights when <delay/> is present

what?

Have you never noticed people enabling mod_delay for no reason and poezio becoming unreadable?

https://cerdale.zash.se/upload/L3qjPKnmAFR5iyoR/not-grey.png

it's dark magenta on black in my theme

and it suppresses highlights, which is evil.

:)

What I says seems largely redundant.

It is indeed (evil). https://cerdale.zash.se/upload/L3qjPKnmAFR5iyoR/not-grey.png if somebody wants to tackle the issue

fail.

https://lab.louiz.org/poezio/poezio/issues/3142 this

> Opened 3 years ago by ge0rg

Everything old is new again.

What is dead may never die

third PR gone into Openfire. Tx Ge0rG

Guus: thanks!

Don't thank me yet: these were shot from the hip.

Guus: deploy to igniterealtime, see what happens

friday afternoon is the best time for that

Yeah, maybe

I should get back to work first 🙂

Is fasten going to be used for the full qoute / reference use case?

Daniel, might even be called "Attach" in the end! See standards@

🙈🙉🙊

And yes

Or is reference going to be used for mentions etc. still?

Are we intentionally sending out repeated newsletter tweets? It is starting to get annoying.

can we get an example in the XEP (for quoteing a message)

Guus, that annoys me to

not that i wouldn’t know how. it's just that i want it explicit that this xep is meant for that

nyco are you triggering these? Maybe cut down on the frequency?

Guus: the worst thing is that the tweets lack actual content

they look like a badly trained AI. Sorry.

or maybe an attempt at SEO

Like the rest of Twitter? </troll>

so references and old attaching are going to be obsoleted?

Daniel, I don’t think so

AAUI, Kev intends to rebase/adapt References to Fastening

or revamp it at least

Fastening and References serve different use-cases

References gets updated to use fastening once fastening's published, and the idea is that old attaching goes away, yes.

and isn’t quoting referse fasting? if you consider the MAM playout you want the original message with the quote and not the quotes for the original message

or maybe you want the later

or maybe both

Kev, humm, isn’t fastening supposed to be 1:N, i.e. a message can be fastened to at most one other message, but a message can have multiple messages fastened to it?

how would that work with multiple mentions, for example?

fasten your references!

fwiw it is completely not obvious from reading the current XEP that this can (even remotely) be used for quoteing

> that adds additional information to the context of a previous message. i'm really not sure that quoteing falls under that category

jonas’: yes 1:N

I don't think that quoting is a good use case for this. You might use references instead.

I'll try to 'complete' my blog post with many examples this weekend.

Including renderings

(of fasten, references, and combinations thereof)

ok. i’ll just wait then. because right now i can’t picture any of this

Guus, pep.: I've been really blind regarding the no-subject-set thing. It's actually right there, in your face, in Example 42: https://xmpp.org/extensions/xep-0045.html#example-42

relevant: https://issues.prosody.im/1053

> Guus, pep.: I've been really blind regarding the no-subject-set thing. It's actually right there, in your face, in Example 42: https://xmpp.org/extensions/xep-0045.html#example-42 I've seen that. I think Daryl just merged my PR that adds that.

While we're on the topic of Openfire bugs here, what's up with sending `</stream:stream>` unencrypted at the end of TLS connections?

Hah

I fixed that earlier this week

At least during dialback

Heh, that explains why I just saw that just now.

Should not happen anymore on IgniteRealtime.org, if you care to test

Gotta be properly capitalized too? :)

No, that's autocorrect on my phone

> Heh, that explains why I just saw that just now. The problem has always been there, the fix is recent.

If you only saw a problem recently, then my fix made things unexpectedly worse...

I think I've pointed it out in the past

Kk

Fyi, my current status:

Looks fixed indeed, normal "closed" message

https://igniterealtime.org:443/httpfileupload/8ad21367-2b15-45d2-8079-670a386067aa/cCutz7hVTKSzxHAk9GyhZA.jpg

Good idea!

> Looks fixed indeed, normal "closed" message Good, tx

One of the benefits of having kids: making pancakes and pretending you do _them_ a favour.

Level 2: Teaching them to make pancakes

That's a trap

You'll have to clean up during the time that they are in training, but suck at flipping pancakes by throwing them in the air.

Cast iron.

https://igniterealtime.org:443/httpfileupload/5801e2dc-ee1d-484c-8d4b-d23f03ffb49a/IBgfNURnQC2YLGJRBF_rVQ.jpg

It is