So Facebook is in the middle of a huge data protection scandal. Can we widely deploy XMPP now?
moparisthebesthas left
flow
no
Ge0rG
Ah, still no web client.
Ge0rG
Yeah well, let's wait for the next scandal then
Tobias
let's wait for the Facebook Uber merger, then everything will be fine
marmistrzhas joined
mrdoctorwho
Uber has chat already, and you can view your driver's profile
mrdoctorwho
Not so far from FB
jubalhhas joined
jubalhhas left
SaltyBoneshas left
SaltyBoneshas left
moparisthebest
uber did just directly kill their first person yesterday so
Dave Cridlandhas left
Andrew Nenakhov
Ge0rG,
> Ah, still no web client.
Your information is outdated )
SaltyBoneshas left
Andrew Nenakhov
As for Uber killing person, from what I got about this incident, person got himself killed with Uber
Ge0rG
Andrew Nenakhov: tell me about an as-easy-as-slack xmpp client!
Andrew Nenakhovhas left
Ge0rG
I expected that.
Dave Cridlandhas left
Andrew Nenakhovhas joined
Andrew Nenakhov
Ge0rG, Xabber, of course
Ge0rG
Andrew Nenakhov: does it already have Carbons by default?
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Ge0rG
Can I self-host Xabber-Web? Is there Xabber-iOS?
Andrew Nenakhov
Ge0rG, of course it does, for more than a year. Of course you can host it.
Andrew Nenakhov
iOS version is coming. Currently it's still ugly (not Mohal or ChatSecure-level ugly, though) but it does work more or less ok.
Andrew Nenakhov
We plan to release it in late April if all goes well
Valerianhas left
Ge0rG
Andrew Nenakhov: that's great news! Will Xabber-Web work without xabber-websocket?
Andrew Nenakhov
Nope. But there is no workaround and if it's self hosted you can still run it on your own server
Andrew Nenakhov
It can in theory work with Bosh but result is shitty. Way too slow.
daniel
Andrew Nenakhov: why doesn't it use regular websockets though?
daniel
I thought xabber-websocket is just a tcp websocket proxy
daniel
For servers that don't have websockets
Ge0rG
Can I use wss://web.xabber.com/websocket to port-scan remote servers? :D
Andrew Nenakhov
Can't work without proxy for off-site domains
Andrew Nenakhov
Ge0rG, actually you can )
rionhas left
Ge0rG
Andrew Nenakhov: my next question would be "can I portscan redsolution DMZ", but it looks like a VPS / colo server :>
Nekithas left
Nekithas joined
LNJhas joined
jjrhhas left
vanitasvitaehas left
Ge0rG
> Group chats are not implemented yet.
No xabber-web for me :(
intosihas left
intosihas joined
Andrew Nenakhov
Xep-0045 is broken by design and we don't even want to waste time on it, sorry
Ge0rG
Andrew Nenakhov: there should be a prominent [+] button in the web UI
Andrew Nenakhov
There is ) or you want it even more prominent?
Ge0rG
Andrew Nenakhov: 0045 is fixable. Have you looked at MIX already?
Ge0rG
And I should be able to just start a chat with somebody by typing their JID into the "Search chats" / "Search contacts" box
Ge0rG
Andrew Nenakhov: the (+) button will add a contact or an account (the latter should be part of the preferences)
Ge0rG
Andrew Nenakhov: I'd like to talk to a JID without adding them first.
Ge0rG
Andrew Nenakhov: or maybe have an (+) when I stopped typing a JID
Andrew Nenakhov
No way, spammer!
Ge0rG
like Chrome's universal input box, you enter a string and the client figures out what you want
Ge0rG
Andrew Nenakhov: I hope you are kidding
Andrew Nenakhov
No subscription no talk. 😈
Ge0rG
Andrew Nenakhov: I hope you are kidding
Ge0rG
xabber-web will show and notify me of messages from foreigners, so why shouldn't it allow to start chats?
Andrew Nenakhov
There are reasons. Mainly because Xabber web is heavily archive centric
Ge0rG
Andrew Nenakhov: but it's got a nice clean UI and a good registration flow
LNJhas left
Ge0rG
Andrew Nenakhov: and your MAM defaults to roster-only?
Andrew Nenakhov
And we can't gather messages from strangers with current mam
Ge0rG
Why not? You can just MAM everything?
LNJhas joined
Andrew Nenakhov
We can, but how exactly do we extract data from it after browser reload?
Ge0rG
Andrew Nenakhov: good point. You could query everything from last 1hr / 24hr / 14d...
jjrhhas left
Andrew Nenakhov
Too data expensive. We're working on server protocol to solve this problem.
Ge0rG
Andrew Nenakhov: something like "list of recent chat JIDs"?
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
deleteme9has joined
jjrhhas left
Andrew Nenakhov
Of course. We call it list of recent conversations.
Ge0rG
Andrew Nenakhov: I'd love to see the XEP for that
jjrhhas left
j.rhas joined
Andrew Nenakhov
It will be, if it'll work well.
Valerianhas joined
jjrhhas left
LNJhas left
LNJhas joined
Tobiashas joined
daniel
Fwiw other people are working on the same thing
Andrew Nenakhov
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.
daniel
Under the name 'inbox'
deleteme9has left
Ge0rG
Andrew Nenakhov: I disagree. I'm fixing the little warts of 0045, one after the other.
Kev
Fix them all and put the enhancements in and eventually you'll have 369.
Andrew Nenakhov
It's beyond help in our opinion. :-/
Ge0rG
Kev: the enhancements that are only needed by a vocal special-case minority, and that complicate the protocol tremendously?
Kev
I mean mostly just putting pubsub nodes for extra data.
Ge0rG
Kev: IMVHO, we can rescue MIX by axing at least half of the XEP.
Kev
I'm potentially up for that.
Maranda
Chop chop
Ge0rG
people are making fun of us for that XEP.
MattJ
Doing so (if the right half is axed) then I'm potentially up for implementing it in Prosody again
Kev
I think very possibly the user server stuff goes away, for one thing. Waiting for thoughts from Dave and Matt on that.
Ge0rG
MattJ: the hard part will be getting consent on which the right parts are.
Ge0rG
Kev: that's not the part I wanted axed.
Kev
Which part do you want axed?
vanitasvitaehas left
Ge0rG
I'd even argue that we can have userserver-side MUC persistence today, based on bookmarks and with zero protocol updates
Maranda
🛠️
Ge0rG
Kev: proxy JIDs would be the highest prio thing for me to get rid of.
Andrew Nenakhov
We'll implement good group chat to our liking, make it work on our server and 3 (6?) platforms and call it a day )
Andrew Nenakhov
Ge0rG, those bookmarks that are already proposed to be replaced? 😂
Ge0rG
Kev: I'm still opposed to roster integration of MIXes, but this is a minor one
Ge0rG
Andrew Nenakhov: it doesn't matter which bookmarks are used.
MattJ
Andrew Nenakhov, so interop is not a goal for you?
Maranda
So muc is being replaced with something with higher running complexity or that's gonna get "axed" right...?
Ge0rG
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
MattJ
Maranda, theoretically MIX's foundations are simpler than MUC's, I believe
Ge0rG
MattJ: in practice, it inherits most of MUCs problems.
Andrew Nenakhov
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.
Maranda
I love the *practically* more MattJ you know me 😘
Ge0rG
Kev: I think that's it, from a brief look through the MIX TOC
Ge0rG
Zash: IIRC you volunteered to implement a PoC server-side MUC idle client
Ge0rG
let's call it "MUC bouncer" ;)
Andrew Nenakhov
We do software, implement on Android, iOS, web, maybe even desktop, then publish docs.
Maranda
... Because if we end with something that is O(N^2) on most things again we might as well stay with MUC. 😀
Zash
Ge0rG: not quite
Kev
We can't do pseudonymous rooms without something like proxy JIDs, though.
Ge0rG
Kev: Sam had a nice proposal of burner JIDs, which would be added into the routing mix
Ge0rG
Kev: so you register with a burner JID component and use that identity to join MUCs, MIXes etc.
Ge0rG
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
alexishas left
Ge0rG
proxy JIDs are a pseudonymity emulation only anyway.
alexishas joined
Andrew Nenakhov
Ejabberd developer said they won't implement MIX
Kev
I maintain that it's a Really Bad Idea to bake anonymous proxies in like that.
Ge0rG
Kev: to bake them into what exactly?
Kev
XMPP
Andrew Nenakhov
No support in ejabberd == XEP dead on arrival
Ge0rG
Kev: as opposed to special-case anon proxies in MIX?
Kev
Yes.
j.rhas joined
alexishas left
alexishas joined
alexishas left
alexishas joined
Ge0rG
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?
Ge0rG
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
Kev
And the compexity ends up much greater like that than it is with MIX proxy JIDs.
Ge0rG
Kev: except that the complexity will be spread onto multiple components that can be debugged individually
Kev
I don't think that's true, you end up needing to break the abstractions, I think.
Ge0rG
Kev: I'd like to see proof of that.
Kev
Of all the bits of MUC that are hard to work with, I'm not convinced that there being proxy JIDs are them.
Ge0rG
Kev: I haven't even started addressing the hard bits from MUC yet. I'm only speaking of the new exciting MIX features
Guushas left
rionhas joined
Alexhas joined
ralphm
Andrew Nenakhov: I think you are misinformed
ralphm
Andrew Nenakhov: there's been ongoing work for ejabberd on MIX for almost two years now
Andrew Nenakhov
ralphm, Evgeniy Khramtsov told me himself
Andrew Nenakhov
I'll ask him again, ok
ralphm
https://docs.ejabberd.im/tutorials/mix-010/
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
SaltyBoneshas left
Tobiashas left
Holger
ralphm: Yes this was during the early stages of MIX development.
Holger
I think Andrew is right that zinid isn't motivated to implement the current revision (nor am I).
marmistrzhas left
ralphm
That's regrettable.
Dave Cridlandhas left
Ge0rG
Not at all, for a specification you need approximately a business day just to read and to make sense of.
ralphm
Holger: is that because of complexity, or because there's no (current) business justification for working on it?
ralphm
Ge0rG: fwiw, XEP-0060 is a lot bigger
Ge0rG
ralphm: luckily, nobody ever implemented all of 0060.
ralphm
This is false
Ge0rG
"no single party"?
edhelas
0060 is a specifc XEP, each time you look at it you find new features and things to implement
Ge0rG
MIX makes use of 0060, so you need that in addition to MIX.
Ge0rG
And then there is the publish-options security nightmare we had recently.
Dave Cridlandhas left
flow
A quick word count shows that xep60 is 1.7x the size of MIX, FWIW
flow
and both are not XEPs I would mention as good examples
Neustradamushas joined
Ge0rG
They are good examples for design by committee.
flow
which committee?
Andrew Nenakhov
Committee of people who wouldn't implement it in software
Ge0rG
flow: I assume this is a rhetorical question
ralphm
that's ridiculous, most of XEP-0060 was defined by just the three people on the author list
Andrew Nenakhov
Ge0rG, not everyone knows this ideom
ralphm
and for MIX, the people that wrote it are also implementing it
flow
ralphm, I doubt that
flow
uhh, implement*ing*
edhelas
it would be nice to have a propre IRL discussion about just Pubsub
intosismiles
flow
I read implemented
edhelas
have a state of the art, see what we understand, maybe with a hackaton to fix the things that we're talking about
edhelas
https://wiki.xmpp.org/web/PubSubIssues
Holger
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.
ralphm
I'm sure there are issues, but the statement that it was design-by-committee and by non-implementors is just false.
Holger
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.
alexishas joined
moparisthebest
are there problems with muc-sub ? like a reason it isn't a good replacement for MUC/MIX?
Holger
As far as I'm concerned it's just the sheer complexity which is demotivating.
Dave Cridlandhas left
flow
At it's core MIX isn't that complex
flow
It's just everything stuffed into the XEP, just like PubSub, that makes one wanna run awawy
flow
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
ralphm
flow: that was just editorial, not actually changing anything in the protocol
flow
ralphm, I know
flow
but even that would improve the situation
edhelas
I'm ok to have a couple of days and do that with a bunch of persons
ralphm
flow: I still have the stacks intosi and I made a few summits ago
edhelas
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
manuel-rubiohas joined
flow
IIRC Zash was running with scissors too
Zash
I helped
intosi
Yes.
intosi
As did Chris, by finding printers with enough reams of paper.
Dave Cridlandhas left
Zash
The threshold for resuming that seems high :/
edhelas
is it possible to just rewrite it ?
edhelas
starting from the bases and slowly adding back all the features that we had
edhelas
it's what I'm doing when I have to refactor code and it's a mess
flow
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
flow
edhelas: rewriting xep60 appears to be to drastic, inefficient and error prone, but maybe that's not what you had in mind?
edhelas
well not really
edhelas
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
manuel-rubio
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?
edhelas
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
flow
manuel-rubio, send a PR, but what's the motivation behind that change?
rionhas left
jubalhhas joined
ralphm
edhelas: I think the split is already more or less clear, I'll see if I can pick that up again
jubalhhas left
ralphm
But I'm not sure if that is a blocker for building MIX
flow
ralphm, Is the split documented somehere?
ralphm
as I said, I have the stacks of paper here
flow
would be great if it where on some wiki page or such, so that more people could participate
flow
and contribute
Ge0rG
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.
ralphm
from the top of my head it is roughly: basic stuff, managent/admin stuff, advanced use cases (publish options, content-based subs)
moparisthebest
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?
moparisthebest
the developers have spoken, you could say
ralphm
I don't know if there's a correlation, no
moparisthebest
it's really the only point that matters
edhelas
ralphm I'd be happy to have a session with you to work on that :D
moparisthebest
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
edhelas
maybe we can organise a Dutch Summit "Let's Make Pubsub Great Again"
moparisthebest
MPSGA doesn't quite roll off the tongue :P
edhelas
let's do some caps and tshirts for the next FOSDEM :p
Dave Cridlandhas left
Andrew Nenakhov
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"
Kev
Except that there are implementations of MIX, BTW.
SamWhited
Kev: link?
Kev
Dave's got some, at least.
Ge0rG
If a tree falls in a forest, ...
Tobias
for Openfire
SamWhited
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.
jubalhhas joined
moparisthebest
Kev, iirc dave half implemented a super early version of MIX in openfire
mrdoctorwhohas left
moparisthebest
not sure I'd count that
flow
So no real implementations of MIX?
SamWhited
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?
SamWhited
If they gave up, that doesn't bode well for the people who keep saying it's not as complicated as it sounds.
MattJ
A bunch of people (including us [Prosody]) implemented the early stuff
flow
SamWhited, I think there never was code I would descripe as MIX implementation in ejabberd
Dave Cridlandhas left
Ge0rG
SamWhited: zinid (Evgeniy) said multiple times that there will be no MIX in ejabberd
MattJ
Possibly even before the XEP was submitted
Holger
flow: Well it was an earlier revision.
SamWhited
https://docs.ejabberd.im/tutorials/mix-010/ ?
SamWhited
What happened to that?
Holger
It's still around.
waqashas joined
SamWhited
Holger: is it being developed, or was it abandoned?
The XEP just grew too big too fast, and with the current XEP I have no intention of implementing
Holger
SamWhited: It's not being developed. The XEP then went into a different direction.
Holger
flow: Is there a MIX client?
MattJ
But this conversation began from the suggestion that the situation may be improved
SamWhited
Thanks
daniel
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
SamWhited
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.
flow
Holger, I'm not aware of one. I think the GSOC project last year tried to produce one but failed
daniel
At least that's in part what stops me from implementing it
jonasw
daniel, +1
Holger
daniel: I'm more afraid the standard won't change again :-)
daniel
😂
jonasw
it seems not too bad to me atm
jonasw
I don’t like the weird roster integration
Ge0rG
> daniel: I'm more afraid the standard won't change again :-)
🤣
intosihas left
Kevhas left
Kev
jonasw: I think the XMPP2 rules may well do away with that.
jonasw
Kev, how that?
Ge0rG
Kev: so you want to bet XMPP2 on MIX?
Kev
Ge0rG: The opposite, I think.
Kev
Use the XMPP2 routing rules in MIX.
moparisthebest
it's also not just server devs, no client dev seems interested in it either
moparisthebest
currently it's a non-starter
moparisthebest
s/currently/past few years/
Ge0rG
Kev: so you are not talking of the weird roster integration?
Kev
I'm interested in it in all our clietns and our server, just haven't got to it yet.
Kev
Ge0rG: I think the roster integration can probably go away once routing rules change.
Ge0rG
I'm interested in fixing MUC
alexishas left
Ge0rG
Kev: please enighten me on how those interdepend
jonasw
moparisthebest, I *am* interested, but I don’t implement things without something to test against.
Maranda
> 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.
Maranda
Sounds more likely
alexishas joined
jonasw
MUC is too simple though.
jonasw
see the mess Multi-Session Nicks is
Ge0rG
Maranda: and it also adds a bunch of legacy MUC issues
jonasw
that ain’t going to be fixed by putting some ducttape on MUC
moparisthebest
again are there problems with muc-sub ?
Ge0rG
jonasw: ITYM "underspecified"
moparisthebest
fully backwards compatible seems a huge giant plus
jonasw
moparisthebest, what’s muc-sub?
daniel
Maranda: well when I say _part of the problem_ I mean in fact _part_
jonasw, something you can test against an implementation: https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/
moparisthebest
that is a xep, kinda? :)
Holger
jonasw: Basically 0045 plus PubSub notifications for offline members.
edhelas
daniel by the way, what are your plans regarding Bookmark support in Conversations, you want to move to a PEP storage ?
jonasw
moparisthebest, xeps are on xmpp.org/extensions/xep-%04d.xml ;-)
flow
jonasw, there is also muc-light
moparisthebest
jonasw, some are in inbox, some haven't made it there yet
moparisthebest
XSF kind of made clear 'MIX is the way, we don't care about what any actual developer thinks'
moparisthebest
which is why I assume it wasn't submitted
jonasw
where did the XSF make that clear?
Ge0rG
moparisthebest: XSF mainly consists of developers.
flow
a few years ago, when the demand for persistent groupchat rose, many MUC replacements appeared, unfortunately we only have one as experimental XEP
SamWhited
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.
jonasw
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.
moparisthebest
well there are developers that just write specs, then there are developers that write code
Holger
jonasw: Do you think it would be good to submit MUC/Sub? Wasn't MUC-Lite already rejected because we have MIX?
jonasw
Holger, I have no idea
jonasw
I also don’t know the history there
SamWhited
Oh, maybe I was thinking of MUC-Lite, I didn't realize these were two different things.
moparisthebest
also XSF has developer firmly entrenched in corporate proprietary servers that have odd use cases not suitable for everyone else
moparisthebest
which isn't a problem in itself
moparisthebest
but look at the XEPs around when MIX came in, a good number of them are virtually universally implemented at this point
pep.
edhelas, movim to PEP storage probably won't happen as long as access-model is not implemented/usable everywhere (from where I understand)
moparisthebest
that MIX has 0 implementations is telling
edhelas
pep. okay
pep.
I mean on servers
Ge0rG
SamWhited: I think we can sufficiently fix MUC with minor tweaks to the protocols and an optional "MUC bouncer" on the users' servers
Maranda
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.
jonasw
Ge0rG, how to fix the multi-session nick mess?
SamWhited
Ge0rG: I have a hard time beleiving that, but I'd love to see a plan outlined if you think it can be done.
Ge0rG
jonasw: it's not much of a mess
jonasw
PMs?
Ge0rG
jonasw: mainly a mess in some implementations
jonasw
Ge0rG, tell that to people trying to feature-discover through MSN.
Ge0rG
just because poezio doesn't get them right doesn't mean it can't be done with minimal effort
Kev
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.
Ge0rG
jonasw: feature discovery for messages is overrated
pep.
edhelas, I'm not talking for daniel, but that's what I gathered
jonasw
Ge0rG, we have many hacks and quirks in aioxmpp and jabbercat code which is solely due to the weirdness of MUCs handling of resources
SamWhited
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.
Maranda
I think somehow I (partially) demessed that jonasw, Ge0rG at least appreciated the effort 😘
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.
Guushas left
ralphm
jonasw: indeed
Kev
SamWhited: Yes, this is true, and yes, we need to make it clear.
ralphm
jonasw: but that's a hard break from how MUC works
jonasw
ralphm, exactly
jonasw
which I think that you cannot simply fix MUC.
Ge0rG
jonasw: I'm using bare JIDs everywhere in my client except for MUC-PMs and it was straight forward to implement
jonasw
Ge0rG, you don’t have avatars in MUC, do you?
ralphm
jonasw: that's why I think MUC is not fixable without breaking compatibility
moparisthebest
jonasw, no one said MIX didn't have good ideas, just that together it's not good
jonasw
moparisthebest, I’m aware.
flow
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.
Ge0rG
jonasw: I don't have avatars. But I heard daniel fixed them recently?
flow
+1
moparisthebest
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' ?
flow
moparisthebest, isn't no answer an answer?
jonasw
Ge0rG, "fixed"?
jonasw
moparisthebest, my specific problem with that is that it’s not a XEP
moparisthebest
jonasw, how is that a problem
flow
but actually, I think there are 1-2 minor problems with MUC-sub
Ge0rG
jonasw: I haven't been watching avatars closely, sorry. Maybe I'm underestimating part of the problem space
moparisthebest
it's running code, that is documented, and can easily be submitted as a xep jonasw
jonasw
moparisthebest, I like to discourage large-scale deployment of things which aren’t XEPs.
flow
but nothing that would prevent me from seeing MUC-Sub as XEP
jonasw
moparisthebest, do it then! ;-)
SamWhited
If there are only 1-2 minor problems, that's pretty good, I really do need to read that again.
Dave Cridland
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.
ralphm
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?
jonasw
Ge0rG, everywhere but in MUC you can (and have to) associate avatars with bare JIDs. in MUCs, you have to use the full JIDs.
Ge0rG
jonasw: yes, as I said. You use bare JIDs everywhere but in MUCs.
jonasw
moparisthebest, it still doesn’t solve the full-jids-as-identities-issue which is my biggest beef with MUC tbh
Dave Cridland
b) I argued against "MUC-light" because it was neither MUC, nor particularly light.
moparisthebest
ralphm, iirc back then council made it clear they would consider nothing but MIX, who would have wasted their time submitting it?
jonasw
Ge0rG, earlier you said "MUC-PMs" ;-)
Ge0rG
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.
Dave Cridland
c) Without seeing MUC-Sub, I don't know how it would differ materially from MIX.
Ge0rG
jonasw: I probably meant "MUC participants"
jonasw
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.
moparisthebest
I also just learned about muc-sub within the last few weeks from someone in here
Dave Cridland
jonasw, FWIW, MIX uses bare jids too. But then doesn't use them for messages, which I never liked.
Ge0rG
jonasw: must inject more <x/>
moparisthebest
it just strikes me as 'good enough'
jonasw
Ge0rG, the <x/> is in there, but that’s breaking layers.
ralphm
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.
moparisthebest
Dave Cridland, did you see the link https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/
Ge0rG
Dave Cridland: I think MIX only used full JIDs for messages in the context of PMs and resource locking?
moparisthebest
sure ralphm , just pointing out there are alternatives that supposedly have running code
moparisthebest
and a (not-yet-submitted) spec
SamWhited
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.
ralphm
moparisthebest: but you don't have first hand experience with this muc-sub then?
moparisthebest
other than hearing about it in passing in here, and reading it, no
Maranda
I'm not sure I entirely get the *real* necessity of offline message deliveries if there's MAM as well.
ralphm
Maranda: indeed, the whole point of putting MAM behind all the things is that you don't have that anymore
ralphm
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.
ralphm
Did MIX really change that much since Feb 2017?
Ge0rG
Only in minor details
Steve Kille
ralphm: No. There was a lot of editorial stuff, but nothing really changed
ralphm
Right, so it is not really a moving target then
Maranda
Well at least it's reliable, offline delivers somehow not so much imho but that's debatable I guess.
edhelas
when I'm reading MIX, I have the feeling that we'll have a Pubsub syndrom in it
edhelas
I mean
edhelas
6.1.15 Telling another User about a Channel
edhelas
this whole piece can be a separate XEP
Ge0rG
edhelas: that's a rather small piece.
edhelas
yup, but still
Marandathinks he mentioned "running complexity"
Ge0rG
Maranda: can you point out specific cases of O(too much)?
ralphm
edhelas: huh? 6.1.15 is not using PubSub at all and points to a separate XEP?
Ge0rG
I think that using MAM both on the MIX and on the private account is a huge mess in the protocol
Ge0rG
"6.5.4 Converting a 1:1 Conversation to a Channel" is a huge security nightmare with questionable benefit
Kev
What's the mess protocol-wise?
Kev
(With 313)
jjrhhas left
jonasw
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).
Ge0rG
Kev: the fact that you have to query the data from different entities, depending on some (internal?) state
ralphm
Ge0rG: in terms of storage, for large rooms, having to MAM store room content 'user-side' seems pretty terrible.
tim@boese-ban.dehas left
jonasw
(ralphm, I think edhelas meant "PubSub syndrome" as in "one huge spec nobody can implement completely")
Kev
Ge0rG: That goes away with MIX and XMPP2, though.
Kev
For messages you just query your own.
Ge0rG
ralphm: so the solution is to store it in user's MAM as well as the MIX' MAM?
moparisthebest
no muc compatibility and requiring support on the user's server also seem to be non-starters
edhelas
jonasw exactly :)
edhelas
as a developper, is simpler to follow small specification, then you can mark that "done"
edhelas
so I implemented MIX-Core, now let's move to the MIX-Invitation XEP
Kev
Can't disagree with that, 369 as a spec is too long.
ralphm
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.
manuel-rubiohas left
ralphm
moparisthebest: there are ways to provide an XEP-0045 layer on top of a MIX backend, of course with limited functionality.
Ge0rG
ralphm: yes, except that's not how MIX is defined.
Ge0rG
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.
Ge0rG
> All MIX messages received by the MIX participant's server for a participant MUST be stored using MAM in the participant's archive.
Ge0rG
And then we have the issue of the user-proxy and the MIX getting desynced due to s2s issues
Ge0rG
Which we know never happens in MUCs
winfriedhas left
ralphm
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
Ge0rG
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
Guushas left
ralphm
what? why?
Maranda
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.
Ge0rG
Maranda: sorry, what context are you in right now?
Maranda
The same running complexity
Ge0rG
Maranda: I think we agree that MIX is not less complex than MUC in that regard?
Marandais multi-tasking atm.
Ge0rG
I should be single-tasking my work now.
Holger
> <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.
ralphm
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.
Kev
That and the broken proxyJIDding.
Ge0rG
ralphm: yes, except that typical pubsub has different traffic patterns compared to a large chatroom
jjrhhas left
lovetoxhas joined
Ge0rG
Holger: that problem can be solved by implementing a "MUC bouncer" on the user's server.
ralphm
Ge0rG: a mix bouncer is exactly what the PAM dependency in MIX does
ralphm
(unless that was your point, in which case never mind)
Ge0rG
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.
ralphm
Ge0rG: interesting, that would have the same impact on abandoned user accounts, though
Ge0rG
ralphm: indeed.
Kev
I think PAM becomes an optional dependency now, though, for MIX.
ralphm
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?
ralphm
Kev: ah, can you expand on that?
Kev
And yes, we can make it transparent.
Ge0rG
ralphm: my point is that we don't need MIX as a solution to _that_ problem.
Kev
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.
Steve Kille
ralphm: the MAM choice you referenced me on makes sense to me. Kev is probably the best person to explain
ralphm
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.
Kev
Which 'that'?
Kev
The XMPP 2 routing rules? Yes, I think we need those, but we need those anyway.
Ge0rG
Kev: I'm pretty sure we'll run into interesting issues when attempting to route 'groupchat' messages to bare JIDs
ralphm
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?
jjrhhas left
ralphm
Ge0rG: why? a server that doesn't support this responds with service-unavailable?
ralphm
(RFC 6121, section 8.5.2.1.1)
Ge0rG
ralphm: I can imagine this not to be the desired outcome for a MIX participant.
danielhas left
ralphm
Ge0rG: so that's why Kev said that indeed the server of the MIX participant needs to support the new routing
waqashas left
waqashas joined
Ge0rG
ralphm: "the new routing" never was about type=groupchat, so Kev must be meaning some newer-than-new routing that I know nothing about.
Ge0rG
So I'm not yet convinced that XMPP2 routing rules solve the MIX routing problem.
alexishas left
Kev
Ge0rG: You might not have intended it to cover gc, but I do.
Zash
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.
Ge0rG
Kev: that's a noble goal. Do you have any documentation on the _how_?
alexishas joined
Ge0rG
Zash: that's exactly what I was talking about. A MUC bouncer of sors
Ge0rG
sorts
Zash
Right
Ge0rG
Zash: how does "the account join MUC" work specifically? Are you using a fake client resource for that?
efrithas left
Ge0rG
Zash: did you encounter any unexpected things? Maybe we should promote that as a server feature?
Zash
Ge0rG: I think I encountered weirdness but I don't remember exactly
Guushas left
Ge0rG
Zash: I'm interested in repeating that experiment
Ge0rG
And while we are speaking of experiments...
Ge0rG
Maranda: do you happen to have new numbers on the GC1 usage?
Maranda
Hm not really.
alexishas left
Ge0rG
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.
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas joined
Zashhas left
rionhas joined
Maranda
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
Ge0rG
Ah, I wish I had a prosody module logging that.
vanitasvitaehas left
Zash
One that isn't mod_muc itself and that works with 0.10?
Ge0rG
Zash: 0.10 mod_muc would be alright with me.
jubalhhas left
SamWhitedhas left
jubalhhas joined
jubalhhas left
jerehas joined
jubalhhas joined
jonasw
Ge0rG, if the archives were solely at the MIX service, the users server wouldn’t need to receive or process them, right?
jonasw
lolwat
jonasw
wtf poezio
Ge0rG
jonasw: yes
Ge0rG
jonasw: except the server would need to tell the MIX when to start and stop sending "live" traffic
jonasw
Ge0rG, BIND2 between server and MIX!
Maranda
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
marmistrzhas joined
Maranda
and most used mobile looks to be Xabber, Conversations on second.
Ge0rG
Nobody is using yaxim 😢
jubalhhas joined
Maranda
Ge0rG, nope one is using Bruno though :P
Ge0rG
Maranda: yeah, glad to hear that.
marmistrzhas left
Maranda
which isn't responding to an IQ btw 🤔
tuxhas left
Ge0rG
Maranda: what kind of IQ?
Maranda
version
Ge0rG
Hm. Must be a very old version then. Or maybe the one with the bug where it dropped IQs because DoS
Ge0rG
But still very old
Yagizahas left
rionhas left
Lancehas joined
marmistrzhas joined
Dave Cridland
So. Yes, I did see muc-sub ages ago, and it's basically a hybrid of MIX and MUC.
Dave Cridland
And I do really hate wrapping messages in pubsub events and sending those as messages. Feels desperately inefficient.
jonasw
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.
moparisthebest
anyone know of a bot that integrates muc with jira ?
Ge0rG
s/jira/git
jonasw
Ge0rG, you know the answer ;-)
moparisthebest
well, kinda jira for tickets and such
Ge0rG
jonasw: yes, two bots. one to integrate git with pubsub and another one to integrate pubsub with muc
Zash
dvcs over pubsub!
Maranda
Ge0rG, be happy: [18:25:32] Echo1: There was an error requesting ***@lightwitch.org/Bruno.554C7F0C's version: recipient-unavailable
Maranda
just dead session :P
Ge0rG
phew.
Ge0rG
Zash: so what about GC1 logging in mod_muc?
Zash
Ge0rG: I started on a module ... twice
Guushas left
jonasw
Ge0rG, just hack it into muc.lib.lua. it’ll probably one line.
Holger
jonasw: Is there any reasoning behind the proxy JID concept besides hiding the real JID?
Maranda
Hmm eww
Maranda
why? mod_muc hooks at -1 anyways
jonasw
Holger, from which jid would one be receiving messages within the MIX otherwise?
jonasw
(and possibly presence)
Maranda
just make a 4 lines module and you're set
Maranda
(or less)
Ge0rG
Maranda: please make a 4 lines module
Ge0rG
jonasw: it's one line, but the challenge is in knowing where to put that line
jonasw: Dunno, maybe the MIX service JID. But why do you need any sort of JID mapping if not for anonymization?
Zash
Ge0rG: You can do it, I believe in you
Ge0rG
Zash: I don't know where to put the chalk mark.
Zash
copy stuff from https://modules.prosody.im/mod_query_client_ver.html
danielhas left
Ge0rG
1. Copy random stuff from different modules
2. Deploy in production
3. ???
4. Crashit
Holger
jonasw: The XEP text also makes it very obvious that this is the point, no? Plus all the JID visibility foo?
Ge0rG
Holger: I think the main reason for having proxy JIDs was indeed to make pseudonymous usage possible
Ge0rG
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.
Ge0rG
Or we need to wrap messages, like <message from=MIX><forwarded><message from=participant///>
Holger
Well the service could obviously just include some tag with the real JID no?
Holger
Like 0045 for non-anon rooms ...
Ge0rG
Holger: what would be the from-JID?
Holger
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.
Ge0rG
Right
waqashas left
waqashas joined
jubalhhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
edhelas
5) Adopt Proposal "Bookmarks 2 (This Time it's Serious)"
edhelas
it's planning to stay titled like that :D ?
Zash
I think we should put Dave in charge of naming all the things
Ge0rG
Zash: that position deserves a better name
moparisthebest
Ge0rG, clearly Dave should name the position
Ge0rG
moparisthebest: I think that naming your own position is a Segregation of Duties violation
Valerianhas left
Steve Killehas left
Steve Killehas left
Zash
Ge0rG: https://q.zash.se/9b36a85d05a9.txt (also some fixes highlighted by static checks)
Zash
Not actually tested
Zash
No warranty etc
waqashas left
waqashas joined
Steve Killehas joined
edhelas
regarding Bookmark 2 do you think it's fine to put muc JID in the nodeid of the Pubsub item ?
edhelas
that is linked with the discussion we had about the format and limitation of those ids
Ge0rG
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?
Zash
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.
Ge0rG
Zash: alright, thanks. That's good enough, as I don't have any other kind of version IQ inducer running
Zash
Could encode stuff into the resource.. but uh
jubalhhas left
Ge0rG
Zash: nah, better not to.
Ge0rG
Zash: it's great as it is now.
Ge0rG
Zash: will it always log with <modulename> in the log line?
Valerianhas joined
Guushas left
Zash
Ge0rG: All module:log() lines do, yes
Ge0rG
Zash: yay. Now all I need to do is to provoke a log manually.
Ge0rG
/rawxml <presence to="yaxim@chat.yax.im/Ge0rG" />
Ge0rG
nothing happens.
Ge0rG
Do I need to load it on the main domain instead of the MUC?
Zash
Supposed to be on the MUC
jubalhhas joined
Steve Killehas left
Zash
Oh
jubalhhas left
Zash
s|preserce/bare|preserce/full|
Ge0rG
heh, I wondered about that too
Ge0rG
Hm. Still nothing
Zash
Are you joined there already?
Ge0rG
Yes.
Zash
So it'll go to "normal presence update"
Ge0rG
Ah, ok.
Ge0rG
Mar 20 19:08:02 chat.yax.im:gc_log info GC 1.0 join from georg@yax.im/poezio
Maranda: this time it worked. Did you rejoin in between?
jubalhhas joined
lovetox
i fixed a muc correction bug yesterday
lovetox
so .. this can happen from time to time
Maranda
Ge0rG, hmm no I don't think I did.
Maranda
lovetox, hmm 1.0?
Maranda
that's what I'm using
lovetox
yes it has that bug
lovetox
basically you have to be really fast with correction
lovetox
if any message in any other muc arrives it wont work anymore ^^
Ge0rG
Is this the week of major client releases? Gajim 1, Conversations 2, ???, Swift 4
moparisthebest
so the same as the https://en.wikipedia.org/wiki/Therac-25 bug ?
moparisthebest
except way less deadly
Ge0rG
lovetox: tell me about race conditions
Maranda
lovetox, oh, well I'm a turtle *known "bug"* :P
Marandasaves speed for olympic lifts ™
Maranda
hehe brb.
j.rhas joined
j.rhas joined
j.rhas joined
j.rhas joined
j.rhas joined
j.rhas joined
j.rhas joined
j.rhas joined
Valerianhas left
j.rhas joined
j.rhas joined
j.rhas joined
j.rhas joined
Valerianhas joined
marmistrzhas joined
j.rhas joined
waqashas left
waqashas joined
j.rhas joined
j.rhas joined
marmistrzhas joined
jubalhhas left
jubalhhas joined
danielhas joined
Holgerhas left
daniel
Ge0rG: does your plan to improve muc also involve a rule that servers should force all connected clients to have the same nick?
daniel
Ie either first joined client gets force renamed to the nick the second client uses or vice versa
daniel
(somewhat re to what you wrote about bookmarks 2)
daniel
Inb4 but muh pidgin can't handle forced renames
Ge0rG
daniel: I don't see how pidgin is in a position to block progress of XMPP
Ge0rG
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
daniel
Tell that to the clients not implemting omemo. Lol
Ge0rG
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
Ge0rG
daniel: as opposed to you, I don't see OMEMO as an integral part of the XMPP future
daniel
Ge0rG: well it wouldn't be the first time backward compat is raised as an argument not to do something
Ge0rG
daniel: with the two of us on Council, we can get rid of GC1, and then of pidgin
daniel
Wait council can get rid of pidgin?
daniel
Why haven't we done this before?
Ge0rG
daniel: I'll propose it as AOB tomorrow
SamWhited
I didn't know we had unilateral power over client devs, we should have been using this for blackmail ages ago.
Guushas left
Ge0rG
SamWhited: I was told we can vote on everything.
Marandahas joined
jonasw
Ceterum Censeo Pidgin Delendam Esse.
daniel
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
daniel
Aehm at least the opt in part
Guushas left
Guushas left
vanitasvitaehas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Ge0rG
daniel: i think we are having a misunderstanding. I'm speaking of the clients synchronizing the nickname to use, not about server side enforcing.
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
LNJhas left
LNJhas joined
Maranda
Apparently killing Pidgin means killing a large portion of XMPP if my server numbers are any exportable 😆
Maranda
Art thou up for such perillous, murderous task?
rionhas joined
Alexhas left
Dave Cridlandhas left
Valerianhas left
Dave Cridlandhas left
Marandahas left
Zash
What about crowdfunded maintenance?
daniel
Ge0rG: I'll summarize that as no such plans then
winfriedhas joined
vanitasvitaehas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Nekithas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
danielhas left
marmistrzhas left
jubalhhas left
rionhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
Zashhas left
jonaswhas left
j.rhas joined
j.rhas joined
Zashhas left
Zashhas left
moparisthebest
this is a good argument for omemo/xmpp https://www.theverge.com/2018/3/20/17142482/russia-orders-telegram-hand-over-user-encryption-keys
Andrew Nenakhov
I can attest that 95% or more of OTR users in Russia are junkies.
Andrew Nenakhov
Also, Telegram is putting a show for masses, there is substantial evidence that it is already controlled by FSB
moparisthebest
wait how do you know they are junkies?
Zashhas left
Andrew Nenakhov
I have access to Xabber support mailbox
moparisthebest
oh, fair :)
moparisthebest
that just means 95% of OTR users that ask for support are junkies though right?
moparisthebest
maybe it works great for non-junkies hehe :)
Andrew Nenakhov
Our app is defacto standard in their circles, they even write on websites 'sales support in Xabber'
Andrew Nenakhov
moparisthebest, I think 95% of e2ee users are criminals (junkies and drug/arms/etc sellers), and 5% crypto nerds )
Andrew Nenakhov
Cryptonerds never ask for tech support though
Andrew Nenakhov
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!".
pep.
Well you have to start somewhere right, first users that see value in the market, and then conquer the world
remkohas left
moparisthebest
well also OTR is terrible for usability, OMEMO fixes most of that
moparisthebest
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
efrithas joined
Andrew Nenakhov
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
Maranda
and then are you certain it really is...?
Maranda
:P
moparisthebest
Andrew Nenakhov: servers never get hacked or misconfigured?
moparisthebest
I run my own too and haven't made those mistakes yet, but I'm not perfect
Kevhas left
Andrew Nenakhov
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
Andrew Nenakhov
In other news. In unexpected turn of events, making an XMPP client for iOS that works well we'll have to implement VoIP 😁
Andrew Nenakhov
*to make an , typo
Holger
Andrew Nenakhov: Yeah. The alternative is sending the body via APNS or generating ugly "New Message!" notifications.
Andrew Nenakhov
Ugly. Btw telegram sends all msg body in Alert-type msg, perfectly open, over APNS
marmistrzhas left
Holger
Ah I was wondering how the commercial things do it.
Andrew Nenakhov
Currently we use non-voip push notifications of 'content-available' type, and it even kinda works...
Holger
But those are unreliable, right?
Holger
I.e. heavily rate-limited by Apple.
jubalhhas joined
Dave Cridlandhas left
Andrew Nenakhov
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
Andrew Nenakhov
*this theory is not yet confirmed
Dave Cridlandhas left
Andrew Nenakhov
Also, when you read articles titled 'force-closing apps does not make your iPhone last longer, stop doing that', know it's a lie.
Holger
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.
Andrew Nenakhov
Content-available type notifications ARE NOT delivered to force-closed apps (swiped away ) at all
Holger
Right.
Andrew Nenakhov
And not delivered after device restart until first launch, too.
jubalhhas left
Andrew Nenakhov
VoIP pushes, on the contrary, work very reliable.
Andrew Nenakhov
Force-close, restart - it works all the time.
Holger
Yup ...
Maranda
of course I vaguely recall VoIP apps getting treated differently even for what regards background running sockets.
Maranda
(and that was ages ago)
Holger
Maranda: Yes, that's going away though.
Holger
Maranda: VoIP apps are supposed to rely on push notifications now.
Andrew Nenakhov
APNS rules changed a while ago. In 2014 you could have a decent background updates without VoIP.
Andrew Nenakhov
We did an xmpp-based app for some guys back then, pushes worked well without additional hassle.
Maranda
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.
Kevhas joined
Maranda
(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*)
Andrew Nenakhov
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.
jubalhhas joined
Maranda
*le sigh*
Andrew Nenakhov
Google's and Apple's tyranny will be much more harsh one of Microsoft.
Andrew Nenakhov
I know a guy who makes a chat app based entirely on FCM. Just pushes and Google's cloud storage. Supaeasy
marmistrzhas left
fippo
somehow this reminds me of the scene from lord of the rings where frodo offers the ring to galadriel...