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 )

0071 I liked too, actually. But *they* killed it.

Can somebody temporarily kick or ban !xsf_Martin?

that was SamWhited mostly, he is not in the XSF anymore, we can resurrect it

yeah, that XEP has attracted so many debates, probably the most controversy XEP I ever seen

I'm somewhat to blame for XHTML-IM getting deprecated

I think we'll implement it despite deprecation. One day.

I'd done a study of XMPP clients implementing XHTML-IM, and basically found security issues (RCE vulnerabilities) in almost all of them. I'd done a presentation at an XMPP Summit about it too. This was quite a few years back.

I recall the same about carbons or something like that

when a lot of clients were affected

and there was a billion laugh attack...

Vulnerabilities are bad. But how come browsers are not vulnerable?

Web applications have vulnerabilities all the time

yeah, super-puper Signal for instance

that was glorious fail

And when you are displaying user provided rich HTML input, and your code to prevent <script> tag injections and such isn't airtight, suddenly someone can send a message to take over your client.

They are vulnerable because they have js

If it's a web client, you can e.g., take over the XMPP session by just resetting the password or whatever

But there was no js in 0071

Yes, but that doesn't prevent me from sending you a message which has js

And if your code can't detect it and clean it up, bad things can happen to you

Andrew Nenakhov, there were a lot of arguments about these in that 0071 debate

Of course.

And my evidence for this being a real problem was reviewing ~10 XMPP clients which implemented XHTML-IM, and getting all of them to remotely run my JS.

Including at least one desktop client, which basically gave me full access to the OS

waqas, anyway, browsers exist. It's a proof enough that html code can be safely contained by a parser

Browsers get constant security updates. And web applications have security issues all the time.

Web apps have updates because they are within same sandbox where scripts work are

Yes, and securing browsers is a hard, non-trivial problem. All browsers come with security teams of their own. This isn't true for XMPP clients.

And we dont need much in xmpp. B I U and maybe UL OL, that's about it

I'm pretty sure that anything resembling scripts or styles can be safely dropped without too much effort.

Most likely those clients just used a ready components like web views or something

which always include a full running javascript engine

hence the problem

Yeah.

"I'm pretty sure that anything resembling scripts or styles can be safely dropped without too much effort." — this is what I disagree with. Sanitizing HTML is not easy.

XHTML-IM is not HTML

HTML and also CSS (which can also contain JS)

It isn't, but you can't block me from sending you stuff that's not in the spec, and if your client doesn't clean that out, I win.

Sure, but I can be pretty strict about it, (and I should)

It's not like I had to support whatever crap you throw at me, like browsers do

pep.: That's basically what I found: clients trying to be strict about it and failing.

Ok, so what, it's better to take them down rather than fix them?

I even wrote a library to be strict about it: https://github.com/zeen/xhtml-im.js/blob/master/xhtml-im.js

cool

2013, that was quite some time ago

Actually I think that due to specifics of our medium all css can be just dropped.

No colors. No scripts. No margins.

What do you actually want to keep?

What about providing tests then for devs to use, alongside your reference impl that they can also reuse, instead of taking the XEP down and creating 393

B I U UL OL, quotes

393 and 394 are abominations

Just to be clear, I didn't take personally take the XEP down. I'd mostly presented my findings, and the discourse on XHTML-IM from that point was negative. This was around when there was a Last Call for the XEP to become final.

that was quite moot decision and basically heavily relied on personal point of view, I already said that in that mail list discussion

like "fixing clients" vs "we're doomed"

you cannot debate between those point of views

*points

zinid: The XSF (XMPP Standards Foundation) has tried hard to be a neutral org which just focuses on standards. There's no wing of the XSF where you send folks out to fix things in clients, and everything relies on individual projects implementing spec updates. There's also no strong outreach to the community.

I'm not a fan of this state of affairs, for what it's worth

waqas, well, maybe I'm currently not very clear, but whatever

"can we rely on client devs: yes or no"

let's say it that

I'm saying "fixing clients" isn't something the XSF can actually do

yes, yes

waqas, and no, XSF is not focused on standards

XSF is focused on XEP publishing process

+1

it has converted recently in a completely beaurocratic body

Yes, but that's what "focused on standards" has been defined as. Note that this is by design, many /wanted/ this to happen, and for us to be more similar to e.g., the IETF.

> <@_xmpp_pep.=2fxsf=40muc.xmpp.org:matrix.org> Matthew, well played, I see you've started another meaningful discussion :P gah, sorry all

(sorry for the spelling, I can never remember how this word is spelled in english)

waqas, well I see a very little point in the XSF now in comparison to the IETF

anyone can go straight to the IETF, where there will no be a bunch of judges

