XSF Discussion - 2019-11-21


  1. moparisthebest

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

  2. pep.

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

  3. moparisthebest

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

  4. 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? :/

  5. 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.

  6. 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)

  7. stpeter

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

  8. 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?

  9. rion

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

  10. rion

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

  11. 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

  12. flow

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

  13. flow

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

  14. 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

  15. Guus

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

  16. Guus

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

  17. jonas’

    not

  18. David Cridland

    Guus, disco#search

  19. David Cridland

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

  20. 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?

  21. flow

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

  22. 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

  23. rion

    flow: yes two file transfers in the same jingle session

  24. rion

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

  25. 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?

  26. Zash

    Guus: Make a serverside thing that keeps track?

  27. rion

    tcp timeouts

  28. Zash

    Like the MIX PAM thing

  29. 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?

  30. rion

    flow: I believe there are many such ambiguity cases

  31. 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

  32. Guus

    Thanks guys

  33. jonas’

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

  34. jonas’

    (or the notification may get lost in the void)

  35. Zash

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

  36. jonas’

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

  37. jonas’

    but maybe I’m wrong

  38. jonas’

    in any case, my second point still holds :)

  39. Zash

    True

  40. Zash

    Something something perfect vs good enough?

  41. Zash

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

  42. rion

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

  43. 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

  44. rion

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

  45. flow

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

  46. rion

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

  47. rion

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

  48. flow

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

  49. flow

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

  50. rion

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

  51. rion

    I prefer the second

  52. 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

  53. rion

    yep

  54. rion

    that's the case.

  55. 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

  56. rion

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

  57. 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.

  58. 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

  59. rion

    Daniel: tried only with Gajim so far

  60. 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

  61. rion

    Daniel: does Conversations support multiple transfers in one session?

  62. 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

  63. flow

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

  64. 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?

  65. Daniel

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

  66. flow

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

  67. 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

  68. Daniel

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

  69. Zash

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

  70. Daniel

    It's probably faster

  71. 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)

  72. David Cridland

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

  73. 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

  74. rion

    David Cridland: then we need another NS in disco

  75. Daniel

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

  76. David Cridland

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

  77. rion

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

  78. David Cridland

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

  79. rion

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

  80. David Cridland

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

  81. rion

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

  82. rion

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

  83. rion

    there is no way to fix xmpp :)

  84. Zash

    Not with that attitude!

  85. Daniel

    Isn't jingle ft still draft?

  86. Daniel

    Or experimental even

  87. 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.

  88. David Cridland

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

  89. 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.

  90. rion

    for now just for ft.

  91. 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 :)

  92. 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.

  93. 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

  94. 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.

  95. 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.

  96. David Cridland

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

  97. 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

  98. 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?

  99. Zash

    I wouldn't say MUC works like that

  100. jonas’

    > and the participants' server archives the message locally wrong

  101. Zash

    MIX otoh would be closer

  102. jonas’

    yes, but MIX isn’t eventually consistent

  103. nyco

    so I want to roughly understand this Matrix replication

  104. Zash

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

  105. Holger

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

  106. 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.

  107. ralphm

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

  108. ralphm

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

  109. nyco

    yeah, more storage consumption, more bandwidth use

  110. nyco

    is that resistent to netsplits?

  111. Zash

    Random message loss due to s2s failures would eventually heal

  112. ralphm

    yes, hence the 'eventual'

  113. nyco

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

  114. Holger

    No.

  115. Zash

    nyco, nit: they're called "rooms"

  116. nyco

    sorry

  117. Zash

    Every room is hosted on every participanting homeserver.

  118. nyco

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

  119. nyco

    ok, thx

  120. Zash

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

  121. nyco

    so, merge whatN

  122. Zash

    XMPP s2s is super easy by comparison

  123. nyco

    ?

  124. Holger

    Well merges without conflict resolution.

  125. nyco

    merge of what with what?

  126. Holger

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

  127. nyco

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

  128. Zash

    Equivalent to a stanza I suppose

  129. nyco

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

  130. nyco

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

  131. 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.

  132. Zash

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

  133. Zash

    Not sure how that fits into the DAG thing

  134. nyco

    ah ok, so merges happen after netsplits?

  135. Holger

    Yes.

  136. Holger

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

  137. nyco

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

  138. Zash

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

  139. nyco

    yes

  140. David Cridland

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

  141. nyco

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

  142. Zash

    nyco, can't avoid netsplits on the Internet

  143. nyco

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

  144. nyco

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

  145. 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".

  146. nyco

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

  147. Holger

    You mean XMPP doesn't distribute rooms. Right.

  148. David Cridland

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

  149. nyco

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

  150. MattJ

    They are aliases

  151. MattJ

    The same room can have multiple different addresses

  152. nyco

    oh

  153. David Cridland

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

  154. MattJ

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

  155. nyco

    MattJ can give examples of Matrix rooms addresses aliases?

  156. MattJ

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

  157. nyco

    got it

  158. MattJ

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

  159. nyco

    thx

  160. MattJ

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

  161. nyco

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

  162. nyco

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

  163. MattJ

    Each server keeps a mapping

  164. MattJ

    A jolly good question :)

  165. nyco

    meh

  166. MattJ

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

  167. nyco

    uniqueness and human-readability

  168. nyco

    well... "meh" again

  169. 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.

  170. 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

  171. MattJ

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

  172. Zash

    This reminds me of IRC netsplit merge algorithms

  173. nyco

    wow...

  174. MattJ

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

  175. MattJ

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

  176. Zash

    Is that what room versions are?

  177. Zash

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

  178. MattJ

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

  179. MattJ

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

  180. MattJ

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

  181. Zash

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

  182. MattJ

    Yeah

  183. Zash

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

  184. nyco

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

  185. 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?

  186. Zash

    nyco: Yes

  187. Zash

    Fairly simple RESTful BOSH+MAM like thing

  188. 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

  189. Zash

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

  190. 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.

  191. nyco

    exactly

  192. nyco

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

  193. Zash

    XMPP-FTW?

  194. nyco

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

  195. Zash

    nyco, WebRTC.

  196. Zash

    Conferencing is literally Jitsi Meet in an <iframe>

  197. Zash

    Dunno what the 1-to-1 calls are tho

  198. nyco

    ok... I was not sure

  199. nyco

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

  200. Zash

    And Jitsi Meet embeds Prosody! 😀

  201. nyco

    so Matrix has XMPP in their core :)

  202. nyco

    MatriXMPP

  203. nyco

    ok, thx all! :)

  204. Guus

    Jitsi meet uses XMPP internally

  205. nyco

    so yeah, what's that part? MUCs?

  206. Zash

    MUC. LDAP authentication.

  207. nyco

    thx

  208. Zash

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

  209. nyco

    thx

  210. 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(?)

  211. Guus

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

  212. 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.

  213. 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

  214. Guus

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

  215. pep.

    I don't understand

  216. 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.

  217. 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)

  218. pep.

    I see

  219. pep.

    dunn othen

  220. pep.

    dunno then

  221. Guus

    Board meeting time/

  222. Guus

    ah, yes.

  223. Guus

    nice.

  224. ralphm bangs gavel

  225. ralphm

    0. Welcome + Agenda

  226. ralphm

    Welcome to the last Board meeting of this term!

  227. Guus

    Seve mentioned that he might not make todays meeting.

  228. ralphm

    I think we can do this fast.

  229. ralphm

    Indeed

  230. ralphm

    nyco, MattJ?

  231. nyco

    yep

  232. MattJ

    Here

  233. ralphm

    1. Minute taker

  234. nyco

    me

  235. ralphm

    yay

  236. nyco

    but please do help me

  237. ralphm

    2. License for website content

  238. 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.

  239. nyco

    ah, that would be clear

  240. 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)

  241. nyco

    https://mensuel.framapad.org/p/6E9JDfCF5L-XSF-Board-Meeting-2019-11-21

  242. ralphm

    but Peter would probably know more about this.

  243. Guus

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

  244. Guus

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

  245. ralphm

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

  246. ralphm

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

  247. MattJ

    wfm

  248. Guus

    ok

  249. ralphm

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

  250. pep.

    Who is actionable for this?

  251. Guus

    (pinging stpeter ...)

  252. pep.

    badly worded

  253. ralphm

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

  254. pep.

    Thanks

  255. ralphm

    3. Task Boards

  256. ralphm

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

  257. pep.

    I guess this can move to next board?

  258. ralphm

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

  259. nyco

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

  260. Guus

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

  261. MattJ

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

  262. pep.

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

  263. MattJ

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

  264. 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.

  265. MattJ

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

  266. MattJ

    For now at least

  267. nyco

    why veto as iTeam?

  268. Guus

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

  269. MattJ

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

  270. ralphm

    And iteam is spread a bit thin already

  271. nyco

    clear

  272. MattJ

    Have you seen the wiki recently? :)

  273. Zash

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

  274. nyco

    I edit the wiki, so yes, why?

  275. MattJ

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

  276. nyco

    oh about obsolete version? yes

  277. nyco

    ok then

  278. Guus

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

  279. nyco

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

  280. pep.

    Otherwise.. there's the mailing list :)

  281. 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

  282. nyco

    ok

  283. 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.

  284. nyco

    ok

  285. nyco

    no need to vote then?

  286. ralphm

    I don't think so.

  287. ralphm

    4. Other items on the trello board

  288. nyco

    badge, adopt character?

  289. ralphm

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

  290. Guus

    why put off the adopt a character thing?

  291. nyco

    put off?

  292. Guus

    put off discussing it now.

  293. nyco

    oh

  294. 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.

  295. nyco

    we chose one, the process was not clear

  296. nyco

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

  297. Zash

    Marketing marketing marketing?

  298. Guus

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

  299. nyco

    what about marketing marketing marketing?

  300. Seve

    Deciding for a specific character is where we are now

  301. nyco

    yes, let's discuss the adoption

  302. Guus

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

  303. nyco

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

  304. ralphm

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

  305. ralphm

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

  306. 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.

  307. nyco

    field day?

  308. ralphm

    nyco, look it up

  309. nyco

    look it up?

  310. nyco

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

  311. ralphm

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

  312. Guus

    I'm happy for commsteam to pick one.

  313. Guus

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

  314. Guus

    and if so, for what level.

  315. Seve

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

  316. ralphm

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

  317. nyco

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

  318. ralphm

    nyco: whatever, again

  319. nyco

    which is not wrong, btw :)

  320. ralphm

    I'll try hunt it down in the logs.

  321. Guus

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

  322. nyco

    stream... OMG :)

  323. ralphm

    Guus: I think we already picked one

  324. ralphm

    so I'll look up which one

  325. nyco

    thx ralphm

  326. ralphm

    5. AOB

  327. Guus

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

  328. Guus

    and be done?

  329. ralphm

    Naturally

  330. ralphm

    Any AOB?

  331. Guus

    cool.

  332. MattJ

    None here

  333. Guus

    AOB: it was my pleasure serving this year

  334. ralphm

    Yay!

  335. nyco

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

  336. ralphm

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

  337. MattJ

    Yes, thanks :)

  338. Zash

    Thanks yall

  339. Ge0rG

    Thank you, dear Board

  340. ralphm

    6. Date of Next

  341. ralphm

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

  342. Guus

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

  343. ralphm

    So, +1W

  344. nyco

    +1

  345. Guus

    +1w wfm

  346. ralphm

    7. Close

  347. ralphm

    Thanks, all!

  348. ralphm bangs gavel

  349. Ge0rG

    Guus: sorry, I don't understand

  350. Guus

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

  351. ralphm

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

  352. Guus

    I actually cannot 😞

  353. Guus

    maybe from mobile, but unlikely.

  354. Ge0rG

    I'll try from mobile

  355. nyco

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

  356. ralphm

    Thanks nyco

  357. Alex

    👍

  358. Guus

    nyco added one reasoning, otherwise lgtm

  359. nyco

    thx!

  360. 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.

  361. nyco

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

  362. nyco

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

  363. nyco

    dunno about iTeam

  364. nyco

    and yeah the tool is not critical

  365. MattJ

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

  366. nyco

    yes, it's fully open

  367. nyco

    huh...

  368. ralphm

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

  369. nyco

    let me check

  370. ralphm

    Our meeting board is 664.

  371. Seve

    None

  372. nyco

    > Our meeting board is 664. exactly

  373. nyco

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

  374. nyco

    there is just not an unique/official way

  375. nyco

    I send the minutes

  376. Guus

    tx

  377. pep.

    Thanks for the minutes

  378. 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 :)

  379. pep.

    board@xmpp.org is not public though..

  380. Zash

    Not used tho, they meet here

  381. pep.

    I mean the list

  382. Zash

    Oh, ah

  383. 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

  384. Ge0rG

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

  385. 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.

  386. MattJ

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

  387. MattJ

    Pidgin does this iirc

  388. Ge0rG

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

  389. MattJ

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

  390. Zash

    Directed presence could be used as a kind of temporary subscription

  391. Ge0rG

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

  392. Ge0rG

    rion: MUC-PMs are not very reliable

  393. Ge0rG

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

  394. Ge0rG

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

  395. Daniel

    Why do I see message three times?

  396. Daniel

    Why do I (not) see my own messages

  397. Zash

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

  398. 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

  399. Zash

    Why did you reply from a different JID?

  400. Ge0rG

    What's a JID?

  401. Guus

    "Can you use Whatsapp please?"

  402. Guus ducks, runs

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

  404. rion

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

  405. pep.

    Isn't that what the change says?

  406. pep.

    Hmm it doesn't say roster

  407. wurstsalat

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

  408. Kev

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

  409. Ge0rG

    I'm still sorry.

  410. Kev

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

  411. Kev

    Ge0rG: No need to be sorry.

  412. Kev

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

  413. Ge0rG

    Those users are broken.

  414. Alex

    hey guys, anyone ready for our annual meeting?

  415. jonas’

    yes

  416. jonas’

    hi Alex :)

  417. Alex

    Hi jonas

  418. Zash

    Hey

  419. mathieui

    yes, hi Alex

  420. Ge0rG

    Oh, it's the time already!

  421. Alex

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

  422. Ge0rG

    I was still feeling like CEST

  423. Alex

    ya, prime time

  424. David Cridland

    EVening all.

  425. Alex

    okay, lets start

  426. Alex bangs the gavel

  427. Alex

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

  428. Alex

    1) Call for Quorum

  429. Alex

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

  430. Alex

    2) Items Subject to a Vote

  431. Ge0rG

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

  432. Alex

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

  433. Alex

    fixing the typo now

  434. jonas’

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

  435. Alex

    🤣

  436. Alex

    3) Opportunity for XSF members to Vote in the Meeting

  437. Alex

    anyone here who has not voted via proxy yet?

  438. Alex

    looks like there are none

  439. Alex

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

  440. David Cridland

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

  441. jonas’

  442. Zash

  443. mathieui

  444. Ge0rG

  445. David Cridland

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

  446. larma

    /me

  447. stpeter

    I'm sort of here. :-)

  448. Ge0rG

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

  449. Link Mauve

    /me

  450. Link Mauve

  451. jonas’

    stpeter, thanks for the clarification about trademark things earlier

  452. larma

    Ge0rG, works without for me 😀

  453. mathieui

    larma, that’s not XEP-compliant!

  454. Zash

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

  455. stpeter

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

  456. jonas’

    result-ish things

  457. larma

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

  458. Alex

    4) Announcement of Voting Results

  459. David Cridland

    jonas’, Your Refresh-Fu is mighty.

  460. Alex

    are you ready?

  461. jonas’ drumrolls

  462. mathieui drumrolls more

  463. 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

  464. David Cridland

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

  465. Zash

    dun dun DUN!

  466. jonas’

    fun

  467. jonas’

    congrats everyone

  468. jonas’

    this is going to be a fun round of things

  469. Alex

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

  470. jonas’

    is board also fixed at 5 members?

  471. Link Mauve

    Wow, congrats everyone!

  472. David Cridland

    jonas’, It is.

  473. Zash

    Woop

  474. larma

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

  475. jonas’

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

  476. jonas’

    larma, I was thinking the same thing earlier

  477. Alex

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

  478. Alex

    congrats to everyone

  479. stpeter

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

  480. Ge0rG

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

  481. mathieui

    congrats to the new board!

  482. stpeter

    Voting was difficult this time - so many good candidates!

  483. Alex

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

  484. jonas’

    stpeter, agreed

  485. David Cridland

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

  486. Alex

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

  487. Zash

    Thanks Alex!

  488. jonas’

    +1 Zash

  489. Ge0rG

    Congratulations to the winners and thanks for your trust!

  490. stpeter

    +2

  491. mathieui

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

  492. stpeter

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

  493. jonas’

    he should

  494. David Cridland

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

  495. mathieui

    +3

  496. Ge0rG

    An xmpp badge!

  497. David Cridland

    So yeah, lots of very good candidates.

  498. Alex

    stpeter, I got, last year in brussels

  499. Alex

    the famous hat

  500. Ge0rG

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

  501. Ge0rG

    Alex: The ~taking~ voting hat?

  502. Ge0rG

    Alex: The ~talking~ voting hat?

  503. David Cridland

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

  504. David Cridland

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

  505. mathieui

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

  506. David Cridland

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

  507. jonas’

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

  508. Alex

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

  509. Alex

    5) Any other Business?

  510. David Cridland

    jonas’, After the meeting, sure.

  511. jonas’

    David Cridland, wfm

  512. 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

  513. jonas’

    Alex, none from me

  514. David Cridland

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

  515. 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

  516. Alex

    6) Formal Adjournment

  517. David Cridland

    Alex, Once again, thanks very much.

  518. Alex

    I motion that we adjourn

  519. Zash

    +1

  520. jonas’

    +1

  521. Alex bangs the gavel

  522. jonas’

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

  523. Alex

    thanks everyone

  524. Ge0rG

    Thanks Alex

  525. jonas’

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

  526. Ge0rG

    jonas’: I suggest the same

  527. jonas’

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

  528. jonas’

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

  529. Zash

    wfm

  530. David Cridland

    That's fine by me.

  531. 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!

  532. David Cridland

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

  533. Alex

    LOL

  534. Ge0rG

    David Cridland: isn't that how everything works?

  535. Ge0rG

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

  536. 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.

  537. stpeter

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

  538. Guus

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

  539. 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).

  540. David Cridland

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

  541. jonas’

    FTR, editors try to force technical discussions away from github

  542. stpeter

    ah

  543. jonas’

    but that doesn’t solve the chat issue indeed

  544. jonas’

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

  545. David Cridland

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

  546. jonas’

    David Cridland, indeed

  547. stpeter

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

  548. 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.

  549. 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. 🙂

  550. David Cridland

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

  551. moparisthebest

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

  552. moparisthebest

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

  553. Zash

    Hm?

  554. Zash

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

  555. 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."

  556. Zash

    We need in-reply-to !

  557. 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.

  558. Ge0rG

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

  559. moparisthebest

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

  560. Ge0rG

    Maybe we need XSF Wave?

  561. stpeter

    niiice

  562. Zash

    MUC full-text search?

  563. Ge0rG

    Zash: and XEP tags as reactions?

  564. Zash

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

  565. Ge0rG

    ...for whole threads

  566. 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).

  567. jonas’

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

  568. 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

  569. Zash

    and Yahoo?

  570. 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

  571. jonas’

    moparisthebest, but that breaks mailing lists

  572. moparisthebest

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

  573. 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

  574. moparisthebest

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

  575. waqas

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

  576. moparisthebest

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

  577. David Cridland

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

  578. Zash

    Everything is terrible, news at 11

  579. moparisthebest

    right UX is a different discussion

  580. moparisthebest

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

  581. 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

  582. moparisthebest

    isn't that useless?

  583. 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

  584. David Cridland

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

  585. 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).

  586. moparisthebest

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

  587. moparisthebest

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

  588. 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.

  589. moparisthebest

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

  590. David Cridland

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

  591. moparisthebest

    that's support for 2369 List-Unsubscribe

  592. David Cridland

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

  593. 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

  594. pep.

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

  595. moparisthebest

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

  596. David Cridland

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

  597. David Cridland

    pep., But not Board.

  598. moparisthebest

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

  599. 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

  600. pep.

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

  601. Ge0rG

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

  602. pep.

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

  603. pep.

    I'm curious.

  604. Ge0rG

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