> [11:26:06] <Zash> Dear lazyxmpp, I wish for a PRECIS implementation suitable for use in C
I need one too
zachhas left
zachhas joined
krauqhas left
andyhas left
remkohas left
remkohas joined
jubalhhas left
zachhas left
zachhas joined
kokonoehas left
zachhas left
zachhas joined
kokonoehas joined
pdurbinhas joined
adiaholichas joined
krauqhas joined
winfriedhas left
winfriedhas joined
adiaholichas left
lovetoxhas joined
adiaholichas joined
flow
join forces and consider starting one :)
Alexhas left
Alexhas joined
kokonoehas left
Ge0rG
Patch libidn?
zachhas left
zachhas joined
kokonoehas joined
andyhas joined
kokonoehas left
Mikaelahas joined
LNJhas joined
kokonoehas joined
kokonoehas left
zachhas left
zachhas joined
Nekithas joined
mtavareshas left
kokonoehas joined
remkohas left
kokonoehas left
Mikaelahas left
mtavareshas joined
kokonoehas joined
Mikaelahas joined
mimi89999has left
mimi89999has joined
kokonoehas left
Daniel
What is the threat analysis for 'resource/presence leak'? Since for ever the community has treated that like something really bad. I never really understood why. I know that it makes some IQ based attacks easier. But really those can also be done over MUC and we generally don't put huge warnings signs up before someone joins a muc
wurstsalathas joined
kokonoehas joined
ralphm
Security Considerations are there to allow people to make informed choices when implementing features. There are always tradeoffs between functionality, UX, and security. Something being called a presence leak doesn't mean it is 100% bad and you MUST NOT allow for it ever.
Daniel
Right. I'm just trying to figure out if I'm missing something
kokonoehas left
adiaholichas left
APachhas joined
APachhas left
APachhas joined
zachhas left
zachhas joined
flow
Daniel, could potentially drain your mobiles battery if I know your resource
flow
(not saying that it isn't possible otherwhise too)
remkohas joined
flow
besides that, joining a MUC is an explicit decission to reveal your presence and potentially your resource. Leaks are typically unintentional
ralphm
Right, but for MUC you could decide to only send availability once and not sync it with your away/xa/etc
ralphm
As an example
ralphm
That then leaks less information
alameyohas left
Guushas left
Daniel
To be clear. (our terminology is a bit confusing here) I'm talking about leaking the resource. Not leaking availability
ralphm
Through MUC?
Daniel
Mostly Auto responding to certain messages
jonas’
Daniel, it can be used to scan for accounts
Danielhas left
Danielhas joined
jonas’
normally we take some care to avoid that being possible unless you know a resource
ralphm
I think it is not so much about leaking resources per se, as you generally reveal them to your contacts anyway, but making them unpredictable
mukt2has left
remkohas left
karoshihas joined
mukt2has joined
kokonoehas joined
mukt2has left
mukt2has joined
pep.
jonas’: vcard-temps and public omemo keys allow that✎
pep.
jonas’: vcard-temp and public omemo keys allow that ✏
flow
I think it is about leaking the resource per se
pep.
(Scanning accounts)
flow
Remote entities shouldn't know that there is a connected client if they are not explicitly allowed to
zachhas left
zachhas joined
flow
andt hen even be able to send data directly to that client
kokonoehas left
Daniel
flow, I get that I guess… That is a slightly different argument than leaking the resource (as in that specific string)
mukt2has left
mukt2has joined
goffihas joined
mukt2has left
mukt2has joined
Danielhas left
Danielhas joined
kokonoehas joined
inputmicehas left
remkohas joined
mukt2has left
mukt2has joined
Steve Killehas left
Steve Killehas joined
mukt2has left
mukt2has joined
kokonoehas left
debaclehas joined
Dele (Mobile)has joined
Ge0rG
Daniel: I agree with you that the leaking is overhyped as a security issue
zachhas left
j.rhas joined
zachhas joined
kokonoehas joined
jubalhhas joined
remkohas left
kokonoehas left
jabberjockehas joined
Nekithas left
debaclehas left
j.rhas left
LNJhas left
LNJhas joined
zachhas left
zachhas joined
j.rhas joined
kokonoehas joined
APachhas left
rionhas left
APachhas joined
Daniel
https://www.businessinsider.de/ihr-koennt-bald-offenbar-nachrichten-von-threema-auf-whatsapp-verschicken-2019-9 IM regulation wrt to interop is happening and nobody has asked us for our expertise. is there a bank account we need to wire money to to get heard?
google translate link: https://translate.google.com/translate?hl=&sl=auto&tl=en&u=https%3A%2F%2Fwww.businessinsider.de%2Fihr-koennt-bald-offenbar-nachrichten-von-threema-auf-whatsapp-verschicken-2019-9
LNJhas left
rionhas joined
rionhas left
rionhas joined
rionhas left
rionhas joined
APachhas left
pep.
I wonder if Matrix also tried and also got ignored
kokonoehas left
kokonoehas joined
rionhas left
ralphm
It reads to me that this is a paper goal, and I don't think that half 2020 is realistic if that's the case.
Daniel
obviously 2020 is not realistic. but that's not the point. the point is that they seem to be somewhat serious about attempting it
rionhas joined
rionhas left
ralphm
The politicians or the companies?
rionhas joined
Daniel
the politicians
ralphm
Right
kokonoehas left
ralphm
I'm curious if Ge0rG has heard back from his contacts.
Ge0rG
ralphm: no news yet. But I'll try to reach out again, I was told to remind them some months in
Ge0rG
That article is a good trigger for a reminder, actually
ralphm
This article seems like a good reason to. Was that contact in one of those parties?
Ge0rG
ralphm: I don't think so, he's an employee of one of the agencies
Ge0rG
ralphm: I'd love to be able to propose a way forward for E2EE
Ge0rG
This is something he was most concerned about
Ge0rG
MLS is probably something we need to evaluate properly in advance
kokonoehas joined
pep.
> There is a lobby battle ahead
Thank you article, I wasn't expecting that.
kokonoehas left
Daniel
also no sources to when and where they said this
Daniel
but who needs sources in 2019
Ge0rG
pep.: sharpen your axes, we are going full in
ralphm
Also curious if governments want 'in' on the conversations.
pep.
Ge0rG: the XSF has no resources for this kind of battle. Companies using XMPP would, more than us already anyway
Daniel
that's only a problem if you believe that democracy is about who can bring the most resources to a battle
delehas joined
delehas left
pep.
I believe that's a harsh reality
delehas joined
ralphm
Companies are people now, in some jurisdictions, so arguably the are part of the demos.
Daniel
maybe we need to go the indirect route and convince 'our' lobby groups (CCC, FSFE, …) first
Ge0rG
Daniel: we've seen recently in the copyright debate that it's not about "resources" in general, but about money to politicians. Having 200k people demonstrating on the streets is meaningless
pep.
Daniel: that might help. EDRi also maybe
ralphm
I was also thinking about IETF
delehas left
jubalhhas left
Ge0rG
ralphm: is IETF a political lobby org?
Daniel
i actually tried to talk to a representative from the FSFE about that and he was like: no I don’t want that i just want free software; to which i replied but that's not the point and also having them interop would actually strengthen free software because network effect; and he was like: but we just want to convince everyone to use Conversations; to which i was like: …
Daniel
i don’t think the IETF is a lobby group in the sense that the CCC is one
pep.
Daniel: can we put up a talk for CCC about this?
Daniel
IM interop? yeah i still have one in the pipeline for the 'privacey week' but they haven’t accepted it (yet?)
pep.
What do we know about it already? Maybe we should also contact matrix
Daniel
the idea was if it goes well at privacy week i'll do the same one at ccc
pep.
Ok
ralphm
Ge0rG: no but they, under ISOC, might have ideas on how to approach this.
ralphm
And I'm not surprised at all about FSF(E)
pep.
I hear FSF/FSFE can be quite different btw, I haven't experienced that myself though
Ge0rG
Maybe we need to find someone else from the FSF then?
ralphm
Yes, there's also recently been considerable friction between them
ralphm
And I think neither cares about protocols
Ge0rG
Anyway, we need to act now.
pep.
I guess this kind of talk at POSS will fall in deaf ears
jubalhhas joined
kokonoehas joined
kokonoehas left
kokonoehas joined
Daniel
maybe i should try calling those two people
kokonoehas left
madhur.garghas joined
LNJhas joined
kokonoehas joined
jubalhhas left
jubalhhas joined
lskdjfhas joined
pdurbinhas left
debaclehas joined
Ge0rG
Daniel: keep us up to date please. I'm going to write to the ministry employee early next week
zachhas left
zachhas joined
jubalhhas left
jabberjockehas left
Daniel
I need to figure out what point I'm trying to make and how to get that across
j.rhas left
Ge0rG
Daniel: "please keep moving this, good work! Demand open standard APIs! Hire me to make E2EE work!"
jubalhhas joined
debaclehas left
kokonoehas left
j.rhas joined
kokonoehas joined
Guushas joined
alameyohas joined
jubalhhas left
winfriedhas left
winfriedhas joined
krauqhas left
kokonoehas left
zachhas left
zachhas joined
murabitohas left
andyhas left
krauqhas joined
remkohas joined
zachhas left
zachhas joined
Nekithas joined
kokonoehas joined
krauqhas left
pdurbinhas joined
flow
> Daniel> flow, I get that I guess… That is a slightly different argument than leaking the resource (as in that specific string)
I think it is the same argument assuming the leaked resource(string) is one of a "currently" connected client
Maybe they are excluding open standards on purpose
ralphm
Now, what did I say?
moparisthebest
Nice chat network you got there, sure would be a shame if some regulation happened to it, maybe if you were to give us plain text though...
Yagiza
*GIRL CRY*
moparisthebest
What you don't trust the govt with everything? I mean in all the history of the German gover... Oh right...
ralphm
Don't mention
kokonoehas left
larma
Daniel
> i actually tried to talk to a representative from the FSFE about that
Who did you talk to?
Also I doubt interop will work with encryption, as there has to be an official, gov-supported encryption standard for that. So if any, we get unencrypted interop and encryption will only work within a messenger network.
lumihas joined
kokonoehas joined
larma
What could make sense though is to require messengers to have easy data export in a standard format that could then be imported in other messengers, making it easier to move to a different network
Daniel
right. because nobody has ever created standardized encryption before that works across different providers and vendors
larma
Daniel, we don't even have it within a single network, how should that work across networks?
larma
We have about 5 different e2e-encryption standards implemented by clients in XMPP
larma
(only counting those in well-known open source implementations)
larma
And it makes sense to have multiple, because they have different properties.
lumihas left
ralphm
And also, you'll probably want the ability to upgrade to newer/better approaches in the future.
Daniel
and six part time open source developers not being able to agree means that you can’t do it?
j.rhas left
larma
Even TLS is a monster of different encryption protocols. It just works because connections are short living and only between two entities.
ralphm
If you get parties to federate based on XMPP, even if it just unencrypted, you already have a connected network. Whatever e2ee can then be put on top.
moparisthebest
Within just a few years here omemo was invented and adopted by all major clients, so I really don't know what you mean larma
larma
Not by all major clients, just by a subset for a specific niche (personal im)
ralphm
But omemo is from the end-all-be-all, though.
zachhas left
zachhas joined
moparisthebest
Also larma TLS is just for short lived connections????
moparisthebest
Are you talking about something else
ralphm
And I purposely turn it off because it invariably fails to work properly with my collection of multiple clients.
larma
Have you seen a TLS session running for several months as do OMEMO sessions?
moparisthebest
Yes
larma
Huh?
Zash
XMPP s2s connections would
larma
Zash, several months? I hope you install updates, don't you?
moparisthebest
Wait until you hear about quic where sessions can survive reboots and network changes etc
Marandahas left
Marandahas joined
ralphm
I've been mentioning (IETF) QUIC a couple of times.
ralphm
I think it definitely deserves an experiment to have an XMPP binding for.
Daniel
also i'm afraid that the people who want to regulate IM won’t stop because larma thinks E2EE (a subset of the entire thing) can’t be done. so I'd rather be part of the debate and help them do a slightly less shitty job than they would do if they'd only listen to facebook and google
Zash
larma: that's besides the point. and there can be months between updates to the servers or tls library that would mandate a restart
moparisthebest
ralphm: yea and I suspect you could do away with stream management inside quic too
ralphm
Daniel: to be honest, I would already settle for just the XMPP based federation, even without e2ee.
ralphm
moparisthebest: but it might be useful for file transfer
moparisthebest
Yes as long as they don't also ban e2e in the process
ralphm
Oh, I get what you meant, sorry. Yes, definitely.
moparisthebest
Cause as you said that can just be done over top of federation later
ralphm
Right
ralphm
moparisthebest: and about QUIC, yeah, there are quite a few benefits.
larma
QUIC probably won't survive reboots in practical scenarios as that would require to persist session keys
I am talking about how TLS works in practice. Sure you can keep connections running longer, but ideally you don't so you can upgrade protocol version and ciphers for higher security at some point. And again TLS is between two entities. A group chat could consist of hundreds of different client versions if there was cross messenger interop...
larma
I guess I will be able to find a set of 5 TLS clients/servers that don't share a single common cipher compatibility
moparisthebest
So maybe you have Rock solid e2e between 2 entities and not as good in group chats?
moparisthebest
In fact that's what we have
moparisthebest
Is your point don't bother at all or?
kokonoehas left
kokonoehas joined
Daniel
i don’t get why "it's going to be difficult" is an argument for "let's not even attempt to try this"
moparisthebest
Also lessons have been learned from TLS, not everything should be an option etc, have you seen 1.3 ?
larma
I just think it's unlikely to get to a common standard for e2e. There are a lot of voices against OMEMO in the XMPP community alone (for some good reasons).
That said, for unecrypted interop at least I see potential. It could even be that we can require unencrypted interop and messengers can voluntarily do encrypted interop if they want to.
moparisthebest
It vastly limits options, and http2 requires a specific cipher for instance
larma
> Daniel
> > i actually tried to talk to a representative from the FSFE about that
> Who did you talk to?
moparisthebest
larma: right, and the voices against omemo didn't matter did they? All main clients support it
Daniel
larma, the guy who gave the free your android talk at gpn
moparisthebest
It's not perfect, but perfect is the enemy of good, and it's good
ralphm
moparisthebest: except omemo is only about text
moparisthebest
Right, so it covers 95% of the use case for IM then? Great
larma
Daniel, I will be at the FSFE european community meetup in November, so I might be able to bring up that topic. I know that the president of FSFE use(d) Dino, so at least there is a certain interest present.
Daniel
fwiw I personally see greater challenges when it comes to group chats. because different IMs do them vastly different. however that is all besides the point. the point is that THEY want to do this and 'we' have 20 years worth of experience on the *how*
ralphm
Well, one of the arguments here is that people needing to use this also want to hide who's talking to whom, and I don't see how to do this in XMPP.
ralphm
And another indeed groups and MAM.
ralphm
We do indeed have 20 years worth of experience on federation.
j.rhas joined
ralphm
And I would probably be a bit sad if for groups we'd have to settle on MUC.
Daniel
i mean we could explain to them what parts are more easily federatable (is that a word?) (1:1, unencrypted, simple media sharing); and I'd rather have us explaining that to them than letting Facebook Inc do the explaining
zachhas left
zachhas joined
ralphm
Calling
ralphm
Yes
flow
> Daniel> i don’t get why "it's going to be difficult" is an argument for "let's not even attempt to try this"
me neither
ralphm
Right. My reservations around e2ee are orthogonal to attempting to get services to federate.
jonas’
+1 Daniel
moparisthebest
Actually group chat is a really good example
moparisthebest
Everyone agrees it's hard, everyone agrees muc isn't ideal, still how many years later here we are
Ge0rG
We rather should try to support the involved law makers in ensuring that things aren't botched from the start.
moparisthebest
Mix is an attempt to make it more perfect, where is that
kokonoehas left
ralphm
moparisthebest: in progress
ralphm
And I'd love to have it sooner rather than later, but some of it is not easy
moparisthebest
I'm just saying it would have been silly to have avoided muc forever while waiting for mix
Daniel
MIX (and that's changing topics now) is pretty sad. I think it somehow got off to a wrong start and there is big resentment in the open source community toward it
ralphm
moparisthebest: sure
moparisthebest
Which is essentially what the "e2e is too hard" argument is
ralphm
Daniel: I mostly draw it up to ignorance, which is ok
Daniel
ralphm, maybe. but how can we make progress in that situation
ralphm
moparisthebest: no, MIX is achievable. I don't know about e2ee.
Ge0rG
Ignorance is also what I've experienced when trying to improve MIX. 🤷♂️
ralphm
I mean, I'm not discouraged by people looking at and going AARGH
moparisthebest
ralphm: except the opposite has happened in practice, we have working e2e, no working mix though
Daniel
i'm somewhat discouraged by people trying to "fix muc" with self ping, occupant id, and 100 others hacks like allowing members to read the affliations just to get something simple as a list of people who are in a room
ralphm
MIX needs to cater for a world with multiple devices, with a saner join model, and then some. I believe we can get it to be much easier for client devs. For servers there might be an impact that relies on server side support.
Ge0rG
ralphm: did you write your suggestions to standards@?
Daniel
or let me clarify that. i'm not discouraged by people trying to "fix muc" but by the fact that we have somehow given them the impression that this is the more achievable path than implementing MIX
ralphm
So various ideas there are solid, some need work. I'm going to take some time to look at that in the coming weeks
Ge0rG
ralphm: write a blog! 😉
ralphm
Ge0rG: I might
Ge0rG
Daniel: maybe the underlying problem isn't "MIX is too complex to tackle" but "server developers don't have enough time to make large changes at once"
ralphm
moparisthebest: as I said, I always disable e2ee because it doesn't work for me. Maybe it is just me.
Ge0rG
So that a path of small improvements of what's there already is working out better
ralphm
Ge0rG: but they do for each inventing their own
Ge0rG
Even if we are bound to end up in a local maximum.
zachhas left
zachhas joined
Ge0rG
ralphm: I also always disable E2EE.
Ge0rG
ralphm: none of those parties have provided reasonable specifications yet.
ralphm
My point is that I don't buy that argument
ralphm
(from them)
lumihas joined
Ge0rG
ralphm: I was mainly talking about the OSS implementations out there.
ralphm
Sure, that's a valid point
kokonoehas joined
Ge0rG
And as MUC isn't going anywhere, it's worth fixing it.
moparisthebest
Doesn't change the fact that omemo "just works" for the majority of people
ralphm
I have no metrics to make that argument
jonas’
moparisthebest, ejabberd has a partial MIX implementation in the current release
moparisthebest
Most people don't use as many clients as you do etc
jonas’
I’m going to start a MIX implementation in aioxmpp against that
moparisthebest
Most people just have a phone only, the ones that have a desktop also use a client that supports it on there
Daniel
well the MUC that is not going to go away is this kind of muc; the muc that we are in right now. however that kind of muc doesn’t suffer that much under the limitations of MUC
Daniel
so it does’t have to go away
moparisthebest
Again, not perfect, but good, waiting for perfect gets you in the waiting for mix forever mode
Daniel
however the "private group chat" can easily be switched over. and will also benefit from what mix has to over
Daniel
*offer
Ge0rG
Daniel: I agree. Still, somebody needs to write the code, then to find out the places where the MIX spec is broken, get them fixed and rewrite the code finally.
Ge0rG
I'm still not convinced that MIX is solving all the known technical problems of MUC.
ralphm
Like?
andyhas joined
Kevhas joined
Daniel
i kinda wish someone would address my MIX feedback so i could move on implementing it…
Daniel
or even invite me to do a PR i guess
Ge0rG
ralphm: my pet issue is message loss during s2s interruptions
ralphm
It would be good to have a list of those and document how such issues are, or are not (yet?), addressed by MIX.
Ge0rG
ralphm: I don't remember my other points raised around 2016.
jonas’
Daniel, you got a +1 and no -1nes on the PEP node thing. Please just do a PR
ralphm
Ge0rG: yeah, that needs work
jonas’
not sure where Steve Kille is
Kevhas left
ralphm
Enjoying his weekend?
Daniel
that might be a tiny bit undeserverd but I never got the impression that MIX is welcoming to PRs
Ge0rG
ralphm: one of my points, the incompatibility of the roster with MIX entries, has been addressed two or three years later, it seems to me
jonas’
ralphm, for three months?
jonas’
Daniel, true, in a way
ralphm
As I said, I'm going to try and dislodge things
Ge0rG
Daniel: not just PRs, but any kind of change requests?
jonas’
Daniel, FTR, I added a +1 to that thread, maybe that gets it rolling again
Ge0rG
ralphm: feel free to make a list from what was written on standards@ over the last years
Daniel
one more than the other maybe
ralphm
Ge0rG: various comments I raised have been addressed by Steve last time around, though.
ralphm
And after that I was less involved, so didn't follow up
Ge0rG
ralphm: so you say I should re-read the XEPs and what I wrote in 2016, and just submit the open points as new feedback? I'd do that, but I lack the time.
Daniel
assuming that I would go ahead and make a PR. what is it that we want to do exactly? private pep node, multiple items, one item per channel, client can’t modify it. last item notify is off (so a client can +notify that node but not get bothered with the last item for no reason on connect)
delehas joined
Ge0rG
I wouldn't mind at all if somebody else did it.
ralphm
Understood. Time is precious. But I do have some, so am going to use it for MIX
delehas left
moparisthebest
And to be clear my only point was no one is saying "group chat too hard we should give up" so why say the same about e2e that's all, sorry for starting mix discussion :)
jonas’
Daniel, all of what you say sounds excellent
Ge0rG
ralphm:
> ralphm: feel free to make a list from what was written on standards@ over the last years
Daniel
and MIX-PAM will automatically send presence to all the items
jonas’
Daniel, if and only if presence is enabled for that MIX, IIRC you can turn that off?
jonas’
(that type of metadata should maybe be included in that PEP node?)
ralphm
Daniel: I am not following. What are you talking about?
Daniel
yes… so a client would have to be able to modify that paramater
jonas’
Daniel, wouldn’t that work via the existing PAM-IQ-flows?✎
jonas’
Daniel, wouldn’t that work via the existing PAM/MIX-IQ-flows? ✏
Daniel
jonas’, i would have to look into that again
jonas’
let’s start it simple though
Ge0rG
Daniel: weren't there issues with multi item PEP?
Daniel
ralphm, moving channels out of the roster
ralphm
Daniel: I missed that was an issue. Can you explain why that is a problem?
Daniel
ralphm, didn’t you raise the same issue during the summit?
Daniel: my primary concern was that it requires servers to know about MIX. I'm not sure if I still think that is a problem. Sure it means that if your server doesn't you can use MIX. A counter argument is that at some point progress means you have to let that go.
zachhas left
zachhas joined
jonas’
ralphm, servers need to know about MIX anyways, that’s '405
ralphm
Daniel: not having a roster indeed is a good point
ralphm
And I did raise that.
Daniel
i remember that
Ge0rG
ralphm: From my 2016 memory: non MIX clients need to get a copy of the roster without the rooms. This means servers need to disco a client before sending roster, and roster versioning becomes a mess.
ralphm
Thanks for bringing that up again.
Daniel
i also see virtually no argument in favor of putting it in the roster
Daniel
and a lot of (some bigger than others) arguments against doing that
jonas’
(FTR, the roster mail I linked was what I was referring to when I was ironically asking whether Steve was enjoying his weekend for three months now ;))
ralphm
Ge0rG: wait huh?
Ge0rG
Also you might not want automatic presence delivery to all rooms, but this is a minor issue.
jonas’
Ge0rG, the 2016 design still had only those MIXes where you’d send presence in the roster
Yagizahas left
Ge0rG
jonas’: which is also bonkers, because how do you know of the others?
jonas’
yeah
Ge0rG
I remember the bad things that happen if you add a MUC to your roster.
ralphm
Knowing which channels you have joined is orthogonal from which channels you send presence to and the current roster integration conflates that? Yes I see that argument.
jonas’
s/bad/fun/
Ge0rG
jonas’: fun for an outside sadistic watcher, yeah
mr.fisterhas joined
Ge0rG
ralphm: it would also require roster annotations to be inside the respective room elements to know those are not people
Because, surprisingly, a client needs to know that when opening a chat window
Ge0rG
ralphm: it's not a MUST, but the alternatives are worse
ralphm
Hmm
Ge0rG
Say, disco#info to all roster entries after connecting.
ralphm
Or doing that right when while opening a chat.
ralphm
And caching it.
mukt2has left
Daniel
not just opening the chat. but take the simple task of learning what channels you are joined
mukt2has joined
ralphm
Obviously CAPS are in issue for this.
ralphm
An issue
Daniel
because when starting the client you might want to have open tabs for all channels
Daniel
how would i do that if the roster items are not annotated
ralphm
Daniel: right
jonas’
(something about inbox)
ralphm
Heh
Ge0rG
ralphm: you also need to know that when receiving a message from MAM. Which is why I've insisted on adding <x/> elements into MUC PMs.
Daniel
also you might want to learn what nodes you are subscribed to for a specific channel
Daniel
in MucSub there is a get me my 'channels' command. and then each items lists the nodes
Daniel
*currently subscribed nodes
Ge0rG
ralphm: making the UI depend on another roundtrip is a horrible idea. What if you just lost your network connection, or are on EDGE?
ralphm
Sure, I see that argument, but once you know it is a MIX Channel, that's forever, likely.
Ge0rG
ralphm: think of thin clients.
ralphm
Daniel: having to query the full list all the time is an issue, too, so you need some versioning there too?
jonas’
or web clients, for that matter
Ge0rG
Do they have to store a local list of MIXes now?
Daniel
also MIX-PAM already has those annotations
Ge0rG
ralphm: how is all that outweighing a simple child element / a dedicated list in PEP?
ralphm
I'm not saying it is
ralphm
Just exploring what's being said here. Happy to see all these points.
Ge0rG
ralphm: you said you disagree with that point.
Ge0rG
ralphm: I've argued all that back in 2016. It's nice to see we have finally moved beyond it.
ralphm
I disagreed that it has to be in the roster
Ge0rG
> ralphm: it would also require roster annotations to be inside the respective room elements to know those are not people
ralphm [16:43]:
> Ge0rG: I disagree with that point
I read that as you disagreeing with annotations.
ralphm
Ge0rG: sure, to get anywhere we need to reevaluate all of it
Ge0rG
ralphm: please do, and blog it.
ralphm
Yes, sir. 🤣
Ge0rG
ralphm: or make a spreadsheet of problems and their respective solutions
pdurbinhas joined
Ge0rG
Because I'm honestly tired of arguing all that, over and again.
ralphm
I definitely want this to be easy and thin.
ralphm
E.g. I think having to ask every channel for MAM is not good.
ralphm
Vn.
Ge0rG
ralphm: I agree with the general idea. Just ping me once you've taken over authorship... 😉
Daniel
what is the counter argument of putting it in a private pep node roughly in i style of:
> private pep node, multiple items, one item per channel, client can’t modify it. last item notify is off (so a client can +notify that node but not get bothered with the last item for no reason on connect)
zachhas left
zachhas joined
Ge0rG
Daniel: it sounds sensible to me, but I haven't really worked with PEP, so don't know the pitfalls
Daniel
(note that servers could implement it as a virtual pep node)
Ge0rG
Daniel: Zash recently mentioned issues with having multiple items in one node. But those might be practical and not protocol limitations, so can be fixed in a MIX supporting server
ralphm
Daniel: might work, indeed. Was just mostly interested in the issues, rather than looking at possible solutions.
jonas’
the only pitfall I see is that it might not scale to enormous numbers of channels
ralphm
jonas’: I'm curious what is enormous
Daniel
can you RSM through pubsub items?
ralphm
Yes
mukt2has left
jonas’
Daniel, in theory, yes
Daniel
so i don’t see the issue
jonas’
ralphm, anything which breaks the stanza limit
jonas’
Daniel, you have to fetch the channel list on each reconnect, don’t you?
Ge0rG
Can you receive a delta of all PEP changes, given a certain initial state? From MAM?
Daniel
that's why it is multiple items
jonas’
Daniel, but if those are 1k items, the fetch will still be annoying on each connect, especially on mobile.
Daniel
also if you are afraid it will break your stanza size limit it will also break your roster fetch
ralphm
When I was in VEON, our Slack had many channels. I was in 40+, and then there are the unnamed 'channels' for talking to an immutable set of people.
ralphm
My daughter uses WhatsApp quite a bit
ralphm
Many many channels
ralphm
None of them ever closed
ralphm
(though many go unused)
mukt2has joined
ralphm
My current thinking is that PEP might not be the best model. If a server manages all your subscriptions, why would a client need to touch it? Maybe just a plain old iq would be good.
Daniel
so the argument against PEP would be that we that we don’t benefit from roster versioning
jonas’
ralphm, the PEP node is read-only to the client
jonas’
Daniel, we cannot benefit from roster versioning in any serious way anyways because for non—MIX clients the entries must not be in the roster
jonas’
it would at least make roster versioning much more complex on the server side
Daniel
i'm not overly attached to PEP. i just don’t like to use roster
pdurbinhas left
ralphm
Aye
Daniel
ralphm, there would need to be some kind of subscribe to changes mechanism. and +notify would _one_ solution to signal that
ralphm
Right.
Syndacehas left
Daniel
also reusing syntax. my client might already have PEP notification handling
Ge0rG
> Can you receive a delta of all PEP changes, given a certain initial state? From MAM?
jonas’
Ge0rG, there are rumors about MAM for PubSub
Daniel
that probably doesn’t help you with PEP
Ge0rG
jonas’: you can't implement a rumor
ralphm
Just to be clear, this is hardly PEP, but node-on-account, but I digress.
Ge0rG
Whatever it is, I want a delta mechanism.
ralphm
jonas’: without MAM for pubsub, I'm unsure how we could do other nodes in MIX
ralphm
Ge0rG: noted
Daniel
> Just to be clear, this is hardly PEP, but node-on-account, but I digress.
fair enough
Syndacehas joined
jonas’
#undef PEP
#define PEP PubSub-on-user-accounts
Zash
PEP Plus
Zash
XEP-0222, XEP-0223
APachhas joined
ralphm
But but
mr.fisterhas left
mr.fisterhas joined
holatesteyhas joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
zachhas left
holatesteyhas left
zachhas joined
Daniel
in an attempt to get to a point where I could actually make a PR. if we didn’t use a pubsub node on the account we would have to specificy: 1) querying the list; (possibly with RSM) 2) subscribing to the list (can be done with putting a mix namespace into caps) 3) new item notification 4) retract item notification
am i missing anything?
Daniel
are those four tasks close enough to pubsub to justify borrowing the syntax
Daniel
or is it better to create own syntax for that
Ge0rG
Daniel: receiving actual deltas if you were offline for some weeks
winfriedhas left
winfriedhas joined
jonas’
Daniel, provisions which would allow us to introduce versioning later
jonas’
ha, what Ge0rG said
ralphm
I'd not put in a PR at this point. Rather reiterate the issues and requirements.
jonas’
ralphm, the issues have been re-iterated on the ML since 2016
jonas’
nobody has objected to Daniels bringing it up three months ago
jonas’
I think we can move forward with proposing an update to this *Experimental* XEP to finally achieve some progress
mukt2has left
Daniel
it doesn’t have to be a PR. and i'm happy not having to create one
ralphm
Ok, if you don't want to wait for me, maybe it'll work.
Daniel
but i would like to get to a point where i'm not being ignored
mukt2has joined
jonas’
ralphm, what timeframe do you anticipate? MIX has been "waiting" for years now.
Daniel
ralphm, wait for you? what are you planning to do?
jonas’
a few more weeks probably won’t hurt if you’re going to do an in-depth evaluation which might actually move us forward
jonas’
what Daniel is saying, effectively
ralphm
I have time on my hands and will try and dislodge the whole thing
archas left
archas joined
jonas’
my dictionary does not list a sensible translation of `dislodge`✎
jonas’
my dictionary does not list a sensible (in this context) translation of `dislodge` ✏
ralphm
Get it unstuck.
jonas’
I see
neshtaxmpphas left
neshtaxmpphas joined
archas left
archas joined
Ge0rG
I'm sure the underlying conditions have changed significantly since I tried the in depth evaluation.
jonas’
ralphm, I don’t mean to attack you. It seems just frustrating to re-iterate all the arguments we’ve had yet another time.
ralphm
Consider the discussions on MAM2 in light of MIX.
jonas’
which reminds me that certain Reactions-interested folks also don’t feel heard with their feedback on XEP-0422
ralphm
jonas’: well, I don't think you have to. I'll try to dig things up.
ralphm
jonas’: I still owe responses to people reacting to my post. Anything specific you mean?
jonas’
all in https://mail.jabber.org/pipermail/standards/2019-September/036422.html
ralphm
Right.
zachhas left
zachhas joined
Daniel
there is also some underlying meta debate one could go into. so assuming I'm company X and I had some money to develop a group chat thing. I'll start looking into MIX but it doesn’t yet do 100% of what i want to achieve. so i provide feedback (like the roster thing); my feedback is being ignored. however my customers needs a group chat now and not in 5 years. so what do I do; do I fork MIX internally and use a "fixed MIX" which due to other constraints in MIX might still only be 99% of what i'm trying to do. or do I start from scratch and develop something new that fits my needs and my needs alone
ralphm
I think Kev did a good job of attempting to help out with his document. People not immediately responding doesn't mean they are being ignored. What do you think are reasonable expectations from people putting in volunteer efforts in our standards process?
jonas’
ralphm, I carefully chose my words to say "feel"
Daniel
seems like a lot of companies in the past have gone down the second road. P1, erlang solutions, redsolution etc
jonas’
I understand as well as anyone that volunteer standards process will have delays and everything
jonas’
ralphm, I’m not sure how we can fix this, but this is in a similar vein as what Daniel says
ralphm
Yep, this stuff is not easy. Some people want something now because they have business constraints, and some others have other priorities.
kokonoehas left
ralphm
I'm not opposed to companies doing their own private thing in the meanwhile.
larmahas left
larmahas joined
Daniel
i don’t have an answer to that (otherwise i wouldn’t be asking) but is there anything we can do to help people who need solutions now and keep them in the community
Daniel
as opposed to what some companies are currently doing with "let's develop our own XEPs"
ralphm
Well, doing your own is a valid choice if you have internal pressure and don't require interop.
Daniel
you say "in the meantime" as if they were coming back once MIX is done. but i highly doubt that
ralphm
Even if we fix the protocol to most desire, it will still take a while to get to a place where we can migrate away from MUC.
ralphm
Daniel: I'm not sure how to help that other than my offer to move things forward.
ralphm
So in the short while that is fastening/references and MIX
ralphm
I also have opinions on calling, but I don't want to overcommit.
neshtaxmpphas left
neshtaxmpphas joined
kokonoehas joined
ralphm
And larma's comments are valid, so I'll try to get to that next week.
kokonoehas left
lumihas left
winfriedhas left
winfriedhas joined
kokonoehas joined
zachhas left
zachhas joined
winfriedhas left
winfriedhas joined
archas left
archas joined
mukt2has left
zachhas left
zachhas joined
Daniel
> Daniel: receiving actual deltas if you were offline for some weeks
Yes. Being able to retrieve deltas is probably a good argument for using custom syntax. I've re-read parts of 60 to see if we can build something like that on pubsub, rsm or mam but it doesn't seem to be the case. Not without either being super hacky or having massiv overheads
kokonoehas left
Daniel
I mean you don't actually want to get pubsub notifications from MAM. Not if your desire is to safe bandwidth
mukt2has joined
Ge0rG
Can a smart server aggregate those?
Nekithas left
kokonoehas joined
Daniel
Well I guess it would be fake mam in practice. Because you don't actually want to store the individual notification messages. It would just use a time stamp as a replacement for a version identifier and the your server would play out the notifications wrapped in pubsub wrapped in mam to you
Daniel
But that's not worth the overhead imho
kokonoehas left
Daniel
Compared to a custom syntax that would probably work more similar to how roster versioning works
wurstsalathas left
lumihas joined
kokonoehas joined
lumihas left
Nekithas joined
lumihas joined
kokonoehas left
ralphm
But you can also use RSM directly on pubsub?
Daniel
ralphm, that won’t give you the deletes
Daniel
also what is your after id
Daniel
if id (like in bookmarks 2) is the jid
ralphm
Right
Ge0rG
Can we generalize that into something to properly synchronize multi item PEP / PubSub?
Zash
pubsub since?
Ge0rG
I have no idea
Zash
https://xmpp.org/extensions/xep-0312.html
kokonoehas joined
ralphm
That also doesn't send retracts.
ralphm
Problem is that PubSub is not designed to store retractions.
Daniel
and it's time based…
ralphm
So servers don't (currently) have that information.
ralphm
Daniel: yeah, that's not ideal either
Ge0rG
Can we design something new around MAM then?
zachhas left
zachhas joined
ralphm
What MAM really means in pubsub has been debated before, but I don't think there's been a conclusion:
ralphm
a) you expose item storage as the archive
Daniel
a) you still don’t have a good ID for use in after b) syntax wise that would mean pubsub notification inside forward inside mam results (=massive overhead)
ralphm
b) you store the notifications as the archive
Daniel
and the ideas with the deltas is to avoid overhead
ralphm
a) clearly doesn't help for this.
j.rhas left
ralphm
And by the way, you could have a mode where replays are *not* enveloped in forwarded.
j.rhas joined
ralphm
But item or retract directly in result.
ralphm
But I'm not sure.
Daniel
i mean what you really want is 'replay me events since x' and then you just get vanilla pubsub events; without any wrapper
Daniel
but at that point you are so far away from what pubsub can do that it is probably better to just use a custom syntax for that
Ge0rG
And x should be an ID, not a timestamp
ralphm
Daniel: maybe, but then how to differentiate between life events
ralphm
Ge0rG: yes
ralphm
Live events
Daniel
do you have to? roster versioning doesn’t use anything different for live events
And you don't get new events until you send presence, no?
Ge0rG
Isn't it all in one iq response?
Daniel
no you send ver to server. server sends you result (empty) and then a bunch of pushes
Daniel
and pushes are of the same syntax like normal pushes would be
Ge0rG
Okay
ralphm
Ah, right
Ge0rG
But it does have merit to know when it's over, at least in a new design
ralphm
But we currently don't have notification ids
ralphm
For pubsub
Daniel
yes
Daniel
that what i mean with "by the time you have hacked all that in you are probably better of just doing something custom"
ralphm
Roster versioning has strictly increasing version numbers, right?
Daniel
the xep doesn’t say i think
ralphm
4.4
Ge0rG
ralphm: strictly opaque
Daniel
i think there are cheap implementations where they just use a hash; and on reconnect if the hash doesn’t match anymore you just get the entire thing
Ge0rG
Yay.
ralphm
Right, and otherwise strictly increasing
j.rhas left
Ge0rG
Still, I'm sure the general problem is worth solving
ralphm
Yes
Daniel
i mean pubsub notifications having an event-id/version-id and then being able to say give me all events since version x would be nice
ralphm
Yes, that seems doable. Besides probably having to redesign storage in implementations. 🤣
adiaholichas joined
mukt2has left
mukt2has joined
wurstsalathas joined
zachhas left
zachhas joined
mukt2has left
mukt2has joined
remkohas left
kokonoehas left
kokonoehas joined
zachhas left
zachhas joined
mr.fisterhas left
mr.fisterhas joined
remkohas joined
kokonoehas left
archas left
archas joined
lumihas left
debaclehas joined
j.rhas joined
vanitasvitaehas left
zachhas left
zachhas joined
vanitasvitaehas joined
winfriedhas left
zachhas left
zachhas joined
APachhas left
gavhas left
jabberjockehas joined
zachhas left
zachhas joined
remkohas left
derdanielhas joined
zachhas left
zachhas joined
remkohas joined
adiaholichas left
APachhas joined
derdanielhas left
kokonoehas joined
APachhas left
zachhas left
zachhas joined
kokonoehas left
j.rhas left
j.rhas joined
kokonoehas joined
remkohas left
mr.fisterhas left
mr.fisterhas joined
remkohas joined
Dele (Mobile)has left
archas left
archas joined
Steve Killehas left
zachhas left
zachhas joined
mukt2has left
Steve Killehas joined
mukt2has joined
zachhas left
zachhas joined
kokonoehas left
winfriedhas joined
kokonoehas joined
sonnyhas left
andyhas left
kokonoehas left
kokonoehas joined
jubalhhas joined
zachhas left
zachhas joined
jubalhhas left
moparisthebesthas left
moparisthebesthas joined
jubalhhas joined
mukt2has left
mukt2has joined
remkohas left
jubalhhas left
mukt2has left
mukt2has joined
mimi89999has left
mimi89999has joined
mukt2has left
pep.
> ralphm> It would be good to have a list of those and document how such issues are, or are not (yet?), addressed by MIX.
Yes please, can we have a wiki page or something. If I ever take the time to read MIX and attempt giving feedback on it I don't want to repeat what everybody said already
remkohas joined
Steve Killehas left
pep.
> moparisthebest, [..] sorry for starting mix discussion
it's fine, it seems some people (not you) love to jump on the opportunity to push the subject whenever there's a slight relation (or not even) :)
pep.
(that alienates me as much as what Matrix making IRC people's lives harder. Even if they deserve it somehow, let's be honest :))