xep publishing process. use a collaborative wiki ...

"where there will no be a bunch of judges" — you've never been part of the IETF process, have you...

waqas, the IETF is a platform which gives you tools to develop a standard

waqas, no, I wasn't

even so, why should I care who will judge me?

so we copied the worst from the IETF?

what's the real meaning of the XSF now?

not how it was, not on the paper, but now de facto

A body which oversees the standards process for XMPP and it's XEPs

I wonder how will this body react to our XEPs

same as IETF?

Similar. The IETF is generic. The XSF for example worked within the IETF framework to get the XMPP RFCs published.

waqas, so IETF restricted to "oversee" the XMPP related specs only

as a standard write why would I care?

*writer

The IETF is quite a bit about the process, yes

yeah, same stuff the XSF converted to

The few paragraphs here basically describe what the XSF has been about: https://xmpp.org/about/xmpp-standards-foundation.html

Zinid let's form our own council, just you and us. Whatever we agree to, it'll be standard.

Note that I'm probably in agreement with you that that's not particularly helpful in making open messaging and XMPP succeed and compete against other solutions.

Andrew Nenakhov, nah, I don't invent wheels, sorry

Andrew Nenakhov, I can always got to IETF, which I think I will with my XOR

*go

Xmpp currently badly needs weels.

😀

And the XMPP Software Foundation used to be the Jabber Software Foundation, and that old thing was much more in line with what you are hoping for.

What is 'your XOR'

*XMPP Standards Foundation

Andrew Nenakhov, http://upload.zinid.ru/xeps.html first link

waqas, exactly, so I kinda agree with Ge0rG's rantings

I too agree with Ge0rG's rantings :)

I can only speak from my experience, and yes xeps and process etc are sometimes a painpoint, but i dont feel this is the reason that holds the xmpp community back

we constantly laugh about endless Matrix's TODO, but we don't even have any, how ironic

lovetox: I'm curious about what you think the reason is

its not like there are a lot of developers who want to do stuff, but are actively inhibited by process of xsf or xeps

lovetox, as a server dev I can do a lot actually, I'm currently very bored

the reason is to few developers in my opinion

so I even resorted to implement that dredful MIX, ha

Well, currently I have 5-6 developers working on XMPP full time

zinid, you shouldn't have.

Andrew Nenakhov, but you didn't provide anything, and what should I do?

I'm kinda stuck in the development

really, what should I implement?

You didn't ask. More precisely you said you're not interested )

yeah zinid its also not about server development

its about good clients with nice GUI

nobody wants to do that

Good clients can't exist without good servers

lovetox, I'm not competent enough

:D

lovetox - I was talking to a company that's actively looking to sponsor project to do just that.

Andrew Nenakhov, i feel servers are good enough

Nope. Not yet.

its not servers who hold us back :)

lovetox, he has his own vision 😀

In telegram I can log in and in mere seconds get a list of recent conversations and their metadata

I don't think lack of standards is a real issue. I think better-than-the-competition UIs are the real issue.

Andrew Nenakhov, that's not a problem with servers, c'mon

How many unread messages, which are read by recipient, etc

> Andrew Nenakhov, that's not a problem with servers, c'mon It absolutely is.

Andrew Nenakhov, and? What do you want from servers? To implement what?

Mam does not contain metadata. Mam does not allow getting recent msgs from conversations

lovetox: I agree that we're currently lacking the resources to create good UI/UX in many frontend-based projects. I don't think that we're unable to get these resources though - I think we generally didn't bother to try.

such things are nice features the cherry on the top, we fail at much more basic stuff

which is what I like about having Matrix as a mirror: to me, their client made it painfully clear what we're lacking.

+1

Guus, yes i think it also doesnt take much

Guus, I'm more often looking at Telegram

pick 3-4 clients, assign 2 motivated developers to each

i think this goes a long way

Who does the assignment and who pays for this?

And who decides what these devs should do?

Well I'm paying my developers and decide what they do. :)

thats not how i meant this, i meant maybe we are getting lucky and someone comes up

:)

That's one way to do it, and that's also what the Matrix team is doing.

but yeah a bit of money could help

But money means you need profits (unless this is all donation money). The Matrix folks raised capital, which does interest things to motivations and direction.

I strongly believe that it is up to the individual projects to arrange this for themselves.

Yes.

The XSF, however, can facilitate, and spread 'best practices'

Guus: And there's no evidence that that would really succeed at scale.

I tried to supply a couple of them a couple of days before

Current approach didn't succeed thus far

waqas true, but there's sufficient evidence that not doing anything does not get us _any_ progress.

Guus: You basically get one or two winners, and their philosophy "wins", except most of the community doesn't like the currently popular UIs.

