XSF Discussion - 2019-09-14

> [11:26:06] <Zash> Dear lazyxmpp, I wish for a PRECIS implementation suitable for use in C I need one too

join forces and consider starting one :)

Patch libidn?

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

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.

Right. I'm just trying to figure out if I'm missing something

Daniel, could potentially drain your mobiles battery if I know your resource

(not saying that it isn't possible otherwhise too)

besides that, joining a MUC is an explicit decission to reveal your presence and potentially your resource. Leaks are typically unintentional

Right, but for MUC you could decide to only send availability once and not sync it with your away/xa/etc

As an example

That then leaks less information

To be clear. (our terminology is a bit confusing here) I'm talking about leaking the resource. Not leaking availability

Through MUC?

Mostly Auto responding to certain messages

Daniel, it can be used to scan for accounts

normally we take some care to avoid that being possible unless you know a resource

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

jonas’: vcard-temp and public omemo keys allow that ✏

I think it is about leaking the resource per se

(Scanning accounts)

Remote entities shouldn't know that there is a connected client if they are not explicitly allowed to

andt hen even be able to send data directly to that client

flow, I get that I guess… That is a slightly different argument than leaking the resource (as in that specific string)

Daniel: I agree with you that the leaking is overhyped as a security issue

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

I wonder if Matrix also tried and also got ignored

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.

obviously 2020 is not realistic. but that's not the point. the point is that they seem to be somewhat serious about attempting it

The politicians or the companies?

the politicians

Right

I'm curious if Ge0rG has heard back from his contacts.

ralphm: no news yet. But I'll try to reach out again, I was told to remind them some months in

That article is a good trigger for a reminder, actually

This article seems like a good reason to. Was that contact in one of those parties?

ralphm: I don't think so, he's an employee of one of the agencies

ralphm: I'd love to be able to propose a way forward for E2EE

This is something he was most concerned about

MLS is probably something we need to evaluate properly in advance

> There is a lobby battle ahead Thank you article, I wasn't expecting that.

also no sources to when and where they said this

but who needs sources in 2019

pep.: sharpen your axes, we are going full in

Also curious if governments want 'in' on the conversations.

Ge0rG: the XSF has no resources for this kind of battle. Companies using XMPP would, more than us already anyway

that's only a problem if you believe that democracy is about who can bring the most resources to a battle

I believe that's a harsh reality

Companies are people now, in some jurisdictions, so arguably the are part of the demos.

maybe we need to go the indirect route and convince 'our' lobby groups (CCC, FSFE, …) first

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

Daniel: that might help. EDRi also maybe

I was also thinking about IETF

ralphm: is IETF a political lobby org?

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

i don’t think the IETF is a lobby group in the sense that the CCC is one

Daniel: can we put up a talk for CCC about this?

IM interop? yeah i still have one in the pipeline for the 'privacey week' but they haven’t accepted it (yet?)

What do we know about it already? Maybe we should also contact matrix

the idea was if it goes well at privacy week i'll do the same one at ccc

Ok

Ge0rG: no but they, under ISOC, might have ideas on how to approach this.

And I'm not surprised at all about FSF(E)

I hear FSF/FSFE can be quite different btw, I haven't experienced that myself though

Maybe we need to find someone else from the FSF then?

Yes, there's also recently been considerable friction between them

And I think neither cares about protocols

Anyway, we need to act now.

I guess this kind of talk at POSS will fall in deaf ears

maybe i should try calling those two people

Daniel: keep us up to date please. I'm going to write to the ministry employee early next week

I need to figure out what point I'm trying to make and how to get that across

Daniel: "please keep moving this, good work! Demand open standard APIs! Hire me to make E2EE work!"

> 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

Ge0rG, Daniel: https://www.theregister.co.uk/2019/05/28/german_government_encryption/

Maybe they are excluding open standards on purpose

Now, what did I say?

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

*GIRL CRY*

What you don't trust the govt with everything? I mean in all the history of the German gover... Oh right...

Don't mention

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.

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

right. because nobody has ever created standardized encryption before that works across different providers and vendors

Daniel, we don't even have it within a single network, how should that work across networks?

We have about 5 different e2e-encryption standards implemented by clients in XMPP

(only counting those in well-known open source implementations)

And it makes sense to have multiple, because they have different properties.

And also, you'll probably want the ability to upgrade to newer/better approaches in the future.

and six part time open source developers not being able to agree means that you can’t do it?

Even TLS is a monster of different encryption protocols. It just works because connections are short living and only between two entities.

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.

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

Not by all major clients, just by a subset for a specific niche (personal im)

But omemo is from the end-all-be-all, though.

Also larma TLS is just for short lived connections????

Are you talking about something else

And I purposely turn it off because it invariably fails to work properly with my collection of multiple clients.

Have you seen a TLS session running for several months as do OMEMO sessions?

Yes

Huh?

XMPP s2s connections would

Zash, several months? I hope you install updates, don't you?

Wait until you hear about quic where sessions can survive reboots and network changes etc

I've been mentioning (IETF) QUIC a couple of times.

I think it definitely deserves an experiment to have an XMPP binding for.

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

larma: that's besides the point. and there can be months between updates to the servers or tls library that would mandate a restart

ralphm: yea and I suspect you could do away with stream management inside quic too

Daniel: to be honest, I would already settle for just the XMPP based federation, even without e2ee.

moparisthebest: but it might be useful for file transfer

Yes as long as they don't also ban e2e in the process

Oh, I get what you meant, sorry. Yes, definitely.

Cause as you said that can just be done over top of federation later

Right

moparisthebest: and about QUIC, yeah, there are quite a few benefits.

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

I guess I will be able to find a set of 5 TLS clients/servers that don't share a single common cipher compatibility

So maybe you have Rock solid e2e between 2 entities and not as good in group chats?

In fact that's what we have

Is your point don't bother at all or?

i don’t get why "it's going to be difficult" is an argument for "let's not even attempt to try this"

Also lessons have been learned from TLS, not everything should be an option etc, have you seen 1.3 ?

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.

It vastly limits options, and http2 requires a specific cipher for instance

> Daniel > > i actually tried to talk to a representative from the FSFE about that > Who did you talk to?

larma: right, and the voices against omemo didn't matter did they? All main clients support it

larma, the guy who gave the free your android talk at gpn

It's not perfect, but perfect is the enemy of good, and it's good

moparisthebest: except omemo is only about text

Right, so it covers 95% of the use case for IM then? Great

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.

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*

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.

And another indeed groups and MAM.

We do indeed have 20 years worth of experience on federation.

And I would probably be a bit sad if for groups we'd have to settle on MUC.

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

Calling

Yes

> 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

Right. My reservations around e2ee are orthogonal to attempting to get services to federate.

+1 Daniel

Actually group chat is a really good example

Everyone agrees it's hard, everyone agrees muc isn't ideal, still how many years later here we are

We rather should try to support the involved law makers in ensuring that things aren't botched from the start.

Mix is an attempt to make it more perfect, where is that

moparisthebest: in progress

And I'd love to have it sooner rather than later, but some of it is not easy

I'm just saying it would have been silly to have avoided muc forever while waiting for mix

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

moparisthebest: sure

Which is essentially what the "e2e is too hard" argument is

Daniel: I mostly draw it up to ignorance, which is ok

ralphm, maybe. but how can we make progress in that situation

moparisthebest: no, MIX is achievable. I don't know about e2ee.

Ignorance is also what I've experienced when trying to improve MIX. 🤷‍♂️

I mean, I'm not discouraged by people looking at and going AARGH

ralphm: except the opposite has happened in practice, we have working e2e, no working mix though

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

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.

ralphm: did you write your suggestions to standards@?

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

So various ideas there are solid, some need work. I'm going to take some time to look at that in the coming weeks

ralphm: write a blog! 😉

Ge0rG: I might

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"

moparisthebest: as I said, I always disable e2ee because it doesn't work for me. Maybe it is just me.

So that a path of small improvements of what's there already is working out better

Ge0rG: but they do for each inventing their own

Even if we are bound to end up in a local maximum.

ralphm: I also always disable E2EE.

ralphm: none of those parties have provided reasonable specifications yet.

My point is that I don't buy that argument

(from them)

ralphm: I was mainly talking about the OSS implementations out there.

Sure, that's a valid point

And as MUC isn't going anywhere, it's worth fixing it.

Doesn't change the fact that omemo "just works" for the majority of people

I have no metrics to make that argument

moparisthebest, ejabberd has a partial MIX implementation in the current release

Most people don't use as many clients as you do etc

I’m going to start a MIX implementation in aioxmpp against that

Most people just have a phone only, the ones that have a desktop also use a client that supports it on there

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

so it does’t have to go away

Again, not perfect, but good, waiting for perfect gets you in the waiting for mix forever mode

however the "private group chat" can easily be switched over. and will also benefit from what mix has to over

*offer

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.

I'm still not convinced that MIX is solving all the known technical problems of MUC.

Like?

i kinda wish someone would address my MIX feedback so i could move on implementing it…

or even invite me to do a PR i guess

ralphm: my pet issue is message loss during s2s interruptions

It would be good to have a list of those and document how such issues are, or are not (yet?), addressed by MIX.

ralphm: I don't remember my other points raised around 2016.

Daniel, you got a +1 and no -1nes on the PEP node thing. Please just do a PR

Ge0rG: yeah, that needs work

not sure where Steve Kille is

Enjoying his weekend?

that might be a tiny bit undeserverd but I never got the impression that MIX is welcoming to PRs

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

ralphm, for three months?

Daniel, true, in a way

As I said, I'm going to try and dislodge things

Daniel: not just PRs, but any kind of change requests?

Daniel, FTR, I added a +1 to that thread, maybe that gets it rolling again

ralphm: feel free to make a list from what was written on standards@ over the last years

one more than the other maybe

Ge0rG: various comments I raised have been addressed by Steve last time around, though.

And after that I was less involved, so didn't follow up

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.

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)

