XSF Discussion - 2019-02-22

https://twitter.com/brunoborges/status/1098472238469111808?s=19

About that recent matrix discussion )

> Pick your markup YAML ain't markup. Netiher is JSON.

Can we stop comparing ourselves to Matrix? Let them be.

YAML. Where MAC address strings become sexagesimal (yes, this is a word. no, it's not a dirty word): https://yaml.org/type/int.html > canonical: 685230 > sexagesimal: 190:20:30

do jids have to be lowercase?

jubalh: no, but IIRC you need to lowercase the bare JID part for comparisons

TL;DR: it's a deep deep rabbit hole... start at https://tools.ietf.org/html/rfc7622#section-3.1

the whole idea of case-insensitivity is broken completely

That's the PRECIS version?

putting it on servers is the worst thing invented

Does anyone implement PRECIS yet?

Zash, not me 🙂

It is indeed a deep rabbit hole, and you will find only sadness at the bottom.

I barely can understand what is written in the PRECIS spec

like some alien wrote that for dogs

Hm? IIRC it's not too different from STRINGPREP

well I didn't read stringprep either, just took a ready-to-use table

I think a problem with PRECIS is that it varies by Unicode version

which is a good idea in theory (no table to go out of data, all the work is done by the maintainers of Unicode)

But in practice it will cause interop problems on the network, as everyone will be using different versions

Didn't that problem exist already?

Also some JIDs that are valid one year will become invalid the next year

Do you remember robot face?

Zash, I think there is a problem with emojis in resources

does it count?

Zash, different issue

Related, but different

Sadness.

Emojis in resources are also Unicode code points which may or may not be supported by a given XMPP implementation

Joining a MUC as 🤖 will make certain clients quit and some servers drop s2s.

And don't even think about sending a MUC message from that nickname

But that's not a problem with the definition of stringprep, is it?

I like how virtually nobody understands exactly why there is a problem with emojis in resources 😀

That was a problem with some library allowing things by default and some others disallowing by default?

I honestly have no idea

Ge0rG, thx

Zash, right

And then there are things like https://discourse.igniterealtime.org/t/smack-disconnects-if-priority-is-out-of-range/73401

Ge0rG, https://issues.prosody.im/921

Link Mauve: what if prosody receives that via s2s? Drop the link?

Link Mauve: what about <show>fubar</show> or the invalid MUC JIDs on conference.jabber.org?

Drop the link and report them to the authorities

Zash, authorities in a decentralized world :P ✏

pep., let's encrypt

True

Ge0rG, fix the emitting server’s software, then use 0157 to tell the sysadmin of the emitting server to update.

And sad at the same time

pep.: Our one true glob, ICANN

Error> No Contact Addresses for jabber.org

Zash, We need blockchains, namecoin!

pep., I consider this as a natural limitation, like a CAP theorem for example, you cannot do anything with it

seems like nature decided "you cannot go fully decentralized, muahahaha"

pep.: Someone will just end up with 51% of the power

yeah, the Byzantine Generals theorem sums it up clearly

And in practice it's not even 51 but less than that :/

1/3 afair

according to the Byzantine theorem

hi kids

hey there

could Ge0rG and jonas’ confirm/deny their vote for PR #744 -- -1 (as-is, +1 with "thereby taking up the role of XEP author" removed)

> https://issues.prosody.im/921 Zash heh, we don't validate that in ejabberd, I added the check, but then reverted because there was a lot of scream

zinid: What kind of check?

Zash, [-127, 127]

zinid: And what kind of action?

-128*

Zash, back then there was a lot of nerdy clients which allow a user to set any priority, so some of snow flakes set it to 666 or 1024

I mean, did you reject them or rewrite into that range?

Zash, reject with stanza error (not stream)

There's a setting in Prosody that rewrites all presence priority to zero, which don't think anyone has had all that much truoble with.

I can fix it instantly since the check is in a single place, that's a one-line commit, but I'm not sure

I’m at work right now though and won’t be able to clarify until tomorrow

I think that priorities are an outdated concept.

So best value is zero.

okay, no problem

Andrew Nenakhov, yeah, that's why I started the discussion now

👍

theTedd: IIRC the introduction of the shepherd was an accepted solution in the council meeting two weeks ago?

Andrew Nenakhov, if priorities are kinda meaningless nowadays, it's better to be RFC compliant in order not to confuse other implementaions

I was just checking whether the changes satisfied your voting condition

zinid [13:16]: > Zash, reject with stanza error (not stream) And if you received that from a MUC participant, you get yourself kicked?

theTedd, in the end, the vote on #744 (if I’m not mixing things up) by council is informational only, anyways.

Ge0rG, MUC what? I just merged MIX into ejabberd 😀

zinid, we set them to zero by default and are thinking to make in non changeable.

Andrew Nenakhov, yeah, that's fine

Ge0rG: Something something liberal about what you receive, except ugh

zinid: ah, then you can `git rm mod_muc.erl` now

Ge0rG, sure I'll do after mod_mix_muc become a thing(y)

jonas’, meaning the PR is accepted or not?

theTedd, board voted on it

one would have to check board votes

I have a nerd use case for negative priority, because my main client can't mam and I don't want to consume messages with the other clients when the main one is offline.

jonas’, so what was the council vote for?

theTedd, to give board an idea on what we want

*if I recall correctly*

So priority should be in (-1, 0)

jonas’, understood

Zash, True/False?

I'm +1 on 744, but it's not formally binding

Ge0rG, thanks

Alternatively, don't send presence.

Zash: did I mention "implementation defined message routing rules" yet?

Ge0rG: mod_firewall with an xmpp interface next?

Something's gotta replace privacy lists!

by privacy lists!

Replace RFC 6120 with mod_firewall?

and the open decentralised comms community might do better to support each other than try to stab each other in the neck...

Agreed. There is a history of splitting efforts nonetheless in the free software community, and that's meh

Matthew, really, so you think IM fragmentation will help fighting with silos?

does this conversation look fragmented to you?

+1 :)

