XSF Discussion - 2019-03-04

aaaaaa

Is there any reason to choose license different from GNU LGPL for an open source iOS library with .ogg support?

embedded systems that use static linking?

Well, has anyone heard of embedded iOS devices?

Also. Are there any reasons to use xep 184 delivery receipts, or xep-333 chat markers can do everything 184 can plus some more. ?

Andrew Nenakhov, xep184 is possibly more widely supported

and i've heard that xep333 is going to change (but I am hearing that for a while now without anything happen)

Is there a reason to use 333 when 184 and 85 does most of it?

It does not.

Xep 085 has very different purpose

And 184 does not indicate anything but delivery.

While 333 tells when message was displayed to user (kinda "read"), as opposing to just delivered to one of his devices and never viewed

Chat states can tell you whether the user is looking at the chat or not. chat state == active and receipt received := displayed, maybe read

Do I have to write my own client to show how this works?

User may have scrolled to 10 years ago do his activity in chat does not in the slightest indicate that he has seen a message in question.

Read markers send progressive updates on user seeing messages that were sent to him.

*so his activity in message above, not "do his activity"

> most of it It's not 100%. But you can get the 80% that matters, eg by setting chat state=not active when they scroll up

Ok, zash, I heard your opinion and we won't do 80% in our client. We need a good quality 100% solution, not repurposing XEP that was meant for other things to do read markers.

Good luck

We do support xep 0085 for what it is purposed: indicating chat state. Also we want to extend it to send 'recording voice message', 'uploading file' states

Zash: What do you dislike about 0333?

Holger: Overlap with 85 and 184.

No overlap with 0085 at all.

With 184, yes, there is, hence my question

Andrew Nenakhov, re extending 0085, as people have suggesting, that can be done, so I guess you can write the XEP :)

Holger: Also that people have asked me to implement it in Prosody, and when I read it, it made no sense to me whatsoever.

Andrew Nenakhov: I agree, I don't quite see the point of keeping 0184 either. Except everyone does it and nobody does 0333, as usual.

Holger, well I think we'll probably use 333 then, discarding 184.

Zash: Implement it server-side?

I was thinking of providing more gentle fallback, but overhead seems to be unnecessary.

Holger: Yes. With offers of payment.

Hm. These are client side xeps

Andrew Nenakhov: The only thing I see that might be problematic is how a 0333 ACK also acknowledges all previous messages. So you can't really use it to check against unreliable message delivery.

Holger: What? Does it?

That sorta confirms my overall feeling of "it doesn't do what it says it's supposed to do"

Holger, yes we are aware of that. We decided that server errors are sufficient to tell client that something went wrong with s2s delivery.

Zash: Yes? In my book that's a feature. Just mentioning the difference compared to 0184.

> That sorta confirms my overall feeling of "it doesn't do what it says it's supposed to do" 333 is called "chat markers", not 333 "reliable s2s message delivery receipts"

Andrew Nenakhov: I agree there as well. If our message delivery isn't reliable we should make it reliable rather than making sure we expose the problem properly to the end user.

And 0333's behavior is much nicer than 0184's e.g. when syncing up tons of messages from MAM or so.

Holger: except we could easily solve that by allowing multiple markers in a single 0184 message.

Bump the namespace, have a server side module translate in both directions and to 0333

Ge0rG, in practice you don't need to send markers on every message, it's unnecessarily excessive.

Andrew Nenakhov: did I mention how it would make sense to integrate 0184, 0198 acks and self-carbons with mam-id into one awesome session thing?

For remote 0184/0333 it would actually make sense to make them CSI unimportant

I wonder which implementations do

We are getting rid of 0198.

We came to conclusion that the way forward is not resumption of stream on reconnect, but restoration of current state.

There is a fine line between these two

Ge0rG: ejabberd's CSI (by default) sends you only the most recent chat state of a given JID when you become active again.

(I was going to de-dup 0333 as well just keep forgetting.)

Holger: that's useful.

Ge0rG: Not sure the traffic savings are such a big deal, you mobile guys usually tell me it doesn't really matter once the cost of waking the radio is payed. I mostly do these things to keep the CSI queue size smaller, to get less frequent queue flushes.

Holger, well, on bad links, every friggin byte counts ;)

and you don’t want everything to hang just because you replayed the last 15 minutes of chat states in xsf@

Holger: without the evil compression, keeping only the latest presence and chat state will make sense indeed. I'm not sure either, but I can imagine that the phone will stay on 2G if there is not too much data

Yeah, we finally need parallel streams over one TCP connection.

SCTP!

HTTP/2!

barf

QUIX

itym QUIC?

Whatever. X is for XMPP! 🤷‍♂️

I just want to mention, at the summit it was suggested that IM-NG could put chatstates in presence

Everything about this makes sense to me

*in directed presence

That makes .. some sense

Yep

Intriguing but I'm not convinced.

Sensible clients already discard chat state info when they receive unavailable presence

Most of the past week someone in this room was typing a message (it's "fixed" since I restarted my client)

But consider that if someone is typing, you don't get that info when you join a MUC, you would if it was in presence

It cancels when they go offline, without the client needing to do extra work

It should time out after 30s or so anyway.

Some people type slowly :)

Let me rephrase that: it should expire after 30s and be refreshed by the sending client every 15s.

(combined with a pop-up in the client that asks the user to kindly write a chat message, not an email)

Guus, Most emails I get these days are shorter than your message

Lucky bastard.

less lucky when it's a response to a long email with multiple questions asked.

that's why you never, ever, must ask more than one question in an email message.

send mulitiple messages if you have more questions.

Btw I can't understand how internet has arrived to this abysmal culture to reply above original email and not include quoted text properly

FIDO had a culture of quoting covered in 1993

it’s all those vegetarians with their TOFU (sorry, I’ll show myself out)

I like tofu! and I'm not veg(etari)?an

Andrew Nenakhov: blame Microsoft Outlook

AN>>> original message MJ>> reply to it MJ>> second line of reply AN> third level reply And my answer What could be more simple and better?

Andrew Nenakhov, I heard from a non-representative sample of non-technicals that that layout is extremely confusing.

Nobody but nerds can follow nested quotes.

Nobody but nerds care, either.

Yeah. That, too

I'm sure they're blaming $things when they don't understand what the reply is talking about and they have to read 5 huge emails above.

Eternal September

But not the fact that they're top-posting

FIDO was full of non tech people and no one had problems with it cause mail editors automatically took care of these initials and >>> symbold

> Andrew Nenakhov: blame Microsoft Outlook

Andrew Nenakhov: it was | in fido, if i remember correctly

Not >

In Russian Fido it was definitely >

http://www.fandom.ru/fido/ru_fantasy/text/67.htm

i think my brain is broken

That's what we Russian hackers do.

at least it's not my fault 🤕

anyway, i also don't remember any major problems with quoting in fidonet. but maybe i'm remembering it all wrong ;)

There were moderators who gave you * and + for overquoting, that kinda kept quotes in check

bandwith was limited :)

jonas’, is there any ETA when XEP-XOR and XEP-EAX will be published? I need the XEP numbers for references.

jonas’, maybe I can help somehow?