XSF Discussion - 2019-11-21

  1. Calvin has left

  2. Calvin has joined

  3. winfried has left

  4. winfried has joined

  5. winfried has left

  6. winfried has joined

  7. Daniel has left

  8. Daniel has joined

  9. calvin has left

  10. calvin has joined

  11. winfried has left

  12. winfried has joined

  13. winfried has left

  14. winfried has joined

  15. Calvin has left

  16. calvin has left

  17. stpeter has joined

  18. SERGE90 has left

  19. waqas has left

  20. SERGE90 has joined

  21. mukt2 has joined

  22. stpeter has left

  23. mukt2 has left

  24. Daniel has left

  25. Daniel has joined

  26. stpeter has joined

  27. UṣL has left

  28. Calvin has joined

  29. stpeter has left

  30. calvin has joined

  31. stpeter has joined

  32. Daniel has left

  33. Daniel has joined

  34. stpeter has left

  35. Daniel has left

  36. calvin has left

  37. Calvin has left

  38. Calvin has joined

  39. waqas has joined

  40. stpeter has joined

  41. calvin has joined

  42. stpeter has left

  43. moparisthebest

    just came across this https://en.wikipedia.org/wiki/SiteJabber does that infringe on *the trademark* ?

  44. Calvin has left

  45. Calvin has joined

  46. pep.

    I'm happy I don't have to answer that for them :x

  47. moparisthebest

    I think the XSF does, since it has _ days to enforce trademark infringement or it loses the right to the trademark

  48. moparisthebest

    I can't remember the # of days, but it's few, 30/60/90 or so, no problem since we have lawyers on retainer right? :/

  49. Douglas Terabyte has left

  50. Douglas Terabyte has joined

  51. andy has left

  52. mukt2 has joined

  53. Calvin has left

  54. stpeter has joined

  55. mukt2 has left

  56. stpeter

    It is NOT, I repeat NOT, the XSF's job to police the JABBER™ trademark. That is the responsibility of the trademark holder (Cisco). It is not even our job to police use of the JABBER mark in open-source software implementations of XMPP. Our only job is to sublicense the JABBER mark on request to projects that request sublicensing under the terms of the XSF's (formerly JSF's) agreement with Cisco.

  57. Calvin has joined

  58. pep.

    hmm, https://xmpp.org/about/xsf/jabber-trademark/pending-applications the link in there gives 404. Maybe we should ask the person handling trademark@jabber.org (stpeter?) to PR against that page when it happens? (/pending-applications)

  59. Daniel has joined

  60. stpeter

    I think we have an open issue or PR about that.

  61. neshtaxmpp has left

  62. neshtaxmpp has joined

  63. calvin has left

  64. calvin has joined

  65. Calvin has left

  66. kokonoe has left

  67. kokonoe has joined

  68. pdurbin has joined

  69. andrey.g has joined

  70. Calvin has joined

  71. lorddavidiii has left

  72. lorddavidiii has joined

  73. pdurbin has left

  74. calvin has left

  75. adiaholic has joined

  76. waqas has left

  77. strypey has joined

  78. zukzuk has joined

  79. pdurbin has joined

  80. waqas has joined

  81. waqas has left

  82. Yagiza has joined

  83. Nekit has joined

  84. lorddavidiii has left

  85. lorddavidiii has joined

  86. zukzuk has left

  87. Calvin has left

  88. adiaholic has left

  89. adiaholic has joined

  90. SERGE90 has left

  91. lskdjf has left

  92. strypey has left

  93. Daniel has left

  94. karoshi has joined

  95. SERGE90 has joined

  96. adiaholic has left

  97. adiaholic has joined

  98. Calvin has joined

  99. Nekit has left

  100. Calvin has left

  101. Nekit has joined

  102. Calvin has joined

  103. Calvin has left

  104. andy has joined

  105. wurstsalat has joined

  106. Tobias has joined

  107. stpeter has left

  108. zukzuk has joined

  109. Daniel has joined

  110. Daniel has left

  111. mukt2 has joined

  112. zukzuk has left

  113. zukzuk has joined

  114. Daniel has joined

  115. mukt2 has left

  116. Nekit has left

  117. Nekit has joined

  118. COM8 has joined

  119. mukt2 has joined

  120. COM8 has left

  121. adiaholic has left

  122. adiaholic has joined

  123. COM8 has joined

  124. Daniel has left

  125. Daniel has joined

  126. COM8 has left

  127. COM8 has joined

  128. COM8 has left

  129. adiaholic has left

  130. adiaholic has joined

  131. adiaholic has left

  132. adiaholic has joined

  133. jubalh has left

  134. COM8 has joined

  135. mathijs has left

  136. mathijs has joined

  137. COM8 has left

  138. COM8 has joined

  139. UṣL has joined

  140. jubalh has joined

  141. COM8 has left

  142. jubalh has left

  143. karoshi has left

  144. karoshi has joined

  145. mukt2 has left

  146. mathijs has left

  147. mathijs has joined

  148. rion

    and jingle again.. can we force in the XEP for content-add and some other messages to have just one content definition? To solve the case when for example we have in the time out-of-order and some other response for different definitions?

  149. rion

    as for me all the jingle has nice ideas but bad design :(

  150. adiaholic has left

  151. adiaholic has joined

  152. COM8 has joined

  153. COM8 has left

  154. rion

    Or we can introduce another error. like ambiguity. and describe best practices.

  155. COM8 has joined

  156. rion

    another way is to always send iq error if we have it for at least one content definition and let a developer decide what's he's doing wrong while sending requests

  157. COM8 has left

  158. flow

    rion, could you elaborate on the possible issue that arrises when content-add has multiple contents?

  159. COM8 has joined

  160. COM8 has left

  161. flow

    I am asking myself why the unique 'name' of the contents doesn't help to resolve ambiguity

  162. COM8 has joined

  163. COM8 has left

  164. COM8 has joined

  165. lorddavidiii has left

  166. lorddavidiii has joined

  167. debacle has joined

  168. Daniel has left

  169. winfried has left

  170. winfried has joined

  171. COM8 has left

  172. Daniel has joined

  173. 8311 has joined

  174. adiaholic has left

  175. adiaholic has joined

  176. Daniel has left

  177. Daniel has joined

  178. winfried has left

  179. winfried has joined

  180. winfried has left

  181. winfried has joined

  182. winfried has left

  183. winfried has joined

  184. COM8 has joined

  185. winfried has left

  186. winfried has joined

  187. adiaholic has left

  188. adiaholic has joined

  189. Dele (Mobile) has joined

  190. COM8 has left

  191. jubalh has joined

  192. COM8 has joined

  193. COM8 has left

  194. COM8 has joined

  195. COM8 has left

  196. COM8 has joined

  197. rion

    flow: for example for incoming transport-replace for 2 jingle-ft. Where for one of them our side as initiator also started transport replace but not sent it yet and should respond with iq error, but should accept the second because our side thinks it's not failed yet

  198. alexis has joined

  199. zukzuk has left

  200. zukzuk has joined

  201. Guus

    How does one retrieve a list of all MUC rooms that one has an affiliation with, from a particular XMPP domain?

  202. Guus

    How does one retrieve a list of all MUC rooms that one has an affiliation with, from a particular XMPP service?

  203. jonas’


  204. COM8 has left

  205. adiaholic has left

  206. jubalh has left

  207. Dele (Mobile) has left

  208. Dele (Mobile) has joined

  209. David Cridland

    Guus, disco#search

  210. David Cridland

    Guus, One day we should actually design such a thing.

  211. Dele (Mobile) has left

  212. goffi has joined

  213. flow

    rion, can't you do a transport-accept for the one and a transport-reject for the other? and what does "also started transport replace but not sent it yet and should respond with iq error" mean? why does one has to respond with an iq error here?

  214. flow

    also just do verify: we are dealing here with two file transfers in the same jingle session?

  215. rion

    flow: if I send transport-reject instead of iq error then remote can think I don't support this transport at all and remove it from the list of available for replace. then consequent transport-replace from my side may fail

  216. rion

    flow: yes two file transfers in the same jingle session

  217. rion

    it's better to not send transport-replace for multiple applications. but xep doesn't explicitly says that

  218. flow

    maybe we should go one step back: what makes the one party send a transport-replace while the other party still believes that the transport is still functional?

  219. Zash

    Guus: Make a serverside thing that keeps track?

  220. rion

    tcp timeouts

  221. Zash

    Like the MIX PAM thing

  222. flow

    or, to put it in a different perspective: shouldn't invovled jingle parties always assume that the other party has a good reason for sending a transport-replace and usually accept it?

  223. rion

    flow: I believe there are many such ambiguity cases

  224. flow

    I don't think we have reached the point where I see an ambiguous case, but this could very well because I don't have all the information yet

  225. Guus

    Thanks guys

  226. jubalh has joined

  227. lorddavidiii has left

  228. lorddavidiii has joined

  229. jonas’

    Zash, but that wouldn’t work because you don’t even get notified if you’re made member of a MUC

  230. jonas’

    (or the notification may get lost in the void)

  231. Zash

    jonas’: There's something in XEP-0045 about sending notifications for that

  232. jonas’

    I recall that too, but I don’t think that was for member

  233. jonas’

    but maybe I’m wrong

  234. jonas’

    in any case, my second point still holds :)

  235. adiaholic has joined

  236. Zash


  237. Dele (Mobile) has joined

  238. Zash

    Something something perfect vs good enough?

  239. Zash

    PubSub has a thing allowing you to ask what nodes you're subscribed to

  240. rion

    flow: same for *-info messages. being combined for multiple applications, one of them may report unsupported-info iq error while the other accepts

  241. debacle has left

  242. rion

    > shouldn't invovled jingle parties always assume that the other party has a good reason for sending a transport-replace and usually accept it? it break tie-breaking rules

  243. rion

    sorry. that's what I meant from the beginning. not out-of-order.

  244. flow

    rion, how can a tie-break be needed here, you wrote that "[has] not sent it yet"

  245. rion

    but it doesn't matter. basically any kind of IQ error combined with valid response

  246. rion

    flow: well it maybe not sent but prepared for sending. or sent but no iq ack yet. does it matter?

  247. flow

    I think a document (pastebin, gist, …) which shows the exchanged stanzas and the state of the jingle state machine would be helpful

  248. flow

    rion, I don't think tie break is needed if you don't sent anything yet

  249. rion

    if for example I spend a few second on collecting candidates, should I abandon them or just sent tie-break?

  250. rion

    I prefer the second

  251. flow

    I assume that you only need a tie break if there is a chance that the two parties send something which would require one

  252. rion


  253. rion

    that's the case.

  254. flow

    so if you only locally processed some data but didn't put anything on the wire yet, then there is no tie-break needed, even though you would need one if you had send the stanza

  255. rion

    Currently I'am trying to implement something like "convert my prepared request into response". That's weird

  256. rion

    for s5b/ice I'll make a candidates cache probably. That will improve performance for such cases. But if standard would forbid such ambiguity cases, that wouldn't be needed.

  257. Daniel

    rion: on a slightly different note: have you done any interop testing with Conversations yet? If not would you be willing to try (with me) at some point

  258. Steve Kille has left

  259. alexis has left

  260. alexis has joined

  261. rion

    Daniel: tried only with Gajim so far

  262. flow

    rion, of course if you are the initator you could force a tie-break and overrule the responder, not sure if there are situations if this is sensible

  263. rion

    Daniel: does Conversations support multiple transfers in one session?

  264. flow

    but if I understand the initially sketched scenario correctly, then why shouldn't you simply accept the incoming transport-replace, as there is probably a good reason the other party send it

  265. flow

    uh, and I am also not sure if we really want to have multiple transports in a single jingle session

  266. Guus

    In 363, this requirement is odd to me: > Do not provide any kind of access control or security for file retrieval beyond Transport Layer Security in form of HTTPS and long random paths that are impossible to guess. That means everyone who knows the URL SHOULD be able to access it. I understand "requirements" defined in the XEP to be requirements that must be met by the specification, not by the implementation. Does this requirement try to express that the specification is defined in such a way that access control or security (beyond TLS) is not needed, or does it try to express that implementations SHOULD NOT apply additional access control / security?

  267. Daniel

    > Daniel: does Conversations support multiple transfers in one session? rion: no

  268. flow

    I always assumed that multi transports in a single jingle session is sensible if both transports are related, like audio and video

  269. Steve Kille has joined

  270. flow

    but for file transfers, even if you are transfering the pictures of the same cat, I would have probably used different jingle sessions. But I love to hear arguments for using the same session

  271. mukt2 has joined

  272. Daniel

    Unfortunately the general answer to 'can Conversations do x' is usually no when it comes to jingle

  273. Zash

    flow: maybe sending a collection or something, tho then you could bundle them up in an archive of some sort

  274. Daniel

    It's probably faster

  275. rion

    flow: if something is not prohibited then it's allowed. Psi currently allows to select multiple files for sending and they all go into one session. then if any party adds more files to the session they will be accepted automatically without user interaction. (not tested this way though)

  276. David Cridland

    rion, If something isn't working we should disallow it though.

  277. flow

    Zash, rion: sure, but as conversation nicely demonstrates, you will have a higher probability of success if you use exactly one transport per session

  278. jubalh has left

  279. rion

    David Cridland: then we need another NS in disco

  280. Daniel

    The problem is that you can't signal support for that

  281. David Cridland

    rion, I don't think we do if it's currently unclear.

  282. rion

    David Cridland: I mean where multi file transfer is supported by remote :)

  283. David Cridland

    rion, Or we just say people should use multiple sessions and/or an archive.

  284. rion

    David Cridland: I'm fine with that. Who will add it to the XEP?

  285. mukt2 has left

  286. debacle has joined

  287. David Cridland

    rion, You should be able to do the PR yourself I'd have thought?

  288. jubalh has joined

  289. rion

    David Cridland: it won't be accepted anyway we regular reason - breaks compatibility

  290. rion

    David Cridland: new corrected xeps won't be accepted either

  291. rion

    there is no way to fix xmpp :)

  292. Zash

    Not with that attitude!

  293. Daniel

    Isn't jingle ft still draft?

  294. Daniel

    Or experimental even

  295. David Cridland

    Well, I'm telling you I'd have accepted it in the last Council session. Can't speak for everyone, but it seems reasonable to me.

  296. David Cridland

    I can certainly say it won't be accepted if there's no PR to accept.

  297. sonny has left

  298. sonny has joined

  299. zukzuk has left

  300. zukzuk has joined

  301. 8311 has left

  302. rion

    so guy can you bring this up on a session? then I'll be happy to make a PR if the decision will be to simplify the things.

  303. 8311 has joined

  304. rion

    for now just for ft.

  305. jonas’

    rion, make a PR, but note that council will be re-elected today, so there’s lots of uncertainty and some delay to be expected :)

  306. David Cridland

    But... I'd do it for Jingle rather than just FT. Not entire sure you *could* do it for just FT. But I may be wrong, I've not looked at the detail here.

  307. rion

    one file transfer = one session is fine. but for rtp is not possible. and for rtp+filetransfer in one session is not clear at all

  308. adiaholic has left

  309. rion

    probably it has to be stated in xep-0166 that some application types should disallow multiple contents per session for simplicity. xep-0234 should apply this rule. and review cases or errors handling when we have multiple contents in a request.

  310. David Cridland

    Ah, I think I understand. Yes, that makes sense. If you're transferring a file, don't do anything else with the session.

  311. David Cridland

    Maybe fippo might have some views on this if I incant his name.

  312. jubalh has left

  313. jubalh has joined

  314. LNJ has joined

  315. Wojtek has joined

  316. zukzuk has left

  317. zukzuk has joined

  318. adiaholic has joined

  319. flow

    > rion> David Cridland: it won't be accepted anyway we regular reason - breaks compatibility Not if it is just a recommendation, which seems sensible instead of a hard requirement

  320. jubalh has left

  321. zukzuk has left

  322. winfried has left

  323. winfried has joined

  324. winfried has left

  325. winfried has joined

  326. Wojtek has left

  327. jubalh has joined

  328. winfried has left

  329. adiaholic has left

  330. adiaholic has joined

  331. jubalh has left

  332. winfried has joined

  333. lskdjf has joined

  334. nyco

    there is something I am not sure about, can anyone (try to) explain it to me? I want to compare XMPP's MUCs to Matrix's Channels I didn't spot fundamental differences I mean the groupchat is hosted on a (home)server every participant receives the messages and the participants' server archives the message locally correct? so what is this eventually consistent replication that is sometimes presented as an advantage?

  335. jubalh has joined

  336. zukzuk has joined

  337. marc_ has joined

  338. Zash

    I wouldn't say MUC works like that

  339. jonas’

    > and the participants' server archives the message locally wrong

  340. pdurbin has left

  341. Zash

    MIX otoh would be closer

  342. lorddavidiii has left

  343. jonas’

    yes, but MIX isn’t eventually consistent

  344. nyco

    so I want to roughly understand this Matrix replication

  345. Zash

    > eventually consistent replication Everything is in a DAG, like git. Every event has a previous event, so you can figure out things eventually.

  346. Holger

    nyco: I think Matrix' main advantage is that the room's messages are linked into a history (a Git-like DAG).

  347. Holger

    nyco: Plus it's replicated to the servers of all participants, which may or may not be seen as an advantage depending on your trade-offs.

  348. ralphm

    RIght, for scalability, that latter part is not great.

  349. ralphm

    Right, for scalability, that latter part is not great.

  350. nyco

    yeah, more storage consumption, more bandwidth use

  351. nyco

    is that resistent to netsplits?

  352. Zash

    Random message loss due to s2s failures would eventually heal

  353. ralphm

    yes, hence the 'eventual'

  354. nyco

    I mean, a Matrix channel is hosted on one homeserver, right?

  355. Holger


  356. Zash

    nyco, nit: they're called "rooms"

  357. nyco


  358. lorddavidiii has joined

  359. Zash

    Every room is hosted on every participanting homeserver.

  360. nyco

    that would be: homeserver => bedrooms... (or toilets, maybe?) :)

  361. nyco

    ok, thx

  362. Zash

    And the DAG thing means you need merges, and that's where I stopped reading.

  363. nyco

    so, merge whatN

  364. Zash

    XMPP s2s is super easy by comparison

  365. nyco


  366. Holger

    Well merges without conflict resolution.

  367. nyco

    merge of what with what?

  368. Holger

    It basically just means that an event can have multiple parents.

  369. nyco

    so an event in the Matrix protocol context is a message?

  370. Zash

    Equivalent to a stanza I suppose

  371. nyco

    ok, so can be a presence as well... I guess

  372. nyco

    (not talking about IQ, not sure there is a mechanism in Matrix protocol)

  373. Holger

    nyco: There's message X in the history, then a netsplit between our homeservers, then we both respond to X, someone else receives both responses and sends a message himself. This last message will have _both_ of our messages as parents in the DAG.

  374. Zash

    Not sure. They do have a proper separation of persistent and ephemeral events (chat states etc)

  375. Zash

    Not sure how that fits into the DAG thing

  376. nyco

    ah ok, so merges happen after netsplits?

  377. Holger


  378. Holger

    Or, well, they can occur simply due to normal races.

  379. nyco

    ouch, so there is netsplits like in IRC in Matrix???

  380. Zash

    XMPP s2s: Open connection, TLS, auth, send messages. Simple.

  381. nyco


  382. David Cridland

    nyco, There are in XMPP too. It's just that conversations halt on one side.

  383. nyco

    proof S2S is simple: I understand it... :)

  384. Zash

    nyco, can't avoid netsplits on the Internet

  385. nyco

    David Cridland indeed, I was referring to IRC-like netsplits

  386. nyco

    well, there is no such thing on XMPP as: half of the room is gone, because

  387. David Cridland

    FWIW, I think there's room for both "this chatroom exists as its own entity in a particular domain", and "we are having a group chat which doesn't formally live anywhere".

  388. nyco

    of course, a MUC room can totally fail if the server fails

  389. Holger

    You mean XMPP doesn't distribute rooms. Right.

  390. David Cridland

    I've never fully understood how Matrix manages chatroom permissions in a distributed manner.

  391. nyco

    David Cridland I got that as well, it is werid since a Matrix room has an address on a specific homeserver

  392. MattJ

    They are aliases

  393. MattJ

    The same room can have multiple different addresses

  394. nyco


  395. David Cridland

    nyco, No, that's the name of the room - they're namespaced to a domain, not controlled by it.

  396. MattJ

    The real room address is a long weird string that nobody would remember

  397. nyco

    MattJ can give examples of Matrix rooms addresses aliases?

  398. MattJ

    So then if you want people to join it, you give it an alias like 'xsf'

  399. mukt2 has joined

  400. nyco

    got it

  401. MattJ

    Examples here in the spec: https://www.matrix.org/docs/spec/#room-aliases

  402. nyco


  403. MattJ

    So #xsf:xmpp.org may be an alias for the same room as #xmpp-standards-foundation:jabber.org

  404. kokonoe has left

  405. nyco

    their public search features gives only one alias, is it consistent? is there an alias mapping somewhere?

  406. nyco

    so, as a user, how do you know it is the same room?

  407. MattJ

    Each server keeps a mapping

  408. MattJ

    A jolly good question :)

  409. nyco


  410. MattJ

    Their #matrix:matrix.org room has actually moved a large number of times

  411. nyco

    uniqueness and human-readability

  412. nyco

    well... "meh" again

  413. Zash

    David Cridland, I wouldn't be suprised if distributed permissions are handled through the fact that there's so far only a single server implementation with any real deployment.

  414. MattJ

    Like the time there was a bug in their DAG merge algorithm, and someone took over the room by injecting a room creation event that got preferred over the authentic room creation event

  415. MattJ

    So all the servers accepted this as fact, and they lost control of their primary discussion channel

  416. Zash

    This reminds me of IRC netsplit merge algorithms

  417. nyco


  418. MattJ

    But they fixed the bug, created a new room, and redirected the alias to their new room

  419. MattJ

    Other upgrades and bug fixes in the protocol have required them to recreate rooms

  420. Zash

    Is that what room versions are?

  421. Zash

    Do they have as many room versions as we have groupchat protocols yet?

  422. MattJ

    Yeah, rooms have versions, they can be upgraded, which I think creates a new room, I'm not sure

  423. MattJ

    It's an interesting model, and it solves some problems for some use cases, but I still prefer the simplicity of XMPP

  424. MattJ

    and nobody >5 years ago would have once thought us defending XMPP on the grounds of simplicity ;)

  425. Zash

    It does go further into the "complicated servers, simple clients" direction tho

  426. MattJ


  427. kokonoe has joined

  428. Zash

    I've seen an internal client that's basically just a few lines of jQuery

  429. nyco

    > and nobody >5 years ago would have once thought us defending XMPP on the grounds of simplicity ;) muhahahaha

  430. nyco

    > I've seen an internal client that's basically just a few lines of jQuery because their C2S "protocol" is a basic RESTful-like API?

  431. Zash

    nyco: Yes

  432. Zash

    Fairly simple RESTful BOSH+MAM like thing

  433. nyco

    yeah, on MongooseIM we had also created a very basic and minimalistic REST-like API iOS and Android clients could be developed very rapidly

  434. Zash

    While the s2s protocol has distributed transactions and DAGs and merges and whatnot

  435. ralphm

    Lance did something similar, it is not hard, per se, but a trade-off, as you are also limiting what kind of interactions you have.

  436. nyco


  437. mukt2 has left

  438. nyco

    on a C2S API, you would have to map the entire XMPP protocol

  439. Zash


  440. nyco

    so I guess Matrix's VoIP signalling is just another event/message, right? then it goes RTP like SIP, Jingle, etc.

  441. Zash

    nyco, WebRTC.

  442. Zash

    Conferencing is literally Jitsi Meet in an <iframe>

  443. Zash

    Dunno what the 1-to-1 calls are tho

  444. nyco

    ok... I was not sure

  445. nyco

    Slack uses Jitsi Meet as well? HipChat used to do so

  446. Zash

    And Jitsi Meet embeds Prosody! 😀

  447. nyco

    so Matrix has XMPP in their core :)

  448. nyco


  449. nyco

    ok, thx all! :)

  450. Guus

    Jitsi meet uses XMPP internally

  451. nyco

    so yeah, what's that part? MUCs?

  452. winfried has left

  453. winfried has joined

  454. Zash

    MUC. LDAP authentication.

  455. Wojtek has joined

  456. nyco


  457. Zash

    https://github.com/jitsi/docker-jitsi-meet#architecture might be a good starting point if you wanna look closer

  458. nyco


  459. winfried has left

  460. winfried has joined

  461. aj has joined

  462. Wojtek has left

  463. mukt2 has joined

  464. zukzuk has left

  465. larma has left

  466. larma has joined

  467. aj has left

  468. calvin has joined

  469. Wojtek has joined

  470. mukt2 has left

  471. pep.

    "Guus> In 363, this requirement is odd to me", I would assume the latter? an implementation should not add additional access control? that is, you get the url you should be able to access the thing behind(?)

  472. Guus

    pep. I had someone ask me if we could add additional security checks. I'm wondering if that requirement allows for that.

  473. Guus

    Like I said - I think this 'requirements' are supposed to be requirements for the protocol design, not the implementation based on the XEP - but it'd be good to have clarity.

  474. calvin has left

  475. calvin has joined

  476. aj has joined

  477. aj has left

  478. pep.

    Generally the url is the password. It has enough entropy that it's not guessable. I agree though that SHOULD NOT could be relaxed. It doesn't entirely make sense in private setups

  479. Guus

    Again - if the 'requirements' are reflective of the protocol, not the implementation, then there's no issue.

  480. pep.

    I don't understand

  481. Guus

    These are two different things: - The protocol defined in this document must be designed in such a way that implementations/deployments need not add additional security checks if they feel that using an URL with enough entropy is safe enough - It is illegal for implementations to add more security checks other than the unguessable URL.

  482. Guus

    ("illegal" is probably a bit stronger than the 'SHOULD' that's in the actual XEP, but I was trying to illustrate the point here)

  483. pep.

    I see

  484. pep.

    dunn othen

  485. pep.

    dunno then

  486. Calvin has joined

  487. aj has joined

  488. pdurbin has joined

  489. kokonoe has left

  490. winfried has left

  491. winfried has joined

  492. kokonoe has joined

  493. winfried has left

  494. winfried has joined

  495. aj has left

  496. pdurbin has left

  497. Calvin has left

  498. Calvin has joined

  499. vanitasvitae has left

  500. vanitasvitae has joined

  501. strypey has joined

  502. Calvin has left

  503. Calvin has joined

  504. adiaholic has left

  505. adiaholic has joined

  506. winfried has left

  507. winfried has joined

  508. jubalh has left

  509. jubalh has joined

  510. COM8 has joined

  511. Calvin has left

  512. Calvin has joined

  513. COM8 has left

  514. calvin has left

  515. COM8 has joined

  516. Calvin has left

  517. waqas has joined

  518. stpeter has joined

  519. winfried has left

  520. winfried has joined

  521. jubalh has left

  522. jubalh has joined

  523. Guus

    Board meeting time/

  524. Guus

    ah, yes.

  525. Guus


  526. ralphm bangs gavel

  527. ralphm

    0. Welcome + Agenda

  528. ralphm

    Welcome to the last Board meeting of this term!

  529. Guus

    Seve mentioned that he might not make todays meeting.

  530. ralphm

    I think we can do this fast.

  531. ralphm


  532. ralphm

    nyco, MattJ?

  533. nyco


  534. MattJ


  535. ralphm

    1. Minute taker

  536. nyco


  537. ralphm


  538. nyco

    but please do help me

  539. ralphm

    2. License for website content

  540. ralphm

    If I remember correctly, and this was a *long* time ago, the idea was that everything on the website was beholden to our IPR policy, which would mean MIT.

  541. nyco

    ah, that would be clear

  542. ralphm

    I'd like to note that initially there was a CC license for this, but it got changed to MIT to make it easier to embed XEPs into software projects (see the changelog)

  543. nyco


  544. ralphm

    but Peter would probably know more about this.

  545. Guus

    https://github.com/xsf/xmpp.org/issues/407 calls for _a_ license to be denoted.

  546. Guus

    Is this is ment to be under MIT, lets add MIT

  547. ralphm

    In any case, I think this does merit better clarity.

  548. adiaholic has left

  549. ralphm

    Let's check with Peter and then have next Board make a decision soon?

  550. MattJ


  551. Guus


  552. ralphm

    (because the wording of the IPR Policy isn't clear on this either)

  553. pep.

    Who is actionable for this?

  554. Guus

    (pinging stpeter ...)

  555. pep.

    badly worded

  556. COM8 has left

  557. ralphm

    pep. I'll ask Peter, and then next Board.

  558. pep.


  559. krauq has left

  560. ralphm

    3. Task Boards

  561. ralphm

    Item by nyco on the use of Trello instead of free software alternatives.

  562. COM8 has joined

  563. pep.

    I guess this can move to next board?

  564. stpeter has left

  565. ralphm

    I'm not in favour of changing things around just because of this, to be honest.

  566. nyco

    yep, since Trello is proprietary SaaS, we are more and more relying on it

  567. Guus

    I'm sympathetic, but I'm seeing benefit in using a SaaS project if that means not adding additional tasks to iteam.

  568. MattJ

    I share the sentiment around Trello (I'm not a fan, and there are plenty of decent open alternatives)

  569. pep.

    Guus, this way, we do nothing, everything is additional things to other people..

  570. MattJ

    But a FOSS solution would require someone to host it, and that's pretty much the same difference to me

  571. ralphm

    The core XMPP standards with the IETF are open, and so are our XEPs, but this doesn't mean that everything the XSF is involved in requires the avoidance of proprietary solutions.

  572. MattJ

    Unless we run it ourselves, which as iteam lead I would veto :)

  573. MattJ

    For now at least

  574. nyco

    why veto as iTeam?

  575. Guus

    Maybe you're not on board after tonight, and have all the time of the world, MattJ 😉

  576. MattJ

    nyco, because iteam is currently in no state to run additional services

  577. ralphm

    And iteam is spread a bit thin already

  578. nyco


  579. MattJ

    Have you seen the wiki recently? :)

  580. Zash

    The who has to interact with it should decide what to use.

  581. nyco

    I edit the wiki, so yes, why?

  582. MattJ

    (off-topic, but Zash put some time into trying to upgrade the wiki recently)

  583. nyco

    oh about obsolete version? yes

  584. nyco

    ok then

  585. Guus

    So we're voting against mandating the abandonment of Trello?

  586. nyco

    looks like we don't have a consensus to move out of Trello, and iTeam is limited capacity

  587. pep.

    Otherwise.. there's the mailing list :)

  588. MattJ

    In the future maybe we can improve iteam and host some more services ourselves where it makes sense, but right now it's not even worth considering

  589. nyco


  590. ralphm

    We could have a broader discussion on this in the future, e.g. on how to make sure we have resources to work for infrastructure, including possibly funding that work, but this doesn't seem the time. I believe MattJ is also still working on his inventory.

  591. nyco


  592. nyco

    no need to vote then?

  593. ralphm

    I don't think so.

  594. COM8 has left

  595. ralphm

    4. Other items on the trello board

  596. COM8 has joined

  597. Calvin has joined

  598. adiaholic has joined

  599. nyco

    badge, adopt character?

  600. ralphm

    I think all of these are either waiting for feedback, or should be handled by the next board anyway.

  601. krauq has joined

  602. Guus

    why put off the adopt a character thing?

  603. nyco

    put off?

  604. Guus

    put off discussing it now.

  605. nyco


  606. ralphm

    From what I remember we said we wanted to do it, but then I am unsure what the next step was going to be.

  607. nyco

    we chose one, the process was not clear

  608. nyco

    then we pay, then what do we use it for?

  609. Zash

    Marketing marketing marketing?

  610. Guus

    There wasn't a next step, which is what we could discuss now 🙂

  611. nyco

    what about marketing marketing marketing?

  612. Seve

    Deciding for a specific character is where we are now

  613. COM8 has left

  614. nyco

    yes, let's discuss the adoption

  615. Guus

    I don't think we need to do anything with it, other than knowing that we're supporting the Unicode consortium with it.

  616. COM8 has joined

  617. nyco

    again, could be fun to say out loud we adopted this character

  618. ralphm

    Ok, so I need to dig up which character we settled on (one of the speech bubbly ones) and then do it.

  619. ralphm

    Of course the comms team can then have their field day with it.

  620. Guus

    did we decide to do this? And if so, what level? If we, as board, decide on that, we can put the question of "what character" to memberhsip.

  621. nyco

    field day?

  622. ralphm

    nyco, look it up

  623. nyco

    look it up?

  624. COM8 has left

  625. nyco

    Guus I remember something like we kind of were reluction to take time and energy for such a vote, high effort

  626. COM8 has joined

  627. ralphm

    nyco: https://lmgtfy.com/?q=having+a+field+day

  628. Guus

    I'm happy for commsteam to pick one.

  629. Guus

    I'm just not sure if we actually decided on doing this.

  630. Guus

    and if so, for what level.

  631. Seve

    I remember we said yes, only discussing which chatacter to pick

  632. ralphm

    I believe we did have consensus in an earlier meeting, I just need to find it in the logs.

  633. nyco

    CommTeam, not commsteam, could be taken for "Comm Steam" :)

  634. ralphm

    nyco: whatever, again

  635. nyco

    which is not wrong, btw :)

  636. ralphm

    I'll try hunt it down in the logs.

  637. Guus

    ok, assuming we did indeed agree to this: shall we have the communication / stream team pick one?

  638. nyco

    stream... OMG :)

  639. COM8 has left

  640. ralphm

    Guus: I think we already picked one

  641. ralphm

    so I'll look up which one

  642. calvin has joined

  643. nyco

    thx ralphm

  644. ralphm

    5. AOB

  645. Guus

    Ok - so lets ask the treasurer to pay for it?

  646. Guus

    and be done?

  647. COM8 has joined

  648. ralphm


  649. COM8 has left

  650. ralphm

    Any AOB?

  651. Guus


  652. MattJ

    None here

  653. Guus

    AOB: it was my pleasure serving this year

  654. ralphm


  655. COM8 has joined

  656. nyco

    oh yeah, bye all! :) thx for this term!

  657. ralphm

    I'd like to thank you all for this term!

  658. MattJ

    Yes, thanks :)

  659. Zash

    Thanks yall

  660. Ge0rG

    Thank you, dear Board

  661. ralphm

    6. Date of Next

  662. ralphm

    I'm suggesting to keep this timeslot for at least the next meeting, to do a proper handover.

  663. Guus

    Ge0rG you somehow make it sound as if you're now taking us out back to get put down 😉

  664. ralphm

    So, +1W

  665. nyco


  666. zukzuk has joined

  667. Guus

    +1w wfm

  668. ralphm

    7. Close

  669. ralphm

    Thanks, all!

  670. ralphm bangs gavel

  671. Ge0rG

    Guus: sorry, I don't understand

  672. Guus

    nevermind, my mind wonders and has to many movie references in it.

  673. ralphm

    Oh, and if you can, please join Alex at 19:00 UTC in this same venue!

  674. Guus

    I actually cannot 😞

  675. Guus

    maybe from mobile, but unlikely.

  676. Ge0rG

    I'll try from mobile

  677. nyco

    https://mensuel.framapad.org/p/6E9JDfCF5L-XSF-Board-Meeting-2019-11-21 please review, edit, correct, fill, etc.

  678. ralphm

    Thanks nyco

  679. Alex


  680. winfried has left

  681. winfried has joined

  682. winfried has left

  683. winfried has joined

  684. Guus

    nyco added one reasoning, otherwise lgtm

  685. Calvin has left

  686. Calvin has joined

  687. nyco


  688. Zash

    Re Trello; if that's the way to communicate with Board then I'm kinda sceptical. If it's an internal tool for Board themselves then they can agree on whatever.

  689. nyco

    I'll send it in 10 min, so you all still have time to review :)

  690. nyco

    Trello is not only for the Board, SCAM as well, and maybe CommTeam

  691. nyco

    dunno about iTeam

  692. nyco

    and yeah the tool is not critical

  693. MattJ

    Zash, it's not for communication with Board, I don't think non-Board have access to it

  694. nyco

    yes, it's fully open

  695. nyco


  696. ralphm

    board can be contacted here or on board@xmpp.org, or info@xmpp.org for more general stuff

  697. nyco

    let me check

  698. ralphm

    Our meeting board is 664.

  699. Seve


  700. nyco

    > Our meeting board is 664. exactly

  701. nyco

    Zash anyway, anyone (I guess) can ping the board

  702. UṣL has left

  703. nyco

    there is just not an unique/official way

  704. Calvin has left

  705. debacle has left

  706. jubalh has left

  707. jubalh has joined

  708. COM8 has left

  709. nyco

    I send the minutes

  710. COM8 has joined

  711. strypey has left

  712. strypey has joined

  713. Daniel has left

  714. Guus


  715. pep.

    Thanks for the minutes

  716. pep.

    nyco, I chose trello for SCAM because board was using it, but yes I'm also in favor of changing to something more free :)

  717. j.r has left

  718. pep.

    board@xmpp.org is not public though..

  719. j.r has joined

  720. Zash

    Not used tho, they meet here

  721. Daniel has joined

  722. pep.

    I mean the list

  723. Zash

    Oh, ah

  724. winfried has left

  725. winfried has joined

  726. moparisthebest

    https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-ripp-03 looks like we are a little behind here, need draft for XMPP over http/3

  727. j.r has left

  728. lorddavidiii has left

  729. Ge0rG

    moparisthebest: you got it backwards. We need to update XEP-0332 to HTTP/3

  730. jubalh has left

  731. jubalh has joined

  732. strypey has left

  733. j.r has joined

  734. lorddavidiii has joined

  735. pdurbin has joined

  736. debacle has joined

  737. jubalh has left

  738. jubalh has joined

  739. COM8 has left

  740. COM8 has joined

  741. COM8 has left

  742. pdurbin has left

  743. debacle has left

  744. Nekit has left

  745. Calvin has joined

  746. COM8 has joined

  747. COM8 has left

  748. COM8 has joined

  749. winfried has left

  750. winfried has joined

  751. Calvin has left

  752. rion

    regarding "Direct messages SHOULD be used over PMs in non-anonymous rooms". What benefits does it bring? When it's muc private chat (with muc private jid) everything is quite clear - logic is fully the same as in anonymous room but we can draw a button like "add to roster" But when we use real jid instead for muc private it's like communication with any other contact not from roster: - presences do not work - pubsub doesn't work - we have invent something borrow status,vcard,whatever from muc.

  753. MattJ

    You could draw the line based on whether the contacts are in the roster or not

  754. MattJ

    Pidgin does this iirc

  755. Ge0rG

    rion: it reduces user confusion: you shouldn't have two different chat windows to the same person

  756. MattJ

    The only time I suggest Pidgin may be doing the right thing...

  757. Zash

    Directed presence could be used as a kind of temporary subscription

  758. Ge0rG

    what's wrong with _not_ having avatar and presence in that window?

  759. Ge0rG

    rion: MUC-PMs are not very reliable

  760. Ge0rG

    if you are offline, or your friend is offline, or only one of their clients is offline...

  761. Ge0rG

    "why did I see your message on my PC, but not on my mobile? also why was it in a new window?"

  762. COM8 has left

  763. COM8 has joined

  764. COM8 has left

  765. Daniel

    Why do I see message three times?

  766. Daniel

    Why do I (not) see my own messages

  767. Zash

    Why is it in the same chat view as the group messages and why did I just reply in public

  768. Ge0rG

    That PR was guided by an impulse that was ignited by biboumi, because on IRC it doesn't even make _any_ sense to have PM routing

  769. UṣL has joined

  770. Zash

    Why did you reply from a different JID?

  771. 8311 has left

  772. Ge0rG

    What's a JID?

  773. COM8 has joined

  774. Guus

    "Can you use Whatsapp please?"

  775. 8311 has joined

  776. COM8 has left

  777. Guus ducks, runs

  778. Ge0rG ,oO( if it ducks like a duck... )

  779. rion

    well I'd prefer to switch to real jid when the contact is already in roster.

  780. patrick has joined

  781. j.r has left

  782. j.r has joined

  783. aj has joined

  784. kokonoe has left

  785. aj has left

  786. kokonoe has joined

  787. 8311 has left

  788. COM8 has joined

  789. COM8 has left

  790. pep.

    Isn't that what the change says?

  791. pep.

    Hmm it doesn't say roster

  792. COM8 has joined

  793. calvin has left

  794. calvin has joined

  795. mathijs has left

  796. mathijs has joined

  797. wurstsalat

    wanted to ask what Kev meant in the vote by commenting "(this breaks things)"

  798. mathijs has left

  799. mathijs has joined

  800. Kev

    I think I said more about this at the time, and intended to say more on-list once Ge0rG starts the discussion there.

  801. Ge0rG

    I'm still sorry.

  802. Kev

    But it may be that clients can talk only through the room, and that direct messages will fail.

  803. Kev

    Ge0rG: No need to be sorry.

  804. mathijs has left

  805. mathijs has joined

  806. Kev

    e.g. it may be that a user only allows incoming messages from JIDs for which they have exchanged presence.

  807. COM8 has left

  808. Ge0rG

    Those users are broken.

  809. COM8 has joined

  810. COM8 has left

  811. Douglas Terabyte has left

  812. mathijs has left

  813. mathijs has joined

  814. jubalh has left

  815. lorddavidiii has left

  816. mathijs has left

  817. mathijs has joined

  818. lorddavidiii has joined

  819. !XSF_Martin has left

  820. !XSF_Martin has joined

  821. jubalh has joined

  822. mathijs has left

  823. mathijs has joined

  824. adiaholic has left

  825. adiaholic has joined

  826. 8311 has joined

  827. winfried has left

  828. winfried has joined

  829. marc_ has left

  830. winfried has left

  831. winfried has joined

  832. 8311 has left

  833. 8311 has joined

  834. kokonoe has left

  835. alexis has left

  836. 8311 has left

  837. APach has left

  838. kokonoe has joined

  839. edhelas has left

  840. nyco has left

  841. jnaeff has left

  842. edhelas has joined

  843. Calvin has joined

  844. APach has joined

  845. winfried has left

  846. winfried has joined

  847. jubalh has left

  848. jubalh has joined

  849. Calvin has left

  850. Calvin has joined

  851. APach has left

  852. Calvin has left

  853. Calvin has joined

  854. calvin has left

  855. patrick has left

  856. pdurbin has joined

  857. pdurbin has left

  858. mukt2 has joined

  859. Calvin has left

  860. Calvin has joined

  861. Calvin has left

  862. Calvin has joined

  863. jubalh has left

  864. APach has joined

  865. stpeter has joined

  866. Calvin has left

  867. Calvin has joined

  868. lorddavidiii has left

  869. Calvin has left

  870. Calvin has joined

  871. jubalh has joined

  872. mathijs has left

  873. mathijs has joined

  874. lorddavidiii has joined

  875. Dele (Mobile) has left

  876. j.r has left

  877. nyco has joined

  878. j.r has joined

  879. lorddavidiii has left

  880. lorddavidiii has joined

  881. Calvin has left

  882. mukt2 has left

  883. david has left

  884. david has joined

  885. david has left

  886. david has joined

  887. marc_ has joined

  888. jubalh has left

  889. calvin has joined

  890. 8311 has joined

  891. Nekit has joined

  892. adiaholic has left

  893. adiaholic has joined

  894. marc_ has left

  895. Steve Kille has left

  896. lovetox has joined

  897. Steve Kille has joined

  898. jubalh has joined

  899. j.r has left

  900. j.r has joined

  901. Alex

    hey guys, anyone ready for our annual meeting?

  902. jonas’


  903. jonas’

    hi Alex :)

  904. Alex

    Hi jonas

  905. Zash


  906. mathieui

    yes, hi Alex

  907. 8311 has left

  908. Ge0rG

    Oh, it's the time already!

  909. Alex

    lets give the rest of the crew 2 or 3 more minutes to wake up ;-)

  910. debacle has joined

  911. Ge0rG

    I was still feeling like CEST

  912. Alex

    ya, prime time

  913. David Cridland

    EVening all.

  914. j.r has left

  915. j.r has joined

  916. Alex

    okay, lets start

  917. Alex bangs the gavel

  918. Alex

    here is our Agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2019-11-21

  919. Alex

    1) Call for Quorum

  920. Alex

    as you can see 39 members voted via proxy, so we have a quorum

  921. Alex

    2) Items Subject to a Vote

  922. Ge0rG

    There is a typo in the agenda: > Board and Election,

  923. Alex

    Board and Council elections, you can see the appications here: https://wiki.xmpp.org/web/Board_and_Council_Elections_2019

  924. Alex

    fixing the typo now

  925. jonas’

    (relevant gif for "bangs the gavel": https://external-preview.redd.it/7P3i0dah8goJXU7BfsdKkF2SthYeoF6Pq6xeEi8H1kc.gif?width=440&height=230.366492147&s=04324486f65cbb7ff2b0ed265caafd552bc6546d )

  926. Alex


  927. Alex

    3) Opportunity for XSF members to Vote in the Meeting

  928. Alex

    anyone here who has not voted via proxy yet?

  929. Alex

    looks like there are none

  930. Alex

    then I will shutdown the bot and start working on the results

  931. David Cridland

    While Alex carefully counts the votes, who do we have present?

  932. jonas’

  933. Zash

  934. mathieui

  935. Ge0rG

  936. David Cridland

    I was mostly wondering if my scare-mongering earlier caused a bit more attendance. :-)

  937. larma


  938. stpeter

    I'm sort of here. :-)

  939. Ge0rG

    larma: you are missing the trailing space, aren't you?

  940. Link Mauve


  941. Link Mauve

  942. jonas’

    stpeter, thanks for the clarification about trademark things earlier

  943. larma

    Ge0rG, works without for me 😀

  944. mathieui

    larma, that’s not XEP-compliant!

  945. Zash

    The XEP clearly says that it must be the 4 characters '/', 'm', 'e' and ' '

  946. stpeter

    jonas’ - my pleasure (I mostly respond to GitHub pings, obviously)

  947. jonas’

    result-ish things

  948. larma

    Zash, I can still do without, I also tend to use /me inside a sentence

  949. Alex

    4) Announcement of Voting Results

  950. David Cridland

    jonas’, Your Refresh-Fu is mighty.

  951. j.r has left

  952. Alex

    are you ready?

  953. jonas’ drumrolls

  954. j.r has joined

  955. mathieui drumrolls more

  956. Alex

    when you refresh the page at: https://wiki.xmpp.org/web/Meeting-Minutes-2019-11-21#Announcement_of_Voting_Results you can see the results

  957. David Cridland

    Well, that's fun. Maybe I should have actually voted for myself. :-)

  958. Zash

    dun dun DUN!

  959. jonas’


  960. jonas’

    congrats everyone

  961. jonas’

    this is going to be a fun round of things

  962. Alex

    top 5 for counsil are: Georg Lukas Daniel Gultsch Jonas Schäfer Kim Alvefur Dave Cridland

  963. jonas’

    is board also fixed at 5 members?

  964. Link Mauve

    Wow, congrats everyone!

  965. David Cridland

    jonas’, It is.

  966. Zash


  967. larma

    Alex, I think you should remove the "No" column, as no Yes is not the same as a No

  968. jonas’

    ah, I could’ve inferred that if I was able to count

  969. jonas’

    larma, I was thinking the same thing earlier

  970. Alex

    Top 5 for board is: Matthew Wild Guus der Kinderen Ralph Meijer Severino Ferrer de la Peñita Maxime Buquet

  971. Alex

    congrats to everyone

  972. stpeter

    jonas’ - in the far past we had boards with more people, but then we settled on 5

  973. Ge0rG

    If it's not the same, they aren't redundant, are they?

  974. mathieui

    congrats to the new board!

  975. stpeter

    Voting was difficult this time - so many good candidates!

  976. Alex

    and thanks to everyone who applied and did not make it this time as well

  977. Daniel has left

  978. jonas’

    stpeter, agreed

  979. David Cridland

    Alex, Most of all, thanks to you for running the election once again.

  980. Alex

    stpeter, agreed. Was recasting and chaning my mind a couple of times ;-)

  981. Zash

    Thanks Alex!

  982. jonas’

    +1 Zash

  983. Ge0rG

    Congratulations to the winners and thanks for your trust!

  984. stpeter


  985. mathieui

    oh congrats to new council as well, I missed that message

  986. stpeter

    Alex should get an award of some kind. :-)

  987. jonas’

    he should

  988. David Cridland

    For Board, I spent ages picking, and once I'd finally cast my vote realised I hadn't voted for myself.

  989. mathieui


  990. Ge0rG

    An xmpp badge!

  991. David Cridland

    So yeah, lots of very good candidates.

  992. Alex

    stpeter, I got, last year in brussels

  993. Alex

    the famous hat

  994. Ge0rG

    David Cridland: it would've been very interesting if you had ended up on both top 5 lists

  995. Ge0rG

    Alex: The ~taking~ voting hat?

  996. Ge0rG

    Alex: The ~talking~ voting hat?

  997. David Cridland

    Ge0rG, Dont it before, it's not a lot of fun, so I'm quite glad I didn't this time aorund.

  998. David Cridland

    Ge0rG, Done it before, it's not a lot of fun, so I'm quite glad I didn't this time around.

  999. mukt2 has joined

  1000. mathieui

    yeah, that sounds like a lot of work to be in both

  1001. David Cridland

    Ge0rG, Of course, it's a little disappointing not to be voted in, so mixed feelings.

  1002. jonas’

    shall we agree on a time for a first meeting real quick, David Cridland, Ge0rG and Zash? (I’m trying to summon daniel)

  1003. Daniel has joined

  1004. Alex

    The famous Jabber hat, someone may have a picture of that

  1005. Alex

    5) Any other Business?

  1006. David Cridland

    jonas’, After the meeting, sure.

  1007. jonas’

    David Cridland, wfm

  1008. Ge0rG

    Is that allowed? I was under the impression that you have to decide on one, which is rather political considering that by that time you know who gets shifted into either list

  1009. jonas’

    Alex, none from me

  1010. 8311 has joined

  1011. David Cridland

    Alex, Tempting as it is to propose some arcane motion, none from me either.

  1012. Ge0rG

    Alex: I had some controversial ideas regarding the start of a new council / board period, but was too lazy to make a text proposal for bylaws

  1013. Alex

    6) Formal Adjournment

  1014. David Cridland

    Alex, Once again, thanks very much.

  1015. Alex

    I motion that we adjourn

  1016. Zash


  1017. jonas’


  1018. Alex bangs the gavel

  1019. jonas’

    Thanks for doing the things with the numbers and stuff, Alex

  1020. Alex

    thanks everyone

  1021. Ge0rG

    Thanks Alex

  1022. jonas’

    David Cridland, Ge0rG, Zash, Daniel, usual time, usual place worksforme.

  1023. Ge0rG

    jonas’: I suggest the same

  1024. jonas’

    (being 16:00Z xmpp:council@muc.xmpp.org)

  1025. jonas’

    (being Wed 16:00Z xmpp:council@muc.xmpp.org)

  1026. Zash


  1027. David Cridland

    That's fine by me.

  1028. Ge0rG

    David Cridland: with you being a very close sixth, we of course expect you to move forward with your board ideas by proposing them to the elected board!

  1029. j.r has left

  1030. j.r has joined

  1031. David Cridland

    Ge0rG, And then running away and not helping? Traditional...

  1032. Alex


  1033. Ge0rG

    David Cridland: isn't that how everything works?

  1034. Ge0rG

    (okay, maybe "work" is not an adequate term in all of its meanings)

  1035. David Cridland

    Ge0rG, Sadly. But no, I'll put together a concrete proposal for the conferences stuff. Looking around at improving our discussion of public record is a little harder - that's a lot of work to do without any likelihood of it going anywhere.

  1036. stpeter

    David Cridland: what do you have in mind for "our discussion of public record"?

  1037. calvin has left

  1038. Guus

    Hello everyone. I managed to miss the meeting almost exactly. Thanks for getting it all organized once again, Alex!

  1039. David Cridland

    stpeter, I don't have anything in particular, but discussion about XEPs etc are fragmented across Github, the mailing list, and here (at least).

  1040. David Cridland

    stpeter, Makes it very hard to track as a Council person, and feels very cliquey I suspect as a newcomer.

  1041. jonas’

    FTR, editors try to force technical discussions away from github

  1042. stpeter


  1043. jonas’

    but that doesn’t solve the chat issue indeed

  1044. jonas’

    Ok, I have to leave now, you can ping me if the usual time doesn’t work for anyone, I’m rather flexible.

  1045. David Cridland

    jonas’, Yeah, and I'm not sure we should be "banning" discussion in chatrooms. Seems very ironic.

  1046. jonas’

    David Cridland, indeed

  1047. 8311 has left

  1048. stpeter

    We're not the only ones feeling the tension here - I've seen this in W3C and IETF, too.

  1049. calvin has joined

  1050. David Cridland

    stpeter, For sure. Had lengthy chats with Joe Hildebrand a while back about this. It's not helped by the likes of Google making traditional mailing lists difficult from both a UX and technical perspective.

  1051. Zash

    I hope I've made it clear that I don't think an account at some non-federated service should be required for participantion. 🙂

  1052. 8311 has joined

  1053. COM8 has joined

  1054. David Cridland

    Zash, Absolutely not. But equally, I have very few answers at the moment, just noting problems.

  1055. COM8 has left

  1056. moparisthebest

    if you are talking about DKIM etc, the mailing list just needs configured correctly

  1057. moparisthebest

    I'm not sure if the XSF's are or not at this moment

  1058. Zash


  1059. Zash

    I thought it was about the discussions being spread out over various places and hard to find

  1060. moparisthebest

    I was responding to "It's not helped by the likes of Google making traditional mailing lists difficult from both a UX and technical perspective."

  1061. Zash

    We need in-reply-to !

  1062. pdurbin has joined

  1063. David Cridland

    moparisthebest, No - DKIM deliberately breaks mailing lists, so you have to configure them incorrectly. But it's more that the average developer is unlikely to have come across a mailing list before, and Gmail et al don't offer any support for them, so they're pretty arcane to use.

  1064. Ge0rG

    Also it would be great to be able to tag certain things as "belongs to XEP 45", after the discussion took place

  1065. moparisthebest

    yea, XSF mailing lists do break DKIM, they should stop doing that

  1066. Ge0rG

    Maybe we need XSF Wave?

  1067. stpeter


  1068. Zash

    MUC full-text search?

  1069. Ge0rG

    Zash: and XEP tags as reactions?

  1070. Zash

    We do have archives that go way back (modulo disk crash loss)

  1071. Ge0rG

    ...for whole threads

  1072. David Cridland

    moparisthebest, Seriously, it's the other way around. DKIM was created by Google, Facebook, etc without regard to mailing lists (and if they thought about them at all, it was in order to break them).

  1073. jonas’

    moparisthebest, no, David Cridland has got it right ;)

  1074. mukt2 has left

  1075. mukt2 has joined

  1076. jonas’

    I was under the impression that DKIM was created by Amazon, Paypal etc (transactional mail users) without regard for any type of non-transactional mail though

  1077. Zash

    and Yahoo?

  1078. moparisthebest

    here's just the first result for a search about how to fix mailing lists https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html

  1079. jonas’

    moparisthebest, but that breaks mailing lists

  1080. moparisthebest

    all decently modern MTAs support all those things, so mailing lists won't be broken in any way

  1081. moparisthebest

    I mean I can complain about how IP isn't a crypto-routed authenticated encrypted protocol by default, and refuse to use IP until google fixes it

  1082. 8311 has left

  1083. moparisthebest

    or I can just bite the bullet and use IP as-is

  1084. waqas

    Didn't modern Mailman default to 'STRIP_DKIM_SIGNATURE = Yes'?

  1085. moparisthebest

    fix the mailing list already, DKIM/DMARC is never going away

  1086. David Cridland

    It's all a moot point anyway - my point was more than the UX sucks for most people.

  1087. 8311 has joined

  1088. pdurbin has left

  1089. Zash

    Everything is terrible, news at 11

  1090. moparisthebest

    right UX is a different discussion

  1091. neshtaxmpp has left

  1092. moparisthebest

    but it'd be nice if the XSF mailing list actually delivered mail reliably to people

  1093. moparisthebest

    seems like a bad tradeoff for adding this at the bottom of each mail: Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-unsubscribe@xmpp.org

  1094. moparisthebest

    isn't that useless?

  1095. moparisthebest

    useless because https://tools.ietf.org/html/rfc2369 and https://tools.ietf.org/html/rfc2919 have been around about as long as XMPP that is

  1096. Maranda has left

  1097. Maranda has joined

  1098. David Cridland

    moparisthebest, And 90% of MUAs people actually use don't support them. :-/

  1099. stpeter

    I have no objections to removing the footer, especially on the standards@ list (it can be useful for lists where less technical people subscribe).

  1100. moparisthebest

    David Cridland, I would have imagined 90% of MUAs is just gmail, and they support it ?

  1101. moparisthebest

    actually now I'm curious which don't support it

  1102. David Cridland

    moparisthebest, 2369 isn't supported by Gmail, isn it? I think 2919 is, but only in as much as Google filters based on it automatically.

  1103. moparisthebest

    David Cridland, https://support.google.com/mail/answer/81126?hl=en

  1104. David Cridland

    In any case, mailing lists, and email in general, is not ideal.

  1105. moparisthebest

    that's support for 2369 List-Unsubscribe

  1106. 8311 has left

  1107. David Cridland

    AH, that's RFC 8058, which I'd never even seen before.

  1108. pep.

    "David Cridland> Of course, it's a little disappointing not to be voted in, so mixed feelings.", I agree. I was seeing you in at least one of them

  1109. pep.

    Wait you are, I didn't interpret your message correctly :p

  1110. moparisthebest

    ah indeed, I was just searching List-Unsubscribe, wonder what the difference is...

  1111. marc_ has joined

  1112. David Cridland

    pep., Oh, I'm on Council still. Just!

  1113. David Cridland

    pep., But not Board.

  1114. moparisthebest

    oh, 8058 seems to just be "2369 List-Unsubscribe except do it with a single click instead of a confirmation page" ?

  1115. Calvin has joined

  1116. mukt2 has left

  1117. moparisthebest

    this is about a year old https://litmus.com/blog/the-ultimate-guide-to-list-unsubscribe if it's accurate, iOS Mail, gmail, outlook.com, and yahoo all support List-Unsubscribe as a mailto, like we have in our DKIM breaking footer

  1118. Cosmo has joined

  1119. jubalh has left

  1120. 8311 has joined

  1121. mukt2 has joined

  1122. Calvin has left

  1123. adiaholic has left

  1124. Cosmo has left

  1125. jubalh has joined

  1126. adiaholic has joined

  1127. 8311 has left

  1128. Nekit has left

  1129. stpeter has left

  1130. 8311 has joined

  1131. marc_ has left

  1132. 8311 has left

  1133. David Cridland has left

  1134. mukt2 has left

  1135. sonny has left

  1136. sonny has joined

  1137. Wojtek has left

  1138. calvin has left

  1139. mukt2 has joined

  1140. LNJ has left

  1141. calvin has joined

  1142. pep.

    So hmm, board keeps the same meeting dates I guess? Nothing was mentioned

  1143. kokonoe has left

  1144. mukt2 has left

  1145. Ge0rG

    pep.: it's up to new board to decide

  1146. pep.

    I know, it's just almost the same as last time and nobody said anything.

  1147. pep.

    I'm curious.

  1148. kokonoe has joined

  1149. Ge0rG

    pep.: you might say whether the usual time works for you and then just see what happens

  1150. kokonoe has left

  1151. kokonoe has joined

  1152. jubalh has left

  1153. jubalh has joined

  1154. calvin has left

  1155. alexis has joined

  1156. typikol has joined

  1157. j.r has left

  1158. j.r has joined

  1159. alexis has left

  1160. alexis has joined

  1161. pdurbin has joined

  1162. alexis has left

  1163. zukzuk has left

  1164. calvin has joined

  1165. jubalh has left

  1166. stpeter has joined

  1167. pdurbin has left

  1168. jubalh has joined

  1169. j.r has left

  1170. j.r has joined

  1171. alexis has joined

  1172. j.r has left

  1173. j.r has joined

  1174. typikol has left

  1175. Yagiza has left

  1176. lovetox has left

  1177. krauq has left

  1178. krauq has joined

  1179. j.r has left

  1180. stpeter has left

  1181. j.r has joined

  1182. mukt2 has joined

  1183. mukt2 has left

  1184. Douglas Terabyte has joined

  1185. calvin has left

  1186. calvin has joined

  1187. goffi has left

  1188. Tobias has left

  1189. stpeter has joined

  1190. Tobias has joined

  1191. calvin has left

  1192. kokonoe has left

  1193. stpeter has left

  1194. kokonoe has joined

  1195. marc_ has joined

  1196. alexis has left

  1197. wurstsalat has left

  1198. waqas has left

  1199. waqas has joined

  1200. andrey.g has left

  1201. waqas has left

  1202. pdurbin has joined

  1203. lorddavidiii has left

  1204. marc_ has left

  1205. jubalh has left

  1206. pdurbin has left