Matthew, what are you talking about?

zinid, he's probably joined from matrix :)

pep., wow

i am. talking from one open network to another

albeit by a bridge

Matthew, so your suggestion is to build many IM networks and connect them via hacky gateways?

dude, I wrote gateways to MSN, ICQ, AIM and Yahoo back then

so I will never buy the argument, I know how shitty they are

I'm saying that it's healthy to experiment with new approaches in any field or technology. Perhaps the new stuff works; perhaps it doesn't; perhaps it dies off and gets incorporated elsewhere. And yeah, i think it's great when people experiment with new networks - e.g. Briar and Cwtch and stuff are insanely cool.

please, spare my time

and yeah, bridges are never going to be perfect, but at least we have the option

and empirically they work well enough for a convo like this.

"new approaches", lmao

zinid, Matrix is a pretty different model to XMPP, so yeah

I happen to personally prefer the XMPP model, but I have nothing against people trying others :)

sorry, I cannot reply to you, you're not joined 😀

zinid: i'm not trying to waste your time; just pointing out (objectively) that being grumpy and "how dare people try to build new IM protocols" all over HN does not reflect at all well on the XMPP community

Matthew, I don't represent the community

i somehow doubt your audience sees it that way.

Matthew, remind me to buy you a beer.

Guus: i will come claim chimay next year in brussels ;P

Matthew last month, I discovered something called "beer mania" there. I'm not to worried. 😃

Building matrix is nih syndrome. Makes sense from business perspective though

Andrew Nenakhov even if that were true - point that out over and over and over and over and over again does not do anyone any good.

Andrew Nenakhov even if that were true - pointing that out over and over and over and over and over again does not do anyone any good.

And probably makes the one doing the pointing out looking worse than the one being pointed at.

if everyone agrees with everyone, what's the point of the discussion?

And probably makes the one doing the pointing out look worse than the one being pointed at.

I personally agree with Andrew Nenakhov - this is technically speaking NIH

and I'm the last guy to blame as XMPP diehard, ejabberd supports XMPP, SIP and MQTT (since 19.02, coming next week)

