-
singpolyma
Look like that's mostly about presence specifically
-
singpolyma
I was gonna say e2ee might kill multicast anyway, but presence isn't going e2ee anytime soon
-
moparisthebest
Squeaky Latex Folf: so XMPP uses literally kilobytes more than it could with some changes? Hmm I wonder why no one cared lol
-
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
-
moparisthebest
In my ideal utopia everyone in the world would have an XMPP address and no single server would have more than 10 users
-
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
-
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.✎ -
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. ✏
-
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. ✏
-
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
-
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
-
flow
of course, that does not mean that we shouldn't address protocol drawbacks when they cause issues
-
ralphm
See also minix
-
flow
doesn't drive minix intel's management engine?
-
ralphm
I mean the interaction Linus had with his professor.
-
flow
but yes, the situation is probably a bit comperable to the linux vs minix situation
-
flow
although, microkernels *are* a thing, even though they are not that visible, they are more widely used than it looks at first sight
-
flow
and I assume that is not the case for psyc, but maybe it is driving something I don't know about?
-
ralphm
I think when we get PAM (or similar) stuff going, servers could optimize subscriptions there. "I'm subscribing for this server"
-
ralphm
Without actually having to sync the local list of subscribers. The room would still have the list of members of course.
-
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.
-
Squeaky Latex Folf
What do you mean with PAM? Pluggable Authentication Modules is all I can think about
-
Daniel
Squeaky Latex Folf: xep376
-
ralphm
By the way, something I thought about last night concerning collations: messages in threads will also have their own, right?
-
MattJ
I was thinking we could just get away with a filter for threads
-
Kev
Each message in the thread could have reactions though, as normal, I think?
-
Kev
I assumed that's what Ralph meant.
-
MattJ
Oh, sure, they're just normal messages
-
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.
-
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.
-
Zash
Sounds like a great initiative. Maybe suitable for resurrecting the other-side-of-the-pond Summit even
-
Guus
(what he said)
-
ralphm
Kev: yes, that's what I meant.
-
Guus
Took me a while to find what FOSSY is :) https://sfconservancy.org/fossy/
-
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.
-
Ge0rG
Where's that? š
-
Daniel
Canada is probably easier to travel to than the US
-
Guus
Unlikely to be true for most US citizens though.
-
ralphm
It had to do with some active Canadian XMPP projects.
-
Zash
ralphm, that would be singpolyma & co :)
-
Ge0rG
There is a Canada in Kentucky and another one in Kansas.
- Guus leaves. (not maple).
-
ralphm
There's an America in The Netherlands, so there's that.
-
ralphm
Anyway, I'd be happy to help organize a North American summit in general.
-
ralphm
However, if there are restrictions like obligatory masking or presenting proof of certain vaccinations, I will likely not participate.
-
Daniel
Isn't proof of vaccination a thing anymore on a country wide level?
-
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
-
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.
-
Daniel
Just checked Canada (for example) doesn't have any restrictions anymore
-
ralphm
singpolyma: I don't mind the form per se. We've previously done NA Summits co-located with OSCon and later RealtimeConf.
-
singpolyma
Oh yeah, fossy is likely to have a strong mask presence. Otherwise I'd never be able to go :)
-
ralphm
Daniel: my point is that the event might still
-
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.
-
Daniel
Yes. I was just curious about nation wide restrictions. Simply because I hadn't checked for the last couple of months
-
singpolyma
ralphm: some people will always choose to do evil. Can't stop them I guess
-
jonasā
like not masking at mass events?
-
ralphm
singpolyma: for sure. It is not clear to me, though, what qualifies as evil these days.
-
singpolyma
Anyway, I think we're impsossibly off topic now :)
-
jonasā
are we?
-
jonasā
I think rules for XSF events are perfectly on-topic
-
ralphm
indeed
-
ralphm
Also, note that I didn't say "we can't do it then". I said "I will likely not participate".
-
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
-
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.
-
ralphm
But I didn't say there can't be an event with such restrictions.
-
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.
-
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...
-
Zash
If there are agreed upon rules or recommendations, following them or staying home seems sensible.
-
Zash
MattJ, did you just jinx it? :)
-
ralphm
Zash: to me those are the only two options
-
Daniel
A dedicated Summit is likely not a 'mass event' in the sense that FOSDEM is one (or ietf even)
-
ralphm
No, but I'm sure the Ibis climate "control" didn't do anyone any good.
-
Daniel
every restaurant has more people in at then the conference room at summit
-
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
-
pep.
(worn?)✎ -
MattJ
Sure, like it was bad luck that I got COVID from IETF despite full mask requirements
-
pep.
(worn? worn.) ✏
-
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
-
MattJ
I'm glad I went to the IETF meeting, but it wasn't an enjoyable experience
-
pep.
I do think that people getting ill easily shouldn't be excluded though, and that we should be mindful of them
-
jonasā
pep., you mean "people getting ill easily" in the sense of people particularly vulnerable to infections?
-
MattJ
Funny to be having this conversation *after* we just had a large event, but... yeah :)
-
pep.
MattJ, agreed
-
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
-
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.
-
pep.
Yeah, and these choices prevent them from going
-
jonasā
I don't follow?
-
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
-
jonasā
my point was even *with* restrictions those I know wouldn't attend
-
Daniel
that has been the case pre-2020 too, no?
-
jonasā
but I might know rather extreme cases, granted
-
pep.
Daniel, yeah FOSDEM has always been packed wayy beyond their official limit :/
-
jonasā
Daniel, that doesn't mean that that wasn't a problem
-
ralphm
pep.: I totally get the concern for people with compromised immune systems. I also have the same feeling as MattJ.
-
ralphm
FOSDEM was a lot less crowded this year, though.
-
Zash
Especially the second day
-
Zash
Isn't all this why there hasn't been a FOSDEM for 2-3 years?
-
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"
-
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)
-
ralphm
pep.: I am afraid there is no right answer.
-
pep.
There's the "we care" or "we care less" answer :P
-
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
-
ralphm
pep.: what? This isn't boolean.
-
pep.
ralphm, no there's also "we don't care at all"!
-
singpolyma
Though certainly there are do nothing situations like FOSDEM vs do anything which I guess is basically Boolean
-
MattJ
*Anyway...*
-
singpolyma
MattJ: indeed
-
Zash
So, yeah, XMPP Event Things in America would be Good
-
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)
-
Zash
And we did briefly talk about resurrecting the Summit there
-
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.
-
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
-
ralphm
Oh, and also, this is more like a devroom than a summit.
-
singpolyma
Yes. Basically a devroom
-
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)
-
ralphm
We've also, separately, talked about a non-summit conference like thing, but maybe 2024 is a nice year for that.
-
ralphm
Right
-
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
-
singpolyma
If anyone *is* interested, especially in giving a talk, I can probably find some travel budget if that's an obstacle to someone
-
Zash
Having something for those who have trouble attending a FOSDEM-attached Summit sure would be great.
-
Zash
Suppose that's why IETF cycles between America, Europe and Asia
-
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.
-
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
-
singpolyma
That's my hope and goal with this
-
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✎ -
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 ✏
-
singpolyma
(well, I know the space is "a lot" by reputation)
-
moparisthebest
If there's going to be an XMPP thing there I'll go
-
moparisthebest
Re: travel restrictions to USA from outside I'm pretty sure they've all been lifted now Daniel
-
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?
-
moparisthebest
What were the values of X
-
Zash
eXtending and Modernising the Protocol Properly?
-
Guus
IETF's MIMI, I think.
-
Guus
but that might not cover everything.
-
Zash
Don't you worry about _blank_, let me worry about _blank_!
-
ralphm
We've discussed a few things in that direction. One is definitely doing MLS.
-
Zash
Yeah, We Should⢠do MLS, going to be rough now to compete with the Good Enough® of OldMEMO
-
MSavoritias (fae,ve)
funny how tech people think the companies will listen for sure this time with MIMI and you are missing out XD
-
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.
-
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
-
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.
-
MattJ
Guus: there are various values of X, and each is being tackled by one or more people
-
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.
-
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.
-
Guus
Thank you.
-
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.
-
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.
-
Zash
we're going to have so much experience replacing e2ee layers! :D
-
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
-
Daniel
I think we've learned a lot from spec-ing omemo 2 and deploying omemo 1 that can be applied to MLS
-
Zash
I idle on the MLS mailing list, I'd recommend you and others here do too
-
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.
-
Daniel
There are certainly complications around OMEMO and MLS is not going to be a magic bullet for a lot of them
-
ralphm
Sure
-
Daniel
We have omemo deployed to a few million users who are the opposite of tech savvy
-
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?
-
Daniel
Obviously without any manual trust management whatsoever
-
Daniel
MattJ: yes and no. Omemo 2 explains a lot more on that topic then omemo 1 did
-
Daniel
But proper group ratcheting (in MLS) is obviously better
-
ralphm
I think the biggest issue is with users with multiple devices.
-
moparisthebest
And why are people trying to resurrect MIX now that MUC is pretty much fixed?
-
Zash
Yeah, and techy users are more likely to have multiple devices.
-
ralphm
Because it isn't.
-
moparisthebest
I have multiple devices, always have, and OMEMO is fine
-
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
-
Zash
And _we here_ are more likely to have clients from the pre-OMEMO world, which gets messy and annoying.
-
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
-
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
-
MattJ
moparisthebest, generally I agree with you, but the discussion at the summit covered various nuances
-
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✎ -
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 ✏
-
MattJ
In particular, multiple people saying they have implemented MIX and preferred it was enough to make me give it another chance
-
Daniel
More attractive even. Because on closed systems we compete with matrix and/or home brewed solutions
-
MattJ
Also Kev's promise that the spec is open to changes if that becomes a barrier
-
MattJ
Also, that the only way I will ever do this in Prosody is in a backwards-compatible way with MUC
-
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
-
Zash
MIX protocol implementation on top of our existing MUC code seems plausible thing we could do
-
moparisthebest
MattJ: excellent I'm fully on board with that
-
Zash
I'm not ready yet to rewrite MUC, since we had a partial rewrite not too many versions ago.
-
Daniel
moparisthebest: closed systems can still bring value (money, human resources, knowledge) into the federated system
-
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
-
Kev
Closed doesn't mean 'not federated', FWIW.
-
Zash
moparisthebest, even with closed systems you sometimes realize you want some limited federation, which XMPP is good at
-
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
-
Kev
There are non-Internet federated networks of XMPP.
-
MattJ
Kev, then substitute "closed" with "not federated"
-
MattJ
in this discussion, because you know what's what we mean :)
-
Daniel
> Closed doesn't mean 'not federated', FWIW. Yes. It's just lacking a proper word for that
-
MattJ
or the other way around, since I guess that was your point
-
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
-
moparisthebest
> Closed doesn't mean 'not federated', FWIW. Right and that's why I said I only care about the *public* federated network
-
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.
-
MattJ
I am pretty sure that a standalone MIX implementation would be pretty straightforward
-
moparisthebest
Right, I have no problem with that
-
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
-
moparisthebest
Sure, just not at the cost of splitting the public federated muc ecosystem
-
Daniel
We are a standards body. Not a publicly federated IM club
-
MattJ
Daniel, if someone wanted to sponsor that in Prosody (and I/Zash/whoever had nothing better to do) then yeah, sure
-
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
-
MattJ
(there are already MIX-only clients, for example)
-
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
-
Daniel
Yes my personal interested and priorities are obviously with the open network. I was just wearing my council hat for a second
-
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
-
moparisthebest
If that can be fixed, and MIX still brings worthwhile improvements, count me in
-
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
-
MattJ
Because I guess in the past I felt the specs were less flexible than the summit discussions have encouraged me to believe
-
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✎ -
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
-
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 ✏
-
MattJ
moparisthebest, apparently there are provisions now in the spec for the user's server not supporting it
-
MattJ
It's more ugly for the client, but apparently can still work
-
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?
-
moparisthebest
Ok well that's one absolutely major blocker out of the way
-
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
-
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.
-
jonasā
("edge cases" such as s2s interruptions)
-
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
-
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
-
moparisthebest
100% to flow's last message
-
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")✎ -
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
-
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") ✏
-
flow
usually if people ask if they should invest in fixing muc or working on mix, I say "why not both?" :)
-
moparisthebest
Because that's more work ;)
-
Guus
> Because that's more work ;) The contractor in me is delighted.
-
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 :)
-
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
-
moparisthebest
Matrix is a good example of "trying a new thing" that did this
-
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
-
moparisthebest
Agreed
-
flow
you can't really prevent such kind of fragmentation as you can't forbid people from working on what they want
-
MSavoritias (fae,ve)
also true
-
flow
so since it is a given, it may be better to think of ways with dealing with such fragmentation
-
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.
-
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.
-
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)
-
Zash
flow, remember how Jitsi (Desktop) was a regular XMPP (and SIP) client with calls and stuff?
-
flow
that said, jitsi contributes back to smack, so I really would miss them
-
Zash
I'd assume it's a case of already having familiarity with the stack and it doing the job
-
flow
Zash, sure
-
ralphm
flow: I don't understand what internal messaging has to do with Jitsi's external signaling and chat implementation.
-
flow
Of course I was hoping of an answer like "XMPP provides this unique feature that no one else has"
-
MattJ
ralphm, I don't get why disabling presences in MUC is "a workaround" but MIX is not
-
ralphm
Jitsi is much more than your run of the mill webpage that you can go to do have a conference.
-
Zash
opt-in vs opt-out?
-
MattJ
Yes, I guess it comes down to that
-
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.
-
MattJ
Right, and it would be **trivial** to add the same thing to MUC
-
MattJ
Literally a matter of defining the syntax
-
Kev
> Literally a matter of defining the syntax As opposed to most protocol issues :)
-
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)
-
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
-
MattJ
It's not trivial to switch to an entirely new protocol *and* bridge it to the old one
-
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.
-
MattJ
It doesn't mean that by nature it's a bad idea
-
ralphm
Indeed
-
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
-
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)
-
moparisthebest
Re: jitsi they aren't interested in interop anyway so I don't care about their desires, simple
-
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
-
ralphm
moparisthebest: what makes you say that?
-
flow
but fact is, there are distributed pub/sub implementations that are not xmpp
-
moparisthebest
ralphm: they said it, I didn't, hold and I'll try to find the link
-
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.
-
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.
-
ralphm
In fact the federation part saved our butts a few times.
-
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
-
Daniel
https://github.com/jitsi/jitsi-meet/issues/6235#issuecomment-616721373
-
Daniel
Not necessarily sharing moparisthebest interpretation of the situation but that's the issue
-
moparisthebest
Thanks!
-
MSavoritias (fae,ve)
if its due to xsf lagging behind in some xeps I have heard that before
-
MSavoritias (fae,ve)
just mentioning
-
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
-
moparisthebest
MSavoritias (fae,ve): the XSF never holds anyone back from doing anything
-
MSavoritias (fae,ve)
of course I was talking about the xeps part. Jitsi is evident of going your own way after all
-
moparisthebest
But "holding up a XEP" or whatever still doesn't hold anyone up
-
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.
-
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
-
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
-
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
-
moparisthebest
XMPP is already by far the best choice from a technical POV
-
Zash
moparisthebest, itym reconstitute us as a lobby organization
-
MattJ
OK then. Protocol development ends here!
-
MattJ
Solves the editor issue š
-
Zash
And we still have reason to go to Brussels!
-
moparisthebest
Not at all, just saying protocol development only for the sake of chasing something that'll never happen isn't very helpful
-
Zash
What comes first, the protocol or the use case? Sometimes it's one, sometimes the other. We shall see how it turns out.
-
moparisthebest
If it improves XMPP, then great
-
Zash
Or I probably mean s/use case/implementation/
-
Zash
moparisthebest, but really, you think the entity that brought you GDPR won't regulate messaging apps into opening up?
-
moparisthebest
Implementation should always come first before protocol, but sometimes new use cases come later
-
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.
-
Daniel
The entity that brought you cookie banners?
-
singpolyma
Yum, cookies
-
moparisthebest
Zash: sure, but Twitter and Facebook will negotiate private federation been themselves and EU officials will declare victory and call it done✎ -
moparisthebest
Zash: sure, but Twitter and Facebook will negotiate private federation between themselves and EU officials will declare victory and call it done ✏
-
moparisthebest
XMPP and Matrix already have interop, and it didn't require govt involvement
-
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.
-
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.
-
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.
-
ralphm
Indeed
-
moparisthebest
Organizations replace protocols?
-
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.
-
Guus
moparisthebest: the larger ones do, yes.
-
moparisthebest
I think my experience with 100% of healthcare being dominated by HL7 from the 80s has taught me otherwise š¤£
-
Guus
or at least, they're choosing protocols and their implementations.
-
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
-
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.
-
Guus
The fact that there is an "old, nobody uses it anymore" sentiment is something that we should stamp out, somehow.
-
moparisthebest
Can't fix stupid
-
Daniel
A good portion of my customer's don't want me to talk about them š
-
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.
-
singpolyma
Daniel: are they embarassed to be using XMPP, or just really secrative?
-
MattJ
The first rule of XMPP
-
Daniel
> Daniel: are they embarassed to be using XMPP, or just really secrative? The latter mostly
-
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)
-
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_.
-
larma
Anyone considering to attend IETF 116, btw?
-
Zash
When and is it in Prague?
-
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.
-
larma
Zash, March✎ -
larma
Zash, March 25 ✏
-
larma
IETF 118 is in Prague✎ -
larma
IETF 118 is in Prague, but that's November ✏
-
Zash
So 116 is in Yokohama, Japan.
-
larma
Yes.
-
ralphm
Guus: for sure, that's my plan
-
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.
-
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.
-
MSavoritias (fae,ve)
agreed. I think the MIM thing is a good opportunity.
-
MSavoritias (fae,ve)
and as it has been said I think we are in a good position to do this, tech wise
-
ralphm
Guus: we've already and we will
-
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.
-
MSavoritias (fae,ve)
true
-
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.
-
Zash
... reimburse the $1000 IETF ticket?
-
Daniel
Guus: you mean actually pay them for time spent? I don't think that's necessary
-
Guus
time spent at the meeting - time spent preparing for the meeting - time spent following up
-
Zash
pay everyone for all time, always!
-
Guus
well, yes, ideally. If this was a conference that you'd attend on behalf of an employer, you'd also be paid.
-
Guus
I know that we're not in the habit of doing things - but that doesn't mean it's unheard of.
-
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
-
MSavoritias (fae,ve)
also submit some xmpp proposals in MIM would be nice
-
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.
-
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.
-
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
-
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.
-
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
-
MattJ
Their goals are to deliver specs by March 2024
-
MSavoritias (fae,ve)
I think not working in the sense that people think that the protocol is dead
-
Daniel
I would have gone to London too. But I think in that case it made more sense to send MattJ
-
MattJ
(some sooner than that, to be clear... but you get the point)
-
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.
-
MattJ
Like having stands at large developer conferences and giving talks
-
Guus
or, to take Daniels example: not have one guy, but a delegation be present at IETF meetings.
-
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
-
Guus
Oh, I'm not saying that at all - I think a lot of people are doing extraordinary effort
-
Guus
you being one of them
-
Guus
I'm trying to see how we can facilitate that. "money" generally is helpful there.
-
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✎ -
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.
-
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 ✏
-
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.
-
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
-
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.
-
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
-
MattJ
Do not have a protocol drafted by an outside consultant... š
-
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.
-
Guus
but, I'm not hung up on any one of these examples.
-
Daniel
Wait I'm supposed to review the xeps?
-
Guus
there's just a lot more that we can do with money than reimburse travel expenses.
- Guus looks at a certain spreadsheet of Doom. I think you are, yes. :)
-
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
-
MattJ
Exactly
-
MSavoritias (fae,ve)
I think there was talk to have somebody compile a MIM proposal and the xsf to pay for it
-
MSavoritias (fae,ve)
not sure where that went
-
Zash
I wouldn't mind having a Technical Writer assist with wrangling words per the will of the Council :)
-
MattJ
Yes, someone we have an ongoing relationship with would be okay
-
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.
-
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
-
pep.
"MattJ> Basically "MattJ killed MIX" was the summary of what went into the summit notepad" wow, that's harsh.
-
pep.
Not like there isn't enough XMPP servers out there (I count 6?) Especially when people talk about private/closed stuff..
-
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
-
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 š
-
Zash
So. Many. Layers. Of quoting.
-
pep.
Zash, wait until you see replies in Dino and Movim
-
Zash
the date of my upgrade to Debian 12 just crept forward
-
pep.
(It's a lot worse for those who have to endure fallbacks)
-
jonasā
I like the quoting there
-
Zash
The subtle prod for users to upgrade, or to indirectly prod their client devs :)
-
jonasā
and I assume people use it here and so far I haven't been annoyed by the fallback yet
-
jonasā
but the new dino broke scaling, so it is unusable on my laptop
-
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
-
jonasā
rocketchat solves that by only showing a limited number of quote layers
-
jonasā
could do the same for the fallbacks
-
jonasā
sounds like an easy, sensible, and acceptable refinement of that
-
moparisthebest
pep.: Is it different to threading in Cheogram?
-
pep.
threading doesn't have fallback
-
pep.
/ need
-
MSavoritias (fae,ve)
Also threading and replies are different. Slightly
-
moparisthebest
Hmm, maybe... Confusing (:
-
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?
-
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)
-
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.
-
Daniel
What's 'the usual time' for that again?
-
ralphm
5 Jan was 17:00 UTC
-
Daniel
OK cool. Just making sure it doesn't conflict with council
-
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