Is there any reason to choose license different from GNU LGPL for an open source iOS library with .ogg support?
dwdhas joined
ThibGhas left
ThibGhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
tux
embedded systems that use static linking?
kokonoehas left
kokonoehas joined
Andrew Nenakhov
Well, has anyone heard of embedded iOS devices?
alacerhas left
dwdhas left
dwdhas joined
Andrew Nenakhov
Also. Are there any reasons to use xep 184 delivery receipts, or xep-333 chat markers can do everything 184 can plus some more. ?
flow
Andrew Nenakhov, xep184 is possibly more widely supported
flow
and i've heard that xep333 is going to change (but I am hearing that for a while now without anything happen)
Zash
Is there a reason to use 333 when 184 and 85 does most of it?
dwdhas left
dwdhas joined
lnjhas left
Andrew Nenakhov
It does not.
Andrew Nenakhov
Xep 085 has very different purpose
Andrew Nenakhov
And 184 does not indicate anything but delivery.
Andrew Nenakhov
While 333 tells when message was displayed to user (kinda "read"), as opposing to just delivered to one of his devices and never viewed
Zash
Chat states can tell you whether the user is looking at the chat or not. chat state == active and receipt received := displayed, maybe read
Zash
Do I have to write my own client to show how this works?
neshtaxmpphas left
Andrew Nenakhov
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.
Andrew Nenakhov
Read markers send progressive updates on user seeing messages that were sent to him.
Andrew Nenakhov
*so his activity in message above, not "do his activity"
melvohas left
Zash
> 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
Andrew Nenakhov
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.
Zash
Good luck
Andrew Nenakhov
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
Holger
Zash: What do you dislike about 0333?
moparisthebesthas joined
Zash
Holger: Overlap with 85 and 184.
Andrew Nenakhov
No overlap with 0085 at all.
Andrew Nenakhov
With 184, yes, there is, hence my question
pep.
Andrew Nenakhov, re extending 0085, as people have suggesting, that can be done, so I guess you can write the XEP :)
Zash
Holger: Also that people have asked me to implement it in Prosody, and when I read it, it made no sense to me whatsoever.
Holger
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.
Andrew Nenakhov
Holger, well I think we'll probably use 333 then, discarding 184.
Holger
Zash: Implement it server-side?
Andrew Nenakhov
I was thinking of providing more gentle fallback, but overhead seems to be unnecessary.
Zash
Holger: Yes. With offers of payment.
Andrew Nenakhov
Hm. These are client side xeps
Holger
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.
Zash
Holger: What? Does it?
Zash
That sorta confirms my overall feeling of "it doesn't do what it says it's supposed to do"
Andrew Nenakhov
Holger, yes we are aware of that. We decided that server errors are sufficient to tell client that something went wrong with s2s delivery.
Holger
Zash: Yes? In my book that's a feature. Just mentioning the difference compared to 0184.
Andrew Nenakhov
> 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"
Holger
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.
Holger
And 0333's behavior is much nicer than 0184's e.g. when syncing up tons of messages from MAM or so.
lumihas joined
!xsf_Martinhas left
!xsf_Martinhas joined
!xsf_Martinhas left
!xsf_Martinhas joined
Ge0rG
Holger: except we could easily solve that by allowing multiple markers in a single 0184 message.
Ge0rG
Bump the namespace, have a server side module translate in both directions and to 0333
404.cityhas left
dwdhas left
dwdhas joined
dwdhas left
Andrew Nenakhov
Ge0rG, in practice you don't need to send markers on every message, it's unnecessarily excessive.
Ge0rG
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?
Ge0rG
For remote 0184/0333 it would actually make sense to make them CSI unimportant
Ge0rG
I wonder which implementations do
Andrew Nenakhov
We are getting rid of 0198.
andyhas left
Andrew Nenakhov
We came to conclusion that the way forward is not resumption of stream on reconnect, but restoration of current state.
Ge0rG
There is a fine line between these two
neshtaxmpphas joined
alacerhas joined
dwdhas joined
Holger
Ge0rG: ejabberd's CSI (by default) sends you only the most recent chat state of a given JID when you become active again.
Holger
(I was going to de-dup 0333 as well just keep forgetting.)
Ge0rG
Holger: that's useful.
ThibGhas left
lumihas left
ThibGhas joined
!xsf_Martinhas left
Holger
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.
jonas’
Holger, well, on bad links, every friggin byte counts ;)
jonas’
and you don’t want everything to hang just because you replayed the last 15 minutes of chat states in xsf@
Ge0rG
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
Ge0rG
Yeah, we finally need parallel streams over one TCP connection.
jonas’
SCTP!
jonas’
HTTP/2!
jonas’
barf
Ge0rG
QUIX
jonas’
itym QUIC?
Ge0rG
Whatever. X is for XMPP! 🤷♂️
MattJ
I just want to mention, at the summit it was suggested that IM-NG could put chatstates in presence
MattJ
Everything about this makes sense to me
MattJ
*in directed presence
Zash
That makes .. some sense
MattJ
Yep
Andrew Nenakhov
Intriguing but I'm not convinced.
MattJ
Sensible clients already discard chat state info when they receive unavailable presence
MattJ
Most of the past week someone in this room was typing a message (it's "fixed" since I restarted my client)
MattJ
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
MattJ
It cancels when they go offline, without the client needing to do extra work
Ge0rG
It should time out after 30s or so anyway.
MattJ
Some people type slowly :)
Ge0rG
Let me rephrase that: it should expire after 30s and be refreshed by the sending client every 15s.
yvohas left
Guus
(combined with a pop-up in the client that asks the user to kindly write a chat message, not an email)
Andrew Nenakhov
Guus, Most emails I get these days are shorter than your message
Neustradamushas left
Guus
Lucky bastard.
Neustradamushas joined
Neustradamushas left
Neustradamushas joined
Neustradamushas left
404.cityhas joined
Neustradamushas joined
neshtaxmpphas left
jjrh
less lucky when it's a response to a long email with multiple questions asked.
kokonoehas left
neshtaxmpphas joined
Guus
that's why you never, ever, must ask more than one question in an email message.
Guus
send mulitiple messages if you have more questions.
Andrew Nenakhov
Btw I can't understand how internet has arrived to this abysmal culture to reply above original email and not include quoted text properly
Andrew Nenakhov
FIDO had a culture of quoting covered in 1993
kokonoehas joined
jonas’
it’s all those vegetarians with their TOFU (sorry, I’ll show myself out)
pep.
I like tofu! and I'm not veg(etari)?an
Ge0rG
Andrew Nenakhov: blame Microsoft Outlook
Andrew Nenakhov
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?
jonas’
Andrew Nenakhov, I heard from a non-representative sample of non-technicals that that layout is extremely confusing.
Ge0rG
Nobody but nerds can follow nested quotes.
Guus
Nobody but nerds care, either.
Ge0rG
Yeah. That, too
pep.
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.
Zash
Eternal September
pep.
But not the fact that they're top-posting
Andrew Nenakhov
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
Ge0rG
> Andrew Nenakhov: blame Microsoft Outlook
rtq3has left
rtq3has joined
oli
Andrew Nenakhov: it was | in fido, if i remember correctly
oli
Not >
Andrew Nenakhov
In Russian Fido it was definitely >
Andrew Nenakhov
http://www.fandom.ru/fido/ru_fantasy/text/67.htm
oli
i think my brain is broken
!xsf_Martinhas joined
!xsf_Martinhas left
!xsf_Martinhas joined
Andrew Nenakhov
That's what we Russian hackers do.
olihas left
olihas joined
oli
at least it's not my fault 🤕
Alexhas joined
oli
anyway, i also don't remember any major problems with quoting in fidonet. but maybe i'm remembering it all wrong ;)
Andrew Nenakhov
There were moderators who gave you * and + for overquoting, that kinda kept quotes in check
oli
bandwith was limited :)
lovetoxhas joined
Alexhas left
rtq3has left
lnjhas joined
rtq3has joined
!xsf_Martinhas left
!xsf_Martinhas joined
!xsf_Martinhas left
!xsf_Martinhas joined
lumihas joined
UsLhas left
UsLhas joined
rtq3has left
alacerhas left
neshtaxmpphas left
Kevhas left
Steve Killehas left
!xsf_Martinhas left
!xsf_Martinhas joined
!xsf_Martinhas left
!xsf_Martinhas joined
Steve Killehas joined
debaclehas left
olihas left
Lancehas joined
Lancehas left
Nekithas left
edhelashas left
edhelashas joined
debaclehas joined
Yagizahas left
!xsf_Martinhas left
wurstsalathas joined
!xsf_Martinhas joined
!xsf_Martinhas left
!xsf_Martinhas joined
!xsf_Martinhas left
!xsf_Martinhas joined
APachhas left
APachhas joined
rtq3has joined
rtq3has left
404.cityhas left
rtq3has joined
alacerhas joined
Alexhas joined
alacerhas left
melvohas joined
melvohas left
rtq3has left
rtq3has joined
404.cityhas joined
404.cityhas left
!xsf_Martinhas left
!xsf_Martinhas joined
!xsf_Martinhas left
!xsf_Martinhas joined
!xsf_Martinhas left
!xsf_Martinhas joined
melvohas joined
!xsf_Martinhas left
!xsf_Martinhas joined
alacerhas joined
melvohas left
Alexhas left
Alexhas joined
404.cityhas joined
!xsf_Martinhas left
!xsf_Martinhas joined
dwdhas left
dwdhas joined
frainzhas left
frainzhas joined
dwdhas left
j.rhas left
Tobiashas left
alacerhas left
404.cityhas left
Nekithas joined
wurstsalathas left
Alexhas left
Alexhas joined
ThibGhas left
ThibGhas joined
yvohas joined
dwdhas joined
Alexhas left
Alexhas joined
dwdhas left
dwdhas joined
frainzhas left
frainzhas joined
waqashas joined
j.rhas joined
vanitasvitaehas left
vanitasvitaehas joined
dwdhas left
Alexhas left
Alexhas joined
blablahas left
wurstsalathas joined
blablahas joined
blablahas left
yvohas left
yvohas joined
blablahas joined
neshtaxmpphas joined
blablahas left
zinid
jonas’, is there any ETA when XEP-XOR and XEP-EAX will be published? I need the XEP numbers for references.