XSF Discussion - 2019-01-29

xmpp is suddenly looking alot better than facetime to some apple users now I bet :D

moparisthebest how so ?

https://9to5mac.com/2019/01/28/facetime-bug-hear-audio/

ah :p

awesome

took 10 days to turn the Facetime switch of

> Weirder yet: if the recipient presses the volume down button or the power button to try to silence or dismiss the call, their camera turns on as well. Though the recipient’s phone display continues showing the incoming call screen, their microphone/camera are streaming.

amazing

they got some pretty weird bahavior going on in their app to have that

indeed

(doesn't facetime use XMPP?)

Guus in a way, everything in IM/VoiP is based on XMPP with a bit or a lot of adaptations :p

Yes, we can declare victory.

VICTORY

hm

Also, 2019 is going to be the year of the linux desktop.

Guus: the twentieth consecutive one!

See? Winning! #tigerblood

See? Winning! #tigerblood

Is it known/expected that the links to Schemas in XEPs lead to a 404?

E.g. 0313 sends me to <http://www.xmpp.org/schemas/archive-management.xsd>.

Holger, known

k

Ge0rG, I've been using linux a my desktop since 1996 (almost exclusive, just a drop into win or macos every now and then), so it's more like 23th consecutive one.

Hey, is there any reason why MAM is not activated on this room?

missing mod_mac_mum?

Mac Mum 🎑✨

Maranda: or was it mod_mum_mac?

Not sure

I remember it being related to a low-income overweight burger-eating family.

Ge0rG, mum mac apparently

maybe it was also a MILFy cam_mum.

This only reinforces my wish to write a blog post: "Prosody Community Modules: The Good, the Bad, and the Ugly"

.oO(gstreamer-plugins-{good,bad,ugly})

jonas’: indeed.

🤔 I guess the query should be directed to Zash for a more proper naming convention on that

Naming convention discussion rather

Maranda: the problem is that depending on prosody version, there are modules in core or not.

and the core modules implement a feature set that is overlapping but neither a subset nor a superset of the community module

I think I need to draw plenty of Venn diagrams.

Not sure I include all modules.... Not having contributed ones

And since my MUC MAM relies on mod_muc_log guess what... It's called mod_muc_log_mam 🙃🤭

Just shuffle the letters.

Maranda: do you know the Kennifyer?

Like wise the http logs are called mod_muc_log_http

Nay

Maranda: https://www.namesuppressed.com/kenny/

s/are/is/

mod_ppmfmfmmfppmmmmppm

Hehe

So, I did something silly and slapped on xep-0359 to any stanza that passed. Doesn't work to well for IQ's, which can have only one direct child.

oops

what's the best approach here? Only Messages?

not doing it at all in this manner?

Ge0rG elaborate, please

I'm not sure it is a good idea to slap 0359 on *all* messages that you pass. You should only do that for messages that end up in your MAM archive

what makes you wonder if it's a good idea?

Ge0rG, I think you *have* to place a stanza-id on anything you archive, with mam:2. Whether you *also* place them on other messages is not specified.

Ge0rG, But a client might ask for "all messages after this one", so if you can't service that from MAM because you're unaware of the stanza-id referenced, that could be a problem.

dwd: that's exactly what I was thinking. CC Guus

Also, there's a nagging concern that if you're a little over-zealous in archiving messages, you can archive the MAM result stanzas, and a query for "every message after this point" can lead you into some interestingly endless interactions.

No

Those would be contained inside forwarded-containers, right?

Zash: it's not *forbidden* to archive those.

I'm not sure whether it was mentioned before, but it would be nice to have consistent rules for MAM and Carbons and ephemeral vs. persistent messages.

Yes

Something for the summit perhaps?

For the 2018 Summit.

You know all these issues stand still while there isn't an ongoing summit :)

I'd like to have Summit discuss the mess of message IDs, and which ones to use when when referencing messages.

Zash: because nobody reads the ML?

Nobody reads anything, ever :)

an awesome tagline for a chat client.

Ge0rG, Might it be worth looking at XEP-0226 again and seeing if it makes sense to stipulate ephemerality in terms of message profiles?

dwd: interesting idea, but I fear it will lead into an endless list of exceptions and exceptions-from-exceptions

dwd: essentially you'd end up codifying the existing rules with a different name

Ge0rG, Well, the existing rules are "apply common sense".

dwd: that doesn't work

It's a good way to delegate the hard work from people who should know it to random server developers.