So maybe it's worth a try to do things differently

waqas I think we're talking about different things

All vision and future-oriented conversations in this room ^

waqas the 'winners' would be those clients that get adopted by the general public end user, right?

Guus: So… Pidgin?

I suspect it has the largest user base, no?

I don't think so

I don't think pidgin has any relevance these days

more like the what-apps of these days

waqas I'm unsure if I understand your argument

(or if we're arguing the same thing)

Its really basics i think, for example Gajim cant find someone who makes a nice installer for MacOS for years, though the application runs fine on it

What would be good is even a clear idea of what "we" want. You said the XSF can facilitate and spread best practices for example. It'd be great to know what those could be. Is the crypto crowd defining the best practices? Is the IETF-like crowd? is the UX-first crowd?

It's hard to even know if I like or dislike an argument when you don't know what the argument is trying to achieve in the long term.

My thoughts are: Many here seem to agree that a common issue with most of our frontends are a lack of UI/UX. Also, a lack of funding is seen as a key issue that prevent problems from being fixed. As these issues are common in our group, I see a role for the XSF to facilitate improving on this point - but in the manner of "helping individual projects to raise money and/or design resources" as opposed to "raise money/hire designers and donate that to projects."

Guus: I can agree with that, with one concern: many projects/developers have their own incompatible ideas for what good UX is, and I'm not sure if there's much money in the ecosystem.

It happened often that users tell me they use Gajim in their company

waqas I don't think that either is true. I think that the majority of projects/developers realize that they don't know what a good design is, and that they need help.

I always think, yeah nice for you, but it would be nice if the company gives something back to the project

waqas also, I'm pretty sure that there's much money in the ecosystem, but that we're failing to raise it (or even _attempt_ to raise it)

and be it only a developer that spends 1 hour per week

lovetox I think you'd be surprised how many people would actually be willing to do that, if they're asked to.

I suspect that our biggest issue is that we're not asking.

you are right, i never asked, i will do next time

I agree with that Guus

There was a time when there were a lot of folks offering to do stuff

We were talking about forming teams of volunteers and some of that actually happened

lovetox: and I think that there might be good ways of asking for somethign, and bad ways to do that. I think that there's a role for the XSF to help people figure out the best way.

waqas sure, but that time has gone. XMPP isn't sexy any more

we need to adapt and move on.

But then it fizzled out, because there was a lack of direction, the XSF folks at the top didn't necessarily agree with the volunteers on what needed to happen.

And the XMPP community sorely lacks much project planning/management/design experience. Most efforts fizzle out because either nobody cares much, or too many care and suddenly there's a todo list of a dozen random things.

also a point that i noticed is, that i cant spend much time on UI, because the core codebase is so old and stuffed together over 15 years by X people

waqas I believe that much fizzles out because it remains in the realm of 'hobby' and 'pet project' - which is _awesome_, but is very unlikely to get the attention it needs, as people need to do stuff that they can earn a living wiht.

so i spend most of my time refactoring stuff,

but i will get there eventually :)

lovetox I suffer from the same issue with our ancient Spark client (which isn't particularly good, but which I would like to see improved)

what i find really nice, are the xmpp meetups that i noticed over the last year, i wasnt able to attend one but planning to go :)

you should definitely do that!

lovetox, nice in what sense? I mean as a social event it might be good (beer and stuff), but what is the outcome for XMPP?

no zinid, i meant the meetings where they code

I don't have any faith for coding at meetings

get together for a weekend sit down talk about stuff and help each other out implementing some feautre

as i said i never was, i hope they do that :D

Why would someone need to get together with someone to code?

ah, that's not xmpp related...

maybe they only drink beer

In my experience, it adds tremendous value

Drinking beer together, is very different from drinking alone at home

Andrew Nenakhov, because i have a family and other things to do at home

Andrew Nenakhov, as I see it people are different in europe, we probably cannot understand that 😀

i cant spend 5 hours on the computer

Lol

but if i tell my girlfriend im going to berlin over the weekend

i can concentrate on the task

I think most value is actually in the social part of the meet, not the code (Which is nice, too)

beer, that is

Ha, if the XSF or equivalent can just fund weekend drinks and food, we'll not lack for dev resources :P

but discussions like the one we're having here are much faster and effective when done in person

lovetox, if you tell her that and instead go to the attic and work there, you'll be able to work those hours that would otherwise be wasted on commute

Guus, faster, but equally inconsequential

Andrew Nenakhov to how many have you been?

Guus, nah, depends on your communication skills (including foreign language)

Guus, I attend 5 eight hours gettogethers of xmpp developers every week

I actually pay them to show up.

