XSF Discussion - 2019-12-12

  1. marc_


  2. marc_

    > Making it non-public and having a long random name works like a password With the difference that a password coule easily be changed whereas the group name not

  3. Ge0rG

    marc_: changing a MUC password will throw everybody out

  4. marc_


  5. marc_

    Sounds broken :)

  6. marc_

    Anyway, the #disco thing looks useful

  7. marc_

    Is this supported by ejabberd?

  8. nyco


  9. nyco

    https://fosstodon.org/web/statuses/103290294377276459 is this for iTeam?

  10. Zash

    Which RSS feed?

  11. nyco

    that's my doubt: could be our blog, or the planet that's why I ask

  12. Zash

    https://xmpp.org/feeds/all.atom.xml has eg `<link href="/" rel="alternate"/>`

  13. Ge0rG

    I wonder if this isn't a bug in the respective feed readers instead.

  14. Zash

    nyco: Maybe ask them where exactly they're seeing that?

  15. ralphm

    If I miss the Board meeting today, it means I've finally beaten jetlag. Bear with me ๐Ÿคฃ

  16. Guus

    Say hi to Bear! ๐Ÿ˜‰

  17. dwd


  18. Zash

    U wut m8?

  19. Seve

    Guus, ralphm, I cannot join today unfortunately.

  20. Guus

    ๐ŸŽถ No more monkeys jumping on the bed

  21. DebXWoody

    Guus: ๐Ÿ˜‚

  22. pep.

    Is it now?

  23. pep.

    Or in an hour? I haven't got my timezones right

  24. Kev

    I love it when an Experimental XEP gets published, discussion happens on-list, and genuinely significant improvements can then be made because of the community suggestions.

  25. Guus

    it's now.

  26. pep.

    poke MattJ

  27. Guus

    Time for the board meeting. Paging pep. MattJ ralphm - Seve mentioned he wasn't going to be here.

  28. pep.

    ralphm, not here then? Seve not here that we know

  29. Guus


  30. Guus

    just you and me?

  31. pep.


  32. Guus

    No quorum then.

  33. Guus

    I can help you with one of the things that you added to the agenda: https://trello.com/c/nAXUNr47/378-google-mentor-summit-expenses

  34. Guus

    I don't think we need to discuss this.

  35. pep.

    that'd be great

  36. Guus

    We've already agreed.

  37. pep.

    poke peter and get money back?

  38. Guus

    So you can simply talk to the Treasurer (Peter)

  39. Guus

    He'll ask you for an expense sheet.

  40. Guus

    but yeah. There's no board decision to be made here - unless I'm missing something?

  41. pep.

    larma, ^

  42. pep.

    I don't think so, I was just unsure

  43. Guus

    As you helpfully linked on Trello: board already voted in favor of this.

  44. pep.

    As for the other items, (made the list public and open history), we can continue discussing this on-list. I guess we could also vote on-list? Does something prevent this?

  45. Guus

    So, unless Peter has concerns that I'm unaware of, you should be good.

  46. pep.

    Does everything have to be done in meetings?

  47. Guus

    No - but if you want to discuss on list, you probably should do it on the member list, not board - for reasons you expressed yourself.

  48. pep.

    It seems to me absent's opinions are just discarded otherwise if they haven't expressed them beforehand

  49. Guus

    (that board list is mostly used for basic "sorry, can't make it" type of comms)

  50. pep.

    Guus, well board hasn't decided anything wrt. these. I'd be happy to start doing it though

  51. Guus

    without Quorum, there's no vote.

  52. pep.

    without quorum "at a specific point in time during the week"?

  53. Guus

    we can discuss on list, but a vote should be called in a meeting, I think.

  54. pep.

    Anyway I'll raise this point as well

  55. Guus

    Details will be in the bylaws.

  56. pep.

    I guess we can leave this here

  57. Guus

    ok. Back to work with me!

  58. Guus


  59. pep.


  60. MattJ

    Sorry, unexpectedly can't make it today

  61. pep.

    We've already closed for the day, please come back next week :P

  62. dwd

    I don't think you actually need to make decisions at meeting. See XSF Bylaws ยง5.8 which seems to explicitly cover this.

  63. pep.

    Yep, looks good to me

  64. dwd

    Though it *appears* to read as if only unanimous decisions can be made that way.

  65. pep.

    hmm. I'd like to have meetings be an extension of "action without a meeting" and not the opposite. (Just a place to sync up if required, not something you have to attend or be ignored. I extrapolate but this doesn't seem to far from the truth to me)

  66. dwd

    I suspect an effective way for the Board to operate would be to vote on things on list, and only hold meetings when things are conetntious (ie, not unanimous). That appears to conform to the bylaws, and you can make such a rule of procedure under ยง5.10 should you wish.

  67. dwd

    Or at least, only vote at things at meetings.

  68. pep.

    What do you mean with that last message?

  69. Kev

    I would suggest making 'the list' be members@ rather than board@ though (which is Board policy anyway, instituted a few Boards ago, to do business on members@ unless something has to be out of camera (sic)).

  70. dwd

    Kev, "in camera", not "out of camera". "Camera" here is the Latin word for room.

  71. Kev


  72. Kev

    That's why the (sic) to show I knew what I was doing and it wasn't a mistake :p

  73. dwd

    Kev, Ah, yes.

  74. pep.

    Kev, yep that's more or less what is being discussed on board@ atm. I'd want that as well.

  75. Kev

    pep.: It's already Board policy, FWIW.

  76. pep.

    Well I'm not even sure where to find this information anyway..

  77. Kev

    I pushed Board on it a number of years ago, and they agreed. So unless a subsequent Board have overturned that (I'm not aware of this).

  78. Kev

    I pushed Board on it a number of years ago, and they agreed. So unless a subsequent Board have overturned that (I'm not aware of this)...

  79. pep.

    So who knows what policy board has now

  80. dwd

    Kev, I don't know that Boards bind subsequent boards as to rules of procedure. Nor do I know how a Board would even know about previous rules of procedure.

  81. Kev

    I'd assume that Board decisions are lasting until overturned.

  82. Kev

    To do otherwise doesn't make sense in most cases.

  83. Kev

    So I don't see why rules of procedure should be different really.

  84. Kev

    But, at least, there's no pratical way of knowing this as Boards' continuity isn't always the best.

  85. Kev

    (As you say)

  86. ralphm

    It might indeed be useful to gather such decisions and write them up in one place. Maybe even as simple as wiki page.

  87. pep.

    yep. I suggested that to board the other day. We should do the same

  88. pep.

    yep. I suggested that to council the other day. We should do the same

  89. ralphm

    But indeed, unless confidentiality is required, everything should really go to members@

  90. pep.

    ralphm, can you put that in writing on the list? So far only Guus from board expressed an opinion

  91. Guus

    pep. this is already happening. It's kind of weird to announce that we're not going to do anything in private, if we're not doing anything in private anyways.

  92. dwd

    Guus, You could announce youre continuing to do so. You never know, it might generate a bit of interest in what the Board is up to.

  93. Guus


  94. lovetox

    Kev, i fear if we dont work out exactly how fastening should be used with MAM, this will end in failure.

  95. lovetox

    Even if it is its own XEP, if it ends not working with MAM perfectly its probably useless

  96. lskdjf

    > Kev, i fear if we dont work out exactly how fastening should be used with MAM, this will end in failure. <reaction>๐Ÿ‘๏ธ</reaction>

  97. Ge0rG

    I disagree on that. Fastening adds a semantic relationship to messages. That's more than we have now, and I'm sure it's enough for fetching messages that belong together

  98. lovetox

    yeah kind of the point, we dont have it now so no problems

  99. lovetox

    afterwards everyone starts fastening X stuff together

  100. lovetox

    then you get problems

  101. Ge0rG

    lovetox: do you have a specific problem in mind?

  102. lovetox

    mostly reactions

  103. lovetox

    joining 20 groupchats already takes much time with querying 20 archives, it will become a pain if i have to download 1000 message reactions

  104. lovetox

    and this is surley just the first new thing someone invents that uses fastening

  105. lovetox

    overall i expect it will result in much more messages sent

  106. lovetox

    like chatstates and markers already did

  107. Ge0rG

    lovetox: but with the current state of affairs, things like LMC from MAM are already broken

  108. lovetox

    right now its bearable traffic wise, but i feel its on the edge

  109. Ge0rG

    lovetox: so you are opposed to more messages, and not to messages being semantically linked?

  110. Ge0rG

    lovetox: MAM2 is planned to provide all reactions inline for a given message

  111. lovetox

    im opposed to inventing tools to raise traffic without at the same time specifing methods to deal with it in a sane manner

  112. Ge0rG

    That will vastly reduce your traffic problem

  113. lovetox

    Ge0rG, thats the point "its planned" is not good enough

  114. Ge0rG

    lovetox: then you should oppose reactions, not fastening

  115. larma

    I think right now it only works because few send read markers in larger MUCs... It's basically already "broken"

  116. Daniel

    I don't think he is opposing fastening

  117. lovetox

    just lets thing this through to the end, thats all im saying

  118. lovetox

    just lets think this through to the end, thats all im saying

  119. pep.

    lovetox, would you prefer something like "all the meta-stuff (reactions, lmc, etc.) is requested separately"?

  120. lovetox

    i was just throwing ideas out, i dont know if this is the best solution

  121. lovetox

    but yeah, some MAM filter like, give me all messages that are not fastening

  122. lovetox

    then afterwards, query the meta stuff, but the problem here is

  123. lovetox

    not all fastening messages are meta

  124. lovetox

    as i think dave mentioned on the list

  125. lovetox

    there are 3 categorys

  126. lovetox

    reactions is just one, if we put lmc, markers, quotes, comments in this

  127. lovetox

    then we need real smart logic on the server to make these decisions

  128. Daniel

    > there are 3 categorys > reactions is just one, if we put lmc, markers, quotes, comments in this > then we need real smart logic on the server to make these decisions Yeah. Fastening is really complex right now. That's why I want proof that MAM will be able to handle that

  129. Daniel

    Or else we might have to reduce complexity

  130. pep.

    I'm only catching up on the "Resurrecting Fastening" thread. And I see Xabber people saying "with aggregated counter, where message is returned with a number of attachments it currently has. Possibly, aggregated on type (6 ๐Ÿ˜‚ 3 ๐Ÿ˜ก 1 ๐Ÿ‘ 1 ๐Ÿ’ฉ), *without *authorship of those attachments". Is anybody actually on board with this? Because I don't like that I'd be missing authorship info :/

  131. pep.

    ("on-board" as in, "agrees with this")

  132. lovetox

    reactions without authorship is the most useless thing i heard

  133. lovetox

    someone like my comment but i dont know who, great

  134. lovetox


  135. Zash

    Feature! Anonymous voting!

  136. Daniel

    I may or may not be fine with it for the special case of reactions. But if fastening has a general aggregation mechanism there will certainly be cases where we need authorship

  137. lskdjf

    yeah reactions without authorship don't make sense at all. Every messenger I know that can do reactions provides the information about who reacted.

  138. pep.

    I mean I would understand applications not displaying authorship info right away (at first glance) but yeah I don't want to lose that info

  139. larma

    the idea is that you get the summary without authorship, but also have the ability to request the details with authorship

  140. pep.

    larma, that's quite specific to one kind of UI possibility though

  141. larma

    yes, that is really specific about reactions

  142. pep.

    Even for reactions I mean

  143. pep.

    Not that I have other UI suggestions right now, but I wouldn't want to see optimisations for every single possible UI in the protocol

  144. larma

    That's why I wrote in one of my mails: > I can hardly imagine summarizing to work in a generic way. The only thing that makes sense to me is to have the procedure to summarize a certain fastening defined with that specific fastening (e.g. in the reactions XEP for reactions) and not generically. This also implies that servers may not be aware of how to summarize certain fastenings and thus clients would always have to be ready to ask for the raw messages for these if they want to display them (obviously servers should announce via disco which they do support).

  145. larma

    pep., I think that's fine for reactions, everyone probably agrees that you don't want to display authorship directly in the message history

  146. pep.

    That's a valid statement in our circles

  147. Daniel

    I think aggregation can work. But since MAM and aggregation is 90% of the reason we are doing fastening in the first place i don't think it makes sense to release fastening without that

  148. lovetox


  149. larma

    I think there is two different kinds of aggregation and people like to mix these two

  150. Daniel

    There are multiple kinds of aggregation because fasting mixes multiple kind of references

  151. larma

    summary style / processed aggregation (6 ๐Ÿ˜‚ 3 ๐Ÿ˜ก 1 ๐Ÿ‘ 1 ๐Ÿ’ฉ) and message-based aggregation (where you basically get the original message details without further modification)

  152. Daniel

    I think we might be able to do without the processed ones

  153. Daniel

    Just give me all the wrapped raw data

  154. Daniel

    With the message that they were fastened to

  155. Daniel

    I can count them myself

  156. Daniel

    But either way. It just further drives home the point that we need to think that together

  157. Daniel

    And not just come up with a new attach-to/reference/fasten element

  158. Daniel

    That is the boring part of it

  159. larma

    Totally agree

  160. Zash

    Are there some kind of stats on ratio of "normal" messages to reactions?

  161. Daniel

    Reactions specifically?

  162. Daniel

    Or all kind of references?

  163. Zash

    That "query MAM, get 1 messagage and 19 reactions" scenario sounds a bit exaggerated

  164. pep.

    Zash, s/reactions/chatstates/ ?

  165. Zash

    No chatstates in MAM

  166. lovetox

    really? just look at facebook, one post can have 1000 reactions

  167. Zash

    Weren't we going to send chat states over presence?

  168. Zash

    Facebook isn't chat

  169. lovetox

    Conversations room has 200+ joined people

  170. lovetox

    if Daniel, says C is for free for the next 5 days

  171. lovetox

    probably 70+ people give thumbs up

  172. lovetox

    i pull these numbers out of my ass

  173. lovetox

    but it will be more than 19

  174. Zash

    Yeah but how often are there that kind of reaction-triggering messages?

  175. lovetox

    the thing is if you give people the UI to react with one click

  176. lovetox

    they will use it

  177. Daniel

    Yeah. You don't know. I mean you probably won't hit an average of 19:1. But it's annoying if the last message sent was one that received a 100 up votes. Than you have two mam pages of just garbage

  178. Zash

    I'm not sure designing something based on numbers you got from *where* is the best.

  179. Zash

    Hence stats.

  180. lovetox

    Zash are you aware that reactions dont exist?

  181. lovetox

    how would we gather stats about a feature that does not exist

  182. Zash

    I'm perfectly aware that they do exist, just not in XMPP.

  183. lovetox

    lets just say we have experience with chat markers

  184. lovetox

    and chatstates

  185. lovetox

    and before you say they are not stored in MAM

  186. lovetox

    yes there was a time prosody stored them

  187. Daniel

    I don't know. There is an angry Twitter post from the xabber people about read markers being in mam or what ever

  188. Zash

    And most rooms aren't the 200+ conversations@ room.

  189. Daniel

    Go ask them for stats ๐Ÿ˜‰

  190. pep.

    Zash, find a somewhat popular mattermost instance, I think they can easily get you a ratio?

  191. pep.

    Running queries in the db

  192. Zash

    pep., that's what I'm talking about

  193. lovetox

    we have to design the XEPs still in a way that they are able to scale, even if xmpp is not big at the moment

  194. Zash

    Designing something to scale by making up imaginary numers?

  195. Ge0rG

    We have designed XEPs in the past to cover all potential use cases. PEP, Message Archival and MIX come to mind.

  196. Daniel

    I'm not really sure I understand Zash's argument here. That we don't need fastening at all?

  197. Daniel

    I mean to me it doesn't matter if we are aggregating 5 or 100 reactions

  198. lovetox

    this does also mean a lot more load for servers

  199. lovetox

    i would implement this like, query all reaction authors on mouse over of the reaction

  200. lovetox

    i bet many servers will not be able to handle that

  201. Kev

    For the record (and it's late and I'm not going to get into a big discussion right now - send it to list), I am onboard with the summary being a summary (e.g. just the reaction counts per reaction), and if you want further information, including the senders, that you do a further query to ask for it.

  202. Arc

    Ok I really hate being the kind of person who laughs at someone's misfortune, but https://www.zdnet.com/article/russian-police-raid-nginx-moscow-office/ has really brightened my day

  203. Arc

    NGINX Inc - the company who's CEO is a former rugby teammate - who's excited mood for hiring me soured over their non-competition clause extending to /all/ FOSS development.

  204. Arc

    NGINX Inc - who's employee contract claims ownership over every FOSS contribution you make as an employee even on your own time, and forbids you from submitting patches to other FOSS projects without permission, now ironically raided by russian police after their lead developer's former employer claims ownership over NGINX because their employee contract has the same clause