XSF logo 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’ not
  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 True
  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 yep
  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 No.
  356. Zash nyco, nit: they're called "rooms"
  357. nyco sorry
  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 Yes.
  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 yes
  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 oh
  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 thx
  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 meh
  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 wow...
  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 Yeah
  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 exactly
  437. mukt2 has left
  438. nyco on a C2S API, you would have to map the entire XMPP protocol
  439. Zash XMPP-FTW?
  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 MatriXMPP
  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 thx
  457. Zash https://github.com/jitsi/docker-jitsi-meet#architecture might be a good starting point if you wanna look closer
  458. nyco thx
  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 nice.
  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 Indeed
  532. ralphm nyco, MattJ?
  533. nyco yep
  534. MattJ Here
  535. ralphm 1. Minute taker
  536. nyco me
  537. ralphm yay
  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 https://mensuel.framapad.org/p/6E9JDfCF5L-XSF-Board-Meeting-2019-11-21
  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 wfm
  551. Guus ok
  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. Thanks
  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 clear
  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 ok
  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 ok
  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 oh
  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 Naturally
  649. COM8 has left
  650. ralphm Any AOB?
  651. Guus cool.
  652. MattJ None here
  653. Guus AOB: it was my pleasure serving this year
  654. ralphm Yay!
  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 +1
  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 thx!
  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 huh...
  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 None
  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 tx
  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’ yes
  903. jonas’ hi Alex :)
  904. Alex Hi jonas
  905. Zash Hey
  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 /me
  938. stpeter I'm sort of here. :-)
  939. Ge0rG larma: you are missing the trailing space, aren't you?
  940. Link Mauve /me
  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’ fun
  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 Woop
  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 +2
  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 +3
  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 +1
  1017. jonas’ +1
  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 wfm
  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 LOL
  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 ah
  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 Hm?
  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 niiice
  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