Andrew NenakhovIs 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
tuxembedded systems that use static linking?
kokonoehas left
kokonoehas joined
Andrew NenakhovWell, has anyone heard of embedded iOS devices?
alacerhas left
dwdhas left
dwdhas joined
Andrew NenakhovAlso. Are there any reasons to use xep 184 delivery receipts, or xep-333 chat markers can do everything 184 can plus some more. ?
flowAndrew Nenakhov, xep184 is possibly more widely supported
flowand i've heard that xep333 is going to change (but I am hearing that for a while now without anything happen)
ZashIs there a reason to use 333 when 184 and 85 does most of it?
dwdhas left
dwdhas joined
lnjhas left
Andrew NenakhovIt does not.
Andrew NenakhovXep 085 has very different purpose
Andrew NenakhovAnd 184 does not indicate anything but delivery.
Andrew NenakhovWhile 333 tells when message was displayed to user (kinda "read"), as opposing to just delivered to one of his devices and never viewed
ZashChat states can tell you whether the user is looking at the chat or not. chat state == active and receipt received := displayed, maybe read
ZashDo I have to write my own client to show how this works?
neshtaxmpphas left
Andrew NenakhovUser 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 NenakhovRead 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 NenakhovOk, 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.
ZashGood luck
Andrew NenakhovWe 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
HolgerZash: What do you dislike about 0333?
moparisthebesthas joined
ZashHolger: Overlap with 85 and 184.
Andrew NenakhovNo overlap with 0085 at all.
Andrew NenakhovWith 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 :)
ZashHolger: Also that people have asked me to implement it in Prosody, and when I read it, it made no sense to me whatsoever.
HolgerAndrew 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 NenakhovHolger, well I think we'll probably use 333 then, discarding 184.
HolgerZash: Implement it server-side?
Andrew NenakhovI was thinking of providing more gentle fallback, but overhead seems to be unnecessary.
ZashHolger: Yes. With offers of payment.
Andrew NenakhovHm. These are client side xeps
HolgerAndrew 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.
ZashHolger: What? Does it?
ZashThat sorta confirms my overall feeling of "it doesn't do what it says it's supposed to do"
Andrew NenakhovHolger, yes we are aware of that. We decided that server errors are sufficient to tell client that something went wrong with s2s delivery.
HolgerZash: 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"
HolgerAndrew 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.
HolgerAnd 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
Ge0rGHolger: except we could easily solve that by allowing multiple markers in a single 0184 message.
Ge0rGBump the namespace, have a server side module translate in both directions and to 0333
404.cityhas left
dwdhas left
dwdhas joined
dwdhas left
Andrew NenakhovGe0rG, in practice you don't need to send markers on every message, it's unnecessarily excessive.
Ge0rGAndrew 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?
Ge0rGFor remote 0184/0333 it would actually make sense to make them CSI unimportant
Ge0rGI wonder which implementations do
Andrew NenakhovWe are getting rid of 0198.
andyhas left
Andrew NenakhovWe came to conclusion that the way forward is not resumption of stream on reconnect, but restoration of current state.
Ge0rGThere is a fine line between these two
neshtaxmpphas joined
alacerhas joined
dwdhas joined
HolgerGe0rG: 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.)
Ge0rGHolger: that's useful.
ThibGhas left
lumihas left
ThibGhas joined
!xsf_Martinhas left
HolgerGe0rG: 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@
Ge0rGHolger: 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
Ge0rGYeah, we finally need parallel streams over one TCP connection.
jonas’SCTP!
jonas’HTTP/2!
jonas’barf
Ge0rGQUIX
jonas’itym QUIC?
Ge0rGWhatever. X is for XMPP! 🤷♂️
MattJI just want to mention, at the summit it was suggested that IM-NG could put chatstates in presence
MattJEverything about this makes sense to me
MattJ*in directed presence
ZashThat makes .. some sense
MattJYep
Andrew NenakhovIntriguing but I'm not convinced.
MattJSensible clients already discard chat state info when they receive unavailable presence
MattJMost of the past week someone in this room was typing a message (it's "fixed" since I restarted my client)
MattJBut consider that if someone is typing, you don't get that info when you join a MUC, you would if it was in presence
MattJIt cancels when they go offline, without the client needing to do extra work
Ge0rGIt should time out after 30s or so anyway.
MattJSome people type slowly :)
Ge0rGLet 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 NenakhovGuus, Most emails I get these days are shorter than your message
Neustradamushas left
GuusLucky bastard.
Neustradamushas joined
Neustradamushas left
Neustradamushas joined
Neustradamushas left
404.cityhas joined
Neustradamushas joined
neshtaxmpphas left
jjrhless lucky when it's a response to a long email with multiple questions asked.
kokonoehas left
neshtaxmpphas joined
Guusthat's why you never, ever, must ask more than one question in an email message.
Guussend mulitiple messages if you have more questions.
Andrew NenakhovBtw I can't understand how internet has arrived to this abysmal culture to reply above original email and not include quoted text properly
Andrew NenakhovFIDO 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
Ge0rGAndrew Nenakhov: blame Microsoft Outlook
Andrew NenakhovAN>>> 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.
Ge0rGNobody but nerds can follow nested quotes.
GuusNobody but nerds care, either.
Ge0rGYeah. 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.
ZashEternal September
pep.But not the fact that they're top-posting
Andrew NenakhovFIDO 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
oliAndrew Nenakhov: it was | in fido, if i remember correctly
oliNot >
Andrew NenakhovIn Russian Fido it was definitely >
Andrew Nenakhovhttp://www.fandom.ru/fido/ru_fantasy/text/67.htm
olii think my brain is broken
!xsf_Martinhas joined
!xsf_Martinhas left
!xsf_Martinhas joined
Andrew NenakhovThat's what we Russian hackers do.
olihas left
olihas joined
oliat least it's not my fault 🤕
Alexhas joined
olianyway, i also don't remember any major problems with quoting in fidonet. but maybe i'm remembering it all wrong ;)
Andrew NenakhovThere were moderators who gave you * and + for overquoting, that kinda kept quotes in check
olibandwith 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
zinidjonas’, is there any ETA when XEP-XOR and XEP-EAX will be published? I need the XEP numbers for references.
XSF Discussion - 2019-03-04