I wouldn't mind at all if somebody else did it.

Understood. Time is precious. But I do have some, so am going to use it for MIX

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

Daniel, all of what you say sounds excellent

ralphm: > ralphm: feel free to make a list from what was written on standards@ over the last years

and MIX-PAM will automatically send presence to all the items

Daniel, if and only if presence is enabled for that MIX, IIRC you can turn that off?

(that type of metadata should maybe be included in that PEP node?)

Daniel: I am not following. What are you talking about?

yes… so a client would have to be able to modify that paramater

Daniel, wouldn’t that work via the existing PAM/MIX-IQ-flows? ✏

jonas’, i would have to look into that again

let’s start it simple though

Daniel: weren't there issues with multi item PEP?

ralphm, moving channels out of the roster

Daniel: I missed that was an issue. Can you explain why that is a problem?

ralphm, didn’t you raise the same issue during the summit?

ralphm, https://mail.jabber.org/pipermail/standards/2019-June/036172.html

mostly because it is mixing concerns

i might not want a roster

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.

ralphm, servers need to know about MIX anyways, that’s '405

Daniel: not having a roster indeed is a good point

And I did raise that.

i remember that

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.

Thanks for bringing that up again.

i also see virtually no argument in favor of putting it in the roster

and a lot of (some bigger than others) arguments against doing that

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

