XSF Discussion - 2018-03-20

So Facebook is in the middle of a huge data protection scandal. Can we widely deploy XMPP now?

no

Ah, still no web client.

Yeah well, let's wait for the next scandal then

let's wait for the Facebook Uber merger, then everything will be fine

Uber has chat already, and you can view your driver's profile

Not so far from FB

uber did just directly kill their first person yesterday so

Ge0rG, > Ah, still no web client. Your information is outdated )

As for Uber killing person, from what I got about this incident, person got himself killed with Uber

Andrew Nenakhov: tell me about an as-easy-as-slack xmpp client!

I expected that.

Ge0rG, Xabber, of course

Andrew Nenakhov: does it already have Carbons by default?

Can I self-host Xabber-Web? Is there Xabber-iOS?

Ge0rG, of course it does, for more than a year. Of course you can host it.

iOS version is coming. Currently it's still ugly (not Mohal or ChatSecure-level ugly, though) but it does work more or less ok.

We plan to release it in late April if all goes well

Andrew Nenakhov: that's great news! Will Xabber-Web work without xabber-websocket?

Nope. But there is no workaround and if it's self hosted you can still run it on your own server

It can in theory work with Bosh but result is shitty. Way too slow.

Andrew Nenakhov: why doesn't it use regular websockets though?

I thought xabber-websocket is just a tcp websocket proxy

For servers that don't have websockets

Can I use wss://web.xabber.com/websocket to port-scan remote servers? :D

Can't work without proxy for off-site domains

Ge0rG, actually you can )

Andrew Nenakhov: my next question would be "can I portscan redsolution DMZ", but it looks like a VPS / colo server :>

> Group chats are not implemented yet. No xabber-web for me :(

Xep-0045 is broken by design and we don't even want to waste time on it, sorry

Andrew Nenakhov: there should be a prominent [+] button in the web UI

There is ) or you want it even more prominent?

Andrew Nenakhov: 0045 is fixable. Have you looked at MIX already?

And I should be able to just start a chat with somebody by typing their JID into the "Search chats" / "Search contacts" box

Andrew Nenakhov: the (+) button will add a contact or an account (the latter should be part of the preferences)

Andrew Nenakhov: I'd like to talk to a JID without adding them first.

Andrew Nenakhov: or maybe have an (+) when I stopped typing a JID

No way, spammer!

like Chrome's universal input box, you enter a string and the client figures out what you want

Andrew Nenakhov: I hope you are kidding

No subscription no talk. 😈

Andrew Nenakhov: I hope you are kidding

xabber-web will show and notify me of messages from foreigners, so why shouldn't it allow to start chats?

There are reasons. Mainly because Xabber web is heavily archive centric

Andrew Nenakhov: but it's got a nice clean UI and a good registration flow

Andrew Nenakhov: and your MAM defaults to roster-only?

And we can't gather messages from strangers with current mam

Why not? You can just MAM everything?

We can, but how exactly do we extract data from it after browser reload?

Andrew Nenakhov: good point. You could query everything from last 1hr / 24hr / 14d...

Too data expensive. We're working on server protocol to solve this problem.

Andrew Nenakhov: something like "list of recent chat JIDs"?

Of course. We call it list of recent conversations.

Andrew Nenakhov: I'd love to see the XEP for that

It will be, if it'll work well.

Fwiw other people are working on the same thing

Ge0rG, MIX will never be in ejabberd so no reason to even look at that ) and no, 0045 is not fixable. If you want push notifications on mobile client , you need ad hoc rubber band aids, if you want to talk seamlessly from different clients you need aids like bookmarks. Better do a new proper group chat.

Under the name 'inbox'

Andrew Nenakhov: I disagree. I'm fixing the little warts of 0045, one after the other.

Fix them all and put the enhancements in and eventually you'll have 369.

It's beyond help in our opinion. :-/

Kev: the enhancements that are only needed by a vocal special-case minority, and that complicate the protocol tremendously?

I mean mostly just putting pubsub nodes for extra data.

Kev: IMVHO, we can rescue MIX by axing at least half of the XEP.

I'm potentially up for that.

Chop chop

people are making fun of us for that XEP.

Doing so (if the right half is axed) then I'm potentially up for implementing it in Prosody again

I think very possibly the user server stuff goes away, for one thing. Waiting for thoughts from Dave and Matt on that.

MattJ: the hard part will be getting consent on which the right parts are.

Kev: that's not the part I wanted axed.

Which part do you want axed?

I'd even argue that we can have userserver-side MUC persistence today, based on bookmarks and with zero protocol updates

🛠️

Kev: proxy JIDs would be the highest prio thing for me to get rid of.

We'll implement good group chat to our liking, make it work on our server and 3 (6?) platforms and call it a day )

Ge0rG, those bookmarks that are already proposed to be replaced? 😂

Kev: I'm still opposed to roster integration of MIXes, but this is a minor one

Andrew Nenakhov: it doesn't matter which bookmarks are used.

Andrew Nenakhov, so interop is not a goal for you?

So muc is being replaced with something with higher running complexity or that's gonna get "axed" right...?

Kev: message retraction can be solved with LMC. Direct invitation needs to get half of the fields stripped, because security. current MAM use is a huge mess

Maranda, theoretically MIX's foundations are simpler than MUC's, I believe

MattJ: in practice, it inherits most of MUCs problems.