and we considered implementing Matrix btw

XMPP was IRC NIH'd with XML. I suspect some still feel that way.

waqas, true, lessons learnt

IRC is NIH'd multiplayer notepad.

There are a few xkcd's that apply

my point is that it's fine to prefer XMPP over Matrix (I do) - but let's not continue a pointless argument over it.

anyone who agrees, please enlighten me what's the point in producing many IM networks and building gateways

As a user, I suspect many of us think of UIs and not underlying tech. With that mindset, the point would be improved UIs (since I personally feel all of them range from mediocre to annoying).

well, I'm not a user here

and Matthew asked to stop fighting or something, did he asked the "users"?

zinid, what's the point of any software development? You know ejabberd wasn't the first jabber server...

Some time ago when I was young and stupid I thought that xmpp transports is a good idea to bring more people on board

MattJ, there is a difference in producing software and standards

I don't know why git exists when we were happy with rcs, etc.

Andrew Nenakhov: Have you stopped being young and stupid? :)

Now I know that it just strengthens silo's network effects

waqas, nice ad hominem 🙂

Yes, now I'm significantly more experienced. )

Also, youth is a trait that you inevitably lose.

The effects of transports are interesting. I still believe in them in that they strengthen the network that has them.

From what I feel, bridges are just usually used by people who do not want to be in the silo, and they are a minority. But I'm no expert on the topic.

waqas, I don't believe in them (I used to)

I think they weaken XMPPs network effect

They're 9 times out of 10 a far worse experience than the native one

Yes, and that's the problem ^

IRC is the 10th time. :p

Something something lowest common denominator

so we think this time we will solve the problem with transports

Link Mauve, ...

:D

Link Mauve, XMPP->IRC->Matrix is how I've been in Matrix rooms for some time now

I believe XMPP as a technology had been a low level features that the IM networks of last decade had. That's why transports could do a reasonable job at the time, and I did use them with MSN/Yahoo/etc. That's no longer true for IM networks of today.

Works pretty well usually

MattJ, I guess so.

My point was more that IRC is a terrible user experience out of the box, and that gateways are almost always an improvement over it.

Link Mauve, sure

The XMPP network effect isn't being particularly helpful these days, as I think the proprietary platforms' network effects are an order of magnitude stronger than any of the non-proprietary ones.

XMPP, network effect?

What's that

pep., the thing that saddled us with the Pidgin users

Haha

Matthew, well played, I see you've started another meaningful discussion :P

MattJ: To clarify, do we want the pidgin users or not?

pep., +1

Pidgin provides such poor XMPP experience, that it's chasing the users away.

started and hides

+1 to Guus, I could feel that in my own skin at FOSDEM

people making statements that weren't true

based on their experience using Pidgin

waqas, we want the users, we don't want pidgin

so we will also build voip gateways to SIP, i.e. Jingle<->SIP

and Jingle<->Matrix

do I understand correctly the postion?

what else?

gotta pick up the kids. ttyl

what a waste of human resources...

whut? My kids?

That's not a nice thing to say zinid

Come on guys :D

wut? I didn't mean to say anything about kids

relax guys

zinid, sarcasm.

wtf is wrong with you?

I was joking 🙂

(well, trying to, at least)

ok, off with me. Later

oh, Matthew decided to continue debating with me at HN

zinid: can you please add to all your public statements a sentence that you are not associated with the xmpp community? 😁

What does that mean to be associated to the XMPP community

pep.: I'm speaking of this Matthew [17:09]: > zinid: i'm not trying to waste your time; just pointing out (objectively) that being grumpy and "how dare people try to build new IM protocols" all over HN does not reflect at all well on the XMPP community

zinid, could you share the link to the discussion, please?

Seve, no

It doesn't mean anything to us in here.

I did this like 10 times today already

> how dare people try to build new IM protocols indeed, how dare whatsapp building IM protocols. But let's fight with them!

just contradictions in every sentences

Seve, https://news.ycombinator.com/item?id=19216527

Thank you MattJ, very appreciated

