XMPP Council - 2019-02-27

I just realized I have a meeting at 14:30Z. depending on the duration (which isn’t clearly defined and may range from 15min to 90min), I won’t be able to be on time.

jonas’, seems like there is no agenda anyway

okay, meeting’s over, depending on traffic I’m somewhere between on time or ~10min late ✏

Good morning everyone!

.

’morning, I’m here. o/

I'm here too.

we have TrueDWD

In the interests of security, I suggest we conduct the meeting in Double-ROT13.

<proceed xmlns="urn:dwd:xmpp:double-rot13"/>

OK, let's go.

https://www.schneier.com/blog/archives/2015/11/paris_terrorist.html

1) Role Call?

✏

Kev said he'd be missing this one, didn't he?

yes

Righty.

2) Agenda Bashing

So, I failed to get an agenda together, but I think we have some ProtoXEPs or something don't we?

no protoxeps I’m aware of

zinid’s.

didn’t we discuss those already?

More than the three ones that expired(?)?

We mostly already voted on them though, this is just a reminder that on list people should vote.

that’s true

Ge0rG, two for us, and one for board.

dwd, there are a bunch of [Needs Council] PRs though

this one for example: https://github.com/xsf/xeps/pull/760

Oh, lots.

yeah, many of them have already started votes

I think today is the last day to vote on my xeps BTW

zinid, yes

according to Tedd sterr

zinid, Yes, sorry for the delay on my part.

jonas’, So I see #752, #758, and #760 to vote on?

maybe

I lost track, too

#746 and #747 too.

but the numbers sound realistic

Link Mauve, we started votes on those already

Oh.

#752 was vetoed already.

Link Mauve, Both those have been voted on and passed/expired at this point.

By Dave and me.

Ge0rG, Good spot, it has indeed.

So #758 and #760.

So with that:

3) Items for a Vote:

a) https://github.com/xsf/xeps/pull/758

(XEP-0060: Expose pubsub#access_model and pubsub#publish_model)

+1 I think

I’m +1 on this one, it does enable very valid usecases.

AFAICT this is still optional so existing services aren’t suddenly non-compliant

Indeed.

It just adds two new fields, without any description?

Yes, this looks straightforward and painless. +1.

Ge0rG, there is a very short description in the second chunk, in the @label.

Ge0rG, No, it updates the registration and includes a short description.

Ge0rG, I'd argue the description is long enough given the values involved.

The description is non-normative, i.e. there is no requirement to fill the fields with [open, presence, roster, authorize, and whitelist] - right?

so pubsub#access_model=dwd would be valid.

Ge0rG, Do you think implementors need to be told that?

Ge0rG, I mean, you could argue it has to be a valid access mode, but people have invented new ones of those before.

BuddyCloud?

Link Mauve, I wasn't going to name names.

Link Mauve, But yes.

Heh. :)

dwd: I'm not sure. I'm seeing a particular XMPP client library that will throw class cast exceptions on unknown field values.

Ge0rG, Really? That seems like a bug.

Ge0rG, that’s the libraries problem.

anyway, just trying to understand this.

Ge0rG, I know more than one, is this much of an issue?

+0

OK.

b) https://github.com/xsf/xeps/pull/760

(XEP-0045: Add avatar support using XEP-0084)

I’m obviously +1, ask me anything.

