XMPP Council - 2019-02-27

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