Ge0rG: wait huh?

Also you might not want automatic presence delivery to all rooms, but this is a minor issue.

Ge0rG, the 2016 design still had only those MIXes where you’d send presence in the roster

jonas’: which is also bonkers, because how do you know of the others?

yeah

I remember the bad things that happen if you add a MUC to your roster.

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.

s/bad/fun/

jonas’: fun for an outside sadistic watcher, yeah

ralphm: it would also require roster annotations to be inside the respective room elements to know those are not people

😈 ✏

Ge0rG: I disagree with that point

Because, surprisingly, a client needs to know that when opening a chat window

ralphm: it's not a MUST, but the alternatives are worse

Hmm

Say, disco#info to all roster entries after connecting.

Or doing that right when while opening a chat.

And caching it.

not just opening the chat. but take the simple task of learning what channels you are joined

Obviously CAPS are in issue for this.

An issue

because when starting the client you might want to have open tabs for all channels

how would i do that if the roster items are not annotated

Daniel: right

(something about inbox)

Heh

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.

also you might want to learn what nodes you are subscribed to for a specific channel

in MucSub there is a get me my 'channels' command. and then each items lists the nodes

*currently subscribed nodes

ralphm: making the UI depend on another roundtrip is a horrible idea. What if you just lost your network connection, or are on EDGE?