KDE community also created a matrix server. They said that there was no foss replacement for IRC and now there is

FUD, FUD all around

mrDoctorWho: XMPP is also a good replacement

mrDoctorWho, I have some @kde.org people in my roster. :p

In my XMPP roster.

> mrDoctorWho: XMPP is also a good replacement But people don't unterstand

j.r: I totally agree with you

I haven't read their announcement yet, but I feel they already had a decision before even looking up for solutions/alternatives.

relax, we have gateways 😀

Hey, sometimes you just want to make something new, and you feel it's different from what's already out there

I'm not sure I've ever seen anyone succeed in trying to stop people from doing that, despite many wanting to

honestly I don't really have a problem with competing open protocols, that's how you narrow down to the best one, it'd be pretty crazy to think XMPP is the best there will ever be

so?

Matthew started with "let's just define our enemy", how does that relate to building something new?

it's the closed ones that trap users with lock-in that I despise

personally I still like XMPP best from what I've seen so far so you don't need to boot me from the XSF :D

zinid, I don't really know what you like about XMPP, to be honest

zinid, to me, I value users being able to choose the client and service that they use, and service operators being able to choose the software they use

I don't particularly value the XML, or any of the other stuff (which I assume you also don't)

MattJ, I don't value XMPP quite high honestly except it being a standard

MattJ, yeah, I also value users choosing their phones by what battery connector it has

If Matrix wants to do their own thing, but also bridge to XMPP, I don't see how that's a problem

It's more choice for users, and service operators

I also would love the situation when every fridge has it's own power supply

It would be bad if it wasn't bridged (which it wasn't for a long time), but that is changing

and when you have a fridge from Samsung you cannot store stuff in the fridge of your relative's Phillips

From the goals and values perspective, Matrix aligns pretty closely with XMPP. More than any other attempt at "free as in freedom" communication networks around

that's a true choice and freedom for users

well I disagree

Maybe you don't realise the goals and values of the original Jabber project

which were pretty much identical to Matrix today

I don't care about original goals, please again note I like cooperation via standardization, not a competition

if you think that competition is always good then go compete for food with your children

And that is one thing that actually annoys *me* - that Matrix folk say "we're all about bridging though!", which is *exactly* where XMPP's roots are too

zinid: I'm a bit confused, can you point out the the main thing you disagree with?

But that's just a difference of perspective

MattJ, same here

(re bridging)

I don't go ranting on HN about it, and I don't bash their project, and I love to see the collaboration happening

MattJ, the point is they don't want cooperate

I don't know what silo you are living in, but that's not true

They are cooperating

what silo I'm living in...

gosh

zinid, if they wanted to cooperate they would just work with XMPP, you mean?

I mean, they are right in this XSF MUC

Seve, yes

Seve, I don't see anything that stops XMPP from implementing that crazy distributed thing

that's the only "advantage" I see, at least what they *now* claim

zinid, if XMPP started today, it wouldn't use XML I'm quite sure

MattJ, so let's change the wire format, I suggested that in 2006 IIRC

and XML isn't even one of the things I dislike about XMPP :)

I'm just saying, new projects aren't forced to use old stuff

abstract data structures from encoding. BTW, Matrix doesn't do that so it will be "outdated" in a next decade

They are bridging, and that's pretty much all I care about, so we don't produce fragmentation

MattJ, are they going to bridge Jingle? Our new brand stuff whatever it is?

zinid, why not? If XMPP is so successful, they only have to lose by not bridging to it :)

lmao

it will be definitely successfull when every HN user claims it's so bad in comparison to Matrix 😀

Just so you know, HN isn't representative of the general population

I knew you say that

Whether the people on HN favour one thing or another isn't a good indication of reality, or whether X is better than Y

so, XMPP will be definitely successful, that's only the way to get Matrix bridges?

so you bet on it?

There are Matrix bridges now

I know, but I asked about what will be next

You mentioned Jingle specifically - I don't think Matrix has user->user calling fully sorted out yet, but to be honest neither do we (look at clients dropping Jingle support recently)

