jonas’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.
zinidjonas’, seems like there is no agenda anyway
ralphmhas left
Neustradamushas left
Neustradamushas joined
jonas’okay, meeting’s over, depending on traffic I’m either on time or ~10min late✎
jonas’okay, meeting’s over, depending on traffic I’m somewhere between on time or ~10min late ✏
lnjhas joined
vanitasvitaehas left
vanitasvitaehas joined
Ge0rGhas joined
Ge0rGGood morning everyone!
ralphmhas joined
jonas’.
olihas left
Link Mauve’morning, I’m here. o/
dwdI'm here too.
jonas’we have TrueDWD
dwdIn the interests of security, I suggest we conduct the meeting in Double-ROT13.
dwdSo, I failed to get an agenda together, but I think we have some ProtoXEPs or something don't we?
jonas’no protoxeps I’m aware of
Link Mauvezinid’s.
jonas’didn’t we discuss those already?
Ge0rGMore than the three ones that expired(?)?
Link MauveWe mostly already voted on them though, this is just a reminder that on list people should vote.
jonas’that’s true
Link MauveGe0rG, two for us, and one for board.
jonas’dwd, there are a bunch of [Needs Council] PRs though
jonas’this one for example: https://github.com/xsf/xeps/pull/760
dwdOh, lots.
jonas’yeah, many of them have already started votes
zinidI think today is the last day to vote on my xeps BTW
jonas’zinid, yes
zinidaccording to Tedd sterr
dwdzinid, Yes, sorry for the delay on my part.
dwdjonas’, So I see #752, #758, and #760 to vote on?
jonas’maybe
jonas’I lost track, too
Link Mauve#746 and #747 too.
jonas’but the numbers sound realistic
jonas’Link Mauve, we started votes on those already
Link MauveOh.
Ge0rG#752 was vetoed already.
dwdLink Mauve, Both those have been voted on and passed/expired at this point.
Ge0rGBy Dave and me.
dwdGe0rG, Good spot, it has indeed.
dwdSo #758 and #760.
dwdSo with that:
dwd3) Items for a Vote:
dwda) https://github.com/xsf/xeps/pull/758
dwd(XEP-0060: Expose pubsub#access_model and pubsub#publish_model)
jonas’+1 I think
Link MauveI’m +1 on this one, it does enable very valid usecases.
jonas’AFAICT this is still optional so existing services aren’t suddenly non-compliant
Link MauveIndeed.
Ge0rGIt just adds two new fields, without any description?
dwdYes, this looks straightforward and painless. +1.
Link MauveGe0rG, there is a very short description in the second chunk, in the @label.
dwdGe0rG, No, it updates the registration and includes a short description.
dwdGe0rG, I'd argue the description is long enough given the values involved.
Ge0rGThe description is non-normative, i.e. there is no requirement to fill the fields with [open, presence, roster, authorize, and whitelist] - right?
Ge0rGso pubsub#access_model=dwd would be valid.
dwdGe0rG, Do you think implementors need to be told that?
dwdGe0rG, I mean, you could argue it has to be a valid access mode, but people have invented new ones of those before.
Link MauveBuddyCloud?
dwdLink Mauve, I wasn't going to name names.
dwdLink Mauve, But yes.
Link MauveHeh. :)
Ge0rGdwd: I'm not sure. I'm seeing a particular XMPP client library that will throw class cast exceptions on unknown field values.
dwdGe0rG, Really? That seems like a bug.
jonas’Ge0rG, that’s the libraries problem.
Ge0rGanyway, just trying to understand this.
Link MauveGe0rG, I know more than one, is this much of an issue?
Ge0rG+0
dwdOK.
dwdb) https://github.com/xsf/xeps/pull/760
dwd(XEP-0045: Add avatar support using XEP-0084)
Link MauveI’m obviously +1, ask me anything.
Ge0rG(re #758) I'd be 1 happier if it would explicitly reference what values are allowed.
Ge0rGis 0084 one of the Avatar XEPs that we want to retain long-term?
zinidwut? another avatar method for muc?
jonas’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)
Link MauveGe0rG, yes, it is this one.
dwdGe0rG, Veto it if you want to require your own happiness.
dwdzinid, Avatars for the MUC itself.
Ge0rGjonas’: this is why I wrote "reference" and not "list"
Link Mauvezinid, the previous council rejected the XEP-0153-based one I proposed, this one is based on a long-term PEP-only solution.
ziniddwd: it's already imlemented using vcards
jonas’re 760: LGTM on first glance, is there a deployment for that version already?
Link Mauvejonas’, NAFAIK.
Link MauveWell, there is a Prosody module that hasn’t been published yet.
zinidsigh
jonas’can you just mix mod_profile (or whatever the new vcard<->pubsub conversion module is) on a prosody muc? :>
dwdLink Mauve, Isn't this one adding a Pubsub service to MUC rooms?
Link Mauvedwd, yes, that’s what it does.
dwdzinid, As in directly on the vCard?
dwdzinid, Ugh. As in, a vCard directly on the MUC?
ziniddwd, yes
ziniddwd, ejabberd, conversations, gajim and dino support it already
zinidand we're now rolling another one?
Link Mauvedwd, https://docs.ejabberd.im/tutorials/muc-vcard/ describes how it works.
zinidalso, full blown pep node on muc?
dwdzinid, Yeah, I hear you.
Link MauveThis was what I tried to standardise back in August, but council rejected it with (imo) valid reasons.
jonas’Link Mauve, wasn’t the main reason "put it in '45, we don’t want many avatar XEPs"?
jonas’so you could’ve technically put the '153 based solution into '45?
Link Mauvejonas’, indeed, but at the same time it’d be much nicer to stop having to implement so many avatar methods.
jonas’yeah, that’s true, t oo
Link MauveBasing it on 0084 we can then deprecate both 0054 and 0153 (finally!).
jonas’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
jonas’so that you don’t have to implement full-blown pubsub on a MUC, instead you can simply do stuff with pubsubby wireformat
Link Mauve(I was the one who vetoed the deprecation of 0153 a few years ago, because of the MUC avatar usecase.)
dwdRight. 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.
Link Mauvejonas’, I could do that yeah.
Ge0rGis this PEP or PubSub?
Link MauveGe0rG, PEP is a subset of PubSub on a user JID, this one is just borrowing the PubSub elements required for 0084 on a MUC.
jonas’dwd, that sounds like a reasonable course of action
Link Mauvedwd, sounds sensible, thanks.
Ge0rGLink Mauve: this is not an answer to my question ;)
Link MauveGe0rG, this isn’t PEP.
Link MauveThis is another PubSub profile.
Ge0rGor 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?
Link MauveGe0rG, no, it requires different features (mostly way fewer, but also persistency) from PEP.
dwdOK.
dwd4) Voting Catch-Up
ZashGe0rG: Same basic concept I guess. PubSub service on the MUC JID.
jonas’I’m also -1 for list discussion. At the very least, this should clearly spell out which subset of '60 is required.
Link Mauve(re #3) I’ll raise that on the list.
Ge0rG-1 and agreed to the call to list discussion.
zinidyeah, this one was a surprise for me, that's why I'm chiming in, sorry
dwdThere's two outstanding votes at the moment, both from zinid's ProtoXEPs.
jonas’zinid, comments from the floor are always appreciated.
vanitasvitaehas left
Ge0rGis guilty.
jonas’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
vanitasvitaehas joined
dwdzinid, FWIW, comments from the floor are always welcome. I'll soon tell you if they're not.
zinidokay
Link Mauvexor: +1 if I weren’t already (latest voting summary says I was still waiting for the next version).
dwdI'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.
jonas’I was already +1 on EAX and still am
Link Mauveeax: also +1.
Link Mauvewants more x86 short names. :3
Ge0rGthe current XOR is the old XOR with the XSF-CA removed, right?
zinidGe0rG, yes
jonas’Ge0rG, pretty much that
zinidand with a few typos removed
Ge0rG+1 to XOR
zinidGe0rG, and I removed your glitch about MUST
Ge0rGLink Mauve: where is the NOP XEP?
Link MauveGe0rG, waiting to be submitted as a ProtoXEP. :D
dwd5) AOB
dwdNobody?
Ge0rGThere was an LC on Compliance Suite 2019
jonas’yeah........ editor’s fault I guess
Ge0rGAnd I'd like to bring up the one specific use of XEP-0066 to indicate inline images for CS-2019.
Ge0rGBecause we want the CS to reflect current best practices, right?
Ge0rGAnd https://xmpp.org/extensions/xep-0066.html#x-oob is non-obvious to new implementors from the outside.
dwdOK - assuming the LC is complete can we get that on the agenda for next week?
dwdAnd speaking of next week:
dwd6) Next Meeting
Ge0rG+1W WFM
jonas’+1
dwdGood stuff.
dwd7) Ite, Meetign Est
dwdThanks all.
Link MauveThanks. :)
zinid> 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.
zinidso it's not that scary as it might be seen
zinidbut again, this depends on global CAs, so, a lot of people to convince, hehe
Ge0rGzinid: 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?
zinidGe0rG, just a second, I will look at 3.1
Ge0rG"General requirements"
zinidah
ZashCould someone set a proper name and description in this rooms config?
zinidwell, the first is well understood I guess, so only bullet 2 requires explanation?
zinidGe0rG, ?
Ge0rGzinid: 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
Ge0rGnon-normative summary would be ok
jonas’mv this_discussion xsf@?
zinidGe0rG, well, the point is that the following 3.2 section explains what to do to fullfill the requirements
zinidI will probably just rephrase it
Ge0rGit 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
zinidGe0rG, 3.1 directly follows from 3.2
Ge0rGzinid: ah, from reading the protoXEP I would have assumed that 3.1 is _in addition to_ 3.2
zinidGe0rG, yes, I agree it's confusing, I'll rephrase it
Ge0rGzinid: 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"
zinidGe0rG, RELOAD URI is used as a device identifier
zinidotherwise I need to invent another field
Ge0rGi.e. "For the purpose of using a certificate in RELOAD, the certificate MUST fulfil the criteria of RFC6940"
zinid> 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.
Ge0rGit will be hard enough to get an xmpp cert signed by a public CA :>
pep."Ge0rG> Because we want the CS to reflect current best practices, right?" re oob, you mean the current ~~best~~ practices
zinidGe0rG, I think no public CA will sign you certs with XmppAddr, I might be wrong though
zinidhow will it validate it?
Ge0rGzinid: 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.
Ge0rGpep.: something doesn't need to be good to be best.
zinidGe0rG, so, if it signs with XmppAddr, then why some uri (reload in our case) should be a problem?
pep.And you're happy to just recommend The Conversations Protocol when there are actually extensions doing what this is trying to do?
Ge0rGpep.: I'm not happy. I'm merely giving in to pressure from the most-widely-deployed peer-group client.
pep.Well don't, please
zinidGe0rG, okay, I will add SHOULD there
Ge0rGzinid: I'm just trying to understand.
zinidand regarding 192.168.1.1, do you mean that recent DigiCert's fuckup?
Ge0rGAs I read EAX, I wonder if it is actually useful for other use cases than RELOAD
Ge0rGzinid: yeah, that
zinidGe0rG, yes, it's absolutely useful, nothing prevents you from using it in c2s sasl external
zinidor in any other place where you need to identify a peer by JID
Ge0rGzinid: but I don't need all the RELOAD stuff for c2s SASL
zinidGe0rG, that's true, so I agreed to add SHOULD for RELOAD URI
zinidand regarding forming the profile, well, I don't know how to formally do that
zinidneed a lot of stupid readings again
Ge0rGzinid: I'd suggest to split §3.2 into multiple sections, where each section describes the requirements for a given e2e use case.
ziniddo we want to hardcode the use cases? I'm not sure
Ge0rGas I understand EAX, it is first a description of the possible CA tree structures, and then the formal requirements when checking a certificate.
zinidGe0rG, won't we run into situation when users end up with multiple certs for incompatible use cases?
zinidI don't see problems in RELOAD URI, it's reload://2342348230948023984@xmpp.org
Zashralphm: Could you set a name and description in this rooms config so that http://logs.xmpp.org/ looks nicer?
ralphmclicks
zinidGe0rG,
> 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.
zinidGe0rG, it's too complex or what? 😀
ralphmZash: nicer how?
Ge0rGzinid: that sounds like a cert serial, except it's now also semantically bound to an obscure P2P network
Zashralphm: I don't see any change
jonas’ralphm, also here https://search.jabber.network/search?q=council
Ge0rGjonas’: that doesn't look bad if you don't have a well-defined reference MUC
Ge0rGalso having the search results below the fold is really unfortunate
ralphmZash, jonas’: I don't understand what you are asking?
Ge0rGralphm: configure the disco#info name and description parameters of this room :)
ralphmOh, I thought you were talking about the room topic
Zashralphm: Configuration dialog for the room itself.
ralphmDo you want the description to match the topic, or something else?
Ge0rGzinid: not complex, just maybe unneeded for the majority of use cases.
zinidGe0rG,
> 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
Ge0rGzinid: we need to hardcode the verification requirements, and those are different per use case
Zashralphm: Some description of the purpose of the room. "Room where the council holts its meetings" or something.
ralphmah right
Ge0rGzinid: for e2ee I only care about xmppAddr. No, wait. About srvId xmpp? Is that a thing for clients?
Ge0rGname="XSF Council Room" would probably be appropriate
Zashralphm: It is a bit funny how we have these 3 different fields :)
Ge0rGZash: and how these fields have even more different names.
zinidGe0rG, so far I can only split it into e2ee/c2s-sasl-externa with XmppAddr and RELOAD use case with RELOAD URI
zinidGe0rG, still, all those cases are documented in the corresponding documents
Zashralphm: Thanks!
ralphmNo worries
pep.Ge0rG: I'm saying that btw because I am currently in your shoes re omemo.
jonas’nice, you also set the language :)
ralphmThe field 'confusion' is one of the reasons why MIX doesn't define a room topic
Ge0rGralphm: but MIX was promised to have sticky messages.
ralphmjonas’: yup
jonas’I poked muclumbus to make it up-to-date there too
ralphmGe0rG: 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.
zinidGe0rG, whatever, I need to go now to my family, we can discuss this later today
ralphmThere's much to be said about having both a room description and a topic.
Ge0rGzinid: thanks
dwdralphm, "about", or "for"?
Ge0rGDamn, this room is sorted under X now.
ralphmdwd: 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.
ZashAlso different target audience. Room name and description would be for people outside of the room. Topic is for people in the room.
Ge0rGralphm: that doesn't give a rationale for having a description.
Ge0rGThere is also some significant overlap between these fields in most rooms
ZashName: Test room
Description: Room for testing
ZashEvery test MUC I ever create ^
Ge0rGThis has now really become off topic
ralphmGe0rG: so me giving my view on things doesn't count as a rationale?
Ge0rGralphm: that's not what I meant. Something being constant over time is not a rationale.
Ge0rG..not for having it at least.
ZashA description of the room for people who aren't in it seems a sensible thing to have.
ralphmIndeed
ralphmAnd yes, things might be overlapping and not consistent across rooms, partly caused by diverging client UIs and probably mostly because of, well, people.
Ge0rGPeople. The largest problem XMPP faces.
Ge0rGI agree that having that description for other people thing is useful indeed.
ralphmThere'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.
ralphm(technical solutions)
Ge0rGralphm: yeah, we can make people sane if we only make the input boxes strict enough!
Ge0rGDid I mention Bookmark Names yet?
ZashNaming things...
Ge0rGIt doesn't help very much to have those names default to the localpart of the room
ZashDefaulting to the room name, if set, seems sensible.
Ge0rGwhich defaults to the localpart.
Ge0rGDaniel 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.
ralphmI 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.
ralphmLike in Slack, I suppose.
Ge0rGralphm: 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.
ralphmSection 4.7.4 in XEP-0369 seems to conflate the room name and such a short identifier in the Name field. Meh.
ralphmRight
Ge0rGin Slack you are referencing to "that chat with peter and anne" and not to 5aaheds7@muc.xmpp.org as well.
Zashidentifier, short name, long name, short description, long description, short subject, long subject, ...
Ge0rGwell, Slack rooms don't have a JID obviously. But some other kind of ID.
ralphmYeah, I was talking about explicitly created rooms in Slack.
Ge0rGZash: you forgot about i18n
ralphmI have a love-hate relationship with 'rooms with multiple people as done in Slack'
ZashGe0rG: That's where I draw the line
Zashand leave, to find something to eat
ralphmAlso probably this is more a topic for xsf@
ralphmDinner, too.
ralphmas in me having it
ZashWhy do board hold meetings in xsf@ but not council ?
dwdZash, History.
dwdZash, 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.