(re #758) I'd be 1 happier if it would explicitly reference what values are allowed.

is 0084 one of the Avatar XEPs that we want to retain long-term?

wut? another avatar method for muc?

Ge0rG, I’m firmly against that. It could state explicitly that it’s about the access/publish model, but listing the allowed values should be done where that is defined (and given that additional XEPs may easily define new models, I don’t see why that’s valuable to have)

Ge0rG, yes, it is this one.

Ge0rG, Veto it if you want to require your own happiness.

zinid, Avatars for the MUC itself.

jonas’: this is why I wrote "reference" and not "list"

zinid, the previous council rejected the XEP-0153-based one I proposed, this one is based on a long-term PEP-only solution.

dwd: it's already imlemented using vcards

re 760: LGTM on first glance, is there a deployment for that version already?

jonas’, NAFAIK.

Well, there is a Prosody module that hasn’t been published yet.

sigh

can you just mix mod_profile (or whatever the new vcard<->pubsub conversion module is) on a prosody muc? :>

Link Mauve, Isn't this one adding a Pubsub service to MUC rooms?

dwd, yes, that’s what it does.

zinid, As in directly on the vCard?

zinid, Ugh. As in, a vCard directly on the MUC?

dwd, yes

dwd, ejabberd, conversations, gajim and dino support it already

and we're now rolling another one?

dwd, https://docs.ejabberd.im/tutorials/muc-vcard/ describes how it works.

also, full blown pep node on muc?

zinid, Yeah, I hear you.

This was what I tried to standardise back in August, but council rejected it with (imo) valid reasons.

Link Mauve, wasn’t the main reason "put it in '45, we don’t want many avatar XEPs"?

so you could’ve technically put the '153 based solution into '45?

jonas’, indeed, but at the same time it’d be much nicer to stop having to implement so many avatar methods.

yeah, that’s true, t oo

Basing it on 0084 we can then deprecate both 0054 and 0153 (finally!).

Link Mauve, I wonder if it’d help if your patches make clear that no full pub-sub service is expected, but merely exactly the use-cases outlined there

so that you don’t have to implement full-blown pubsub on a MUC, instead you can simply do stuff with pubsubby wireformat

(I was the one who vetoed the deprecation of 0153 a few years ago, because of the MUC avatar usecase.)

Right. I'm going to veto this one because I think squeezing Pubsub/PEP into a MUC room needs a lot more than just a quick vote by Council - I'd like to see considerable discussion on the list from implementors first.

jonas’, I could do that yeah.

is this PEP or PubSub?

Ge0rG, PEP is a subset of PubSub on a user JID, this one is just borrowing the PubSub elements required for 0084 on a MUC.

dwd, that sounds like a reasonable course of action

dwd, sounds sensible, thanks.

Link Mauve: this is not an answer to my question ;)

Ge0rG, this isn’t PEP.

This is another PubSub profile.

or maybe my question is badly worded: is this the same subset of pubsub as PEP, but on a MUC JID instead of an account JID?

Ge0rG, no, it requires different features (mostly way fewer, but also persistency) from PEP.

OK.

4) Voting Catch-Up

Ge0rG: Same basic concept I guess. PubSub service on the MUC JID.

I’m also -1 for list discussion. At the very least, this should clearly spell out which subset of '60 is required.

(re #3) I’ll raise that on the list.

-1 and agreed to the call to list discussion.

yeah, this one was a surprise for me, that's why I'm chiming in, sorry

There's two outstanding votes at the moment, both from zinid's ProtoXEPs.

zinid, comments from the floor are always appreciated.

Voting Catch-Up: XMPP Over Reload: +1; I still don’t know a lot about reload, but I don’t see anything which should be blocking from moving to Experimental

zinid, FWIW, comments from the floor are always welcome. I'll soon tell you if they're not.

okay

xor: +1 if I weren’t already (latest voting summary says I was still waiting for the next version).

I'm +1 on both of these. I'm not sure if they'll go anywhere, to be honest, but I see no reason to block them.

I was already +1 on EAX and still am

eax: also +1.

the current XOR is the old XOR with the XSF-CA removed, right?

Ge0rG, yes

Ge0rG, pretty much that

and with a few typos removed

+1 to XOR

Ge0rG, and I removed your glitch about MUST

Link Mauve: where is the NOP XEP?

Ge0rG, waiting to be submitted as a ProtoXEP. :D

5) AOB

Nobody?

There was an LC on Compliance Suite 2019

yeah........ editor’s fault I guess

And I'd like to bring up the one specific use of XEP-0066 to indicate inline images for CS-2019.

Because we want the CS to reflect current best practices, right?

And https://xmpp.org/extensions/xep-0066.html#x-oob is non-obvious to new implementors from the outside.

OK - assuming the LC is complete can we get that on the agenda for next week?

And speaking of next week:

6) Next Meeting

+1W WFM

+1

Good stuff.

7) Ite, Meetign Est

Thanks all.

Thanks. :)

> I'm not sure if they'll go anywhere, to be honest I'm going to implement RELOAD in ejabberd, as soon as it's deployed, XMPP clients may use it as a global storage (for storing telephone numbers, etc). Note that RELOAD defines "nodes" (complex stuff) and "client" (simple stuff), an XMPP client may only implement "client" functionality, it's quite simple, you don't need to join Chord DHT, only to parse RELOAD packets and support DTLS.

so it's not that scary as it might be seen

but again, this depends on global CAs, so, a lot of people to convince, hehe