yeah, I mentioned Jingle for a reason, it's just a classical example of wheel reinvention

Peak Jingle was when the N900 was a thing

and it had built-in XMPP and Jingle calling out of the box, and it just worked

anyway, Jingle is just an example

let's not change the discussion subject

Sure, but what else? The discussion was the bridging, which I think is a core part of this debate

let's say we go MIX

If a good quality bridge exists, the fragmentation argument is not an issue

MattJ, what about we go p2p?

if, if, if

Treat the bridge just like any of the other clients we have to convince to implement MIX

that's more people to convince

And we already have Xabber which never will (perhaps), and so on

(Talking about jingle, I found that a few days ago: https://blogs.gnome.org/danni/2010/06/07/muji-multi-user-jingle/)

so we will have nothing new?

so let's figure out MIX and then decide whether it's worth Matrix bridges supporting it, eh

Like I said, if we do cool stuff that works, it's in the best interests of Matrix to bridge that stuff

if?

if, probably

If we don't, XMPP is pretty irrelevant and Matrix can drop the bridge and everyone can just use Matrix

you see, that's the main problem with gateways, you add another element of complexity

so it's up to us, nothing to do with Matrix

so if they drop the network is fragmented?

So we're back to resources in the XMPP community

They will drop if XMPP isn't worth supporting, sure, why wouldn't they?

I can name many smaller networks XMPP doesn't bridge to, because nobody cares enough

yeah, and we will end up with two IM networks

Some of them are even Standards

two irrelevant IM networks 🙂

because I doubt any of us will attract masses

*shrug*

Not with that attitude :)

that's pragmatism

~20 years and where are we?

and not by fighting with each other on HN, or anywhere

why do you calling this a fight?

Because that's what it looks like, to many people

that's just a debate, actually they try to move the discussion to fight

Maybe you don't intend it to

also, what I'm saying at HN is irrelevant according to you, even you put me in the XMPP community

*even if

and I personally don't "fight" with them elsewhere 😀

It's not irrelevant to the people on HN, I said HN was not a true indicator of anything outside of HN

But many developers are there for example

whatever, I think users will choose the best one, let them decide by reading "fights"

That's what I'm concerned about :)

about what part of the statement? 🙂

that they will choose the best one? yeah, that's what you want, do I get it right?

Because I think you think those "fights" make XMPP look good

or make Matrix look bad

I already said I don't think so, again, I don't care that much, I mostly do that for fun

Many people reading those will just see someone who refuses to accept the new technology replacing their favourite one

something that happens all the time on HN...

new technology... okay

XMPP is 15 years older than Matrix, yes

let them choose matrix, and I will continue "fighting" because I find that funny enough

I also can claim that I'm not the part of XMPP community! In my every post 😀

Anybody can claim anything!

Anybody can claim the person is in the community!

that's a nice ad hominem argument btw

people read that and think "ah, he is from that outdated 20 y.o. XML Cobol taliban", I see

zinid, are you saying that I'm attacking you by saying this?

I'm not. I know you rant about XMPP daily, trust me, I don't think you are an XMPP fanboy :)

MattJ, no you attacked me once by saying I'm living in kinda "silo"

MattJ, why would Xabber implement this stupid mix?

zinid, I apologise, my point was that you didn't seem to be accepting the visible facts (that cooperation between the communities is happening)

It already has something far better

MattJ, that's not very acceptable for us cooperation

If it has some level of muc compatibility it's failure

MattJ, it's like a cooperation with a human and linked dog

us?

oh shi~

Andrew Nenakhov, I don't want to start yet another debate :)

zinid: now you are trolling... 🙄

Andrew Nenakhov, I wasn't judging you for implementing MIX or not, I was just using you as an example of a project that will not implement MIX in a hurry

Moreover unless you read Russian you can't yet MattJ :)

Andrew Nenakhov, FWIW I also have not implemented MIX, and have no concrete plans to

Need specs

Ge0rG, thanks for your thoughtful input

moparisthebest, there are "specs" on the mailing list

i.e. an overview of how it works without the XML parts