😂

I've been at two, and I've learned things that changed things for the better for me, a lot. I need not look back further than the last 24 hours, in which I've gotten an XMPP customer that I would not have gotten if I had not done the things that others at such meetings told me to do

that's direct XMPP-based income. I've already earned back my tickets.

Andrew Nenakhov, like hookers 😀

zinid communication skills are always important - but what stops you from having a russian meetup?

that takes away the foreign language issue.

Hahaha

The vast distances of Russia

Guus, lmao, I'm quite antisocial and I don't like such events

Also 1500km to moscow

Andrew Nenakhov, I'm in Moscow, there are no people outside Moscow, you know that

only bears

You was in Krasnodar, no?

Andrew Nenakhov, I moved

Ah, ok. Maybe we should meet next time I'm there then. See, Guus, I'm just 2000km east of Moscow

that's almost near

So meeting people is kinda more difficult than in Germany.

at least not Vladivostok with 9000km 😀

Lol.

Btw do you guys know the town with a most per-capita concentration of Xmpp developers?

I've learned lots of things in sprints! Now I know how to stack vim buffers! (thanks jc!) I think that was the best thing I learned out of sprints :P (/s)

Guys, I'm happy for you to go about it your own way. I'm only offering suggestions, and i'm trying to find solutions. If you have a better idea, by all means, share it, so that everyone can benefit.

random question; do you guys have a code of conduct for xsf moderated rooms?

I don't think so

s/guys/folks/

Matthew nope

wut? I was banned once

First time I've even heard the phrase "xsf moderated rooms"

also: can how do I add you as a contact via that bridge?

zinid, no need for a code of conduct for that

You just need moderator permissions

The, the MUC XEP doesn't require a code of conduct for the banning feature

pep., indeed, it's convenient

Matrix guy wants to steal our codes of conduct!

ban them already!!

+1

So basically, they'll start banning zinid ? 🙂

First, they came for our uses. Then, codes of conduct. That's next, our beautiful women?

yeah, banning people is funny, muc drama

I'm not sure at what frequency heated discussions happen fwiw

XHTML-IM, OMEMO, zinid, that's about the main events

as far as I've seen: once. And he got banned.

What was the Omemo drama?

the _ongoing_ omemo drama

Its mostly Ge0rG hating it

Ge0rG is hating everything

probably because he has not enough time to implement it, and his users bug him :D

Yeah, that's usually how you get features in implementations anyway

Having users bully other developers :P

I hate Omemo too. Protocol written like shit, with race conditions, and has zealous users who believe it to be the silver bullet

Andrew Nenakhov, you will not such arguments for the upcoming MLS 😛

Andrew Nenakhov, thanks, let's not redo the OMEMO discussion right now

*will not have

What's MLS?

I bet the MLS WG will produce high quality spec, they all look very *clever* 😀

https://datatracker.ietf.org/wg/mls/about/

namely, https://tools.ietf.org/html/draft-ietf-mls-protocol-03

DISCLAIMER: This is a work-in-progress draft of MLS and has not yet seen significant security analysis. It should not be used as a basis for building production systems.

I wonder if there ever was a serious security analysis of OMEMO

OMEMO itself, or signal's encryption mechanism?

there was for both

Actually both

omemo is only about wrapping signal in xmpp

not much you can do wrong

It bugged me when reading that terminology is different in different documents.

Very so-so

Andrew Nenakhov, there was for OMEMO afair

I'm off. goodnight!

Bye.

Andrew Nenakhov, re security analysis of omemo https://conversations.im/omemo/audit.pdf

I saw that. I meant serious )

then you'll have to define serious :)

Those that have their most interesting part being just a link to some other research done of course but a very respectable experts, ha

I mean the signal protocol has been pretty extensively reviewed hasn't it? what else can an implementation of it get than a 3rd party audit?

moparisthebest, was signals protocol really reviewed? Or, it's so popular itmust have been reviewed?

Andrew Nenakhov, it is reviewed you can find this out pretty fast

Anyway I'm not really in the mood arguing about that

there is nothing to argue about

:)

well I ddg'd "signal protocol review" and found a ton of results so, probably?

> In October 2016, researchers from the UK's University of Oxford, Australia's Queensland University of Technology, and Canada's McMaster University published a formal analysis of the protocol.[15][16] They concluded that the protocol was cryptographically sound.[15][16]

knock yourself out following all the citations https://en.wikipedia.org/wiki/Signal_Protocol

like lovetox said, nothing to argue about, 100% has been widely reviewed

lovetox [22:02]: > probably because he has not enough time to implement it, and his users bug him :D Is this a troll or a massive misinformation?

it was a joke, dont take it to serious

Alright