XSF Discussion - 2023-02-07


  1. singpolyma

    Look like that's mostly about presence specifically

  2. singpolyma

    I was gonna say e2ee might kill multicast anyway, but presence isn't going e2ee anytime soon

  3. moparisthebest

    Squeaky Latex Folf: so XMPP uses literally kilobytes more than it could with some changes? Hmm I wonder why no one cared lol

  4. moparisthebest

    Oh, and it would only save any bandwidth at all with absolutely massive servers which are an antifeature we should be moving away from

  5. moparisthebest

    In my ideal utopia everyone in the world would have an XMPP address and no single server would have more than 10 users

  6. flow

    Squeaky Latex Folf, the critique is valid but misses the point that 1. the missing functionality did cause relevant issues for deployments and 2. it could be added retroactively if someone is willing to put in the effort. which will likely be the a big org which massively benefits from the improvments such a feature brings

  7. flow

    that said, multi-value to stanzs (potentially even with compressed domainpart) are probably a good candidate for something that would be nice if it where in core, as it seems to bring some benefit without much additional implementation complexity.

  8. flow

    that said, multi-value 'to' attribute stanzs (potentially even with compressed domainpart) are probably a good candidate for something that would be nice if it where in core, as it seems to bring some benefit without much additional implementation complexity.

  9. flow

    that said, multi-value 'to'-attribute stanzs (potentially even with compressed domainpart) are probably a good candidate for something that would be nice if it where in core, as it seems to bring some benefit without much additional implementation complexity.

  10. Guus

    Haven't read the article, but wanted to throw in that although XMPP core might not be optimized for lowest amount of data, there are XEPs that work towards this. FMUC comes to mind, https://xmpp.org/extensions/xep-0289.html, as does EXI https://xmpp.org/extensions/xep-0322.xml

  11. flow

    most of the psyc critiques are valid. but I assume the lesson here that can be learned is that a community building on protoocl and implementations can be more successful than a small group (or just one individual) trying to achieve perfection

  12. flow

    of course, that does not mean that we shouldn't address protocol drawbacks when they cause issues

  13. ralphm

    See also minix

  14. flow

    doesn't drive minix intel's management engine?

  15. ralphm

    I mean the interaction Linus had with his professor.

  16. flow

    but yes, the situation is probably a bit comperable to the linux vs minix situation

  17. flow

    although, microkernels *are* a thing, even though they are not that visible, they are more widely used than it looks at first sight

  18. flow

    and I assume that is not the case for psyc, but maybe it is driving something I don't know about?

  19. ralphm

    I think when we get PAM (or similar) stuff going, servers could optimize subscriptions there. "I'm subscribing for this server"

  20. ralphm

    Without actually having to sync the local list of subscribers. The room would still have the list of members of course.

  21. ralphm

    Kind of like how ikDisplay (the thing I use to protect the Twitter stream at FOSDEM) works. It has the concept of feeds (e.g. "fosdem") which each specify which keywords and accounts they want to subscribe to. The aggregator then opens a single connection to the Twitter streaming API with the union of keywords and accounts, and then demultiplexing the items as they come in.

  22. Squeaky Latex Folf

    What do you mean with PAM? Pluggable Authentication Modules is all I can think about

  23. Daniel

    Squeaky Latex Folf: xep376

  24. ralphm

    By the way, something I thought about last night concerning collations: messages in threads will also have their own, right?

  25. MattJ

    I was thinking we could just get away with a filter for threads

  26. Kev

    Each message in the thread could have reactions though, as normal, I think?

  27. Kev

    I assumed that's what Ralph meant.

  28. MattJ

    Oh, sure, they're just normal messages

  29. singpolyma

    Hello everyone. Now that's I won't be directly overlapping with discussion of another event, I would like to bring up that I really want to submit a proposal to FOSSY to do a one day XMPP track. If you haven't seen it yet, FOSSY is basically an attempt to start a FOSDEM class event in USA in the summer, organized by software freedom conservancy. I'm interested to know if XMPPeople, especially those this side of the water, would be interested in participating in, speaking at, or helping organize such a one day track event.

  30. singpolyma

    The event organizers are *very* disease consious and I expect this to be the safest event anywhere this year or next, which is why I'm considering to go myself, though I understand if others aren't up for that of course.

  31. Zash

    Sounds like a great initiative. Maybe suitable for resurrecting the other-side-of-the-pond Summit even

  32. Guus

    (what he said)

  33. ralphm

    Kev: yes, that's what I meant.

  34. Guus

    Took me a while to find what FOSSY is :) https://sfconservancy.org/fossy/

  35. ralphm

    I definitely would like to do a North American summit this year. There was a suggestion in Brussels for it to be in Canada, I believe.

  36. Ge0rG

    Where's that? 😁

  37. Daniel

    Canada is probably easier to travel to than the US

  38. Guus

    Unlikely to be true for most US citizens though.

  39. ralphm

    It had to do with some active Canadian XMPP projects.

  40. Zash

    ralphm, that would be singpolyma & co :)

  41. Ge0rG

    There is a Canada in Kentucky and another one in Kansas.

  42. Guus leaves. (not maple).

  43. ralphm

    There's an America in The Netherlands, so there's that.

  44. ralphm

    Anyway, I'd be happy to help organize a North American summit in general.

  45. ralphm

    However, if there are restrictions like obligatory masking or presenting proof of certain vaccinations, I will likely not participate.

  46. Daniel

    Isn't proof of vaccination a thing anymore on a country wide level?

  47. singpolyma

    Yeah, if people wanted to organize a summit alongside this because people were preset anyway, that might make sense. I can't promise I'd be involved in that as well, and if the goal is to include European representation more easily than eastern Canada vs Western US is probably a thing I dunno

  48. ralphm

    Daniel: I don't know, singpolyma mentioned them being “*very* disease conscious”. I've seen e.g. PyCon US having a masking mandate, even though the CDC doesn't recommend that any more. Not going there.

  49. Daniel

    Just checked Canada (for example) doesn't have any restrictions anymore

  50. ralphm

    singpolyma: I don't mind the form per se. We've previously done NA Summits co-located with OSCon and later RealtimeConf.

  51. singpolyma

    Oh yeah, fossy is likely to have a strong mask presence. Otherwise I'd never be able to go :)

  52. ralphm

    Daniel: my point is that the event might still

  53. ralphm

    singpolyma: sure, we've seen people masking at FOSDEM, too. As long as it is a choice, people need to do what they need to do.

  54. Daniel

    Yes. I was just curious about nation wide restrictions. Simply because I hadn't checked for the last couple of months

  55. singpolyma

    ralphm: some people will always choose to do evil. Can't stop them I guess

  56. jonas’

    like not masking at mass events?

  57. ralphm

    singpolyma: for sure. It is not clear to me, though, what qualifies as evil these days.

  58. singpolyma

    Anyway, I think we're impsossibly off topic now :)

  59. jonas’

    are we?

  60. jonas’

    I think rules for XSF events are perfectly on-topic

  61. ralphm

    indeed

  62. ralphm

    Also, note that I didn't say "we can't do it then". I said "I will likely not participate".

  63. singpolyma

    Oh sure, I'm not going to be able to participate in any "xsf event" (clearly) so I guess it felt off topic vs what I was bringing up

  64. ralphm

    singpolyma: that was not clear to me. If your participation depends on other people masking or being vaccinated in some way, then maybe that's the case.

  65. ralphm

    But I didn't say there can't be an event with such restrictions.

  66. MattJ

    FWIW the IETF meeting in London was mandatory FFP2 masks, which I complied with. It was my first big event for years, and I understood why the requirement was there and took some comfort that they were trying (masks have not been a thing in the UK for some time). I have to say that it definitely gave me a negative experience at the event, and when I got home I had a positive COVID test.

  67. MattJ

    Like most, I did not mask at FOSDEM (though I was prepared to), and so far I'm free of even the FOSDEM flu...

  68. Zash

    If there are agreed upon rules or recommendations, following them or staying home seems sensible.

  69. Zash

    MattJ, did you just jinx it? :)

  70. ralphm

    Zash: to me those are the only two options

  71. Daniel

    A dedicated Summit is likely not a 'mass event' in the sense that FOSDEM is one (or ietf even)

  72. ralphm

    No, but I'm sure the Ibis climate "control" didn't do anyone any good.

  73. Daniel

    every restaurant has more people in at then the conference room at summit

  74. pep.

    "MattJ> Like most, I did not mask at FOSDEM (though I was prepared to), and so far I'm free of even the FOSDEM flu..." < that's certainly not because you haven't worn a mask though. That's most likely luck :P

  75. pep.

    (worn?)

  76. MattJ

    Sure, like it was bad luck that I got COVID from IETF despite full mask requirements

  77. pep.

    (worn? worn.)

  78. MattJ

    I'm not really trying to make a point about anything really... except from my personal experience, my personal choice would be to avoid large gatherings (masked or not) if I really didn't want to risk getting ill, and that if I'm faced with the option of attending an event with mandatory masks again I'd certainly take that into account before choosing to attend

  79. MattJ

    I'm glad I went to the IETF meeting, but it wasn't an enjoyable experience

  80. pep.

    I do think that people getting ill easily shouldn't be excluded though, and that we should be mindful of them

  81. jonas’

    pep., you mean "people getting ill easily" in the sense of people particularly vulnerable to infections?

  82. MattJ

    Funny to be having this conversation *after* we just had a large event, but... yeah :)

  83. pep.

    MattJ, agreed

  84. pep.

    jonas’, yeah for example, immunodepressed people, this group of people is the must obvious one I'm talking about but there's a nebulous crowd around that isn't labelled which is also vulnerable, or prefers taking steps in protecting themselves and those around them. And they won't manage if they're the only ones caring

  85. jonas’

    fair, though at least those affected I know would rule out attending an event like FOSDEM or IETF even with masks, because those are simply not effective enough.

  86. pep.

    Yeah, and these choices prevent them from going

  87. jonas’

    I don't follow?

  88. pep.

    Well packing officially-5k people in a small building (such as FOSDEM has always done), with no sanitary restriction, surely prevents them from going if they care a little

  89. jonas’

    my point was even *with* restrictions those I know wouldn't attend

  90. Daniel

    that has been the case pre-2020 too, no?

  91. jonas’

    but I might know rather extreme cases, granted

  92. pep.

    Daniel, yeah FOSDEM has always been packed wayy beyond their official limit :/

  93. jonas’

    Daniel, that doesn't mean that that wasn't a problem

  94. ralphm

    pep.: I totally get the concern for people with compromised immune systems. I also have the same feeling as MattJ.

  95. ralphm

    FOSDEM was a lot less crowded this year, though.

  96. Zash

    Especially the second day

  97. Zash

    Isn't all this why there hasn't been a FOSDEM for 2-3 years?

  98. pep.

    So yeah.. "You can wear a mask if you want it's your choice", "maybe, but it's not enough if I'm the only one caring"

  99. MattJ

    Someone pointed out to me privately that my anecdote may be interpreted as me saying that masks increase the chance of infection, I just want to make clear that this was not the case - a sample size of 1 is unable to lead to any such conclusion (in case there was any doubt)

  100. ralphm

    pep.: I am afraid there is no right answer.

  101. pep.

    There's the "we care" or "we care less" answer :P

  102. singpolyma

    Big, ventilated spaces, adequate filtration, use of real masks, outdoor meals, etc. It's all grade, it's not a black and white do x or not situation

  103. ralphm

    pep.: what? This isn't boolean.

  104. pep.

    ralphm, no there's also "we don't care at all"!

  105. singpolyma

    Though certainly there are do nothing situations like FOSDEM vs do anything which I guess is basically Boolean

  106. MattJ

    *Anyway...*

  107. singpolyma

    MattJ: indeed

  108. Zash

    So, yeah, XMPP Event Things in America would be Good

  109. MattJ

    This event exists, it has policies, if that makes some people want to attend and others not to attend, that's fine (just as FOSDEM's policies did the same)

  110. Zash

    And we did briefly talk about resurrecting the Summit there

  111. ralphm

    I only found https://sfconservancy.org/blog/2023/jan/31/fossy-call-for-tracks/ with some more information, but haven't found the actual policies.

  112. MattJ

    I'll probably not attend, but mainly for other reasons (I probably used up most of my travel budget for the year... the financial and energy kind), I find travel exhausting and it would take a lot to entice me to the US

  113. ralphm

    Oh, and also, this is more like a devroom than a summit.

  114. singpolyma

    Yes. Basically a devroom

  115. Zash

    > We are also mindful of having a safe environment for all. In this new time of conferences, we will be focused on COVID safety and making sure all attendees feel safe participating as much as they feel comfortable ( *we will have a detailed policy published in the coming weeks* ). on https://sfconservancy.org/fossy/ seems to be the words so far (em mine)

  116. ralphm

    We've also, separately, talked about a non-summit conference like thing, but maybe 2024 is a nice year for that.

  117. ralphm

    Right

  118. singpolyma

    MattJ: that totally makes sense. While it would be great to have you there of course, if we have to count in the same people flying to every event it's not a good strategy for sure

  119. singpolyma

    If anyone *is* interested, especially in giving a talk, I can probably find some travel budget if that's an obstacle to someone

  120. Zash

    Having something for those who have trouble attending a FOSDEM-attached Summit sure would be great.

  121. Zash

    Suppose that's why IETF cycles between America, Europe and Asia

  122. pep.

    It would be great if the XSF was a bit less Europe centric yeah. Funny how the legal entity itself is still US-based.

  123. singpolyma

    Yeah, if this event works out as is hoped and there can be an XMPP track in the first year of it, I don't see why there wouldn't be an annual presence there, which is good for all the same reasons the presence at FOSDEM is good

  124. singpolyma

    That's my hope and goal with this

  125. singpolyma

    I don't know how much space they have or how many proposals they'll get, but I have a decent hope if making a good application

  126. singpolyma

    I don't know how much space they have or how many proposals they'll get, but I have a decent hope of making a good application

  127. singpolyma

    (well, I know the space is "a lot" by reputation)

  128. moparisthebest

    If there's going to be an XMPP thing there I'll go

  129. moparisthebest

    Re: travel restrictions to USA from outside I'm pretty sure they've all been lifted now Daniel

  130. Guus

    While we have many of the usual suspects here: at the summit, there was talk of (and I'm paraphrasing): "If it wants XMPP to be perceived as remaining relevant/modern, the XSF should do X". This was around MattJ talking about his experiences at the recent IETF meeting. Is "doing X" on anyone's agenda?

  131. moparisthebest

    What were the values of X

  132. Zash

    eXtending and Modernising the Protocol Properly?

  133. Guus

    IETF's MIMI, I think.

  134. Guus

    but that might not cover everything.

  135. Zash

    Don't you worry about _blank_, let me worry about _blank_!

  136. ralphm

    We've discussed a few things in that direction. One is definitely doing MLS.

  137. Zash

    Yeah, We Should™ do MLS, going to be rough now to compete with the Good Enough® of OldMEMO

  138. MSavoritias (fae,ve)

    funny how tech people think the companies will listen for sure this time with MIMI and you are missing out XD

  139. Kev

    > funny how tech people think the companies will listen for sure this time with MIMI and you are missing out XD That was very much not the tone at the Summmit.

  140. Zash

    None of them are actually involved in MIMI as far as I'm aware, so there's the distinct risk that they'll just ignore it and do their own APIs

  141. ralphm

    Another was a more involved effort that coincided with discussions on EU legislation on interoperability and the requirement to use open standards in government in EU countries. I have spoken to several people at FOSDEM that have way more involvement with people on the non-technical side of the discussion. I am working with MattJ to come up with a plan to attack that together with such people, so we can get at the right tables. As a community that will mean we have to get really serious about compliance suites, explaining why XMPP is the right (only?) choice, and likely act as a financial host for funding work to do all that.

  142. MattJ

    Guus: there are various values of X, and each is being tackled by one or more people

  143. ralphm

    MSavoritias (fae,ve): these efforts don't have to be mutually exclusive. It is good that MIMI exists as an effort. Nobody can say how effective it will be.

  144. ralphm

    We've also discussed, at length, the related topics of MIX and IM-NG. I'm not sure how to succinctly capture the outcome of that, but in any case several people have indicated that they'll restart their MIX efforts.

  145. Guus

    Thank you.

  146. ralphm

    Zash: I'm not sure why MLS would be a hard sell if it actually works. Because not my experience with OMEMO. I understand that the people who wanted to get together to discuss OMEMO last week had issues reading OMEMO encrypted messages.

  147. Zash

    ralphm, why I said "good enough", it's not perfect but it does work and is deployed already, so there's going to be some friction to replace it.

  148. Zash

    we're going to have so much experience replacing e2ee layers! :D

  149. Daniel

    Spec wise omemo 2 is a worthy upgrade to omemo 1 that I'm sure will happen eventually. If MLS comes around fast enough one possible future would be to not do omemo2 and instead do omemo over MLS

  150. Daniel

    I think we've learned a lot from spec-ing omemo 2 and deploying omemo 1 that can be applied to MLS

  151. Zash

    I idle on the MLS mailing list, I'd recommend you and others here do too

  152. ralphm

    Zash: generally agree but so far OMEMO is not good enough. Whether that's because of implementations or the specifications doesn't matter. I explicitly disable it everywhere to make sure I can read all messages people try to send me. And I'm tech savvy.

  153. Daniel

    There are certainly complications around OMEMO and MLS is not going to be a magic bullet for a lot of them

  154. ralphm

    Sure

  155. Daniel

    We have omemo deployed to a few million users who are the opposite of tech savvy

  156. MattJ

    I feel like MLS might allow us to clean up a lot of edge cases though. For example, the specific details of how to do OMEMO in MUC aren't really documented cleanly anywhere IIRC?

  157. Daniel

    Obviously without any manual trust management whatsoever

  158. Daniel

    MattJ: yes and no. Omemo 2 explains a lot more on that topic then omemo 1 did

  159. Daniel

    But proper group ratcheting (in MLS) is obviously better

  160. ralphm

    I think the biggest issue is with users with multiple devices.

  161. moparisthebest

    And why are people trying to resurrect MIX now that MUC is pretty much fixed?

  162. Zash

    Yeah, and techy users are more likely to have multiple devices.

  163. ralphm

    Because it isn't.

  164. moparisthebest

    I have multiple devices, always have, and OMEMO is fine

  165. moparisthebest

    MUC is fine, MIX will never go anywhere until it's backwards compatible with MUC and doesn't require a network wide flag day

  166. Zash

    And _we here_ are more likely to have clients from the pre-OMEMO world, which gets messy and annoying.

  167. moparisthebest

    imho MIX doesn't bring enough advantages over MUC to even expend any effort on, but that's simply my opinion and is trumped by never being deployable on the public federated network without a flag day, it's utterly useless for that while it's still the case

  168. Daniel

    Not all xmpp deployments are on the open network (or care about the open network) and I think _if xmpp wants to be successful_ we need to be attrictive for closed systems too

  169. MattJ

    moparisthebest, generally I agree with you, but the discussion at the summit covered various nuances

  170. moparisthebest

    Right, mix may be useful for closed systems, people do implement them can and will do it themselves, I only care about the public federated network

  171. moparisthebest

    Right, mix may be useful for closed systems, people who implement them can and will do it themselves, I only care about the public federated network

  172. MattJ

    In particular, multiple people saying they have implemented MIX and preferred it was enough to make me give it another chance

  173. Daniel

    More attractive even. Because on closed systems we compete with matrix and/or home brewed solutions

  174. MattJ

    Also Kev's promise that the spec is open to changes if that becomes a barrier

  175. MattJ

    Also, that the only way I will ever do this in Prosody is in a backwards-compatible way with MUC

  176. moparisthebest

    Honestly I don't care if closed systems use matrix or mqtt or something homebrewed, that's their bed and they can lie in it

  177. Zash

    MIX protocol implementation on top of our existing MUC code seems plausible thing we could do

  178. moparisthebest

    MattJ: excellent I'm fully on board with that

  179. Zash

    I'm not ready yet to rewrite MUC, since we had a partial rewrite not too many versions ago.

  180. Daniel

    moparisthebest: closed systems can still bring value (money, human resources, knowledge) into the federated system

  181. MattJ

    Basically "MattJ killed MIX" was the summary of what went into the summit notepad, and I'm not prepared to be one person stubbornly driving the direction of the ecosystem if other people are telling me that MIX is absolutely better

  182. Kev

    Closed doesn't mean 'not federated', FWIW.

  183. Zash

    moparisthebest, even with closed systems you sometimes realize you want some limited federation, which XMPP is good at

  184. Daniel

    Basically all my commercial customers are closed systems. And if it weren't for them I might not be able to participate in the XSF like I do now

  185. Kev

    There are non-Internet federated networks of XMPP.

  186. MattJ

    Kev, then substitute "closed" with "not federated"

  187. MattJ

    in this discussion, because you know what's what we mean :)

  188. Daniel

    > Closed doesn't mean 'not federated', FWIW. Yes. It's just lacking a proper word for that

  189. MattJ

    or the other way around, since I guess that was your point

  190. moparisthebest

    Here's what I'm 100% opposed to: the already small MUC ecosystem being split into some MUC some MIX where clients (or worse in the MIX case, servers) supporting one or the other can't communicate

  191. moparisthebest

    > Closed doesn't mean 'not federated', FWIW. Right and that's why I said I only care about the *public* federated network

  192. MattJ

    moparisthebest, yes, I absolutely agree with that. Which is why I will *only* implement MIX in Prosody if we maintain MUC compatibility. I've never tried to implement MIX standalone, and I don't intend to do that.

  193. MattJ

    I am pretty sure that a standalone MIX implementation would be pretty straightforward

  194. moparisthebest

    Right, I have no problem with that

  195. Daniel

    I agree with that. Still a I think we should consider offering an attractive standard to those who don't care about backwards compatibility

  196. moparisthebest

    Sure, just not at the cost of splitting the public federated muc ecosystem

  197. Daniel

    We are a standards body. Not a publicly federated IM club

  198. MattJ

    Daniel, if someone wanted to sponsor that in Prosody (and I/Zash/whoever had nothing better to do) then yeah, sure

  199. MattJ

    But my personal priority is working on stuff that is also going to benefit the network, while having multiple competing incompatible protocols may harm it

  200. MattJ

    (there are already MIX-only clients, for example)

  201. moparisthebest

    Right, and some people here are employed mainly by creating private systems, and some are volunteers that only interact with the public federated network, it's normal and fine that they have different priorities, I'm just stating mine

  202. Daniel

    Yes my personal interested and priorities are obviously with the open network. I was just wearing my council hat for a second

  203. moparisthebest

    Yes, and council hat on I'm impartial too, but with it off I'm super opposed to anything that will cause: > Here's what I'm 100% opposed to: the already small MUC ecosystem being split into some MUC some MIX where clients (or worse in the MIX case, servers) supporting one or the other can't communicate

  204. moparisthebest

    If that can be fixed, and MIX still brings worthwhile improvements, count me in

  205. MattJ

    So where things stand from my perspective: I'm going to try again (or convince Someone Else™ to), and provide feedback if anything in the specs becomes an obstacle

  206. MattJ

    Because I guess in the past I felt the specs were less flexible than the summit discussions have encouraged me to believe

  207. Daniel

    The question to me is not "can muc be fixed" (it can) the question is do I want to explain to need for occupant id and schrodingers muc in a 60 minute intro talk to xmpp

  208. moparisthebest

    As is here's my main argument against MIX: It requires the client's server to support MIX too right? If it needs that, why not just have the client's server be a MUC bouncer and you are done? (Clients could even talk to their muc bouncer with a mix like protocol) But then rooms are still MUCs, and individual servers can enable this new plugin/protocol as they see fit

  209. Daniel

    The question to me is not "can muc be fixed" (it can) the question is do I want to explain the need for occupant id and schrodingers muc in a 60 minute intro talk to xmpp

  210. MattJ

    moparisthebest, apparently there are provisions now in the spec for the user's server not supporting it

  211. MattJ

    It's more ugly for the client, but apparently can still work

  212. Zash

    Daniel, do you think MIX solves all that and if we use it for the next 20 years, we won't end up with as many edge case tweaks and fixes?

  213. moparisthebest

    Ok well that's one absolutely major blocker out of the way

  214. Daniel

    > Daniel, do you think MIX solves all that and if we use it for the next 20 years, we won't end up with as many edge case tweaks and fixes? I'm at least ready to continue exploring the possibility

  215. flow

    Zash, we certainly will discover edge cases in mix and thinks that where not considered. but the approach that MIX takes on group chats is clearly superious to the MUC approach from an architectural point of view. my hopes would also be that this also results in less edge cases and fixing.

  216. jonas’

    ("edge cases" such as s2s interruptions)

  217. flow

    note that I am talking about the MIX aproach and not MIX as it is right now. I feel like MIX is probalby still a bit bloated (at least from the spec side of things). Ideally we would define a minimal set of features that are absolutely neccessary for a groupchat and build from there

  218. moparisthebest

    "clearly superior" isn't the only benchmark though, is it advantageous enough to justify the effort once you account for everything including backwards compatibility etc etc

  219. moparisthebest

    100% to flow's last message

  220. flow

    moparisthebest, yes, that is what I tried to express. mix has the better techonolgical architecture compared to muc, but that alone is no enough to get market adaption (think "vhs vs. betamax")

  221. Daniel

    I guess we will see. It will either be a sasl2 situation where nothing happens for years and then suddenly over night everyone implements it - or it won't

  222. flow

    moparisthebest, yes, that is what I tried to express. mix has the better techonolgical architecture compared to muc, but that alone is not enough to get market adaption (think "vhs vs. betamax")

  223. flow

    usually if people ask if they should invest in fixing muc or working on mix, I say "why not both?" :)

  224. moparisthebest

    Because that's more work ;)

  225. Guus

    > Because that's more work ;) The contractor in me is delighted.

  226. MSavoritias (fae,ve)

    we shouldnt be scared of trying new things. I am glad at least I see a lot of voices willing to try new things here without being overly stuck in their ways :)

  227. moparisthebest

    We should be afraid of trying new things if it's going to fragment the public federated network though, that's my only point

  228. moparisthebest

    Matrix is a good example of "trying a new thing" that did this

  229. MSavoritias (fae,ve)

    I agree. Just that as with everything there is a balance :) Be afraid too much and you end up being stuck and then nobody wants to get involved

  230. moparisthebest

    Agreed

  231. flow

    you can't really prevent such kind of fragmentation as you can't forbid people from working on what they want

  232. MSavoritias (fae,ve)

    also true

  233. flow

    so since it is a given, it may be better to think of ways with dealing with such fragmentation

  234. ralphm

    I was speaking to Saul (of Jitsi fame) and he mentioned that one of the biggest issues in their use of XMPP for multi-user conferencing is all the presences being exchanged. Of course they can choose to not broadcast it, but from the protocol perspective that's a workaround. This is just one of the things that MIX aims to address, and of course MUC could be retrofitted to do that. In my and other's experience, though, MIX solves this in a lot cleaner way. Yes we need MUC compat at least for a while, and yes closed environments make it a lot easier to choose to do MIX only. What we discussed was do both: see how well we can implement MIX, likely with backwards compat support on servers, *and* see what improvements we can do to MUC itself. One concrete example is explicit, persistent room joins that do not depend on presence.

  235. ralphm

    As with other protocols before this (pubsub, disco, signaling) we'll see what will win out in the end. We may be able to secure funding for certain developments in the community (as I wrote above), too.

  236. flow

    to be frank, I always wondered why jitsi uses xmpp and not some other pubsub service (like kafka). but this can probably asked for everyting that is build on MUC where the participants are more machines and not really humans (or at least humans not aware that they are also in a MUC)

  237. Zash

    flow, remember how Jitsi (Desktop) was a regular XMPP (and SIP) client with calls and stuff?

  238. flow

    that said, jitsi contributes back to smack, so I really would miss them

  239. Zash

    I'd assume it's a case of already having familiarity with the stack and it doing the job

  240. flow

    Zash, sure

  241. ralphm

    flow: I don't understand what internal messaging has to do with Jitsi's external signaling and chat implementation.

  242. flow

    Of course I was hoping of an answer like "XMPP provides this unique feature that no one else has"

  243. MattJ

    ralphm, I don't get why disabling presences in MUC is "a workaround" but MIX is not

  244. ralphm

    Jitsi is much more than your run of the mill webpage that you can go to do have a conference.

  245. Zash

    opt-in vs opt-out?

  246. MattJ

    Yes, I guess it comes down to that

  247. ralphm

    MattJ: because in MIX it is very explicit whether you subscribe to presence or not, both in the client and on the server subscription.

  248. MattJ

    Right, and it would be **trivial** to add the same thing to MUC

  249. MattJ

    Literally a matter of defining the syntax

  250. Kev

    > Literally a matter of defining the syntax As opposed to most protocol issues :)

  251. Zash

    MUC does a ton of things implicitly by default, which you can opt out to (history comes to mind in favor of MAM, and now presence)

  252. flow

    yeah, I probably don't know enough of jitsi's internals. I always assumed that here is a muc backing every videoconference, which is used to fan out control messages to the participants of the conference

  253. MattJ

    It's not trivial to switch to an entirely new protocol *and* bridge it to the old one

  254. ralphm

    MattJ: as I said above, many things in MIX could be retrofitted into the MUC protocol. That doesn't mean that it is by nature a good idea.

  255. MattJ

    It doesn't mean that by nature it's a bad idea

  256. ralphm

    Indeed

  257. moparisthebest

    > you can't really prevent such kind of fragmentation as you can't forbid people from working on what they want Sure but I can bring up my reasons as to why I think it's a terrible idea and the public federated network shouldn't do it

  258. ralphm

    flow: I don't see how "Kafka" makes that better. It doesn't really matter what the server side internal messaging does. (Saying that having built an XMPP service with internal Kafka messaging)

  259. moparisthebest

    Re: jitsi they aren't interested in interop anyway so I don't care about their desires, simple

  260. flow

    ralphm, I maybe mislead you with dropping kafka, that was just the name of the first java'ish pub/sub thing that come to my mind

  261. ralphm

    moparisthebest: what makes you say that?

  262. flow

    but fact is, there are distributed pub/sub implementations that are not xmpp

  263. moparisthebest

    ralphm: they said it, I didn't, hold and I'll try to find the link

  264. ralphm

    I think XMPP brings a bunch of things to the table that you have to reinvent if you use another such system. At VEON, the prototype implementation that was done before we started our own development, was based on a custom websocket protocol. We explored MQTT, for example, but it would still be mostly all custom stuff. XMPP gave us a bunch of features out of the box that made basing calls, groups, etc. on, much, much easier.

  265. ralphm

    And yes, because we were a closed system (we did federate, just not openly), we could get started with MIX much easier than I think we'd have done with MUC.

  266. ralphm

    In fact the federation part saved our butts a few times.

  267. moparisthebest

    ralphm: I can't find the issue but iirc it was a discussion with Daniel on the jitsi issue tracker where they said they weren't interested in doing any interop over XMPP and if other projects wanted to interop the only way they'd support it is via embedding a webview of jitsi web

  268. Daniel

    https://github.com/jitsi/jitsi-meet/issues/6235#issuecomment-616721373

  269. Daniel

    Not necessarily sharing moparisthebest interpretation of the situation but that's the issue

  270. moparisthebest

    Thanks!

  271. MSavoritias (fae,ve)

    if its due to xsf lagging behind in some xeps I have heard that before

  272. MSavoritias (fae,ve)

    just mentioning

  273. moparisthebest

    Anyway, glad to have closed systems (that may federate with each other) collaborate on ways to do things here, but they shouldn't be pushed on the public federated network if they will harm it, and as it sits currently, this is MIX

  274. moparisthebest

    MSavoritias (fae,ve): the XSF never holds anyone back from doing anything

  275. MSavoritias (fae,ve)

    of course I was talking about the xeps part. Jitsi is evident of going your own way after all

  276. moparisthebest

    But "holding up a XEP" or whatever still doesn't hold anyone up

  277. ralphm

    If we would be able to prevent active harm from a protocol perspective, XHTML-IM would not be implemented any more. I think we should not be afraid to try out alternative approaches to any of our building blocks, and how well that is supported is up to implementations. If it turns out that MIX works out better than MUC, then it is likely it will win out. I still think that, for now, MUC support, even if limited, is likely to help adoption of MIX. You can have a MIX implementation that supports MUC, or a MUC implementation that supports MIX. For clients, obviously, the situation is harder. But I don't think we should hold on to older protocol just because they currently have wide adoption.

  278. moparisthebest

    I think we have tried it out, mix has been a thing for 2644 days and everyone still uses muc, but we'll see what the future will hold

  279. ralphm

    Daniel: yeah, that summary makes sense and comes down to: incompatible stuff sucks. With all the interop discussions happening in the EU, I honestly think that Jitsi will also need to play, and if XMPP is to be the common thing, they actually have a much easier starting position. I also think that three years later, and discussing this not through the issue tracker but through e.g. Saul will get us further. So I did and then this happened: https://github.com/jitsi/lib-jitsi-meet/pull/2212#issuecomment-1420691239

  280. moparisthebest

    Now I'm gonna sound like a pessimist... But does anyone think EU is gonna pick anything on technical grounds instead of marketing/donation budget? Not sure it's worth expending any effort on that front without a ~bribe~marketing budget in the millions

  281. moparisthebest

    XMPP is already by far the best choice from a technical POV

  282. Zash

    moparisthebest, itym reconstitute us as a lobby organization

  283. MattJ

    OK then. Protocol development ends here!

  284. MattJ

    Solves the editor issue 😜

  285. Zash

    And we still have reason to go to Brussels!

  286. moparisthebest

    Not at all, just saying protocol development only for the sake of chasing something that'll never happen isn't very helpful

  287. Zash

    What comes first, the protocol or the use case? Sometimes it's one, sometimes the other. We shall see how it turns out.

  288. moparisthebest

    If it improves XMPP, then great

  289. Zash

    Or I probably mean s/use case/implementation/

  290. Zash

    moparisthebest, but really, you think the entity that brought you GDPR won't regulate messaging apps into opening up?

  291. moparisthebest

    Implementation should always come first before protocol, but sometimes new use cases come later

  292. Kev

    > Now I'm gonna sound like a pessimist... But does anyone think EU is gonna pick anything on technical grounds instead of marketing/donation budget? Not sure it's worth expending any effort on that front without a ~bribe~marketing budget in the millions There was suggestion at the summit that if all that came out of it was interop between the not-so-big players like XMPP and Matrix, that'd still be a win.

  293. Daniel

    The entity that brought you cookie banners?

  294. singpolyma

    Yum, cookies

  295. moparisthebest

    Zash: sure, but Twitter and Facebook will negotiate private federation been themselves and EU officials will declare victory and call it done

  296. moparisthebest

    Zash: sure, but Twitter and Facebook will negotiate private federation between themselves and EU officials will declare victory and call it done

  297. moparisthebest

    XMPP and Matrix already have interop, and it didn't require govt involvement

  298. ralphm

    There's much more in this space than just the public IM services. There's also what governments use for communication, and current legislation makes it pretty much impossible to doing anything but XMPP. There are multiple similar situations, like NATO and healthcare.

  299. ralphm

    If anything, the conversations I had at FOSDEM have convinced me that we're not just a viable standard for this, we might be the most likely one. I'm going to see how far we can take this, but this indeed goes beyond just working on standards. And we will need external expertise. And possibly funding. And we need to be at the tables that discuss this stuff. This is not impossible.

  300. Guus

    For many organizations, the choice for XMPP was already made, long ago. In many industries, we're not so much having the problem of "not being picked" as we are running the risk of being replaced. I feel that there is much to be gained by capitalizing on where XMPP is already established.

  301. ralphm

    Indeed

  302. moparisthebest

    Organizations replace protocols?

  303. Guus

    Being used everywhere is something that we should showcase better. Also, where we are already in place, there's often some kind of budget (either financial, or otherwise) to improve on the standard or on implementations.

  304. Guus

    moparisthebest: the larger ones do, yes.

  305. moparisthebest

    I think my experience with 100% of healthcare being dominated by HL7 from the 80s has taught me otherwise 🤣

  306. Guus

    or at least, they're choosing protocols and their implementations.

  307. moparisthebest

    HL7 in particular came out with a newer standard around 2000 based on XML and no one uses it, they stay with the 1980s version

  308. larma

    As far as I understood, MIMI WG is basically thinking of 3 layers of protocol: s2s transport, encryption and payload. For encryption, MLS is basically set. For transport, XMPP is an option considered, but not very much liked by some parties (not necessarily with any actual reason other than the typical "old, nobody uses it anymore"). Alternative could be a rather simple HTTP-based pushing of MLS encrypted messages. For payload, consensus seems to be that consensus is even harder to reach than for transport. Matrix people obviously are proposing to use Matrix here, obviously liked by Matrix fanboys.

  309. Guus

    The fact that there is an "old, nobody uses it anymore" sentiment is something that we should stamp out, somehow.

  310. moparisthebest

    Can't fix stupid

  311. Daniel

    A good portion of my customer's don't want me to talk about them 🙈

  312. larma

    I'd assume that if XMPP was found to be a good fit for MLS as a transport, also using it for payload might be something that people would consider.

  313. singpolyma

    Daniel: are they embarassed to be using XMPP, or just really secrative?

  314. MattJ

    The first rule of XMPP

  315. Daniel

    > Daniel: are they embarassed to be using XMPP, or just really secrative? The latter mostly

  316. larma

    So it boils down to: if we want XMPP to be reasonably considered within MIMI we probably need a XEP and POC for MLS in XMPP, which I happen to be interested in working on (but probably not before April due to time constraints)

  317. Guus

    There's plenty of examples, I think. I mean, as I want to populate xmpp.work, I have a filter on LinkedIn that reports on jobs that have 'xmpp' in their description. In the last 24 hours, there were 12 new results. Granted, not all of them are very specific XMPP jobs, but it's used _all over the place_.

  318. larma

    Anyone considering to attend IETF 116, btw?

  319. Zash

    When and is it in Prague?

  320. Guus

    The XSF may want to decide to reserve budget for this, to avoid efforts like these becoming to much time-constrained on the calendar of people that need to span their attention between this, and a daytime job.

  321. larma

    Zash, March

  322. larma

    Zash, March 25

  323. larma

    IETF 118 is in Prague

  324. larma

    IETF 118 is in Prague, but that's November

  325. Zash

    So 116 is in Yokohama, Japan.

  326. larma

    Yes.

  327. ralphm

    Guus: for sure, that's my plan

  328. MattJ

    It was on my radar. I think it would be good to have someone there, but I don't know if it can be me this time.

  329. Guus

    If (I'm not saying it is) we deem it important for XMPP to be well represented, maybe the XSF can consider funding people (eg: council and board members) to attend meetings like these.

  330. MSavoritias (fae,ve)

    agreed. I think the MIM thing is a good opportunity.

  331. MSavoritias (fae,ve)

    and as it has been said I think we are in a good position to do this, tech wise

  332. ralphm

    Guus: we've already and we will

  333. Guus

    I think there are more sides to it - it's not just the technical perspective - but by participating, we're also taking away from the old/obsolete characteristic that we apparantly bear.

  334. MSavoritias (fae,ve)

    true

  335. Guus

    ralphm: we've already? Unless I missed something, I think we're talking about different orders of magnitude. I'm suggesting to do more than reimburse travel expense.

  336. Zash

    ... reimburse the $1000 IETF ticket?

  337. Daniel

    Guus: you mean actually pay them for time spent? I don't think that's necessary

  338. Guus

    time spent at the meeting - time spent preparing for the meeting - time spent following up

  339. Zash

    pay everyone for all time, always!

  340. Guus

    well, yes, ideally. If this was a conference that you'd attend on behalf of an employer, you'd also be paid.

  341. Guus

    I know that we're not in the habit of doing things - but that doesn't mean it's unheard of.

  342. Daniel

    Thus far I think we've paid for one or two people's ticket and travel I think? If that's something we could continue to do I'd be happy

  343. MSavoritias (fae,ve)

    also submit some xmpp proposals in MIM would be nice

  344. Guus

    What we've done so far has apparently not been enough - I'm not saying that we'll fix all these issues with money - but if we spend it wisely, it will definitely help.

  345. Guus

    MSavoritias (fae,ve): if that's something that we as an organization find important enough, we could pay an individual or an organization to make that happen.

  346. Daniel

    We've done it for one event. I don't think we are ready to jump to the conclusion that it's not working

  347. Daniel

    Or to put it into more concrete terms. If the XSF would pay for my travels and the ticket to IETF I wouldn't take extra money on top of it.

  348. MattJ

    Yeah, I think "not working" is a stretch. This isn't something that happens overnight. For example, the MIMI working group was officially formed by the IETF... just today

  349. MattJ

    Their goals are to deliver specs by March 2024

  350. MSavoritias (fae,ve)

    I think not working in the sense that people think that the protocol is dead

  351. Daniel

    I would have gone to London too. But I think in that case it made more sense to send MattJ

  352. MattJ

    (some sooner than that, to be clear... but you get the point)

  353. Guus

    I wasn't specifically meaning _this_ meeting, but more of the larger perspective. I feel that the XSF is quite conservative in spending money. That has not helped us avoid being perceived as becoming outdated. I am suggesting that this could possibly be addressed by the XSF spending more money for things to happen. Sending people to a meeting could be one of those things, but we can probably think of quite a few more examples.

  354. MattJ

    Like having stands at large developer conferences and giving talks

  355. Guus

    or, to take Daniels example: not have one guy, but a delegation be present at IETF meetings.

  356. MattJ

    I'm not saying there isn't more we can do (there always will be), but it's not like we're doing nothing

  357. Guus

    Oh, I'm not saying that at all - I think a lot of people are doing extraordinary effort

  358. Guus

    you being one of them

  359. Guus

    I'm trying to see how we can facilitate that. "money" generally is helpful there.

  360. Daniel

    Yes I fully agree with 'money can be helpful' I'm just wondering if it is enough to limit this to travel expenses. Thus far we haven't even really tried that a lot

  361. MattJ

    Sure, but it's not the only factor. We have money, and if there are proposals people have about what to spend it on, we should discuss those.

  362. Daniel

    Yes I fully agree with 'money can be helpful' I'm just wondering if it is enough to limit this to travel expenses (for now) . Thus far we haven't even really tried that a lot

  363. Guus

    Hire a consultant to do the MIM proposal. Hire a marketing firm to help the image. Pay for designers that float around software implementation projects.

  364. MattJ

    If someone wants to go to IETF in Japan and the only thing stopping them is money, I'm certain we can sort that out

  365. Guus

    there's three, from the top of my head. Not all of them might be appealing to everyone - but maybe we should get more into the mindset of: we have money, how can we put that to good use.

  366. Daniel

    Just practically speaking we do have money but not endless amounts of it. And travel to Japan for one or two people is expensive enough without an hourly wage on top

  367. MattJ

    Do not have a protocol drafted by an outside consultant... 🙂

  368. Guus

    why not (and they need not be external)? We have an excellent mechanism for reviewing protocol proposals. We accept external protocols all the time, it's our core business.

  369. Guus

    but, I'm not hung up on any one of these examples.

  370. Daniel

    Wait I'm supposed to review the xeps?

  371. Guus

    there's just a lot more that we can do with money than reimburse travel expenses.

  372. Guus looks at a certain spreadsheet of Doom. I think you are, yes. :)

  373. moparisthebest

    For someone external it would take us more time to explain what was needed and how to do it than to just write the XEP

  374. MattJ

    Exactly

  375. MSavoritias (fae,ve)

    I think there was talk to have somebody compile a MIM proposal and the xsf to pay for it

  376. MSavoritias (fae,ve)

    not sure where that went

  377. Zash

    I wouldn't mind having a Technical Writer assist with wrangling words per the will of the Council :)

  378. MattJ

    Yes, someone we have an ongoing relationship with would be okay

  379. stpeter

    As someone who has a strong interest in the rate at which we might spend XSF funds (since I’m the Treasurer and a current Board member) but who doesn’t pay close attention to this channel, I’d find it helpful for folks to write up one or more proposals.

  380. moparisthebest

    Well singpolyma proposed an XMPP track/get together at https://sfconservancy.org/fossy/ this year, and someone else mentioned we could maybe do a NA Summit

  381. pep.

    "MattJ> Basically "MattJ killed MIX" was the summary of what went into the summit notepad" wow, that's harsh.

  382. pep.

    Not like there isn't enough XMPP servers out there (I count 6?) Especially when people talk about private/closed stuff..

  383. pep.

    > ralphm> because in MIX it is very explicit whether you subscribe to presence or not https://wiki.xmpp.org/web/MUC_Extensions, There's two specs for this even. 311 and 436

  384. MattJ

    pep. [19:46]: > "MattJ> Basically "MattJ killed MIX" was the summary of what went into the summit notepad" wow, that's harsh. Out of context, perhaps 🙂

  385. Zash

    So. Many. Layers. Of quoting.

  386. pep.

    Zash, wait until you see replies in Dino and Movim

  387. Zash

    the date of my upgrade to Debian 12 just crept forward

  388. pep.

    (It's a lot worse for those who have to endure fallbacks)

  389. jonas’

    I like the quoting there

  390. Zash

    The subtle prod for users to upgrade, or to indirectly prod their client devs :)

  391. jonas’

    and I assume people use it here and so far I haven't been annoyed by the fallback yet

  392. jonas’

    but the new dino broke scaling, so it is unusable on my laptop

  393. pep.

    jonas’, I feel it's easy to have many layers of quoting very quickly with replies to replies, and I've seen it happen in the wild already

  394. jonas’

    rocketchat solves that by only showing a limited number of quote layers

  395. jonas’

    could do the same for the fallbacks

  396. jonas’

    sounds like an easy, sensible, and acceptable refinement of that

  397. moparisthebest

    pep.: Is it different to threading in Cheogram?

  398. pep.

    threading doesn't have fallback

  399. pep.

    / need

  400. MSavoritias (fae,ve)

    Also threading and replies are different. Slightly

  401. moparisthebest

    Hmm, maybe... Confusing (:

  402. pep.

    Re IETF meeting in Japan. While I'm not saying anyone from europe shouldn't go or shouldn't be funded, is there nobody from the community that lives somewhere close?

  403. pep.

    I also agree with Guus re funding people. Within XSF limits of XSF resources of course. (Even though getting money is something we haven't really tried to do so I suspect we can get some more somewhat easily)

  404. ralphm

    > As someone who has a strong interest in the rate at which we might spend XSF funds (since I’m the Treasurer and a current Board member) but who doesn’t pay close attention to this channel, I’d find it helpful for folks to write up one or more proposals. stpeter: yes, my plan was to use tomorrow's board meeting to bring you up to speed with what MattJ, Winfried and I have discussed with some (external) people, come up with a set of goals, and then see how we work that out into a plan. Finance is just one part of it.

  405. Daniel

    What's 'the usual time' for that again?

  406. ralphm

    5 Jan was 17:00 UTC

  407. Daniel

    OK cool. Just making sure it doesn't conflict with council

  408. singpolyma

    While it violates a MUST in https://xmpp.org/extensions/xep-0221.html as currently written, what would people think about this element going into an <option> (and not just a <field>) for eg list-single