XSF Discussion - 2019-11-22

  1. Seve

    I was not able to be here for yesterday's meeting due to my work, much to my regret. I would like to congratulate new Council&Board! Hope they give the best of them! :) Also thank you very much Alex!

  2. Guus

    On that note: Zash Daniel pep. I have created separate issues for each of you to provide a bio for our website. Be fast, or run the risk of me making one up for you 😆

  3. Guus

    (I didn't miss anyone on that list, did I?)

  4. Guus

    MattJ If you haven't thought about that yet: could you make sure that the relevant mailing lists (board@ is one, unsure if we have others) and github permissions are updated?

  5. MattJ

    Yes, I have some time this afternoon, I'll do it then

  6. Guus


  7. Guus

    pep. can you confirm your Trello username? I'll add that to the Trello board for Board

  8. MattJ

    While I'm in mailman I'll see to removing the footer from standards@ unless someone has a sensible objection

  9. Ge0rG

    Guus: you might be able to retrieve Daniel's bio from git history

  10. Guus

    Ge0rG I already suggested that in the issue

  11. Guus

    unsure if Daniel wants to see it updated.

  12. Ge0rG

    Ah, perfect

  13. Guus

    but I provided the old text for him

  14. Guus is trying to think of other things that need an update

  15. Guus

    oh, wikipedia lists people too, I believe

  16. Guus

    updated Wikipedia

  17. Guus

    ... anything else?

  18. Guus

    Unrelated, but trying to benefit from MattJ's window of opportunity: This issue seems worthy of a redirect of sorts https://github.com/xsf/xmpp.org/issues/651

  19. MattJ

    I'll see :)

  20. flow

    feels like this election would have benefited from condorcet voting, something like https://civs.cs.cornell.edu/

  21. flow

    although it wouldn't automtically help with ties, I think it would have helped people to express their opinion and especially from preventing them from strategic voting (cast less than 5 votes), which may be one reason why we have so many 'No' votes

  22. jonas’

    flow, what?

  23. jonas’

    I thought No just means "did not explicitly vote for them"

  24. jonas’

    seems to be confirmed by yes+no always being equal to 39

  25. jonas’

    (which is the number of folks who voted

  26. jonas’

    (which is the number of folks who voted)

  27. Ge0rG

    I was also under the impression that you only can say "yes" or "no", and not None

  28. jonas’

    Ge0rG, you can "abstain" for one or more of your votes

  29. jonas’

    which probably counts as one less "yes"

  30. jonas’

    (and one more "no")

  31. flow

    jonas’, that

  32. flow

    you are not forced to cast 5 yes votes

  33. Ge0rG

    but if "abstain" means "no", what's the difference?

  34. jonas’

    Ge0rG, when you abstain, you discard one of your "yes" votes

  35. Ge0rG


  36. jonas’

    flow, ah, indeed, not everyone used their five votes

  37. Ge0rG

    so you could just vote "no" for everybody

  38. jonas’

    specifically, we have 12 abstainations(?!) for Board

  39. jonas’

    Ge0rG, correct

  40. jonas’

    and even 21 for Council

  41. jonas’

    now I wonder whether I’m doing this wrong

  42. jonas’

    39*5 - sum(yes votes for body)?

  43. Guus

    Counting is fun.

  44. jonas’

    flow, irrespective of that, yes, I also thought that we should maybe use a different system for the body elections

  45. jonas’

    I’m not sure if a process geared towards finding the (one) best choice of a set of choices is correct for a thing where we elect the top N choices

  46. jonas’

    voting is hard

  47. Guus

    I suggest you make your case on the mailinglist, outlining benefits over the current process.

  48. flow

    I just voted in the Jenkins election and they use for example civs.cs.cornell.edu

  49. jonas’

    ah, they support the Schulze method

  50. jonas’

    and MAM :-X

  51. jonas’


  52. flow

    I am not saying that we should use that particular system from cornell, but condorcet voting sure seems desirable

  53. Ge0rG

    Is it just me, or is every system that we usually only tangentially need, infinitely complex when looked at?

  54. flow

    It's just you and the other guy

  55. Ge0rG


  56. Ge0rG

    Who's the other guy?

  57. Daniel

    Yeah I suggested ranked voting *before* we actually voted

  58. Daniel

    And I'd be fine switching to something like that. Probably something new board can decide on

  59. jonas’

    FTR, I have pondered this for a while and this is not in response to current results. More in response to the difficulty of casting votes though.

  60. Daniel

    That said I don't see the problem with not giving away all five yes votes. If you only think four people can do the job

  61. Daniel

    (yes I brought this up when we were talking about ties)

  62. flow

    Daniel, I don't think the rationale for casting less than five votes is not that people believe that only <5 people can do the job, but that you really want those 3 people in council

  63. Alex

    Guus: have you updated mailing lists for board & council?

  64. Alex

    Or should I take care of that? Not sure if I have the keys to them ;-)

  65. Guus

    Alex I have no access. If you can, please! If you can't either, MattJ will have a look later today.

  66. ralphm

    I agree the 'no' counts are not really proper.

  67. pep.

    "flow> feels like this election would have benefited from condorcet voting", I'm also in favor of Ranked-choice voting fwiw.

  68. pep.

    Atm there's no way to distinguish between no and absent

  69. Kev

    ralphm: Not 'proper' in what sense?

  70. Kev

    Not optimal, or actually improper by our bylaws?

  71. pep.

    Kev, in the current system there's no difference between "I don't want that person" and "I don't know"

  72. pep.

    (no / blank)

  73. Kev

    I think that's consistent with the bylaws at the moment.

  74. pep.

    Sure, that doesn't excuse it

  75. Kev

    Well, it does excuse the voting system, yes.

  76. pep.

    That doesn't excuse the fact that we're not looking for something better

  77. Kev

    The voting system does what the bylaws require of it. It's the bylaws that we want to change for a different approach, not just memberbot.

  78. Kev

    And yes, the current approach is daft, given the joint requirements of 5 people, and each having a majority vote.

  79. larma

    I tried to explain Alex yesterday why I think the voting was not conducted in compliance with bylaws. He didn't agree with my assessment on bylaws compliance but he did agree that the voting system breaks when you start to have significantly more than 5 candidates, so imo we definitely should change it before next election

  80. Alex

    Third, the individuals elected shall be those receiving the highest percentage of votes cast, up to the limit set by the Members and with the proviso that no individual receiving less than a majority of votes cast shall be elected.

  81. Alex

    larma: Thanks for bringing it up here

  82. Kev

    larma: Yes, that's the daftness.

  83. Alex

    This section of the bylways can be an issue when we have a large pool of applicants

  84. Kev


  85. ralphm

    Kev: I mean that we only vote 'yes' for candidates. Not 'no'.

  86. ralphm

    Kev: so I'd display it differently, not change the outcome.

  87. pep.

    I would be willing to change it for the next elections

  88. Kev

    Actually, I take back my previous assessment. The bylaws continue to function, it's the memberbot that's not right.

  89. Kev

    The bylaws don't say that an individual is only allowed to vote 'yes' to the maximum number of people on Board/Council.

  90. Kev

    If you remove that restriction from memberbot, the system continues to function with a large pool.

  91. ralphm

    That is true, we could totally have a range voting system.

  92. Kev

    You don't need range voting for it to work.

  93. Kev

    Just an unlimited number of 'Yes' votes.

  94. ralphm

    With choices like 0 and 1, or even -1, 0, 1

  95. Kev

    Then 'pick the ones with the most votes, with not less than half' works.

  96. ralphm

    I would personally like to have the option of explicitly expressing my disapproval of a candidate.

  97. Kev

    Although I admit that range voting might make it better.

  98. Alex

    Kev: how do you define less than half?

  99. Kev

    I think there's two questions. 1) What would make the current system non-broken (and I think it's a memberbot change, not a bylaws change) 2) what would the most appropriate system be.

  100. ralphm

    Alex: if you have to vote -1, 0, or 1 for each candidate, less than half is the tally going below 0.

  101. Kev

    Alex: Under the current system, it's half the number of members voting.

  102. pep.

    Is there any record of member not voting btw? Alex. I'm looking at §2.6

  103. Kev vanishes back to work.

  104. larma

    It is my interpretation of the bylaws that I must be able to vote on each candidate or decide to not vote (abstain) from the vote of each candidate

  105. ralphm

    We have indeed expelled people for not voting thrice in a row. But I think that was a long time ago.

  106. Alex

    pep., yes, some where removed in the past for not voting. I don't like this rule either. Its a lot of admin work with little value for me. Because they can just get voted in again the next quarter, and this happened before

  107. pep.

    I don't mind this rule. It asks for a minimum of contribution, which is really not much

  108. ralphm

    The idea here was that voting for Council, Board is just about the only obligation Members have, and if you can't even be bothered to do that three times in a row, maybe you should not be a member.

  109. ralphm

    However, for that to work, it needs to be made visible that people did indeed get removed, so that in such next elections, voters can weigh that in their choices.

  110. ralphm

    (voting for Council, Board, *and Members*)

  111. larma

    > Because they can just get voted in again the next quarter We should have a "blame list" then, so that people are aware that they were removed for that reason.

  112. larma

    What ralphm said 😀

  113. ralphm

    Well, I think it is sufficient to notify the Members mailing list.

  114. ralphm

    I don't think we should maintain a naughty list.

  115. ralphm

    Also, as I said, it has been a while since this happened.

  116. pep.

    Maybe not a naughty list

  117. pep.

    But a list of people who voted would make sense, alongside with the results, in small print or sth :)

  118. ralphm

    Meeting minutes include a list of those present, so that should suffice.

  119. ralphm

    (it includes people that voted by proxy)

  120. pep.

    ah ok

  121. ralphm

    E.g. see https://wiki.xmpp.org/web/Meeting-Minutes-2019-11-21

  122. ralphm

    Just for my understanding. Does anyone want to contest the current results, or are we just discussing possible improvements for future Council, Board elections?

  123. ralphm

    If the former, please let me know, so I can look into it.

  124. pep.

    ralphm, ok these minutes are enough to me (the list of people). And personally I'm speaking about improvements for the next elections.

  125. Alex

    board and council election only? or are there also concerns for our quarterly membership votes?

  126. Alex

    next voting is starting soon

  127. Zash

    Is now a good time to do a switcharoo with the xmpp.org Prosody?

  128. pep.


  129. larma

    I don't see a reason to contest the results. I brought up this issue in private to Alex after election to not mess with this election, but Alex told that without any decision from members being taken, he does not plan to change the procedure (I hope that summarizes it correctly). (3.13) "Second, the Members shall vote on the candidates standing for election in accordance with Section 3.9 of these Bylaws." (3.9) "Each current Member of the Corporation (other than Emeritus Members) shall be entitled to one (1) vote on each matter submitted to a vote at a meeting of the Members". -> This is what makes me assume one should be able to vote on each candidate not just a set of up to 5 candidates. Also if one votes on each candidate, each candidate becomes a matter so it should be possible to abstain from voting for each candidate. And Alex, this only affects board/council elections, I think membership votes are perfectly fine (it's clear that every member is one matter to vote on).

  130. pep.

    Well I could also see a different voting system for members, someone might still want to say no explicitely

  131. ralphm

    You already choose yes or no for each member application

  132. pep.

    (do I? I had my mind mixed up in council/board stuff..)

  133. ralphm


  134. larma

    I think the main issue is that the memberbot does not give the full flexibility of voting. But legally it is not required to, because Alex as a proxy can legally only accept whatever he wants and also he can legally completely ignore your memberbot wishes and instead vote something else for you.

  135. ralphm


  136. 8311

    hello world

  137. ralphm

    If the Membership would like to change how memberbot works for Board, Council elections, they can take a vote on this, and then Alex will happily comply.

  138. ralphm

    And of course someone needs to change the code.

  139. Alex

    Yes, I am also happy to use some other services like CIVS if we think they are a better solution for us. Or Webforms or whatever we come up with

  140. larma

    I personally would rather prefer to get rid of memberbot for voting and instead a) have people vote during the meeting as it is intended b) have people pick any proxy to vote for them during the meeting if they cannot attend. This can be any other member that is present during the meeting, we don't need to bother Alex with that. Our member meetings are basically useless because they cannot be used for what they are intended (you cannot bring up things for discussion or vote during the meeting, but have to bring up every matter to vote on before the memberbot started). It shouldn't be the default to vote by proxy, it should be the exception for when people are not able to make it to the members meeting (which only happens one time a year and is announced way in advance, so most should be able to make it even in different timezones). Member meetings should be where members meet (and not only 10% of them) Maybe we should even have the annual members meeting during the XSF Summit so that many members are already at the same physical location?

  141. Zash

    Needing to bring up things for voting way in advance is a good thing

  142. larma

    Zash, I agree, but it still should be possible to do so in the meeting. Also the exact thing to vote on could be the result of a discussion in the meeting

  143. ralphm

    larma: I don't any of this as a problem

  144. ralphm

    I don't see

  145. Alex

    only a small percentage of the members attend the summit. Members are distrubuted all over the world, and also are busy in their day jobs. I do not expect them all to join the meeting. This is also why we have proxy voting

  146. pep.

    Alex, there are different ways to do proxy voting

  147. ralphm

    larma: I agree with Zash here. It would be *very* good to plan ahead if you need to bring something up with the membership. Also, if needed, we can have additional meetings for topics during the year.

  148. larma

    Alex, "small percentage", more than attend the member meetings right now

  149. pep.

    ralphm, while I agree that bringing matters early is good, I don't like that the current implementation prevents bringing anything at all while memberbot is started. (Maybe not "at all", but it's impractical)

  150. ralphm

    Also, we don't need the annual meeting to bring up topics. This is why we have a members mailinglist, and this room, and why our board meetings are open for all, etc.

  151. ralphm

    pep. I have not yet seen a case where this has been a problem, and I prefer addressing problems after we've actually identified them.

  152. ralphm

    Or rather, actually encountered them.

  153. Ge0rG

    We do have five membership votes each year. It would be easy to add things to vote on into the next one.

  154. Ge0rG

    And to discuss them in advance on members@

  155. Alex

    ya, this is wat we have done in the past. At max it takes 3 month to get a change approved and into a vote. 3 month should not be an issue

  156. pep.

    3 months is a bit long tbh :/

  157. ralphm

    come on

  158. pep.

    isn't it?

  159. ralphm

    what thing needs changing that runs into this

  160. ralphm

    I've followed a bunch of discussions in here lately, and I feel people are in search for problems where there aren't any.

  161. pep.

    It will depend on the issue for sure, but once there is some kind of consensus on list I don't see why 3 months is required. If somebody has an issue they can reply to the thread before a vote is decided

  162. Zash

    Issues of the sort you need to get through a member vote should not be rushed

  163. ralphm

    This takes up a lot of time, without a clear benefit. We don't have to strife for perfection, just because we can.

  164. pep.

    Also I don't see a point in attaching votes to regular meetings, as mentioned above it's not necessary

  165. ralphm

    Well, I'd certainly don't see a reason to have *more* meetings, especially for the hypothetical cases we seem to be discussing.

  166. ralphm

    Let's first have an actual problem?

  167. SpaceFreak

    > much room rooms

  168. flow

    Alex, may I suggest to also put the list of members who did *not* vote into the meeting minutes? That would increase transparency and allow easier checking for a three-times not voted streak. This information is already publicly available, just not in a single place

  169. flow

    and I assume memberbot has that list already

  170. ralphm

    flow: which problem are we solving?

  171. flow

    ralphm, make it easier for everyone to determine if the rule is followed

  172. flow

    right now I have to get a list of the members at the time (from the website, out of the git, not sure if this is accurate), then the list of the members who voted from the minutes and create the list of members who did not vote

  173. flow

    that I have to do for the last three times, and see if a name/jid appears all three times

  174. SpaceFreak aka Tracer

    > ralphm, make it easier for everyone to determine if the rule is followed

  175. ralphm

    Is it because you think we have missed expelling people?

  176. flow

    ralphm, no, I just like transparency and verify things, not to blame anyone, mistakes happens

  177. flow

    and this seems like a low hanging fruit to increase the XSF's tranparency

  178. flow

    as the list probably exists in memberbot already, it should be easy to add it to the meeting minutes

  179. flow

    and it's also not leaking any data, as the data to construct the list exists publicly already

  180. ralphm

    Transparency is great. I also think there is a) underestimation on what fixing such hanging fruit means in terms on work, b) a lot of actual work that that volunteer time could actually be put to use for.

  181. ralphm

    Transparency is great. I also think there is a) underestimation on what fixing such hanging fruit means in terms of work, b) a lot of actual work that that volunteer time could actually be put to use for.

  182. Alex

    flow, in order to do that we would more data in the memberlist which we maintain in the website repo. Jids would have to be added. People have multiple jids, and sometimes vote from difefrent ids

  183. flow

    surely the memberbot has a list of jids allowed to vote, and definelty a list of jids who voted, so creating the complement should be trivial

  184. SpaceFreak aka Tracer

    Alex: i dint want that my JID is public on the web

  185. flow

    Alex, so memberbot does currently not run with the complete list of member JIDs?

  186. Alex

    and this is where the transparency stops ;-)

  187. SpaceFreak aka Tracer

    ade` transpiranyc cuz any random kek can get my jid out of the web

  188. SpaceFreak aka Tracer

    Alex: my words

  189. flow

    I would assumed that there is a single memberlist including one jid per member acting as truth somewhere, which is used as input for the memberbot

  190. Alex

    flow, no, memberbot does not have the capability to compile this list. You can find memberbots code here: https://github.com/legastero/memberbot

  191. ralphm

    flow: my point is that the XSF doesn't need to be perfect, IMHO. The information is out there, but maybe not in an optimal form. If you really care about it, write a script to compile the information in a way you think is better.

  192. ralphm

    I'd much rather focus on XMPP itself, then get multiple people bogged down to solve cosmetic issues in our procedures.

  193. ralphm

    I'd much rather focus on XMPP itself, than get multiple people bogged down to solve cosmetic issues in our procedures.

  194. SpaceFreak aka Tracer

    ralphm: i count that Jabber is 1A for communications

  195. Alex

    ralphm, 👍

  196. Guus

    For the record, I'm agreeing with ralphm largely. If we're not suffering from serious ill effects, we should consider limiting the amount of effort that goes into changing/optimizing processes.

  197. flow

    ralphm, well I don't intent to add extra work on other people, but if someone motiviated to put effort into this, why not make it better?

  198. SpaceFreak aka Tracer

    flow: because no one asked for improvement

  199. SpaceFreak aka Tracer

    may be its ok how it is now

  200. SpaceFreak aka Tracer

    get some other topic flow

  201. flow

    Open source development is largely about first finding consensus how to approach, and then finding someone to implement it, not about having other people fix your issues if they don't want to

  202. SpaceFreak aka Tracer

    > no one asked for improvement

  203. Guus

    That's not quite right, SpaceFreak aka Tracer - I've seen various members suggest changes.

  204. Guus

    so it's definitely not 'no-one' that asks for this

  205. SpaceFreak aka Tracer

    Guus: well users arent admins so :fart:

  206. flow

    So if we have consensus how this can be improved, and someone is willing to put effort into it and improve it, why stop him?

  207. Guus

    I think it's important to listen to everyone - even more so as the people that I've seen ask stuff are members of the XSF, and highly active members at that.

  208. Guus

    flow - for my part, we don't spend any effort on it. If there's a strong feeling amongst membership that we should, then I'll happily oblige.

  209. jonas’

  210. jonas’


  211. jonas’

    (sorry, that was me trying to get ssh to disconnect because wifi outage)

  212. flow

    Guus, I probably didn't express myself very well, I am sorry for that. My point was mostly that people don't have to oblige to anything, or spend time doing someting. You do not even have to particpate in the discussion(s). But as soon as we have consensus that e.g., the list if non-votes in the meeting minutes is desirable, and someone is willing to put in some effort/time and make the necessary adjustments, then there is no reason to not do it. Or am I wrong?

  213. Guus

    flow I was just saying that if it were up to me, we'd not apply many of the changes that I feel are maybe an improvement, but don't really add value. If a good deal of the membership thinks differently, then (board hat on) I'd happily conform to the wishes of the membership.

  214. Guus

    in other words: I'll happily carry out the wishes of the membership, even if I don't think certain changes are needed.

  215. Guus

    but as I don't see much added value in some of the things that have been discussed recently, I'll not spend to much time on it, unless instructed to.

  216. Guus

    (I'm happy and comfortable to recognize that I sometimes disagree with others)

  217. flow

    Ok, I wasn't expecting that board members need to state that they will carry out whishes of the membership if they do not see any harm in doing so.

  218. Guus

    I'm not sure if I understand that last sentence 🙂

  219. Guus

    If I see _harm_ in doing so, I'll try and stop whatever it is, or step down from board.

  220. flow

    Guus, I feel it's normal and nothing that needed to be stated explicitly that you agree to stuff that you do not disagree with

  221. Guus

    What we're talking about here is not something that I think is harmful - it's rather a poor return on investment.

  222. flow

    exactly, so you have no incentive to block it, and if someone else feels like it is helpful and does the work, why stop him

  223. Guus

    I'm thinking we're basically saying the same thing, but misunderstanding each-others words?

  224. flow


  225. Guus

    good. Back to work with me then 🙂

  226. Kev

    I hear that people in the XSF tend to use very complicated English. That's probably why.

  227. Guus

    What, no tripple negatives? Who are you and what did you do to Kev?

  228. Kev

    It's a good question.

  229. Guus

    I have _the best_ questions

  230. Guus

    (ok, back to work with me)

  231. pep.

    "cosmetic issues", ralphm, I'd like have this piece of mind and think that's just comestic issues.

  232. SpaceFreak aka Tracer

    Kev: or complicated formulation + deepl.com translate ;-) (no shit)

  233. SpaceFreak aka Tracer

    > good. Back to work with me then 🙂 zurück zur arbeit mit mir? sounds exactly like german right?

  234. pep.

    Also, "lot of actual work that that volunteer time could actually be put to use for", maybe we could make it so that "The Secretary" is a team instead. (as in bring in more people, or people with more time, or actually pay people.)

  235. SpaceFreak aka Tracer

    pep., flow: you can(should) take part but not like : "use my code now"

  236. flow

    I guess the takeway is that it does not matter (as board member) if you think something is not worth the effort, but not really harmful either, if it is someone else who is volunteering to do the work. And I guess board shouldn't try to manage the volunteer resources, because in volunteer organizations you can't instruct people how to spend their time, they will spend their time as they wish anyways (which usually yields the best results)

  237. Ge0rG

    that is a good summary

  238. pep.

    There is still a foundation to run though :/

  239. pep.

    flow, I agree with you for the most part, minus ^

  240. flow

    pep., to be frank, I have to idea how much time and effort goes into running the foundation. could be a bank account and a post box somewhere which one person once in a while checks

  241. flow

    and, as far as I can tell, and while we had and have some issues, e.g., finding a treasurer, running the foundation seems to work

  242. SpaceFreak aka Tracer

    deepl.com deep translate

  243. SpaceFreak aka Tracer


  244. edhelas

    Funny detail https://gitlab.linphone.org/BC/public/linphone/merge_requests/474/diffs#cabe58cc52506439c27d6eca77272251f3e53ac4_55_59

  245. pep.

    urn:xmpp:ephemeral:0. Fortunately it's not like this namespace needed to be registered somewhere

  246. jonas’

    relevant: https://xmpp.org/extensions/inbox/ephemeral-messages.html

  247. pep.

    Ah I remember the discussion around that

  248. pep.

    https://xmpp.org/extensions/xep-0313.html#filter is anything extending these 3 fields already? "Other fields may be used, but are not defined in this document"

  249. Holger

    ejabberd has an additional field to search the body text FWIW.

  250. pep.


  251. Holger


  252. Holger

    There's no standard field for that purpose.

  253. MattJ

    I didn't know that. I was planning to write a XEP for search

  254. jonas’

    search for "This message is OMEMO encrypted"?

  255. lovetox

    pep., yes its standard

  256. lovetox

    there is no need to register fields

  257. MattJ

    The problem is that plain text search is boring, and advanced search varies by implementation

  258. lovetox


  259. Holger

    jonas': Yup.

  260. Holger

    MattJ: Yup.

  261. Holger

    ejabberd just has boring search.

  262. MattJ

    Good to know

  263. jonas’

    Holger, your client is incorrectly completing my nickname (assuming that you used features of your client to generate that `jonas'`)

  264. MattJ

    I think registering something standard for boring search would be a good start

  265. Zash

    "how to buy a tunnel boring machine"

  266. Holger

    jonas': You told me so in the past, and we still haven't switched to UTF-8.

  267. Holger

    All I can do is try my best not to talk to you in the meantime :-)

  268. pep.

    lovetox, I see. That disrupts my plans a bit..

  269. MattJ

    pep., what plans?

  270. Zash

    What what

  271. pep.

    One struct to rule them all

  272. jonas’

    Holger, ah, I knew I told someone, but I didn’t know whom :)

  273. pep.

    If I can't statically know in advance

  274. MattJ

    You can if the additional fields have disco features too

  275. pep.

    MattJ, you tell my compiler to do the disco to run against your code? :P

  276. pep.

    So it generates a struct that matches and then every client use it

  277. lovetox

    MattJ, for what if i can request them via IQ?

  278. pep.

    I'll have to do that differently

  279. MattJ

    pep., you can't implement what you don't understand in that kind of system anyway, so why bother?

  280. lovetox

    these are custom searches, you are not going to request mam messages automatically on connect

  281. MattJ

    Just implement the standard ones in your struct

  282. pep.

    MattJ, but I don't want to prevent people from querying more

  283. MattJ

    Well you do

  284. pep.

    So I'll need to allow for optional fields

  285. MattJ

    or you wouldn't be trying to define such things at compile time :)

  286. pep.

    it's a matter of adding another attribute `moar_fields: Vec<Field>`, but that's a bit ugly

  287. jonas’

    pep., in aioxmpp, there are two layers: you can either access the raw fields (Vec<Field>) with helper methods, or you can use a declarative form wrapper around the original data to access it more sanely

  288. jonas’

    (including stuff like validation)

  289. pep.

    hmm. I could do that I guess

  290. jonas’

    this type of two-layer approach also helps with applications which need to operate on things more generically (since it provides an individual uniform interface on both layers)

  291. jonas’

    and if you make the declarative layer easy enough, it’s also extensible for proprietary (or simply new) extensions

  292. pep.

    https://dpaste.de/Zyeq that's what I have in mind. Or a mix of both or..

  293. pep.

    The current design is meh because most used options aren't validated

  294. pep.

    In the end I think I'll have almost the same design as the original, with `form: Option<Into<DataForm>>`, providing a helper struct with common options.

  295. edhelas

    it's crazy the amount of <presences> messages that a client is receiving overall

  296. edhelas

    compared to <iq> and <message>

  297. MattJ

    It would be nice to do some analysis some time and figure out what the stanzas are, at a high level

  298. MattJ

    e.g. what percentage of them are actual user-initiated presence changes (my guess is a very small fraction)

  299. MattJ

    and of the rest, figure out if they can be reduced

  300. waqas

    What do you expect them to be?

  301. MattJ

    Stupid noise, disconnects/reconnects and stuff

  302. MattJ

    CSI makes it less of a problem, but fixing issues at the source would be better

  303. MattJ

    Maybe there isn't a problem. But I bet there is :)

  304. MattJ

    There's rarely a time I look at a real-life XMPP stream and don't find something weird happening

  305. MattJ

    That's the reality of such a diverse network, but it would be good to fix any obvious issues

  306. waqas

    I suspect in practice the fix would be servers selectively dropping/merging stanzas

  307. waqas

    And the tradeoff would be more state for the server, and slightly more expensive stanza processing, leading to less bandwidth/battery usage for clients.