Interop is definitely a goal. I'm just not a fan of making theory-based standards. One should be implemented first and work well. Then standard can be based on implementation.

I love the *practically* more MattJ you know me 😘

Kev: I think that's it, from a brief look through the MIX TOC

Zash: IIRC you volunteered to implement a PoC server-side MUC idle client

let's call it "MUC bouncer" ;)

We do software, implement on Android, iOS, web, maybe even desktop, then publish docs.

... Because if we end with something that is O(N^2) on most things again we might as well stay with MUC. 😀

Ge0rG: not quite

We can't do pseudonymous rooms without something like proxy JIDs, though.

Kev: Sam had a nice proposal of burner JIDs, which would be added into the routing mix

Kev: so you register with a burner JID component and use that identity to join MUCs, MIXes etc.

Kev: I'm sure that can be polished into a proper protocol with some amount of work, and it would remove the proxy JID stuff from MIX

proxy JIDs are a pseudonymity emulation only anyway.

Ejabberd developer said they won't implement MIX

I maintain that it's a Really Bad Idea to bake anonymous proxies in like that.

Kev: to bake them into what exactly?

XMPP

No support in ejabberd == XEP dead on arrival

Kev: as opposed to special-case anon proxies in MIX?

Yes.

Kev: I know well what happens if we provide anon proxies to the masses (see IBR bot spam), but what would be wrong with having a burner proxy attached as a component on a MIX service, with no external s2s?

One could argue that such a proxy could enforce a given "burner" JID for a given source JID, so the mapping would be a constant 1:1

And the compexity ends up much greater like that than it is with MIX proxy JIDs.

Kev: except that the complexity will be spread onto multiple components that can be debugged individually

I don't think that's true, you end up needing to break the abstractions, I think.

Kev: I'd like to see proof of that.

Of all the bits of MUC that are hard to work with, I'm not convinced that there being proxy JIDs are them.

Kev: I haven't even started addressing the hard bits from MUC yet. I'm only speaking of the new exciting MIX features

Andrew Nenakhov: I think you are misinformed

Andrew Nenakhov: there's been ongoing work for ejabberd on MIX for almost two years now

ralphm, Evgeniy Khramtsov told me himself

I'll ask him again, ok

https://docs.ejabberd.im/tutorials/mix-010/

ralphm: Yes this was during the early stages of MIX development.

I think Andrew is right that zinid isn't motivated to implement the current revision (nor am I).

That's regrettable.

Not at all, for a specification you need approximately a business day just to read and to make sense of.

Holger: is that because of complexity, or because there's no (current) business justification for working on it?

Ge0rG: fwiw, XEP-0060 is a lot bigger

ralphm: luckily, nobody ever implemented all of 0060.

This is false

"no single party"?

0060 is a specifc XEP, each time you look at it you find new features and things to implement

MIX makes use of 0060, so you need that in addition to MIX.

And then there is the publish-options security nightmare we had recently.

A quick word count shows that xep60 is 1.7x the size of MIX, FWIW

and both are not XEPs I would mention as good examples

They are good examples for design by committee.

which committee?

Committee of people who wouldn't implement it in software

flow: I assume this is a rhetorical question

that's ridiculous, most of XEP-0060 was defined by just the three people on the author list

Ge0rG, not everyone knows this ideom

and for MIX, the people that wrote it are also implementing it

ralphm, I doubt that

uhh, implement*ing*

it would be nice to have a propre IRL discussion about just Pubsub

I read implemented

have a state of the art, see what we understand, maybe with a hackaton to fix the things that we're talking about

https://wiki.xmpp.org/web/PubSubIssues

ralphm: I can't really speak for zinid, but for him it might be a bit of both. As MIX development stalled they came up with their MUC/Sub thing as a temporary solution, and now that mostly does the trick for their customers.

I'm sure there are issues, but the statement that it was design-by-committee and by non-implementors is just false.

ralphm: I wasn't involved with implementing the earlier draft, but according to zinid it was much easier to actually re-use PubSub code back then.

are there problems with muc-sub ? like a reason it isn't a good replacement for MUC/MIX?

As far as I'm concerned it's just the sheer complexity which is demotivating.

At it's core MIX isn't that complex

It's just everything stuffed into the XEP, just like PubSub, that makes one wanna run awawy

And it becomes hard and harder to distill the gist out of as longer as it stays that way. IIRC ppl attempted a few years back to modularize xep60/PubSub and that never got anywhere

flow: that was just editorial, not actually changing anything in the protocol

ralphm, I know

but even that would improve the situation

I'm ok to have a couple of days and do that with a bunch of persons

flow: I still have the stacks intosi and I made a few summits ago

0060 is the core of many many things that we are doing at the moment, from MIX, to PEP related XEP, MAM is linked to it

IIRC Zash was running with scissors too

I helped

Yes.

As did Chris, by finding printers with enough reams of paper.

The threshold for resuming that seems high :/

is it possible to just rewrite it ?

starting from the bases and slowly adding back all the features that we had

it's what I'm doing when I have to refactor code and it's a mess

Maybe a good starting point would be to tag every xep60 section as mandatory-to-implement or optional in a wiki page and start from there

edhelas: rewriting xep60 appears to be to drastic, inefficient and error prone, but maybe that's not what you had in mind?

well not really

I was saying to basically re-understand the substance of all the sections, maybe put that on a wiki, and rewrite properly those things once we figured out the whole schema