Ge0rG, I think we can approach this by saying "these elements are metadata - ignore them for the purposes of MAM/Carbons/etc", and "these elements mean it's worth doing something with".

Ge0rG, In general, server developers are not random. Certainly not cryptogrphically so.

dwd: ah, so you are into tagging stanza elements and using those as signal/noise indicators?

I'd not consider myself to be a cryptographically strong random, but more random like https://xkcd.com/221/

Ge0rG, I'm into exploring the idea, certainly. That's the approach of XEP-0226 - to use the elements as contents (and, in this case, ban certain combinations).

Ge0rG, Also, same, but in my case with a loaded dice.

dwd: what you propose sounds like a formal notion (with explicitly named elements) of https://op-co.de/tmp/xep-0280.html#which-messages

dwd: while I was more interested in changing the semantics of either message type, to-JID-fullness or both, to encode the ephemerality. Hence IM-NG

I think that's a waste of effort. It's a boil-the-ocean forklift upgrade.

I mean, those are great fun, but they've repeatedly failed.

dwd: I'm not convinced it actually is.

dwd: my ideas are 90% compliant with 6121 rules

But yeah, I have ambitious goals.

I need to restrain myself. Can we please get Summit to at least figure out which of the (only?) three message identifiers are to be used when?

Ambition is laudable, but we need a touch of pragmatism too.

Hints?

Ge0rG, Three? Origin, Stanza-id, and id attribute?

dwd: yes

Zash, Council shot down hints. I didn't agree, and still find it very useful.

IIRC, Council's problem was that the XEP format is not suitable for Hints.

Maybe there should be a Registry of Hints instead?

Ge0rG, Yes indeed. I think if origin isn't the same as the id attribute something has borkened, and stanza-id is for ids applied by intermediates (and used when querying those intermediates).

Ge0rG, I thought there were multiple arguments against hints, like servers might ignore them and things.

dwd: but which one do you use in 0184 ACKs? Which one in 0333? Which one in proto-XEP-emoji-Reactions?

dwd: yeah, those too

Ge0rG, The first two are specified as the stanza's id attribute, aren't they?

dwd: that doesn't mean it's right, just that they predate 0359.

@id is optional and scoped on the c2s stream, so there are no uniqueness guarantees. origin-id can be forged by a malicious client, and stanza-id isn't available until the message was reflected to you, which is "never" in the default case.

Ge0rG, Let me rephrase - I think origin-id is an unfortunate workaround for broken behaviour, some of which I even contributed to.

dwd: okay okay. I'm writing up the long version to standards@

Ge0rG, Rather than ossify it, I'd rather treat it as the workaround it is, and work to remove the requirement for its existence.

dwd: there is a principal problem with attacker-generated-IDs scoped to a MUC (as opposed to a direct chat) ✏

Ge0rG, Does origin-id help with that at all?

dwd: no

it merely adds to the confusion

Ge0rG, Right. Of course, if MUCs *don't* preserve ids, then the reflection would ... Oh.

dwd: oh?

Ge0rG, That is, the attack is only even vaguely possible because an attacker has control of the id. If the MUC re-issues a new id, then it's largely moot.

dwd: yes, you have replaced a reference authentication problem with a race condition problem.

Is there a canonical XMPP logo somewhere?

Yes

flow, any of xmpp*.png in https://github.com/xsf/xmpp.org/tree/master/content/images/logos ?

No .svg?

somewhere

haven’t found it yet

`$ locate xmpp.svg`

flow, https://github.com/xsf/xmpp.org/pull/363 Guus probably knows where the SVG version is

jonas’, thanks, png is fine

ah, got it

https://github.com/xsf/xmpp.org/blob/master/xmpp.org-theme/static/images/xmpp-logo.svg

I found ~/src/xmpp/images/xmpp.svg

https://cerdale.zash.se/upload/-uwGf0VaQc-n_Gnr/xmpp.svg

That's the old one

The new one, as linked by jonas’ has the little orange thingy crossover moved to under

This was out of a very old repo, I think from before it was split into multiple

2015, not /that/ old

Yes, this was changed more recently

in sept 2017

Interestingly, Guus apparently removed the old version with the XMPP letters included

use the logo on the top-left corner of the website

that links to https://xmpp.org/theme/images/xmpp-logo.svg

Guus: that's without the XMPP letters, hence my comment

ah, sorry, _without_

I'm scrambling today, not paying enough attention

No worries

I have a proper one, hold on

Unsure where that logo with letters is.