Sure, I see that argument, but once you know it is a MIX Channel, that's forever, likely.

ralphm: think of thin clients.

Daniel: having to query the full list all the time is an issue, too, so you need some versioning there too?

or web clients, for that matter

Do they have to store a local list of MIXes now?

also MIX-PAM already has those annotations

ralphm: how is all that outweighing a simple child element / a dedicated list in PEP?

I'm not saying it is

Just exploring what's being said here. Happy to see all these points.

ralphm: you said you disagree with that point.

ralphm: I've argued all that back in 2016. It's nice to see we have finally moved beyond it.

I disagreed that it has to be in the roster

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

Ge0rG: sure, to get anywhere we need to reevaluate all of it

ralphm: please do, and blog it.

Yes, sir. 🤣

ralphm: or make a spreadsheet of problems and their respective solutions

Because I'm honestly tired of arguing all that, over and again.

I definitely want this to be easy and thin.

E.g. I think having to ask every channel for MAM is not good.

Vn.

ralphm: I agree with the general idea. Just ping me once you've taken over authorship... 😉

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)

Daniel: it sounds sensible to me, but I haven't really worked with PEP, so don't know the pitfalls

(note that servers could implement it as a virtual pep node)

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

Daniel: might work, indeed. Was just mostly interested in the issues, rather than looking at possible solutions.

the only pitfall I see is that it might not scale to enormous numbers of channels

jonas’: I'm curious what is enormous

can you RSM through pubsub items?

Yes

Daniel, in theory, yes

so i don’t see the issue

ralphm, anything which breaks the stanza limit

Daniel, you have to fetch the channel list on each reconnect, don’t you?

Can you receive a delta of all PEP changes, given a certain initial state? From MAM?

that's why it is multiple items

Daniel, but if those are 1k items, the fetch will still be annoying on each connect, especially on mobile.

also if you are afraid it will break your stanza size limit it will also break your roster fetch

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.

My daughter uses WhatsApp quite a bit

Many many channels

None of them ever closed

(though many go unused)

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.

so the argument against PEP would be that we that we don’t benefit from roster versioning

ralphm, the PEP node is read-only to the client

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

it would at least make roster versioning much more complex on the server side

i'm not overly attached to PEP. i just don’t like to use roster

Aye

ralphm, there would need to be some kind of subscribe to changes mechanism. and +notify would _one_ solution to signal that

Right.

also reusing syntax. my client might already have PEP notification handling

> Can you receive a delta of all PEP changes, given a certain initial state? From MAM?

Ge0rG, there are rumors about MAM for PubSub

that probably doesn’t help you with PEP

jonas’: you can't implement a rumor

Just to be clear, this is hardly PEP, but node-on-account, but I digress.

Whatever it is, I want a delta mechanism.

jonas’: without MAM for pubsub, I'm unsure how we could do other nodes in MIX

Ge0rG: noted

> Just to be clear, this is hardly PEP, but node-on-account, but I digress. fair enough

#undef PEP #define PEP PubSub-on-user-accounts

PEP Plus

XEP-0222, XEP-0223

But but

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?

are those four tasks close enough to pubsub to justify borrowing the syntax

or is it better to create own syntax for that

Daniel: receiving actual deltas if you were offline for some weeks

Daniel, provisions which would allow us to introduce versioning later

ha, what Ge0rG said

I'd not put in a PR at this point. Rather reiterate the issues and requirements.

ralphm, the issues have been re-iterated on the ML since 2016

nobody has objected to Daniels bringing it up three months ago

I think we can move forward with proposing an update to this *Experimental* XEP to finally achieve some progress

it doesn’t have to be a PR. and i'm happy not having to create one

Ok, if you don't want to wait for me, maybe it'll work.

but i would like to get to a point where i'm not being ignored

ralphm, what timeframe do you anticipate? MIX has been "waiting" for years now.

ralphm, wait for you? what are you planning to do?