hey! I was checking MIX and I'm still checking it (there are still several typos) but I wanted to change the section 6.3, Ensuring Message Delivery to use "ping" (XEP-0199) instead of the "marker" tag (that's confusing me with markable from Chat Markers (XEP-0333), how can I propose it?

but it would be more efficient to do that IRL, during a meetup, like a full day, 3 personnes with already some Pubsub background and a set of rules

manuel-rubio, send a PR, but what's the motivation behind that change?

edhelas: I think the split is already more or less clear, I'll see if I can pick that up again

But I'm not sure if that is a blocker for building MIX

ralphm, Is the split documented somehere?

as I said, I have the stacks of paper here

would be great if it where on some wiki page or such, so that more people could participate

and contribute

ralphm: my design-by-committee impression of MIX results from each involved party stuffing their favorite feature into the specification, and us ending up with a huge and complex piece of meta-protocol.

from the top of my head it is roughly: basic stuff, managent/admin stuff, advanced use cases (publish options, content-based subs)

ralphm, I don't know all the details, but wouldn't you agree it's pretty obvious MIX is too terrible to implement considering it's years old and has 0 implementations?

the developers have spoken, you could say

I don't know if there's a correlation, no

it's really the only point that matters

ralphm I'd be happy to have a session with you to work on that :D

I mean you can figure out *why* no one is interested in implementing it and fix those things, or you can continue to say "it's not that bad" and convince no one

maybe we can organise a Dutch Summit "Let's Make Pubsub Great Again"

MPSGA doesn't quite roll off the tongue :P

let's do some caps and tshirts for the next FOSDEM :p

I'd rather support slogan "Let's Make XMPP Great Again". Just kidding, XMPP was never great. So real slogan should be "Let's Make XMPP Great For Once"

Except that there are implementations of MIX, BTW.

Kev: link?

Dave's got some, at least.

If a tree falls in a forest, ...

for Openfire

The only thing I see from searching is someone else asking for a link on a Jira issue last year sometime (either September or November, no idea what this date format is) with no response.

Kev, iirc dave half implemented a super early version of MIX in openfire

not sure I'd count that

So no real implementations of MIX?

What happened with ejabberd's implementation? Someone earlier said they weren't going to implement it, but they did have one for a while IIRC?

If they gave up, that doesn't bode well for the people who keep saying it's not as complicated as it sounds.

A bunch of people (including us [Prosody]) implemented the early stuff

SamWhited, I think there never was code I would descripe as MIX implementation in ejabberd

SamWhited: zinid (Evgeniy) said multiple times that there will be no MIX in ejabberd

Possibly even before the XEP was submitted

flow: Well it was an earlier revision.

https://docs.ejabberd.im/tutorials/mix-010/ ?

What happened to that?

It's still around.

Holger: is it being developed, or was it abandoned?

https://github.com/processone/ejabberd/blob/master/src/mod_mix.erl

Holger, was it tested against an client?

The XEP just grew too big too fast, and with the current XEP I have no intention of implementing

SamWhited: It's not being developed. The XEP then went into a different direction.

flow: Is there a MIX client?

But this conversation began from the suggestion that the situation may be improved

Thanks

That seems to be part of the problem. That mix is a moving target and people who initially implement something that was then changed completely are now afraid that the standard might change again

So that's multiple major servers that have old half implemented versions or say they have no intention of implementing. Sounds like we need a rethink.

Holger, I'm not aware of one. I think the GSOC project last year tried to produce one but failed

At least that's in part what stops me from implementing it

daniel, +1

daniel: I'm more afraid the standard won't change again :-)

😂

it seems not too bad to me atm

I don’t like the weird roster integration

> daniel: I'm more afraid the standard won't change again :-) 🤣

jonasw: I think the XMPP2 rules may well do away with that.

Kev, how that?

Kev: so you want to bet XMPP2 on MIX?

Ge0rG: The opposite, I think.

Use the XMPP2 routing rules in MIX.

it's also not just server devs, no client dev seems interested in it either

currently it's a non-starter

s/currently/past few years/

Kev: so you are not talking of the weird roster integration?

I'm interested in it in all our clietns and our server, just haven't got to it yet.

Ge0rG: I think the roster integration can probably go away once routing rules change.

I'm interested in fixing MUC

Kev: please enighten me on how those interdepend

moparisthebest, I *am* interested, but I don’t implement things without something to test against.

> That seems to be part of the problem. That mix is a moving target and people who initially implement something that was then changed completely are now afraid that the standard might change again Or more likely that now it's ending being twice as cumbersome as muc is.

Sounds more likely

MUC is too simple though.

see the mess Multi-Session Nicks is

Maranda: and it also adds a bunch of legacy MUC issues

that ain’t going to be fixed by putting some ducttape on MUC

again are there problems with muc-sub ?

jonasw: ITYM "underspecified"

fully backwards compatible seems a huge giant plus

moparisthebest, what’s muc-sub?

Maranda: well when I say _part of the problem_ I mean in fact _part_

jonasw, something actually implemented https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/

moparisthebest, is there a XEP?

jonasw, something you can test against an implementation: https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/

that is a xep, kinda? :)

jonasw: Basically 0045 plus PubSub notifications for offline members.

daniel by the way, what are your plans regarding Bookmark support in Conversations, you want to move to a PEP storage ?

moparisthebest, xeps are on xmpp.org/extensions/xep-%04d.xml ;-)