If you need to find the font: it's the same font as was used for HAL in 2001: Space Odyssey

I just noticed that the middle lines aren't completely smooth, they have sharp edges near the bottom. Now I can't un-see it :(

I always forget the font name, but not that reference. 😉

The font is called OPTIEdgar Bold Extended

https://upload.ik.nu/upload/vEqZhG9m0siQiaH6/xmpp.svg

Zash: ^

Nice

https://upload.ik.nu/upload/jbbkx8yLJnk6ZNbi/VfKA42JTTua6Abrw9GG8iQ.jpg

CHEAT! CHEAT!

(I would've done the same 😛 )

maybe I'll cover myself in stickers... 😉

I wish I had a Jabber® hoodie.

Ge0rG: I'm sure you like these, too.

Thank you for using a reference, Ge0rG

🙂

speaking of which - did Peter get back to you?

Guus: not yet

> Will reply tonight or tomorrow! -- Thu, 24 Jan 2019

Guus: should I ping him?

dwd: I'd like to conclude the 0410 LC with a Council vote, but there was an intersting issue brought up and not yet resolved: should there be an _additional_ error condition that says something like "you are not a participant to this MUC"?

Ge0rG, I think we need to have a second round of LC after you updated the XEP

Ge0rG I just pinged Peter

wraaaagghhh why can't I type on three keyboards at the same time.

Guus: thanks very much

jonas’: but why?

ah, no

it is indeed a council vote which is the next step

you do updates, council votes whether to decide on it now or have another LC

XEP-0001, §7 > Once the consensus of the Standards SIG has been incorporated into the XEP and all issues of substance raised during the Last Call have been addressed by the XEP author, the XMPP Extensions Editor shall formally propose a specific revision of the XEP to the Approving Body for its vote. If necessary, the XMPP Extensions Editor may, at his discretion and in consultation with the Approving Body, extend the Last Call or issue a new Last Call if the XEP requires further discussion.

jonas’: so the options are now: - merge the PR and let the Council vote on Proposal - try to gain more feedback and resolve open questions

maybe

I’m too full of cold slime to figure that out at the moment

my gut feeling is that there are two issues worth delaying the Proposal: the additional error condition; and the correct baseline IQ response for a non-participant

yes

I suggest that you make an update to the PR which incorporates what you’d like them to be and we can discuss that tomorrow and decide whether we find it okay enough or put it into another LC?

Ge0rG, "occupant", but yeah.

Participant: An occupant who does not have admin status

Ew.

I thought a particpant had voice, as well.

dwd: I don't feel ready for Proposing yet.

the key question is, do you have a ring yet?

jonas’: a jingle ring or a token ring?

a facetime ring, maybe

one ring to spy upon them

:>

> The <error/> element: > - MUST contain a defined condition element. > - MAY contain a <text/> child element ... > - MAY contain a child element for an application-specific error condition Is it allowed to have multiple application-specific error conditions? Multiple defined condition elements?

<xs:element name='error'> <xs:complexType> <xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'> <xs:group ref='err:stanzaErrorGroup'/> <xs:element ref='err:text' minOccurs='0'/> </xs:sequence> <xs:attribute name='by' type='xs:string' use='optional'/> <xs:attribute name='type' use='required'> <xs:simpleType> <xs:restriction base='xs:NMTOKEN'> <xs:enumeration value='auth'/> <xs:enumeration value='cancel'/> <xs:enumeration value='continue'/> <xs:enumeration value='modify'/> <xs:enumeration value='wait'/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element>

can someone parse that?

jonas’: `<xs:group ref='err:stanzaErrorGroup'/>` is probably the relevant part

that’s just an enumeration of the different error types

the defined error types that is

a single xs:choice thing with all the elements in it

doesn’t specify/handle application defined conditions

so it needs an optional any?

Or is that implicitly allowed?

I don’t know

I fear I just trolled the standards@ ML, a little.

Time to walk myself out.

good luck

Okay, so it looks like I identified the cause of massive MUC message duplication in yaxim.

Anybody wants to guess?

SQL index something?

jonas’: it's my favorite MUC protocol feature.

yrtnpl tebhcpung cebgbpby

oh dear

It looks like MultiUserChat.isJoined() is not updated on connection re-auth.

https://blog.freedombone.net/dark-messenger

What would be the right way to officially suggest that all clients/servers omit TLS authentication for any .onion domain?

A XEP or?

A XEP, informational I guess

"Best Practices for using XMPP with Tor"