I know enough

what I see is that community really falls apart actually, the future direction is quite moot

"community" is implementors and standard writers

zinid, what are we missing in that regard?

zinid: I think it's really awesome that Matthew and Half-ShotX are here and doing meaningful work on bridging the communities. Yes, bridges are imperfect. However, the ugliness depends on the mismatch between the feature sets, and I think the mismatch between matrix and xmpp isn't that large

zinid, the summit this year had great attendance, it had great discussions and I assume we'll see standards and implementation progress this year

MattJ, so what to do with MIX?

Daniel convinced me to implement it

Maybe we can learn something from matrix about reliable message delivery. That's something I have failed to fix in XMPP for a decade now.

Btw, our glorious group chat protocol can be supported at basic level by processing just two stanza types. Or even one.

Adding support is like, maybe an hour.

Of course without viewing participants , etc

MattJ, who will resolve the disambiguation with MIX?

zinid i look forward to the realease, i also want to play with it

zinid, implementers, as always

You potentially already did, by providing the first open server implementation

MattJ, I see at least one here who is opposing

There are always people who oppose, even within communities... that's a fact of life, not the end of the road

lovetox, the branch is merged, the release is next week with 95% guarantee 😀

Rough consensus and running code is how XMPP has mostly operated

A community isn't a group of people who always agree 100% on everything

It's a group of people who generally have similar goals and values

MattJ, I understand there are always opposing, please. But what you suggest is completely stochastic process which I disagree with

What?

like that implemented, this implemented, those two didn't implement

If ejabberd and Conversations implements MIX, that's a huge milestone, no?

It has to start somewhere

Servers will upgrade, and MIX will be supported

MattJ, yes, but I don't see any consensus here, shouldn't I?

whatever

that takes time

you will answer something very general like always

Sure, probably

moparisthebest, that took already 3 years

right, and maybe others will implement soon, not so soon, or never, and then you'll have consensus

so stochastic process, okay

the point is that back then it was not so stochastic, so Matrix indeed looks much better here

zinid, what do you want the XSF to do? Kidnap developers of projects and force them to implement stuff? :)

It'd be effective...

That's a signficant advantage that Matrix (currently) has, agility due to the mostly single implementation and deployment

I think they know that, and are making the most of it

MattJ, I ask the XSF to produce a recommendation

Compliance Suites

no need to go with absurd like kidnapping

MattJ, I don't see MIX there

So that's the recommendation

so MIX is not recommended?

A 2018 XMPP implementation does not need to support MIX

zinid: propose it

Which is sensible given that there is no stable implementation of it currently

Ge0rG, and what will you do? I'm already working on 5 XEPs, so such arguments don't work anymore to me 🙂

zinid: you might still get into last call for 2019

going in circles...

and you conveniently ignored the question about you doing what 🙂

zinid: im not going to implement mix yet

Ge0rG, but you can "propose" something (not sure what)

zinid: send a mail to standards@ and ask for inclusion of mix into compliance Suite 2019

I'm really lost, who can clarify: 1) XSF doesn't produce recommendation without implementations. But constantly discussing something at endless meetings to come to some agreement? 2) XSF is only a standardization body, but it doesn't produce specs 3) XSF continues telling about the mythical community, but doesn't represent any do I get it right? What is it now responsible for? I see only XEP submitting process, which takes a lot of time looking at my own contributions, but that's kinda okay: lack of time, lazyness, understaffed

Ge0rG, and to end up in endless discussions?

like the one I had recently with you: "remove that MUST!!!"

zinid: This is why I think there should be something separate from the compliance suite that describes a vision, what "we" want XMPP too look like in the near future. Compliance suites are mostly about what we think XMPP should look like right now.

Zash, I think this idea will face some opposition instantly

XSF is reduced to XEP submitting process

I see no other value currently

We won't support compliance suites at all.

Cause we intend to drop some xeps that are in it completely

Andrew Nenakhov, what's the point in being so reluctant? Do you think I like MIX or carbons or something?

That not what I'm telling

well it looks like that

you suggest nothing as replacement