jonasw, there is also muc-light

jonasw, some are in inbox, some haven't made it there yet

XSF kind of made clear 'MIX is the way, we don't care about what any actual developer thinks'

which is why I assume it wasn't submitted

where did the XSF make that clear?

moparisthebest: XSF mainly consists of developers.

a few years ago, when the demand for persistent groupchat rose, many MUC replacements appeared, unfortunately we only have one as experimental XEP

I was all for sticking with one way forward when mix was a bit smaller, but now it's gotten rather large, maybe muc-sub is worth a look again. It's been a while since I read it.

I am pretty sure that if something which was much more trivial than MIX but fixes the issues of MUC was presented, it would gain massive adoption immediately.

well there are developers that just write specs, then there are developers that write code

jonasw: Do you think it would be good to submit MUC/Sub? Wasn't MUC-Lite already rejected because we have MIX?

Holger, I have no idea

I also don’t know the history there

Oh, maybe I was thinking of MUC-Lite, I didn't realize these were two different things.

also XSF has developer firmly entrenched in corporate proprietary servers that have odd use cases not suitable for everyone else

which isn't a problem in itself

but look at the XEPs around when MIX came in, a good number of them are virtually universally implemented at this point

edhelas, movim to PEP storage probably won't happen as long as access-model is not implemented/usable everywhere (from where I understand)

that MIX has 0 implementations is telling

pep. okay

I mean on servers

SamWhited: I think we can sufficiently fix MUC with minor tweaks to the protocols and an optional "MUC bouncer" on the users' servers

moparisthebest, I doubt it expecially when you have over half the server developers (me included) that do not intend implementing it in its current state, just saying.

Ge0rG, how to fix the multi-session nick mess?

Ge0rG: I have a hard time beleiving that, but I'd love to see a plan outlined if you think it can be done.

jonasw: it's not much of a mess

PMs?

jonasw: mainly a mess in some implementations

Ge0rG, tell that to people trying to feature-discover through MSN.

just because poezio doesn't get them right doesn't mean it can't be done with minimal effort

You *can* fix MUC, certainly, but it needs doing basically what MIX does, even if the way we currently describe MIX doesn't make it sound straightforward the core is.

jonasw: feature discovery for messages is overrated

edhelas, I'm not talking for daniel, but that's what I gathered

Ge0rG, we have many hacks and quirks in aioxmpp and jabbercat code which is solely due to the weirdness of MUCs handling of resources

It doesn't matter how straight forward the core is if no one else but a handful of people understand it. I'm not convince that statement is true, but if it is then someone who understands it needs to make it clear how simple it is.

I think somehow I (partially) demessed that jonasw, Ge0rG at least appreciated the effort 😘

Ge0rG, I like how MIX uses bare JIDs for identities and resources for sessions, unlike MUC. it simplifies a lot if we can just assume that.

jonasw: indeed

SamWhited: Yes, this is true, and yes, we need to make it clear.

jonasw: but that's a hard break from how MUC works

ralphm, exactly

which I think that you cannot simply fix MUC.

jonasw: I'm using bare JIDs everywhere in my client except for MUC-PMs and it was straight forward to implement

Ge0rG, you don’t have avatars in MUC, do you?

jonasw: that's why I think MUC is not fixable without breaking compatibility

jonasw, no one said MIX didn't have good ideas, just that together it's not good

moparisthebest, I’m aware.

jonasw> Ge0rG, I like how MIX uses bare JIDs for identities and resources for sessions, unlike MUC. it simplifies a lot if we can just assume that.

jonasw: I don't have avatars. But I heard daniel fixed them recently?

+1

again are there specific problems with https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/ other than 'well it's not MIX' ?

moparisthebest, isn't no answer an answer?

Ge0rG, "fixed"?

moparisthebest, my specific problem with that is that it’s not a XEP

jonasw, how is that a problem

but actually, I think there are 1-2 minor problems with MUC-sub

jonasw: I haven't been watching avatars closely, sorry. Maybe I'm underestimating part of the problem space

it's running code, that is documented, and can easily be submitted as a xep jonasw

moparisthebest, I like to discourage large-scale deployment of things which aren’t XEPs.

but nothing that would prevent me from seeing MUC-Sub as XEP

moparisthebest, do it then! ;-)

If there are only 1-2 minor problems, that's pretty good, I really do need to read that again.

Catching up, but: a) I didn't implement MIX, Ash Ward did (mostly), and we concentrated on the async messaging cases we needed. But it *is* in use. Various things in later revisions diverged from what we did, however.

moparisthebest: I didn't know of this specification until 30 min. ago, how can I have evaluated it against MIX? Was it submitted as an alternative to the Council?

Ge0rG, everywhere but in MUC you can (and have to) associate avatars with bare JIDs. in MUCs, you have to use the full JIDs.

jonasw: yes, as I said. You use bare JIDs everywhere but in MUCs.

moparisthebest, it still doesn’t solve the full-jids-as-identities-issue which is my biggest beef with MUC tbh

b) I argued against "MUC-light" because it was neither MUC, nor particularly light.

ralphm, iirc back then council made it clear they would consider nothing but MIX, who would have wasted their time submitting it?

Ge0rG, earlier you said "MUC-PMs" ;-)

jonasw: so you have an API get_foo_for_jid() and you can pass it a bare JID or a full JID of a MUC participant.