zinid: re EAX: §3.1 references two rather complex related works, would it be possible to explicitly list all those requirements in §3.1 so one doesn't need to parse the other docs as well?

Ge0rG, just a second, I will look at 3.1

"General requirements"

ah

Could someone set a proper name and description in this rooms config?

well, the first is well understood I guess, so only bullet 2 requires explanation?

Ge0rG, ?

zinid: I'd prefer to have a summary of both, so that as a reader I can see whether it is common sense or whether I need to invest some hours hunting down the rabbit hole

non-normative summary would be ok

mv this_discussion xsf@?

Ge0rG, well, the point is that the following 3.2 section explains what to do to fullfill the requirements

I will probably just rephrase it

it is like in other places of XMPP. You read something harmless like "MUST conform to PRECIS profile XY" and then you end up spending half a day following unicode mapping tables

Ge0rG, 3.1 directly follows from 3.2

zinid: ah, from reading the protoXEP I would have assumed that 3.1 is _in addition to_ 3.2

Ge0rG, yes, I agree it's confusing, I'll rephrase it

zinid: maybe you should define certificate profiles, so that I can use EAX for XMPP auth without fulfilling "SubjectAltName field in the certificate MUST contain a single RELOAD URI"

Ge0rG, RELOAD URI is used as a device identifier

otherwise I need to invent another field

i.e. "For the purpose of using a certificate in RELOAD, the certificate MUST fulfil the criteria of RFC6940"

> Even if XOR extension (XEP-XOR) is unused, the RELOAD URI uniquely identifies a user device: a user MAY have several certificates assigned to their XMPP address but with different RELOAD URIs.

it will be hard enough to get an xmpp cert signed by a public CA :>

"Ge0rG> Because we want the CS to reflect current best practices, right?" re oob, you mean the current ~~best~~ practices

Ge0rG, I think no public CA will sign you certs with XmppAddr, I might be wrong though

how will it validate it?

zinid: I think so too. But then again, you can get a cert for 192.168.1.1 from a public CA, so I wouldn't bet any money on it.

pep.: something doesn't need to be good to be best.

Ge0rG, so, if it signs with XmppAddr, then why some uri (reload in our case) should be a problem?

And you're happy to just recommend The Conversations Protocol when there are actually extensions doing what this is trying to do?

pep.: I'm not happy. I'm merely giving in to pressure from the most-widely-deployed peer-group client.

Well don't, please

Ge0rG, okay, I will add SHOULD there

zinid: I'm just trying to understand.

and regarding 192.168.1.1, do you mean that recent DigiCert's fuckup?

As I read EAX, I wonder if it is actually useful for other use cases than RELOAD

zinid: yeah, that

Ge0rG, yes, it's absolutely useful, nothing prevents you from using it in c2s sasl external

or in any other place where you need to identify a peer by JID

zinid: but I don't need all the RELOAD stuff for c2s SASL

Ge0rG, that's true, so I agreed to add SHOULD for RELOAD URI

and regarding forming the profile, well, I don't know how to formally do that

need a lot of stupid readings again

zinid: I'd suggest to split §3.2 into multiple sections, where each section describes the requirements for a given e2e use case.

do we want to hardcode the use cases? I'm not sure

as I understand EAX, it is first a description of the possible CA tree structures, and then the formal requirements when checking a certificate.

yes

and certs discovery

Right. ✏

Ge0rG, won't we run into situation when users end up with multiple certs for incompatible use cases?

I don't see problems in RELOAD URI, it's reload://2342348230948023984@xmpp.org

ralphm: Could you set a name and description in this rooms config so that http://logs.xmpp.org/ looks nicer?

Ge0rG, > The CA MUST generate a cryptographically random 128-bit integer each time it issues a leaf certificate for a new user device. This integer MUST be a part of the RELOAD URI and MUST be included in the certificate as specified under Section 3.2 of XEP-EAX.

Ge0rG, it's too complex or what? 😀

Zash: nicer how?

zinid: that sounds like a cert serial, except it's now also semantically bound to an obscure P2P network

ralphm: I don't see any change

ralphm, also here https://search.jabber.network/search?q=council

jonas’: that doesn't look bad if you don't have a well-defined reference MUC

that’s true

https://search.jabber.network/search?q=muc.xmpp.org

also having the search results below the fold is really unfortunate

Zash, jonas’: I don't understand what you are asking?

ralphm: configure the disco#info name and description parameters of this room :)

