- vanitasvitae has left
- vanitasvitae has joined
- oli has left
- lnj has joined
- lnj has left
- oli has joined
- oli has left
- ralphm has joined
- oli has joined
-
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.
-
zinid
jonas’, seems like there is no agenda anyway
- ralphm has left
- Neustradamus has left
- Neustradamus has 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 ✏
- lnj has joined
- vanitasvitae has left
- vanitasvitae has joined
- Ge0rG has joined
-
Ge0rG
Good morning everyone!
- ralphm has joined
-
jonas’
.
- oli has left
-
Link Mauve
’morning, I’m here. o/
-
dwd
I'm here too.
-
jonas’
we have TrueDWD
-
dwd
In the interests of security, I suggest we conduct the meeting in Double-ROT13.
-
jonas’
<proceed xmlns="urn:dwd:xmpp:double-rot13"/>
-
dwd
OK, let's go.
-
Ge0rG
https://www.schneier.com/blog/archives/2015/11/paris_terrorist.html
-
dwd
1) Role Call?
- jonas’
- Ge0rG
- Ge0rG is very unprepared.
-
Link Mauve
/me✎ - Link Mauve same.
-
dwd
Kev said he'd be missing this one, didn't he?
-
jonas’
yes
-
dwd
Righty.
-
dwd
2) Agenda Bashing
-
dwd
So, 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 Mauve
zinid’s.
-
jonas’
didn’t we discuss those already?
-
Ge0rG
More than the three ones that expired(?)?
-
Link Mauve
We mostly already voted on them though, this is just a reminder that on list people should vote.
-
jonas’
that’s true
-
Link Mauve
Ge0rG, 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
-
dwd
Oh, lots.
-
jonas’
yeah, many of them have already started votes
-
zinid
I think today is the last day to vote on my xeps BTW
-
jonas’
zinid, yes
-
zinid
according to Tedd sterr
-
dwd
zinid, Yes, sorry for the delay on my part.
-
dwd
jonas’, 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 Mauve
Oh.
-
Ge0rG
#752 was vetoed already.
-
dwd
Link Mauve, Both those have been voted on and passed/expired at this point.
-
Ge0rG
By Dave and me.
-
dwd
Ge0rG, Good spot, it has indeed.
-
dwd
So #758 and #760.
-
dwd
So with that:
-
dwd
3) Items for a Vote:
-
dwd
a) https://github.com/xsf/xeps/pull/758
-
dwd
(XEP-0060: Expose pubsub#access_model and pubsub#publish_model)
-
jonas’
+1 I think
-
Link Mauve
I’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 Mauve
Indeed.
-
Ge0rG
It just adds two new fields, without any description?
-
dwd
Yes, this looks straightforward and painless. +1.
-
Link Mauve
Ge0rG, there is a very short description in the second chunk, in the @label.
-
dwd
Ge0rG, No, it updates the registration and includes a short description.
-
dwd
Ge0rG, I'd argue the description is long enough given the values involved.
-
Ge0rG
The description is non-normative, i.e. there is no requirement to fill the fields with [open, presence, roster, authorize, and whitelist] - right?
-
Ge0rG
so pubsub#access_model=dwd would be valid.
-
dwd
Ge0rG, Do you think implementors need to be told that?
-
dwd
Ge0rG, I mean, you could argue it has to be a valid access mode, but people have invented new ones of those before.
-
Link Mauve
BuddyCloud?
-
dwd
Link Mauve, I wasn't going to name names.
-
dwd
Link Mauve, But yes.
-
Link Mauve
Heh. :)
-
Ge0rG
dwd: I'm not sure. I'm seeing a particular XMPP client library that will throw class cast exceptions on unknown field values.
-
dwd
Ge0rG, Really? That seems like a bug.
-
jonas’
Ge0rG, that’s the libraries problem.
-
Ge0rG
anyway, just trying to understand this.
-
Link Mauve
Ge0rG, I know more than one, is this much of an issue?
-
Ge0rG
+0
-
dwd
OK.
-
dwd
b) https://github.com/xsf/xeps/pull/760
-
dwd
(XEP-0045: Add avatar support using XEP-0084)
-
Link Mauve
I’m obviously +1, ask me anything.
-
Ge0rG
(re #758) I'd be 1 happier if it would explicitly reference what values are allowed.
-
Ge0rG
is 0084 one of the Avatar XEPs that we want to retain long-term?
-
zinid
wut? 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 Mauve
Ge0rG, yes, it is this one.
-
dwd
Ge0rG, Veto it if you want to require your own happiness.
-
dwd
zinid, Avatars for the MUC itself.
-
Ge0rG
jonas’: this is why I wrote "reference" and not "list"
-
Link Mauve
zinid, the previous council rejected the XEP-0153-based one I proposed, this one is based on a long-term PEP-only solution.
-
zinid
dwd: it's already imlemented using vcards
-
jonas’
re 760: LGTM on first glance, is there a deployment for that version already?
-
Link Mauve
jonas’, NAFAIK.
-
Link Mauve
Well, there is a Prosody module that hasn’t been published yet.
-
zinid
sigh
-
jonas’
can you just mix mod_profile (or whatever the new vcard<->pubsub conversion module is) on a prosody muc? :>
-
dwd
Link Mauve, Isn't this one adding a Pubsub service to MUC rooms?
-
Link Mauve
dwd, yes, that’s what it does.
-
dwd
zinid, As in directly on the vCard?
-
dwd
zinid, Ugh. As in, a vCard directly on the MUC?
-
zinid
dwd, yes
-
zinid
dwd, ejabberd, conversations, gajim and dino support it already
-
zinid
and we're now rolling another one?
-
Link Mauve
dwd, https://docs.ejabberd.im/tutorials/muc-vcard/ describes how it works.
-
zinid
also, full blown pep node on muc?
-
dwd
zinid, Yeah, I hear you.
-
Link Mauve
This 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 Mauve
jonas’, 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 Mauve
Basing 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.)
-
dwd
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.
-
Link Mauve
jonas’, I could do that yeah.
-
Ge0rG
is this PEP or PubSub?
-
Link Mauve
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.
-
jonas’
dwd, that sounds like a reasonable course of action
-
Link Mauve
dwd, sounds sensible, thanks.
-
Ge0rG
Link Mauve: this is not an answer to my question ;)
-
Link Mauve
Ge0rG, this isn’t PEP.
-
Link Mauve
This is another PubSub profile.
-
Ge0rG
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?
-
Link Mauve
Ge0rG, no, it requires different features (mostly way fewer, but also persistency) from PEP.
-
dwd
OK.
-
dwd
4) Voting Catch-Up
-
Zash
Ge0rG: 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.
-
zinid
yeah, this one was a surprise for me, that's why I'm chiming in, sorry
-
dwd
There's two outstanding votes at the moment, both from zinid's ProtoXEPs.
-
jonas’
zinid, comments from the floor are always appreciated.
- vanitasvitae has left
- Ge0rG is 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
- vanitasvitae has joined
-
dwd
zinid, FWIW, comments from the floor are always welcome. I'll soon tell you if they're not.
-
zinid
okay
-
Link Mauve
xor: +1 if I weren’t already (latest voting summary says I was still waiting for the next version).
-
dwd
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.
-
jonas’
I was already +1 on EAX and still am
-
Link Mauve
eax: also +1.
- Link Mauve wants more x86 short names. :3
-
Ge0rG
the current XOR is the old XOR with the XSF-CA removed, right?
-
zinid
Ge0rG, yes
-
jonas’
Ge0rG, pretty much that
-
zinid
and with a few typos removed
-
Ge0rG
+1 to XOR
-
zinid
Ge0rG, and I removed your glitch about MUST
-
Ge0rG
Link Mauve: where is the NOP XEP?
-
Link Mauve
Ge0rG, waiting to be submitted as a ProtoXEP. :D
-
dwd
5) AOB
-
dwd
Nobody?
-
Ge0rG
There was an LC on Compliance Suite 2019
-
jonas’
yeah........ editor’s fault I guess
-
Ge0rG
And I'd like to bring up the one specific use of XEP-0066 to indicate inline images for CS-2019.
-
Ge0rG
Because we want the CS to reflect current best practices, right?
-
Ge0rG
And https://xmpp.org/extensions/xep-0066.html#x-oob is non-obvious to new implementors from the outside.
-
dwd
OK - assuming the LC is complete can we get that on the agenda for next week?
-
dwd
And speaking of next week:
-
dwd
6) Next Meeting
-
Ge0rG
+1W WFM
-
jonas’
+1
-
dwd
Good stuff.
-
dwd
7) Ite, Meetign Est
-
dwd
Thanks all.
-
Link Mauve
Thanks. :)
-
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.
-
zinid
so it's not that scary as it might be seen
-
zinid
but again, this depends on global CAs, so, a lot of people to convince, hehe
-
Ge0rG
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?
-
zinid
Ge0rG, just a second, I will look at 3.1
-
Ge0rG
"General requirements"
-
zinid
ah
-
Zash
Could someone set a proper name and description in this rooms config?
-
zinid
well, the first is well understood I guess, so only bullet 2 requires explanation?
-
zinid
Ge0rG, ?
-
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
-
Ge0rG
non-normative summary would be ok
-
jonas’
mv this_discussion xsf@?
-
zinid
Ge0rG, well, the point is that the following 3.2 section explains what to do to fullfill the requirements
-
zinid
I will probably just rephrase it
-
Ge0rG
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
-
zinid
Ge0rG, 3.1 directly follows from 3.2
-
Ge0rG
zinid: ah, from reading the protoXEP I would have assumed that 3.1 is _in addition to_ 3.2
-
zinid
Ge0rG, yes, I agree it's confusing, I'll rephrase it
-
Ge0rG
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"
-
zinid
Ge0rG, RELOAD URI is used as a device identifier
-
zinid
otherwise I need to invent another field
-
Ge0rG
i.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.
-
Ge0rG
it 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
-
zinid
Ge0rG, I think no public CA will sign you certs with XmppAddr, I might be wrong though
-
zinid
how will it validate it?
-
Ge0rG
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.
-
Ge0rG
pep.: something doesn't need to be good to be best.
-
zinid
Ge0rG, 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?
-
Ge0rG
pep.: I'm not happy. I'm merely giving in to pressure from the most-widely-deployed peer-group client.
-
pep.
Well don't, please
-
zinid
Ge0rG, okay, I will add SHOULD there
-
Ge0rG
zinid: I'm just trying to understand.
-
zinid
and regarding 192.168.1.1, do you mean that recent DigiCert's fuckup?
-
Ge0rG
As I read EAX, I wonder if it is actually useful for other use cases than RELOAD
-
Ge0rG
zinid: yeah, that
-
zinid
Ge0rG, yes, it's absolutely useful, nothing prevents you from using it in c2s sasl external
-
zinid
or in any other place where you need to identify a peer by JID
-
Ge0rG
zinid: but I don't need all the RELOAD stuff for c2s SASL
-
zinid
Ge0rG, that's true, so I agreed to add SHOULD for RELOAD URI
-
zinid
and regarding forming the profile, well, I don't know how to formally do that
-
zinid
need a lot of stupid readings again
-
Ge0rG
zinid: I'd suggest to split §3.2 into multiple sections, where each section describes the requirements for a given e2e use case.
-
zinid
do we want to hardcode the use cases? I'm not sure
-
Ge0rG
as I understand EAX, it is first a description of the possible CA tree structures, and then the formal requirements when checking a certificate.
-
zinid
yes
-
zinid
and certs discovery
-
Ge0rG
Righ.✎ -
Ge0rG
Right. ✏
-
zinid
Ge0rG, won't we run into situation when users end up with multiple certs for incompatible use cases?
-
zinid
I don't see problems in RELOAD URI, it's reload://2342348230948023984@xmpp.org
-
Zash
ralphm: Could you set a name and description in this rooms config so that http://logs.xmpp.org/ looks nicer?
- ralphm clicks
-
zinid
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.
-
zinid
Ge0rG, it's too complex or what? 😀
-
ralphm
Zash: nicer how?
-
Ge0rG
zinid: that sounds like a cert serial, except it's now also semantically bound to an obscure P2P network
-
Zash
ralphm: I don't see any change
-
jonas’
ralphm, also here https://search.jabber.network/search?q=council
-
Ge0rG
jonas’: that doesn't look bad if you don't have a well-defined reference MUC
-
jonas’
that’s true
-
jonas’
https://search.jabber.network/search?q=muc.xmpp.org
-
Ge0rG
also having the search results below the fold is really unfortunate
-
ralphm
Zash, jonas’: I don't understand what you are asking?
-
Ge0rG
ralphm: configure the disco#info name and description parameters of this room :)
-
ralphm
Oh, I thought you were talking about the room topic
-
Zash
ralphm: Configuration dialog for the room itself.
-
ralphm
Do you want the description to match the topic, or something else?
-
Ge0rG
zinid: not complex, just maybe unneeded for the majority of use cases.
-
zinid
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
-
Ge0rG
zinid: we need to hardcode the verification requirements, and those are different per use case
-
Zash
ralphm: Some description of the purpose of the room. "Room where the council holts its meetings" or something.
-
ralphm
ah right
-
Ge0rG
zinid: for e2ee I only care about xmppAddr. No, wait. About srvId xmpp? Is that a thing for clients?
-
Ge0rG
name="XSF Council Room" would probably be appropriate
-
Zash
ralphm: It is a bit funny how we have these 3 different fields :)
-
Ge0rG
Zash: and how these fields have even more different names.
-
zinid
Ge0rG, so far I can only split it into e2ee/c2s-sasl-externa with XmppAddr and RELOAD use case with RELOAD URI
-
zinid
Ge0rG, still, all those cases are documented in the corresponding documents
-
Zash
ralphm: Thanks!
-
ralphm
No worries
-
pep.
Ge0rG: I'm saying that btw because I am currently in your shoes re omemo.
-
jonas’
nice, you also set the language :)
-
ralphm
The field 'confusion' is one of the reasons why MIX doesn't define a room topic
-
Ge0rG
ralphm: but MIX was promised to have sticky messages.
-
ralphm
jonas’: yup
-
jonas’
I poked muclumbus to make it up-to-date there too
-
ralphm
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.
-
zinid
Ge0rG, whatever, I need to go now to my family, we can discuss this later today
-
ralphm
There's much to be said about having both a room description and a topic.
-
Ge0rG
zinid: thanks
-
dwd
ralphm, "about", or "for"?
-
Ge0rG
Damn, this room is sorted under X now.
-
ralphm
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.
-
Zash
Also different target audience. Room name and description would be for people outside of the room. Topic is for people in the room.
-
Ge0rG
ralphm: that doesn't give a rationale for having a description.
-
Ge0rG
There is also some significant overlap between these fields in most rooms
-
Zash
Name: Test room Description: Room for testing
-
Zash
Every test MUC I ever create ^
-
Ge0rG
This has now really become off topic
-
ralphm
Ge0rG: so me giving my view on things doesn't count as a rationale?
-
Ge0rG
ralphm: that's not what I meant. Something being constant over time is not a rationale.
-
Ge0rG
..not for having it at least.
-
Zash
A description of the room for people who aren't in it seems a sensible thing to have.
-
ralphm
Indeed
-
ralphm
And yes, things might be overlapping and not consistent across rooms, partly caused by diverging client UIs and probably mostly because of, well, people.
-
Ge0rG
People. The largest problem XMPP faces.
-
Ge0rG
I agree that having that description for other people thing is useful indeed.
-
ralphm
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.
-
ralphm
(technical solutions)
-
Ge0rG
ralphm: yeah, we can make people sane if we only make the input boxes strict enough!
-
Ge0rG
Did I mention Bookmark Names yet?
-
Zash
Naming things...
-
Ge0rG
It doesn't help very much to have those names default to the localpart of the room
-
Zash
Defaulting to the room name, if set, seems sensible.
-
Ge0rG
which defaults to the localpart.
-
Ge0rG
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.
-
ralphm
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.
-
ralphm
Like in Slack, I suppose.
-
Ge0rG
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.
-
ralphm
Section 4.7.4 in XEP-0369 seems to conflate the room name and such a short identifier in the Name field. Meh.
-
ralphm
Right
-
Ge0rG
in Slack you are referencing to "that chat with peter and anne" and not to 5aaheds7@muc.xmpp.org as well.
-
Zash
identifier, short name, long name, short description, long description, short subject, long subject, ...
-
Ge0rG
well, Slack rooms don't have a JID obviously. But some other kind of ID.
-
ralphm
Yeah, I was talking about explicitly created rooms in Slack.
-
Ge0rG
Zash: you forgot about i18n
-
ralphm
I have a love-hate relationship with 'rooms with multiple people as done in Slack'
-
Zash
Ge0rG: That's where I draw the line
-
Zash
and leave, to find something to eat
-
ralphm
Also probably this is more a topic for xsf@
-
ralphm
Dinner, too.
-
ralphm
as in me having it
-
Zash
Why do board hold meetings in xsf@ but not council ?
-
dwd
Zash, History.
-
dwd
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.
- Neustradamus has left
- oli has joined
- oli has left
- oli has joined
- Link Mauve has left
- Link Mauve has joined
- oli has left
- Link Mauve has left
- Link Mauve has joined
- vanitasvitae has left
- vanitasvitae has joined
- oli has left
- lnj has joined
- lnj has left
- oli has joined
- oli has left
- ralphm has joined
- oli has joined
- ralphm has left
- Neustradamus has left
- Neustradamus has joined
- lnj has joined
- vanitasvitae has left
- vanitasvitae has joined
- Ge0rG has joined
- ralphm has joined
- oli has left
- vanitasvitae has left
- vanitasvitae has joined
- Neustradamus has left
- oli has joined
- oli has left
- oli has joined
- Link Mauve has left
- Link Mauve has joined
- oli has left
- Link Mauve has left
- Link Mauve has joined