c) Without seeing MUC-Sub, I don't know how it would differ materially from MIX.

jonasw: I probably meant "MUC participants"

Ge0rG, depends. with avatar pushes in presence, the stuff handling the caches needs to be aware whether a JID is from a MUC or not. and this is where things get ugly.

I also just learned about muc-sub within the last few weeks from someone in here

jonasw, FWIW, MIX uses bare jids too. But then doesn't use them for messages, which I never liked.

jonasw: must inject more <x/>

it just strikes me as 'good enough'

Ge0rG, the <x/> is in there, but that’s breaking layers.

moparisthebest: that's fine, but you are asking about an alternative that (almost) nobody has seen and why that is not better than MIX. I don't think it is reasonable to expect an answer during this discussion.

Dave Cridland, did you see the link https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/

Dave Cridland: I think MIX only used full JIDs for messages in the context of PMs and resource locking?

sure ralphm , just pointing out there are alternatives that supposedly have running code

and a (not-yet-submitted) spec

Reviewing them, muc-light is the one I've seen before and I didn't like it for similar reasons to Dave (also, at the time MIX still seemed like a viable way forward so it felt worth focusing on that and encouraging others to participate in that effort). MUC-sub I'll have to read because I don't think I have read this one and was just mixing (pardon the pun) it up with MUC-light.

moparisthebest: but you don't have first hand experience with this muc-sub then?

other than hearing about it in passing in here, and reading it, no

I'm not sure I entirely get the *real* necessity of offline message deliveries if there's MAM as well.

Maranda: indeed, the whole point of putting MAM behind all the things is that you don't have that anymore

So, what are the specific issues with MIX that people trying to implemented are facing. So far I've heard 1) the complexity of the specification (as a piece of text, not necessarily the actual protocol), 2) the fact that there've been (big) changes.

Did MIX really change that much since Feb 2017?

Only in minor details

ralphm: No. There was a lot of editorial stuff, but nothing really changed

Right, so it is not really a moving target then

Well at least it's reliable, offline delivers somehow not so much imho but that's debatable I guess.

when I'm reading MIX, I have the feeling that we'll have a Pubsub syndrom in it

I mean

6.1.15 Telling another User about a Channel

this whole piece can be a separate XEP

edhelas: that's a rather small piece.

yup, but still

Maranda: can you point out specific cases of O(too much)?

edhelas: huh? 6.1.15 is not using PubSub at all and points to a separate XEP?

I think that using MAM both on the MIX and on the private account is a huge mess in the protocol

"6.5.4 Converting a 1:1 Conversation to a Channel" is a huge security nightmare with questionable benefit

What's the mess protocol-wise?

(With 313)

ralphm, (1) there’s on complete-ish server implementation I could test against (I’m a client developer. I also have limited time, otherwise I’d make one myself). (2) s2s failures (last time I checked) feld underappreciated in the spec, leading to possible desync between the MIX service and the users archive. skipping the archiving step at the users server would eliminate that risk and also simplify things. (3) The roster integration feels extremely weird. I’d prefer a different mechanism (specialized virtual PEP node for example).

Kev: the fact that you have to query the data from different entities, depending on some (internal?) state

Ge0rG: in terms of storage, for large rooms, having to MAM store room content 'user-side' seems pretty terrible.

(ralphm, I think edhelas meant "PubSub syndrome" as in "one huge spec nobody can implement completely")

Ge0rG: That goes away with MIX and XMPP2, though.

For messages you just query your own.

ralphm: so the solution is to store it in user's MAM as well as the MIX' MAM?

no muc compatibility and requiring support on the user's server also seem to be non-starters

jonasw exactly :)

as a developper, is simpler to follow small specification, then you can mark that "done"

so I implemented MIX-Core, now let's move to the MIX-Invitation XEP

Can't disagree with that, 369 as a spec is too long.

Ge0rG: It seems perfectly normal to me to store one-to-one chats in the respective MAM archives of the two participants, and group chat history in a room-bound MAM archive, yes.

moparisthebest: there are ways to provide an XEP-0045 layer on top of a MIX backend, of course with limited functionality.

ralphm: yes, except that's not how MIX is defined.

ralphm: > MIX messages are archived by both the MIX channel and the user's server, so that clients can generally use their local MAM archiver.

> All MIX messages received by the MIX participant's server for a participant MUST be stored using MAM in the participant's archive.

And then we have the issue of the user-proxy and the MIX getting desynced due to s2s issues

Which we know never happens in MUCs

Ge0rG: on MAM archives, I didn't remember those parts, and that's surely a choice that could be debated. I'm not sure why that choice was made. Maybe Steve Kille can comment on that

Maranda: regarding runtime complexity: the user server is essentially an always-on proxy for all MIXes a user enters, for enternity. So if a user abandons their account, the server will still be receiving all their MIX traffic

what? why?

Ge0rG, I might fail to get the point glancing the current XEP but if the problem of muc is basically broadcasts I don't entirely see where MIX is solving it, splitting it..? 🤨 Well.

Maranda: sorry, what context are you in right now?

The same running complexity

Maranda: I think we agree that MIX is not less complex than MUC in that regard?

I should be single-tasking my work now.

> <Maranda> I'm not sure I entirely get the *real* necessity of offline message deliveries if there's MAM as well. The most important reason in practce is push notifications. My impression was that MUC being presence-based was the main driving force to come up with a replacement.