Oh, I thought you were talking about the room topic

ralphm: Configuration dialog for the room itself.

Do you want the description to match the topic, or something else?

zinid: not complex, just maybe unneeded for the majority of use cases.

Ge0rG, > that sounds like a cert serial right, okay. I said I can do it SHOULD, but I'm not sure we need to hardcode usecases

zinid: we need to hardcode the verification requirements, and those are different per use case

ralphm: Some description of the purpose of the room. "Room where the council holts its meetings" or something.

ah right

zinid: for e2ee I only care about xmppAddr. No, wait. About srvId xmpp? Is that a thing for clients?

name="XSF Council Room" would probably be appropriate

ralphm: It is a bit funny how we have these 3 different fields :)

Zash: and how these fields have even more different names.

Ge0rG, so far I can only split it into e2ee/c2s-sasl-externa with XmppAddr and RELOAD use case with RELOAD URI

Ge0rG, still, all those cases are documented in the corresponding documents

ralphm: Thanks!

No worries

Ge0rG: I'm saying that btw because I am currently in your shoes re omemo.

nice, you also set the language :)

The field 'confusion' is one of the reasons why MIX doesn't define a room topic

ralphm: but MIX was promised to have sticky messages.

jonas’: yup

I poked muclumbus to make it up-to-date there too

Ge0rG: there's a note to that effect. I'm not sure if it counts as a promise but rather as one way it could be done.

Ge0rG, whatever, I need to go now to my family, we can discuss this later today

There's much to be said about having both a room description and a topic.

zinid: thanks

ralphm, "about", or "for"?

Damn, this room is sorted under X now.

dwd: I see a room name and description is more or less constant over time, whereas the topic would be something that changes depending on current affairs. Like how I change the topic of the xsf room during Board meetings.

Also different target audience. Room name and description would be for people outside of the room. Topic is for people in the room.

ralphm: that doesn't give a rationale for having a description.

There is also some significant overlap between these fields in most rooms

Name: Test room Description: Room for testing

Every test MUC I ever create ^

This has now really become off topic

Ge0rG: so me giving my view on things doesn't count as a rationale?

ralphm: that's not what I meant. Something being constant over time is not a rationale.

..not for having it at least.

A description of the room for people who aren't in it seems a sensible thing to have.

Indeed

And yes, things might be overlapping and not consistent across rooms, partly caused by diverging client UIs and probably mostly because of, well, people.

People. The largest problem XMPP faces.

I agree that having that description for other people thing is useful indeed.

There's also this innate desire by software developers for things to nicely align with definitions and try and find solutions for things that are better solved by social conventions or interactions.

(technical solutions)

ralphm: yeah, we can make people sane if we only make the input boxes strict enough!

Did I mention Bookmark Names yet?

Naming things...

It doesn't help very much to have those names default to the localpart of the room

Defaulting to the room name, if set, seems sensible.

which defaults to the localpart.

Daniel brought up the question on how to discriminate between a default-value of localpart and a manually set value that just happens to equal localpart.

I don't know, I'm pretty with having room identifiers separate from room name and description and topic. I'm not sure if it must be the localpart, though. Being able to refer to such a more or less stable (but possibly mutable) short name seems great.

Like in Slack, I suppose.

ralphm: in impromptu MUCs you end up with a random base32 localpart that's not very human-friendly, so you'll want to hide that everywhere.

Section 4.7.4 in XEP-0369 seems to conflate the room name and such a short identifier in the Name field. Meh.

Right

in Slack you are referencing to "that chat with peter and anne" and not to 5aaheds7@muc.xmpp.org as well.

identifier, short name, long name, short description, long description, short subject, long subject, ...

well, Slack rooms don't have a JID obviously. But some other kind of ID.

Yeah, I was talking about explicitly created rooms in Slack.

Zash: you forgot about i18n

I have a love-hate relationship with 'rooms with multiple people as done in Slack'

Ge0rG: That's where I draw the line

and leave, to find something to eat

Also probably this is more a topic for xsf@

Dinner, too.

as in me having it

Why do board hold meetings in xsf@ but not council ?

Zash, History.

Zash, As a very loose version, Council always held meetings in an open room designated for the purpose, whereas Board held meetings in camera (ie, in a closed room). When Board decided to hold meetings openly instead, we/they decided to keep the existing Board room closed and held the meetings in XSF@ hoping to gain some interest and involvement.