a few more weeks probably won’t hurt if you’re going to do an in-depth evaluation which might actually move us forward

what Daniel is saying, effectively

I have time on my hands and will try and dislodge the whole thing

my dictionary does not list a sensible (in this context) translation of `dislodge` ✏

Get it unstuck.

I see

I'm sure the underlying conditions have changed significantly since I tried the in depth evaluation.

ralphm, I don’t mean to attack you. It seems just frustrating to re-iterate all the arguments we’ve had yet another time.

Consider the discussions on MAM2 in light of MIX.

which reminds me that certain Reactions-interested folks also don’t feel heard with their feedback on XEP-0422

jonas’: well, I don't think you have to. I'll try to dig things up.

jonas’: I still owe responses to people reacting to my post. Anything specific you mean?

all in https://mail.jabber.org/pipermail/standards/2019-September/036422.html

Right.

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

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?

ralphm, I carefully chose my words to say "feel"

seems like a lot of companies in the past have gone down the second road. P1, erlang solutions, redsolution etc

I understand as well as anyone that volunteer standards process will have delays and everything

ralphm, I’m not sure how we can fix this, but this is in a similar vein as what Daniel says

Yep, this stuff is not easy. Some people want something now because they have business constraints, and some others have other priorities.

I'm not opposed to companies doing their own private thing in the meanwhile.

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

as opposed to what some companies are currently doing with "let's develop our own XEPs"

Well, doing your own is a valid choice if you have internal pressure and don't require interop.

you say "in the meantime" as if they were coming back once MIX is done. but i highly doubt that

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.

Daniel: I'm not sure how to help that other than my offer to move things forward.

So in the short while that is fastening/references and MIX

I also have opinions on calling, but I don't want to overcommit.

And larma's comments are valid, so I'll try to get to that next week.

> 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

I mean you don't actually want to get pubsub notifications from MAM. Not if your desire is to safe bandwidth

Can a smart server aggregate those?

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

But that's not worth the overhead imho

Compared to a custom syntax that would probably work more similar to how roster versioning works

But you can also use RSM directly on pubsub?

ralphm, that won’t give you the deletes

also what is your after id

if id (like in bookmarks 2) is the jid

Right

Can we generalize that into something to properly synchronize multi item PEP / PubSub?

pubsub since?

I have no idea

https://xmpp.org/extensions/xep-0312.html

That also doesn't send retracts.

Problem is that PubSub is not designed to store retractions.

and it's time based…

So servers don't (currently) have that information.

Daniel: yeah, that's not ideal either

Can we design something new around MAM then?

What MAM really means in pubsub has been debated before, but I don't think there's been a conclusion:

a) you expose item storage as the archive

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)

b) you store the notifications as the archive

and the ideas with the deltas is to avoid overhead

a) clearly doesn't help for this.

And by the way, you could have a mode where replays are *not* enveloped in forwarded.

But item or retract directly in result.

But I'm not sure.

i mean what you really want is 'replay me events since x' and then you just get vanilla pubsub events; without any wrapper

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

And x should be an ID, not a timestamp

Daniel: maybe, but then how to differentiate between life events

Ge0rG: yes

Live events

do you have to? roster versioning doesn’t use anything different for live events

Race conditions and sync are not fun

seems to work for roster versioning

do i?

With roster you know when the sync is complete ✏

And you don't get new events until you send presence, no?

Isn't it all in one iq response?

no you send ver to server. server sends you result (empty) and then a bunch of pushes

and pushes are of the same syntax like normal pushes would be

Okay

Ah, right

But it does have merit to know when it's over, at least in a new design

But we currently don't have notification ids

For pubsub

yes

that what i mean with "by the time you have hacked all that in you are probably better of just doing something custom"

Roster versioning has strictly increasing version numbers, right?

the xep doesn’t say i think

4.4

ralphm: strictly opaque

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

Yay.

Right, and otherwise strictly increasing

Still, I'm sure the general problem is worth solving

Yes

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

Yes, that seems doable. Besides probably having to redesign storage in implementations. 🤣

> 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

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

(that alienates me as much as what Matrix making IRC people's lives harder. Even if they deserve it somehow, let's be honest :))