Ge0rG: I don't get the 'for eternity' part. You mean that if a user never logs into his account anymore, the server would still get the room's notifications? This also goes for regular pubsub, and I don't see how that's a failure of MIX per se. I'm sure that server implementation need some kind of resource management in such cases anyway.

That and the broken proxyJIDding.

ralphm: yes, except that typical pubsub has different traffic patterns compared to a large chatroom

Holger: that problem can be solved by implementing a "MUC bouncer" on the user's server.

Ge0rG: a mix bouncer is exactly what the PAM dependency in MIX does

(unless that was your point, in which case never mind)

ralphm: I know. But for MIX, you need to implement it on the client, on the server and on the MIX service. A "MUC bouncer" can be quietly implemented as part of the server without touching any protocol.

Ge0rG: interesting, that would have the same impact on abandoned user accounts, though

ralphm: indeed.

I think PAM becomes an optional dependency now, though, for MIX.

a MUC bouncer is basically what IRC does, for MIX it is part of the package and considered a feature. Is your point that this MIX too complex?

Kev: ah, can you expand on that?

And yes, we can make it transparent.

ralphm: my point is that we don't need MIX as a solution to _that_ problem.

ralphm: If we change routing rules as $SUMMIT, we get bare-JID routing for MIXs, and we don't need the repeater in the user's server.

ralphm: the MAM choice you referenced me on makes sense to me. Kev is probably the best person to explain

Kev: but it would still require server's to implement /that/, so how transparent is that? On the whole, of course, I think it is a good idea.

Which 'that'?

The XMPP 2 routing rules? Yes, I think we need those, but we need those anyway.

Kev: I'm pretty sure we'll run into interesting issues when attempting to route 'groupchat' messages to bare JIDs

Kev: well, Ge0rG said that for doing MIX with PAM, you need the client, its server, and the MIX server to implement that. For the routing thing, you need both servers to be support that, no?

Ge0rG: why? a server that doesn't support this responds with service-unavailable?

(RFC 6121, section 8.5.2.1.1)

ralphm: I can imagine this not to be the desired outcome for a MIX participant.

Ge0rG: so that's why Kev said that indeed the server of the MIX participant needs to support the new routing

ralphm: "the new routing" never was about type=groupchat, so Kev must be meaning some newer-than-new routing that I know nothing about.

So I'm not yet convinced that XMPP2 routing rules solve the MIX routing problem.

Ge0rG: You might not have intended it to cover gc, but I do.

Ge0rG: FWIW, what I already did was to write a thing that made the account join MUCs instead, while pretending to clients that nothing changed.

Kev: that's a noble goal. Do you have any documentation on the _how_?

Zash: that's exactly what I was talking about. A MUC bouncer of sors

sorts

Right

Zash: how does "the account join MUC" work specifically? Are you using a fake client resource for that?

Zash: did you encounter any unexpected things? Maybe we should promote that as a server feature?

Ge0rG: I think I encountered weirdness but I don't remember exactly

Zash: I'm interested in repeating that experiment

And while we are speaking of experiments...

Maranda: do you happen to have new numbers on the GC1 usage?

Hm not really.

Maranda: what about a formal statement about the last numbers you gathered, e.g. on standards@? I'd like to use that as evidence that we can get rid of GC1 now.

Ge0rG, if I had any last numbers gathered I would give out those, but beside the scarce muc usage on my server, looking at the clients using my server, I can sort of safely assume that as long as Pidgin doesn't still use it (I have no idea) there's no client using GC1.0

Ah, I wish I had a prosody module logging that.

One that isn't mod_muc itself and that works with 0.10?

Zash: 0.10 mod_muc would be alright with me.

Ge0rG, if the archives were solely at the MIX service, the users server wouldn’t need to receive or process them, right?

lolwat

wtf poezio

jonasw: yes

jonasw: except the server would need to tell the MIX when to start and stop sending "live" traffic

Ge0rG, BIND2 between server and MIX!

Ge0rG, just making a fast census, the majority looks to be running Pidgin, the Mac users look to be running Adium few are using iMessage/iChat, some others Trillian, Telepathy... oh one is running Bruno :P

and most used mobile looks to be Xabber, Conversations on second.

Nobody is using yaxim 😢

Ge0rG, nope one is using Bruno though :P

Maranda: yeah, glad to hear that.

which isn't responding to an IQ btw 🤔

Maranda: what kind of IQ?

version

Hm. Must be a very old version then. Or maybe the one with the bug where it dropped IQs because DoS

But still very old

So. Yes, I did see muc-sub ages ago, and it's basically a hybrid of MIX and MUC.

And I do really hate wrapping messages in pubsub events and sending those as messages. Feels desperately inefficient.

if we’re substantially changing MUC, it’d be great to revamp how JIDs work in MUCs, and that’s essentially the proxy JID concept of MIX. which everyone seems to hate.

anyone know of a bot that integrates muc with jira ?

s/jira/git

Ge0rG, you know the answer ;-)

well, kinda jira for tickets and such

jonasw: yes, two bots. one to integrate git with pubsub and another one to integrate pubsub with muc

dvcs over pubsub!

Ge0rG, be happy: [18:25:32] ‎Echo1‎: There was an error requesting ***@lightwitch.org/Bruno.554C7F0C's version: recipient-unavailable

just dead session :P

phew.

Zash: so what about GC1 logging in mod_muc?