But we have that vision you're talking about

zinid, actually we do.

One of the reasons we still didn't release spec for our group chat is cause it is based on some other protocols

yeah...

We call em xep-0XXX reliable message delivery Xep-0RRR Message Retract and replace

reliable delivery again?

Not again. For once.

😀

What's your magical solution

I'm interested

Get server id from destination server. It acts as a recipe and also tells the client a server time. Thus allowing to sync message orders on all parties

Tricky part is making it work with carbons

destination server?

And to account for potential not delivery of some msgs

What does reliable delivery mean to you? Is that message ordering?

Yes, if it's a simple chat between two persons, destination server is sender's server

If it's a group chat, receipt is generated by group chat server

Andrew Nenakhov: just request carbons with a special flag, and then your server sends carbons of your own messages with the server-id

Reliable delivery means ensuring sending client that message was delivered to where it intended to. If not, sender will retry. And protocol must not duplicate messages if retry is attempted.

So the proposal allows strict serializability of messages? Between two full JIDs or bare JIDs or what?

yeah, looks like synchronous call to me

Works for us well.

yeah, I can say the same about current mess with IDs 😀

It's not really complex. As I said,tricky part was carbons and capability to support legacy clients without fuss

Andrew Nenakhov: Is there a link to the proposal?

I can give link to Google doc. It's in Russian though.

waqas, it's in Russian, I tried to read it once 😀

No you didn't.

I did

Also it evolved since that time.

I *tried*

You mentioned server time, does it rely on the server acting as the authority, and using timestamps to order?

waqas, yes.

What happens when there are multiple servers involved (i.e., s2s)?

I would prefer lamport clock and rely on timestamp in the case of conflicts only

What happens when one server has its clock waaaay out of sync?

so definitely I don't like relying solely on timestamps

Reliable delivery cares to only deliver to destination server. Once my message is on my server, I get a recipe, the rest is like normal xmpp

Zash, his protocol assumes the time never goes backward

Andrew Nenakhov: Okay, so this means the client is in sync with its server, but this doesn't try to make all clients in a chat sync across servers. Do I understand that correctly?

Yes, you understand correctly.

Good thing time doesn't go backwards then. Clocks OTOH...

For a two person chats. In group chats ots a bit different

Zash, so you basically should just prevent the server from stopping if you detect backward screw

also, need to store the last timestamp on disc for that 😀

*from starting, sorry

Let me check something...

Tho nothing likes time jumps, most NTP things should be trying hard to do things gradually these days, maybe it's not too much to worry about :)

Zash, yeah

unless you start the server on some crappy embedded device

and if you don't have that protection you will face some fancy side effects which is hard to debug and understand 🙂

so basically, server should go full ACID in timestamp generation

Hard to do anyting if something starts before network is up after some failure that reset the clock to 1970

Well yes that protocol relied on more or less consistent time on authority server.

not sure how this will work in clustering where you cannot guarantee ACID due to CAP

Global transactions!

Have the entire world agree before commiting!

Andrew Nenakhov, what about clustering? Should the nodes synchronize time?

I'm not qualified enough in clustering questions. 😁

well I'm just telling that time synchronization tolerance is a hard problem

But I'm pretty sure that does not have to be part of a protocol.

so we should avoid it in the spec

If servers generating stamps are slightly out of sync it won't have any really bad effects

Maybe some msgs will appear in different order

We treat situations if you send 3 msgs and they arrive on different time and this reordered as ok.

lamport clock anyone?

this is already resolved in 1970

okay, whatever, that's not a drastical change in the protocol

though I think the ID must be generated by a client using lamport clock and formed into a vector clock in a conversation with other party

I think that can be done actually.

Synchronization stops being a hard problem when you accept a central authority, which is what it looks like has happened here

Yes. We postulate that in general sense users server is an authority.

Sync is only hard if you need to figure out distributed consensus for your serializability without a central authority

waqas, which just moves the problem to this central authority

Cause we heavily rely on message archive

central authority can consist of several nodes

and actually MUST

That's why we are getting rid of offline messages, for example

