XSF Discussion - 2023-02-07

Look like that's mostly about presence specifically

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

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

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

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

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

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

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

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

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

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

See also minix

doesn't drive minix intel's management engine?

I mean the interaction Linus had with his professor.

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

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

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

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

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

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.

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

Squeaky Latex Folf: xep376

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

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

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

I assumed that's what Ralph meant.

Oh, sure, they're just normal messages

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.

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.

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

(what he said)

Kev: yes, that's what I meant.

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

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.

Where's that? 😁

Canada is probably easier to travel to than the US

Unlikely to be true for most US citizens though.

It had to do with some active Canadian XMPP projects.

ralphm, that would be singpolyma & co :)

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

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

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

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

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

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

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.

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

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

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

Daniel: my point is that the event might still

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.

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

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

like not masking at mass events?

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

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

are we?

I think rules for XSF events are perfectly on-topic

indeed

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

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

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.

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

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.

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

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

MattJ, did you just jinx it? :)

Zash: to me those are the only two options

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

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

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

"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

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

(worn? worn.) ✏

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

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

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

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

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

MattJ, agreed

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

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.

Yeah, and these choices prevent them from going

I don't follow?

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

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

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

but I might know rather extreme cases, granted

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

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

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

FOSDEM was a lot less crowded this year, though.

Especially the second day

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

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"

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)

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

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

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

pep.: what? This isn't boolean.

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

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

*Anyway...*

MattJ: indeed

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

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)

And we did briefly talk about resurrecting the Summit there

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.

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

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

Yes. Basically a devroom

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

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

Right

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

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

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

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

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

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

That's my hope and goal with this

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 ✏

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

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

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

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?

What were the values of X

eXtending and Modernising the Protocol Properly?

IETF's MIMI, I think.

but that might not cover everything.

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

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

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

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

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

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

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.

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

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.

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.

Thank you.

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.

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.

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

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

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

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

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.

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

Sure

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

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?

Obviously without any manual trust management whatsoever

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

But proper group ratcheting (in MLS) is obviously better

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

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

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

Because it isn't.

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

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

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

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

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

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

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 ✏

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

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

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

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

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

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

MattJ: excellent I'm fully on board with that

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

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

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

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

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

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

There are non-Internet federated networks of XMPP.

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

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

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

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

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

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

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.

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

Right, I have no problem with that

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ✏

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

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

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?

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

> 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

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.

("edge cases" such as s2s interruptions)

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

"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

100% to flow's last message

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

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") ✏

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

Because that's more work ;)

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

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

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

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

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

Agreed

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

also true

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

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.

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.

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)

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

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

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

Zash, sure

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

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

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

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

opt-in vs opt-out?

Yes, I guess it comes down to that

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

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

Literally a matter of defining the syntax

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

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)

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

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

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.

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

Indeed

> 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

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)

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

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

moparisthebest: what makes you say that?

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

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

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.

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.

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

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

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

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

Thanks!

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

just mentioning

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

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

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

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

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.

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

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

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

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

moparisthebest, itym reconstitute us as a lobby organization

OK then. Protocol development ends here!

Solves the editor issue 😜

And we still have reason to go to Brussels!

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

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

If it improves XMPP, then great

Or I probably mean s/use case/implementation/

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

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

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

The entity that brought you cookie banners?

Yum, cookies

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

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

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.

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.

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.

Indeed

Organizations replace protocols?

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.

moparisthebest: the larger ones do, yes.

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

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

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

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.

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

Can't fix stupid

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

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.

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

The first rule of XMPP

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

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)

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

Anyone considering to attend IETF 116, btw?

When and is it in Prague?

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.

Zash, March 25 ✏

IETF 118 is in Prague, but that's November ✏

So 116 is in Yokohama, Japan.

Yes.

Guus: for sure, that's my plan

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.

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.

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

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

Guus: we've already and we will

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.

true

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.

... reimburse the $1000 IETF ticket?

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

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

pay everyone for all time, always!

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

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

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

also submit some xmpp proposals in MIM would be nice

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.

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.

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

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.

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

Their goals are to deliver specs by March 2024

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

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

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

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.

Like having stands at large developer conferences and giving talks

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

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

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

you being one of them

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

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.

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 ✏

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.

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

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.

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

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

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.

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

Wait I'm supposed to review the xeps?

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

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

Exactly

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

not sure where that went

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

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

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.

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

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

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

> 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

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 🙂

So. Many. Layers. Of quoting.

Zash, wait until you see replies in Dino and Movim

the date of my upgrade to Debian 12 just crept forward

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

I like the quoting there

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

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

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

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

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

could do the same for the fallbacks

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

pep.: Is it different to threading in Cheogram?

threading doesn't have fallback

/ need

Also threading and replies are different. Slightly

Hmm, maybe... Confusing (:

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?

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)

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

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

5 Jan was 17:00 UTC

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

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