Ge0rG: I started on a module ... twice

Ge0rG, just hack it into muc.lib.lua. it’ll probably one line.

jonasw: Is there any reasoning behind the proxy JID concept besides hiding the real JID?

Hmm eww

why? mod_muc hooks at -1 anyways

Holger, from which jid would one be receiving messages within the MIX otherwise?

(and possibly presence)

just make a 4 lines module and you're set

(or less)

Maranda: please make a 4 lines module

jonasw: it's one line, but the challenge is in knowing where to put that line

oh, there is one

,oO( https://colterreed.com/the-parable-of-the-two-dollar-chalk-mark/ )

https://q.zash.se/94296e585f69.txt

Ge0rG: ^

Ge0rG, hook to presence/bare?

I guess you can s/module:/origin./

Zash: can have print of the resource string, and version-iq the client?

module:log("info", "GC 1.0 join: {muc} {full-client-JID} {client version}") please :)

jonasw: Dunno, maybe the MIX service JID. But why do you need any sort of JID mapping if not for anonymization?

Ge0rG: You can do it, I believe in you

Zash: I don't know where to put the chalk mark.

copy stuff from https://modules.prosody.im/mod_query_client_ver.html

1. Copy random stuff from different modules 2. Deploy in production 3. ??? 4. Crashit

jonasw: The XEP text also makes it very obvious that this is the point, no? Plus all the JID visibility foo?

Holger: I think the main reason for having proxy JIDs was indeed to make pseudonymous usage possible

But when viewed from a message routing point of view, we probably need proxy JIDs to associate incoming messages to a MIX in some way.

Or we need to wrap messages, like <message from=MIX><forwarded><message from=participant///>

Well the service could obviously just include some tag with the real JID no?

Like 0045 for non-anon rooms ...

Holger: what would be the from-JID?

As I said my spontaneous response would be the groupchat service. But it's not like I thought about this. I just asked why we need a JID mapping.

Right

5) Adopt Proposal "Bookmarks 2 (This Time it's Serious)"

it's planning to stay titled like that :D ?

I think we should put Dave in charge of naming all the things

Zash: that position deserves a better name

Ge0rG, clearly Dave should name the position

moparisthebest: I think that naming your own position is a Segregation of Duties violation

Ge0rG: https://q.zash.se/9b36a85d05a9.txt (also some fixes highlighted by static checks)

Not actually tested

No warranty etc

regarding Bookmark 2 do you think it's fine to put muc JID in the nodeid of the Pubsub item ?

that is linked with the discussion we had about the format and limitation of those ids

Zash: awww... I kind of hoped to have the version reply inline. Will loading this on my MUC component allow me to grep version responses for the MUC JID in some way?

Ge0rG: Prosody doesn't have any internal IQ tracking framework, so it gets a bit messier to do like that than what I'm willing to do while being this tired.

Zash: alright, thanks. That's good enough, as I don't have any other kind of version IQ inducer running

Could encode stuff into the resource.. but uh

Zash: nah, better not to.

Zash: it's great as it is now.

Zash: will it always log with <modulename> in the log line?

Ge0rG: All module:log() lines do, yes

Zash: yay. Now all I need to do is to provoke a log manually.

/rawxml <presence to="yaxim@chat.yax.im/Ge0rG" />

nothing happens.

Do I need to load it on the main domain instead of the MUC?

Supposed to be on the MUC

Oh

s|preserce/bare|preserce/full|

heh, I wondered about that too

Hm. Still nothing

Are you joined there already?

Yes.

So it'll go to "normal presence update"

Ah, ok.

Mar 20 19:08:02 chat.yax.im:gc_log info GC 1.0 join from georg@yax.im/poezio

Yay.

Zash: thanks very much. I'll collect datas now.

But no version followup there.

awww...

well

https://muc.metronome.im:5280/pastebin/32c7b657-90e2-4411-9c9c-5903dfe07a00

:P

Ge0rG, Zash, it would be useful to know if the client was joined before and got removed with an error presence.

was joined before using MUC protocol.

Tracking hell

I'm out for today. Let's hope it won't crash yax.im overnight

Thanks everyone

and woops typo but it looks to be working, https://muc.metronome.im:5280/pastebin/d84f1589-1920-4e48-8f47-b09e6fbe0ec4

and woops typo but it looks to be working, https://muc.metronome.im:5280/pastebin/918d0c29-6e42-4c32-8c72-18fd75b860c7

Was that last message correction without last message correction?

Ge0rG, apparently... I corrected using Gajim, but Gajim didn't use Message correction?

toast ✏

Ge0rG, no clue what I did there

Maranda: this time it worked. Did you rejoin in between?

i fixed a muc correction bug yesterday

so .. this can happen from time to time

Ge0rG, hmm no I don't think I did.

lovetox, hmm 1.0?

that's what I'm using

yes it has that bug

basically you have to be really fast with correction

if any message in any other muc arrives it wont work anymore ^^

Is this the week of major client releases? Gajim 1, Conversations 2, ???, Swift 4

so the same as the https://en.wikipedia.org/wiki/Therac-25 bug ?

except way less deadly

lovetox: tell me about race conditions

lovetox, oh, well I'm a turtle *known "bug"* :P

hehe brb.

Ge0rG: does your plan to improve muc also involve a rule that servers should force all connected clients to have the same nick?

Ie either first joined client gets force renamed to the nick the second client uses or vice versa

