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
gooyahas left
Skull Fuckerhas left
marc0shas left
marc0shas joined
snowhas left
snowhas joined
Kevhas left
dellhas left
Maranda[x]has joined
adiaholichas left
adiaholichas joined
karoshihas left
Skull Fuckerhas joined
tbm16has joined
zonsopkomsthas left
zonsopkomsthas joined
Axelhas left
snowhas left
brunrobehas left
KitKat::new()has left
Mjolnir Archonhas left
Marandahas left
Maranda[x]has left
Tobiashas joined
Link Mauvehas joined
snowhas joined
catchyhas joined
Tobiashas left
andrewhas joined
stphas joined
*IM*has left
raucaohas left
raucaohas joined
raucaohas left
raucaohas joined
stpeterhas joined
stphas left
kurisuhas joined
antranigvhas left
moparisthebest
Squeaky Latex Folf: so XMPP uses literally kilobytes more than it could with some changes? Hmm I wonder why no one cared lol
antranigvhas joined
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
restive_monkhas left
restive_monkhas joined
antranigvhas left
stpeterhas left
Steve Killehas left
Steve Killehas joined
adiaholichas left
adiaholichas joined
Yagizahas joined
Wojtekhas left
*IM*has joined
Tobihas joined
Tobiashas joined
L29Ahhas left
L29Ahhas joined
L29Ahhas left
L29Ahhas joined
Tobihas left
Tobiashas left
*IM*has left
bhavyhas joined
kurisuhas left
marc0shas left
marc0shas joined
adiaholichas left
adiaholichas joined
*IM*has joined
Trunghas joined
adiaholichas left
adiaholichas joined
L29Ahhas left
intosihas left
intosihas joined
L29Ahhas joined
Kevhas joined
intosihas left
intosihas joined
davidhas joined
davidhas left
Axelhas joined
snowhas left
L29Ahhas left
L29Ahhas joined
Tobiashas joined
Tobihas joined
Rebeldhas left
nicocohas joined
projjalmhas joined
L29Ahhas left
L29Ahhas joined
Tobihas left
resolihas joined
L29Ahhas left
L29Ahhas joined
Tobiashas left
Mjolnir Archonhas joined
KitKat::new()has joined
brunrobehas joined
Mjolnir Archonhas left
KitKat::new()has left
brunrobehas left
L29Ahhas left
Tobihas joined
Tobiashas joined
L29Ahhas joined
paulhas joined
adiaholichas left
Axel Reimerhas joined
adiaholichas joined
L29Ahhas left
kurisuhas joined
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
eevvoorhas joined
Menelhas joined
MSavoritias (fae,ve)has joined
Mjolnir Archonhas joined
KitKat::new()has joined
brunrobehas joined
miruxhas joined
Marandahas joined
Mjolnir Archonhas left
KitKat::new()has left
brunrobehas left
Marandahas left
wurstsalathas joined
Menelhas left
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
Kevhas left
Steve Killehas left
resolihas left
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.✎
Steve Killehas joined
Menelhas joined
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. ✏
Kevhas joined
Patigahas left
Patigahas joined
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
atomicwatchhas left
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.
jcbrandhas joined
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.
Half-Shothas left
Matthewhas left
uhoreghas left
homebeachhas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
Mikaelahas left
atomicwatchhas joined
Mikaelahas joined
krauqhas left
krauqhas joined
Danielhas left
Danielhas joined
Titihas joined
emushas joined
marc0shas left
marc0shas joined
Squeaky Latex Folf
What do you mean with PAM? Pluggable Authentication Modules is all I can think about
bhavyhas left
marc0shas left
marc0shas joined
adiaholichas left
chipmnkhas joined
adiaholichas joined
jabberjockehas joined
jabberjockehas left
djorzhas joined
LNJhas joined
neoxhas joined
adiaholichas left
adiaholichas joined
Alexhas joined
Menelhas left
Daniel
Squeaky Latex Folf: xep376
Menelhas joined
deimoshas left
deimoshas joined
atomicwatchhas left
projjalmhas left
dellhas joined
krauqhas left
krauqhas joined
arcxihas left
arcxihas joined
petrescatraianhas left
Chadhas left
petrescatraianhas joined
djorzhas left
atomicwatchhas joined
adiaholichas left
marc0shas left
marc0shas joined
SteveFhas joined
Mario Sabatinohas joined
gooyahas joined
Martinhas joined
SteveFhas left
SteveFhas joined
adiaholichas joined
Patigahas left
ralphm
By the way, something I thought about last night concerning collations: messages in threads will also have their own, right?
Andrzejhas joined
Andrzejhas left
LNJhas left
Andrzejhas joined
Titihas left
Andrzejhas left
Andrzejhas joined
LNJhas joined
sonnyhas left
KitKat::new()has joined
lskdjfhas joined
sonnyhas joined
Sevehas left
Sevehas joined
brunrobehas joined
praveenhas joined
Andrzejhas left
Zashhas left
stphas joined
Andrzejhas joined
eevvoorhas left
praveenhas left
praveenhas joined
Zashhas joined
dellhas left
dellhas joined
dellhas left
eevvoorhas joined
Mjolnir Archonhas joined
Marandahas joined
Andrzejhas left
Dele Olajidehas joined
Andrzejhas joined
Andrzejhas left
intosihas left
stphas left
intosihas joined
Steve Killehas left
Steve Killehas joined
karoshihas joined
Trunghas left
Trunghas joined
intosihas left
intosihas joined
Menelhas left
Menelhas joined
adiaholichas left
adiaholichas joined
Menelhas left
flashcorehas left
Andrzejhas joined
Andrzejhas left
intosihas left
intosihas joined
Maxencehas left
Maxencehas joined
Menelhas joined
adiaholichas left
Patigahas joined
adiaholichas joined
Chadhas joined
MattJ
I was thinking we could just get away with a filter for threads
atomicwatchhas left
Patigahas left
Patigahas joined
atomicwatchhas joined
atomicwatchhas left
resolihas joined
adiaholichas left
Andrzejhas joined
adiaholichas joined
intosihas left
intosihas joined
Trunghas left
Trunghas joined
Kev
Each message in the thread could have reactions though, as normal, I think?
Kev
I assumed that's what Ralph meant.
antranigvhas joined
MattJ
Oh, sure, they're just normal messages
asterixhas left
asterixhas joined
Vaulorhas left
Vaulorhas joined
eevvoorhas left
papatutuwawahas joined
eevvoorhas joined
xnamedhas left
kurisuhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
eevvoorhas left
eevvoorhas joined
atomicwatchhas joined
atomicwatchhas left
SteveFhas left
flashcorehas joined
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
Andrzejhas left
Andrzejhas joined
adiaholichas left
atomicwatchhas joined
atomicwatchhas left
adiaholichas joined
praveenhas left
praveenhas joined
Andrzejhas left
atomicwatchhas joined
atomicwatchhas left
SteveFhas joined
sonnyhas left
wladmishas left
wladmishas joined
millesimushas left
sonnyhas joined
atomicwatchhas joined
atomicwatchhas left
Titihas joined
xnamedhas joined
millesimushas joined
goffihas joined
praveenhas left
*IM*has left
millesimushas left
millesimushas joined
atomicwatchhas joined
atomicwatchhas left
*IM*has joined
bhavyhas joined
atomicwatchhas joined
atomicwatchhas left
Titihas left
intosihas left
intosihas joined
millesimushas left
Titihas joined
millesimushas joined
atomicwatchhas joined
atomicwatchhas left
Vaulorhas left
Vaulorhas joined
atomicwatchhas joined
atomicwatchhas left
paulhas left
paulhas joined
bhavyhas left
bhavyhas joined
Sevehas left
restive_monkhas left
restive_monkhas joined
Ingolfhas left
L29Ahhas joined
restive_monkhas left
jgarthas left
archas joined
restive_monkhas joined
Sevehas joined
resolihas left
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.
Vaulorhas left
Zash
Sounds like a great initiative. Maybe suitable for resurrecting the other-side-of-the-pond Summit even
Guus
(what he said)
atomicwatchhas joined
atomicwatchhas left
ralphm
Kev: yes, that's what I meant.
kurisuhas joined
govanifyhas left
praveenhas joined
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.
*IM*has left
Ingolfhas joined
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.
Guusleaves. (not maple).
ralphm
There's an America in The Netherlands, so there's that.
atomicwatchhas joined
atomicwatchhas left
Tobi_has joined
ralphm
Anyway, I'd be happy to help organize a North American summit in general.
Vaulorhas joined
ralphm
However, if there are restrictions like obligatory masking or presenting proof of certain vaccinations, I will likely not participate.
Menelhas left
Daniel
Isn't proof of vaccination a thing anymore on a country wide level?
atomicwatchhas joined
atomicwatchhas left
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
Rebeldhas joined
BASSGODhas left
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.
Mikaelahas left
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
Menelhas joined
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 :)
atomicwatchhas joined
atomicwatchhas left
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
Mikaelahas joined
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
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
Andrzejhas joined
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
Andrzejhas left
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
raucaohas left
raucaohas joined
bhavyhas left
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.
karoshihas left
pep.
Yeah, and these choices prevent them from going
adiaholichas left
jonas’
I don't follow?
Menelhas left
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
adiaholichas joined
jonas’
my point was even *with* restrictions those I know wouldn't attend
Daniel
that has been the case pre-2020 too, no?
Menelhas joined
jonas’
but I might know rather extreme cases, granted
singpolymahas left
pep.
Daniel, yeah FOSDEM has always been packed wayy beyond their official limit :/
singpolymahas joined
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"
karoshihas joined
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
Steve Killehas left
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
Steve Killehas joined
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
BASSGODhas joined
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.
karoshihas left
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 ✏
karoshihas joined
singpolyma
(well, I know the space is "a lot" by reputation)
Andrzejhas joined
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
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
Andrzejhas left
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?
dellhas joined
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_!
singpolymahas left
singpolymahas joined
Tobi_has left
singpolymahas left
singpolymahas joined
PeterWhas joined
Ingolfhas left
*IM*has joined
Wojtekhas joined
marc0shas left
marc0shas joined
sonnyhas left
intosihas left
ralphm
We've discussed a few things in that direction. One is definitely doing MLS.
intosihas joined
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
praveenhas left
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.
praveenhas joined
PeterWhas left
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.
praveenhas left
praveenhas joined
jgarthas joined
Ingolfhas joined
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.
PeterWhas joined
Menelhas left
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
jgarthas left
Zash
I idle on the MLS mailing list, I'd recommend you and others here do too
Menelhas joined
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
intosihas left
intosihas joined
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
jgarthas joined
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
restive_monkhas left
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?
restive_monkhas joined
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
PeterWhas left
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.
PeterWhas joined
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
PeterWhas left
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
Titihas left
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
Ingolfhas left
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
Ingolfhas joined
Maranda[x]has joined
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
PeterWhas joined
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
PeterWhas left
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
marc0shas left
marc0shas joined
PeterWhas joined
petrescatraianhas left
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.
projjalmhas joined
petrescatraianhas joined
gooyahas left
jonas’
("edge cases" such as s2s interruptions)
Dele Olajidehas left
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
paulhas left
paulhas joined
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
PeterWhas left
moparisthebest
100% to flow's last message
govanifyhas joined
PeterWhas joined
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
restive_monkhas left
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") ✏
PeterWhas left
flow
usually if people ask if they should invest in fixing muc or working on mix, I say "why not both?" :)
adiaholichas left
adiaholichas joined
restive_monkhas joined
Sevehas left
snowhas joined
atomicwatchhas left
Wojtekhas left
atomicwatchhas joined
intosihas left
intosihas joined
Wojtekhas joined
bhavyhas joined
bunghas joined
resolihas joined
atomicwatchhas left
Sevehas joined
resolihas left
dellhas left
marc0shas left
marc0shas joined
bunghas left
moparisthebest
Because that's more work ;)
Guus
> Because that's more work ;)
The contractor in me is delighted.
*IM*has left
*IM*has joined
SteveFhas left
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 :)
Tobiashas left
Tobiashas joined
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
bhavyhas left
moparisthebest
Matrix is a good example of "trying a new thing" that did this
Maranda[x]has left
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
Maranda[x]has joined
moparisthebest
Agreed
Tobiashas left
Tobiashas joined
Tobiashas left
resolihas joined
Tobiashas joined
Tobiashas left
Tobiashas joined
Tobiashas left
sonnyhas joined
Tobihas left
Tobihas joined
Tobiashas joined
flow
you can't really prevent such kind of fragmentation as you can't forbid people from working on what they want
djorzhas joined
Tobiashas left
Tobiashas joined
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
gooyahas joined
Tobiashas left
Tobiashas joined
adiaholichas left
Tobiashas left
Tobiashas joined
adiaholichas joined
Tobiashas left
Tobiashas joined
tbm16has left
Tobiashas left
Tobiashas joined
Wojtekhas left
Wojtekhas joined
jgarthas left
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.
papatutuwawahas left
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
massiveboxhas left
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.
Tobiashas left
Tobiashas joined
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.
Fishbowlerhas left
Fishbowlerhas joined
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
Tobiashas left
Tobiashas joined
massiveboxhas joined
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
bunghas joined
chipmnkhas left
chipmnkhas joined
Dele Olajidehas joined
Yagizahas left
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.
praveenhas left
bhavyhas joined
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.
catchyhas left
catchyhas joined
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
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
Titihas joined
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.
snowhas left
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
asterixhas left
asterixhas joined
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
Wojtekhas left
paulhas left
rubihas left
sonnyhas left
rubihas joined
rubihas left
praveenhas joined
Wojtekhas joined
twisted firestarterhas left
sonnyhas joined
neshtaxmpphas left
rubihas joined
neshtaxmpphas joined
neshtaxmpphas left
beanhas joined
Ingolfhas left
pablohas joined
Ingolfhas joined
neshtaxmpphas joined
stpeterhas joined
beanhas left
neshtaxmpphas left
Tobiashas left
Tobihas left
neshtaxmpphas joined
pablohas left
Tobihas joined
Tobiashas joined
Tobiashas left
Tobiashas joined
Sevehas left
djorzhas left
paulhas joined
praveenhas left
airjumphas joined
rubihas left
rubihas joined
airjumphas left
bhavyhas left
Tobiashas left
djorzhas joined
Tobiashas joined
antranigvhas left
neshtaxmpphas left
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
Tobiashas left
Tobiashas joined
Dele Olajidehas left
Sevehas joined
moparisthebest
XMPP is already by far the best choice from a technical POV
Zash
moparisthebest, itym reconstitute us as a lobby organization
massiveboxhas left
neshtaxmpphas joined
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
resolihas left
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
paulhas left
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?
atomicwatchhas joined
atomicwatchhas left
singpolyma
Yum, cookies
Maxencehas left
Maxencehas joined
marc0shas left
marc0shas joined
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 ✏
atomicwatchhas joined
atomicwatchhas left
moparisthebest
XMPP and Matrix already have interop, and it didn't require govt involvement
Tobiashas left
Tobiashas joined
antranigvhas joined
antranigvhas left
marc0shas left
marc0shas joined
massiveboxhas joined
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.
marc0shas left
marc0shas joined
atomicwatchhas joined
atomicwatchhas left
atomicwatchhas joined
atomicwatchhas left
Tobiashas left
marc0shas left
marc0shas joined
Andrzejhas joined
Tobiashas joined
PeterWhas joined
Tobiashas left
Tobiashas joined
Menelhas left
antranigvhas joined
atomicwatchhas joined
atomicwatchhas left
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.
atomicwatchhas joined
atomicwatchhas left
Andrzejhas left
atomicwatchhas joined
marc0shas left
marc0shas joined
Wojtekhas left
paulhas joined
antranigvhas left
Wojtekhas joined
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.
PeterWhas left
Menelhas joined
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.
marc0shas left
marc0shas joined
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 🙈
stphas joined
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
antranigvhas joined
Vaulorhas left
Vaulorhas joined
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?
beanhas joined
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.
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.
asterixhas joined
eevvoorhas joined
atomicwatchhas joined
atomicwatchhas left
raucaohas left
raucaohas joined
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.
stphas left
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
atomicwatchhas joined
atomicwatchhas left
ralphm
Guus: we've already and we will
atomicwatchhas joined
atomicwatchhas left
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.
papatutuwawahas joined
atomicwatchhas joined
atomicwatchhas left
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.
davidhas joined
davidhas left
florettahas left
atomicwatchhas joined
atomicwatchhas left
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.
paulhas joined
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
resolihas joined
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
stphas joined
Wojtekhas left
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)
marc0shas left
marc0shas joined
florettahas joined
PeterWhas joined
atomicwatchhas joined
atomicwatchhas left
projjalmhas left
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
djorzhas left
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
Andrzejhas joined
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.
archas left
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.
restive_monkhas left
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
djorzhas joined
BASSGODhas left
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
marc0shas left
marc0shas joined
MattJ
Do not have a protocol drafted by an outside consultant... 🙂
djorzhas left
PeterWhas left
antranigvhas left
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.
resolihas left
Guus
but, I'm not hung up on any one of these examples.
Daniel
Wait I'm supposed to review the xeps?
restive_monkhas joined
Guus
there's just a lot more that we can do with money than reimburse travel expenses.
Andrzejhas left
Guuslooks 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
beanhas left
beanhas joined
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 :)
projjalmhas joined
resolihas joined
MattJ
Yes, someone we have an ongoing relationship with would be okay
atomicwatchhas joined
atomicwatchhas left
Maranda[x]has left
miruxhas left
miruxhas joined
rubihas left
rubihas joined
Ingolfhas left
Ingolfhas joined
rubihas left
resolihas left
Andrzejhas joined
archas joined
Andrzejhas left
chipmnkhas left
davidhas joined
davidhas left
atomicwatchhas joined
atomicwatchhas left
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
resolihas joined
atomicwatchhas joined
atomicwatchhas left
pep.
"MattJ> Basically "MattJ killed MIX" was the summary of what went into the summit notepad" wow, that's harsh.
Wojtekhas joined
pep.
Not like there isn't enough XMPP servers out there (I count 6?) Especially when people talk about private/closed stuff..
djorzhas joined
rubihas joined
rubihas left
antranigvhas joined
jcbrandhas left
resolihas left
rubihas joined
atomicwatchhas joined
atomicwatchhas left
paulhas left
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
stpeterhas left
Ingolfhas left
Trunghas joined
atomicwatchhas joined
atomicwatchhas left
PeterWhas joined
projjalmhas left
twisted firestarterhas joined
PeterWhas left
Trunghas left
Ingolfhas joined
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 🙂
wladmishas left
wladmishas joined
Zash
So. Many. Layers. Of quoting.
pep.
Zash, wait until you see replies in Dino and Movim
bunghas left
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
neoxhas left
atomicwatchhas joined
atomicwatchhas left
twisted firestarterhas left
miruxhas left
miruxhas joined
Maxencehas left
Maxencehas joined
twisted firestarterhas joined
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?
atomicwatchhas joined
atomicwatchhas left
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)
beanhas left
jgarthas joined
Sevehas left
paulhas joined
chipmnkhas joined
Vaulorhas left
Vaulorhas joined
Sevehas joined
Trunghas joined
marmarperhas joined
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.
MSavoritias (fae,ve)has left
Daniel
What's 'the usual time' for that again?
marmarperhas left
jcbrandhas joined
atomicwatchhas joined
atomicwatchhas left
papatutuwawahas left
Wojtekhas left
Maxencehas left
Maxencehas joined
stphas left
snowhas joined
chipmnkhas left
ralphm
5 Jan was 17:00 UTC
chipmnkhas joined
Mario Sabatinohas left
Menelhas left
Daniel
OK cool. Just making sure it doesn't conflict with council
Wojtekhas joined
Sevehas left
davidhas joined
davidhas left
Sevehas joined
paulhas left
stpeterhas joined
atomicwatchhas joined
atomicwatchhas left
Menelhas joined
marmarperhas joined
resolihas joined
Maranda[x]has joined
paulhas joined
Vaulorhas left
Titihas left
Vaulorhas joined
paulhas left
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