Cause we fetch msgs from an archive anyway

zinid: MUST? The vast majority of XMPP servers today are single node, generally single process, often single thread.

waqas: okay

zinid: Note that I fully agree with you in principle: clustered nodes should be allowed.

But I suspect making things such that it's the server's problem to sync things up between its nodes, and not every single client implementation has to worry or even know about it is the way to go.

zinid, how big can one cluster time difference be?

Realistic estimate? I don't have much experience with those

The answer is it can vary a lot, and there are all kinds of algorithms and software and databases to help you in this area. This is up to the server implementation.

This is essentially the distributed database problem, and there are many distributed databases, and probably just as many approaches to tackling this.

Andrew Nenakhov: in my practice once and it was full of sync due to ntp daemon failure

Well I think that's not really a protocol problem. I like idea of vector time actually, but we didn't include it because we've got too much on our hands already

So for now we settled for the simplest approach

usually clocks are synced very well

sure, not a protocol problem, it will be my problem

okay, I already used to this in XMPP world

we resolve only *your* problems

A XEP should not attempt to solve an implementation's internal details

what if I say I have no problems?

as I server dev I really have no problems you're constantly discussing: mam, ids, routing, carbons

why would I solve your problems when you don't care about mine?

fair question

Hey, we have server developer too, you are no longer alone

I'm a server dev. Ultimately the server was written for end users, and their problems matter :)

I'm a cluster server dev 😀

waqas, what server are you developing?

Andrew Nenakhov: I'm on the Prosody team.

Andrew Nenakhov, none 🙂

currently none

))

yeah, always remember how the XSF community is formed 😀

Evgeny you are a bitter and jaded old man

Andrew Nenakhov, just as you!

Scarred by lost battles

I'm young and innocent.

And traumatized by the rise of Signals and Telegrams

But not all is lost and we will prevail

everything is lost already

Join us, and together we'll defeat the emperor and rule the Galaxy!

Oh sorry got carried away. Wrong script.

you guys cannot even defeat Matrix!

Yes we can!

zinid: We are missing Neo obviously

yeah, being a dog on a leash is a good achievement!

But really we're mostly aiming at Slack's market

maybe our Master will improve our leash!

maybe not

That's an important thing by the way: Different people in the XMPP community are focused on separate messaging problems. Team/company chat like Slack, consumer chat like whatsapp/messenger/etc, special purpose stuff like video conferencing (Zoom, etc).

not sure what XMPP community is

I'm really lost after today's debate

I think xmpp should be a universal messaging protocol.

The intersection of a bunch of unrelated communities, come together to write XEPs and argue about things, and we're fresh out of XEPs.

Andrew Nenakhov, that was a goal in 1999

we failed

20 years passed, in IT that's an epoch

Because xmpp always came with a knife to a gun fight

so you suggest some nuclear weapon? with that your proposals? 😀

Yes. We have some wunderwaffen in our secret labs

But even without wunderwaffen, so far xmpp developers produced exactly ZERO great xmpp clients

I'm fine with Conversations, and seems like Dino is back on track

Most close client that I can call great is surprisingly Xabber for Web

Conversations is ravaged by cryprocancer

Ah yes, the crypto faction

true, but I can live with that

there is a switch to disable cancer, in Advanced Preferences

What I also have about it is that it omits too many important xmpp parts,like statuses and presence information

I hate not being able to see who's online. I get this 'always online' concept but it's not always good

and vcards!

Yes!

Im actually happy with that recent new vCard XEP

Old vCard is a shame

yeah, vcards is our main problem...

and IDs

!xsf_Martin, you're blinking

IDs are important.

I'd say extremely important.

Too bad they weren't enforced in 1999

first attempt with IDs was not so successful, politely saying 🙂

Which one?

Andrew Nenakhov, what about stream management, do you eliminate them with your proposal?

I mean do you eliminate that stupid SM counter?

Yes, of course. My hate for 198 is widely known

right, just asking to understand what you don't hate 😀

Vcards! )

Presences

Xml

meh

Also, federation )