(somewhat re to what you wrote about bookmarks 2)

Inb4 but muh pidgin can't handle forced renames

daniel: I don't see how pidgin is in a position to block progress of XMPP

daniel: but to answer your question: no, I don't think we need to *force* all clients to the same nickname. But it would make sense to keep that the default

Tell that to the clients not implemting omemo. Lol

daniel: because I'm sure joining the same MUC with two different nicknames at the same time is a use case needed by less than 0.1% of XMPP users

daniel: as opposed to you, I don't see OMEMO as an integral part of the XMPP future

Ge0rG: well it wouldn't be the first time backward compat is raised as an argument not to do something

daniel: with the two of us on Council, we can get rid of GC1, and then of pidgin

Wait council can get rid of pidgin?

Why haven't we done this before?

daniel: I'll propose it as AOB tomorrow

I didn't know we had unilateral power over client devs, we should have been using this for blackmail ages ago.

SamWhited: I was told we can vote on everything.

Ceterum Censeo Pidgin Delendam Esse.

Ge0rG: well an opt out / opt in to server please rename me to what ever you think is right might be a way not to break pidgin

Aehm at least the opt in part

daniel: i think we are having a misunderstanding. I'm speaking of the clients synchronizing the nickname to use, not about server side enforcing.

Apparently killing Pidgin means killing a large portion of XMPP if my server numbers are any exportable 😆

Art thou up for such perillous, murderous task?

What about crowdfunded maintenance?

Ge0rG: I'll summarize that as no such plans then

this is a good argument for omemo/xmpp https://www.theverge.com/2018/3/20/17142482/russia-orders-telegram-hand-over-user-encryption-keys

I can attest that 95% or more of OTR users in Russia are junkies.

Also, Telegram is putting a show for masses, there is substantial evidence that it is already controlled by FSB

wait how do you know they are junkies?

I have access to Xabber support mailbox

oh, fair :)

that just means 95% of OTR users that ask for support are junkies though right?

maybe it works great for non-junkies hehe :)

Our app is defacto standard in their circles, they even write on websites 'sales support in Xabber'

moparisthebest, I think 95% of e2ee users are criminals (junkies and drug/arms/etc sellers), and 5% crypto nerds )

Cryptonerds never ask for tech support though

They figure it out themselves and know why they use xmpp. But junkies... "i entered my Gmail address into Xmpp id field and it doesn't connect!".

Well you have to start somewhere right, first users that see value in the market, and then conquer the world

well also OTR is terrible for usability, OMEMO fixes most of that

my mom uses OMEMO messaging me without problems, she would have just used the default though if I didn't set it up for her

I personally don't see any value in encryption, especially when running my own server. The only one e2ee is protecting from is server operator, and if that's mine... Why bother? Also it makes seamless syncing more difficult across devices and requires transmitting WAY more data

and then are you certain it really is...?

:P

Andrew Nenakhov: servers never get hacked or misconfigured?

I run my own too and haven't made those mistakes yet, but I'm not perfect

Hacking a diligently configured server is not an easy thing to do. And it is not really linked to Telegram situation. Russian government wants direct access to user chat history that it can use without warrant or court decision

In other news. In unexpected turn of events, making an XMPP client for iOS that works well we'll have to implement VoIP 😁

*to make an , typo

Andrew Nenakhov: Yeah. The alternative is sending the body via APNS or generating ugly "New Message!" notifications.

Ugly. Btw telegram sends all msg body in Alert-type msg, perfectly open, over APNS

Ah I was wondering how the commercial things do it.

Currently we use non-voip push notifications of 'content-available' type, and it even kinda works...

But those are unreliable, right?

I.e. heavily rate-limited by Apple.

Yes, but it looks to be tricky. Our developer sees almost perfect work on his test devices, but when we roll out build on test devices to managers, etc in company, it works much worse. As if iOS gives more priority to often used apps

*this theory is not yet confirmed

Also, when you read articles titled 'force-closing apps does not make your iPhone last longer, stop doing that', know it's a lie.

Yes it's my impression as well that the behavior is very different for different users. I didn't come up with a theory yet though, seemed totally non-deterministic to me.

Content-available type notifications ARE NOT delivered to force-closed apps (swiped away ) at all

Right.

And not delivered after device restart until first launch, too.

VoIP pushes, on the contrary, work very reliable.

Force-close, restart - it works all the time.

Yup ...

of course I vaguely recall VoIP apps getting treated differently even for what regards background running sockets.

(and that was ages ago)

Maranda: Yes, that's going away though.

Maranda: VoIP apps are supposed to rely on push notifications now.

APNS rules changed a while ago. In 2014 you could have a decent background updates without VoIP.

We did an xmpp-based app for some guys back then, pushes worked well without additional hassle.

I swear I can't express how much mobile OSes that do these stupid things with app tombstoning and background connections limit impositions annoy me.

(and neither I get how can people spend 1400 eurs for a device that doesn't let you do what you want to with *your friggin battery*)

Maranda, it'll get worse. I think Google will be locking developers into their ecosystem even more, displacing natural device capabilities with proprietary centralized FCM APIs.

*le sigh*

Google's and Apple's tyranny will be much more harsh one of Microsoft.

I know a guy who makes a chat app based entirely on FCM. Just pushes and Google's cloud storage. Supaeasy

somehow this reminds me of the scene from lord of the rings where frodo offers the ring to galadriel...