Ge0rGlovetox: I'm not sure if there are situations where Gajim is using an ID generated by another entity, like e.g. Last message correction (where it's not a security problem, but to illustrate the attack channel)
lskdjfhas joined
Lancehas joined
Lancehas left
Str4tocasterhas left
moparisthebesthas joined
moparisthebesthas joined
Str4tocasterhas joined
sonnyhas joined
lskdjfhas joined
Zashhas left
sonnyhas left
Zashhas joined
lhas left
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
alacerhas left
alacerhas joined
lnjhas left
genofirehas left
dedekinhas joined
Ge0rGWhat's the official way to talk to iteam?
Yagizahas left
Ge0rGI'd like to get https://www.mediawiki.org/wiki/Extension:MobileFrontend installed/enabled on our wiki
jonas’join iteam muc
Alexhas joined
Alexhas left
j.rhas joined
Steve Killehas left
tahas joined
Steve Killehas joined
guusdkhas left
sonnyhas joined
genofirehas left
Valerianhas joined
ralphmhas left
dwdhas joined
Kevhas joined
tahas left
j.rhas left
j.rhas joined
j.rhas left
j.rhas joined
Steve Killehas left
Steve Killehas joined
genofirehas left
genofirehas joined
j.rhas left
j.rhas joined
dedekinhas left
dedekinhas joined
alacerhas left
alacerhas joined
lnjhas joined
dedekinhas left
j.rhas left
j.rhas joined
dedekinhas joined
j.rhas left
j.rhas joined
alacerhas left
SeveI still don't receive emails from the members list. Can somebody double check, please?
SeveI'm not sure if my new email address was added.
j.rhas left
j.rhas joined
moparisthebesthas joined
alacerhas joined
moparisthebesthas joined
j.rhas left
j.rhas joined
APachhas left
dedekinhas left
j.rhas left
j.rhas joined
dedekinhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
APachhas joined
tahas left
Nekithas left
Nekithas joined
Str4tocasterhas left
Str4tocasterhas joined
Zashhas left
Zashhas joined
guusdkhas left
guusdkhas joined
labdsfhas left
labdsfhas joined
blablahas left
tahas left
lnjhas left
genofirehas left
genofirehas joined
genofirehas left
genofirehas joined
Steve Killehas left
Yagizahas joined
AlexSeve: which email address? i can check
SeveAlex, seve@delape.net, I used to have my JID the same as my email address before in case you see that still there
alacerhas left
AlexSeve: its there, but sais `nomail, reason B`
Alexlooks like you have disabled it once. I can revert he checkbox
Alexyou also maybe alble to congigure it here yourself here:
https://mail.jabber.org/mailman/admin/members/
or send commands to the list. Just let me know what you prefer
SeveThat's weird... Yes please do, Alex. Very appreciated!
alacerhas joined
Alexresetted, I think you should be good now
SeveAlex: thank you!
Str4tocasterhas left
Str4tocasterhas joined
lorddavidiiihas left
alacerhas left
lhas left
lhas joined
Zashhas left
alacerhas joined
lhas joined
danielhas left
danielhas joined
Zashhas left
Sevehas left
vaulorhas joined
404.cityhas joined
Yagizahas left
Yagizahas joined
lorddavidiiihas left
alacerhas left
SeveAlex, I have no password to edit it myself. I tried to see if I could ask for a new password and it says `Your subscription request has been received, and will soon be acted upon.`
I wonder if that has some relation to it?
alacerhas joined
Valerianhas left
Valerianhas joined
Str4tocasterhas left
Nekithas left
Nekithas joined
Str4tocasterhas joined
vanitasvitaehas left
alacerhas left
alacerhas joined
Valerianhas left
Valerianhas joined
danielhas left
danielhas joined
ThibGhas joined
ThibGhas joined
danielhas left
danielhas joined
Valerianhas left
matlaghas left
lnjhas joined
tuxhas joined
ragohas left
alacerhas left
danielhas left
danielhas joined
alacerhas joined
danielhas left
danielhas joined
ragohas joined
danielhas left
danielhas joined
Andrew Nenakhovhas left
ragohas left
Alexhas left
blablahas left
Andrew Nenakhovhas joined
ragohas left
lnjhas left
Andrew Nenakhovhas joined
blablahas left
alacerhas left
alacerhas joined
lhas left
lskdjfhas joined
lnjhas joined
Alexhas joined
Str4tocasterhas left
dedekinhas left
AlexSeve: lets see if you get new messages to the list. If not then please contact me again and we try to figure it out. To me it looks all good now.
j.rhas left
SeveSure, Alex. Thank you very much for your time, I will let you know :)
blablahas left
moparisthebesthas joined
j.rhas joined
moparisthebesthas left
Zashhas left
blablahas left
dedekinhas joined
matlaghas left
Zashhas left
ThibGhas joined
Valerianhas joined
matlaghas left
alacerhas left
matlaghas left
matlaghas left
dedekinhas left
ThibGhas joined
alacerhas joined
Zashhas left
Zashhas left
vanitasvitaehas left
dedekinhas joined
Valerianhas left
Valerianhas joined
Alexhas left
dedekinhas left
matlaghas left
dwdhas left
lhas joined
matlaghas left
labdsfhas left
labdsfhas joined
Yagizahas left
krauqhas left
krauqhas joined
Alexhas joined
andyhas left
lorddavidiiihas left
APachhas left
APachhas joined
jjrhhas left
jjrhhas left
efrithas joined
j.rhas left
tahas left
mrdoctorwhohas joined
j.rhas joined
Valerianhas left
Valerianhas joined
jjrhhas left
jjrhhas left
jjrhhas left
thorstenhas left
mrdoctorwhohas joined
jjrhhas left
waqashas joined
thorstenhas left
mrdoctorwhohas left
ragohas left
lumihas joined
thorstenhas left
thorstenhas left
Nekithas left
Nekithas joined
ragohas left
tahas left
tuxhas left
Tobiashas joined
Tobiashas joined
ralphmhas left
guusdkhas left
guusdkhas joined
Guushas left
Guushas joined
Ge0rGhas left
Valerianhas left
Valerianhas joined
!xsf_martinhas left
peterhas joined
dwdhas left
dwdhas joined
guusdkhas left
danielhas left
Nekithas left
Nekithas joined
Valerianhas left
Valerianhas joined
ragohas left
ragohas joined
ragohas left
Ge0rGhas left
Ge0rGhas left
Guushas left
Ge0rGhas left
Guushas joined
guusdkhas left
guusdkhas joined
Ge0rGhas joined
lskdjfhas left
alacerhas left
efrithas left
mightyBroccolihas left
mightyBroccolihas joined
lovetoxhas joined
sonnyhas left
Valerianhas left
Valerianhas joined
labdsfhas left
mimi89999has joined
tahas left
tahas joined
lhas joined
lskdjfhas joined
krauqhas left
krauqhas joined
tuxhas left
Yagizahas joined
guusdkhas left
vanitasvitaehas left
Valerianhas left
Valerianhas joined
Sevehas joined
lhas left
lskdjfhas joined
vaulorhas joined
sonnyhas joined
Steve Killehas left
Steve Killehas left
danielhas joined
Valerianhas left
Steve Killehas joined
Valerianhas joined
jonas’in-band bytestreams. is there a way to close an IBB with an error?
jonas’in-band bytestreams. is there a way to close an IBB with an error while the peer is *not* sending to you?
marchas joined
SamWhitedhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Ge0rGjonas’: remember the last incoming message id?
flowjonas’, can't you always send a session-terminate (if we are talking Jingle based IBB)?
ralphmhas left
Alexhas left
Nekithas left
Nekithas joined
Yagizahas left
Steve Killehas left
Kevhas left
Yagizahas joined
vanitasvitaehas joined
dwdhas left
edhelashas left
edhelashas joined
Valerianhas left
Valerianhas joined
lorddavidiiihas left
Yagizahas left
jjrhhas left
guusdkhas left
lskdjfhas left
lhas left
marchas left
labdsfhas joined
marchas joined
jjrhhas left
jonas’flow, no, plain IBB
ThibGhas joined
guusdkhas left
guusdkhas joined
labdsfhas left
labdsfhas joined
guusdkhas joined
jjrhhas left
Alexhas joined
sonnyhas joined
sonnyhas joined
sonnyhas joined
Valerianhas left
jjrhhas left
labdsfhas left
labdsfhas joined
jjrhhas left
guusdkhas left
guusdkhas joined
Steve Killehas left
sonnyhas left
genofirehas left
lumihas joined
!xsf_martinhas joined
!xsf_martinhas joined
matlaghas left
tahas joined
tahas joined
Valerianhas joined
lskdjfhas joined
Valerianhas left
Valerianhas joined
jjrhhas left
labdsfhas left
Link Mauvejonas’, AFAIK you can’t even do that if they’re sending to you, since they could use the <message/> transport.
Valerianhas left
Valerianhas joined
labdsfhas joined
jjrhhas left
labdsfhas left
labdsfhas joined
lorddavidiiihas left
dwdhas joined
!xsf_martinhas left
Valerianhas left
Valerianhas joined
MattJ<message type='error' id='...'>
Lancehas joined
dwdhas left
jjrhhas left
lnjhas left
jjrhhas left
Valerianhas left
Valerianhas joined
lovetoxhas left
Ge0rGSpeaking of which, can we get error messages stored in offline storage, because Carbons and multi client?
MattJYes
tahas left
lovetoxhas joined
tahas joined
tahas left
tahas joined
!xsf_martinhas joined
rionhas left
j.rhas joined
j.rhas joined
jjrhhas left
valohas left
valohas joined
Kevhas joined
tahas joined
tahas joined
Ge0rGMattJ: In prosody 0.10?
MattJ"LOL"
HolgerGe0rG: You mean in MAM?
dwdhas joined
jjrhhas left
Ge0rGHolger: MAM is not needed if you have per device offline storage queues
Kevhas left
HolgerHah.
HolgerWhy proper solutions if we can have ugly hacks!
Ge0rGAnd my evil secret plan is to defer implementing MAM in yaxim (and annoying MattJ with message loss) until he gives up and finishes client tracking
lnjhas left
Ge0rGHolger: MAM is an ugly hack.
lnjhas left
HolgerHow do you handle outgoing messages with offline storage? Wait whether the client enables carbons and then push them out?
HolgerHow do you do paging?
jonas’different use-cases
HolgerHm?
jonas’although
jonas’ignore me, I want to see how this plays out
dwdhas left
Ge0rGHolger: how do you handle sync of messages between MAM and offline? Just drop all offline messages before sending presence?
lorddavidiiihas left
HolgerThat's what Conversations does, the alternative is de-dup, obviously.
HolgerWhatever that has to do with my question.
Alexhas left
Tobiashas joined
Tobiashas joined
HolgerI think MAM becomes problematic to implement if you *don't* want full-sync. If you do, like you'd get with per-device offline storage, it's trivial. I don't get why you wouldn't just want to implement this.
SamWhitedhas left
Ge0rGHolger: MAM is *also* a dirty hack. Is it better now?
HolgerOk, so that's go for a worse hack instead.
Ge0rGHolger: because it's complicated with my current code base
tahas joined
Ge0rGHolger: MAM is the worse hack.
HolgerWhy?
Ge0rGActually sending out Carbons from offline is a I nice idea
lnjhas joined
HolgerHaha.
Ge0rGHolger: it's full of race conditions!
HolgerFor example?
Ge0rGYou don't need paging if you do full sync.
Ge0rGHolger: between querying MAM and dropping offline history
ZashIt's dirty hacks all the way down to the silicon
tahas left
tahas joined
Ge0rGHolger: also between completing your MAM sync and receiving first live messages
jonas’Ge0rG, isn’t bind2 there to solve all those races?
Ge0rGjonas’: yes
jonas’purge offline, enable carbons, give you the id of the last stanza in MAM
marchas left
marchas joined
Ge0rGjonas’: also magically enable / resume SM
HolgerUntil we have that, de-dup should be trivial using stanza-IDs.
Ge0rGHolger: you mean unique ids?
Ge0rGWill MAM inject ids into offline storage?
Holgermam:2 guarantees that, yes.
danielFwiw Conversations would handle the dedup just fine. But I don't like the extra traffic
jjrhhas left
Ge0rGBut if you just drop offline history, you'll get message loss if your MAM is "contacts only"
HolgerYes, I don't know why we offer that option.
danielYep
Ge0rGAnd dropping before MAM sync is lossy
danielOr disabled
HolgerYou get even more message loss if MAM is disabled.
HolgerRight.
danielI'd like the mam preference to be announced in disco
danielThat could help circumvent that problem
Ge0rGdaniel: you drop offline history if MAM is disabled???
HolgerI'd like to see the "contacts only" option ditched.
danielGe0rG: yes
Ge0rGdaniel: ...
Holger> You don't need paging if you do full sync.
You might need it for traffic throtting. Otherwise the server will flood you with messages and if you're not fast enough with acknowledging it, you'll exceed 0198 queue size limits and the server will kill your connection.
Holger*throttling
!xsf_martinhas left
HolgerI open yaxim once in a few weeks, it would become unusable if I implemented that thing.
jonas’Holger, FWIW, Conversations *is* unusable when you open it only once in a few weeks.
Zashand Gajim
jonas’or even once a week
jonas’I plan for like one hour or maybe two for it to sync when I haven’t used it for a week
Holgerjonas': Hm no I didn't run into that.
jonas’maybe it’s just me or my device?
jonas’ever since that full text search index each message takes like 0.5s to process
jonas’you can do the math with a few public MAM’d MUCs.
Link MauveZash, Gajim fixed that (for public MUCs only) in their latest release from today.
jonas’it’s terrible in any case.
ZashLink Mauve: By some random coincidence, I can't start Gajim anymore
Ge0rGXMPP is terrible.
Ge0rG&
jonas’fg
Link MauveThat may be related, you should report this bug at gajim@conference.gajim.org.
Link MauveMaybe they’ll do a 1.1.1 fixing it.
vanitasvitaehas left
jjrhhas left
ZashI think it's some Python search path thing
lnjhas left
sonnyhas joined
SamWhitedhas left
SamWhitedhas joined
mimi89999has left
!xsf_martinhas joined
goffihas left
Lancehas left
alacerhas joined
lorddavidiiihas left
alacerhas left
Alexhas joined
jjrhhas left
lumihas joined
sonnyhas left
Valerianhas left
MattJhas joined
lovetoxyes the user can set a threshold now for public mucs how much gets synced
lovetoxand the default is 1 day, if you join 20 mucs, you still can expect around 30 seconds until everything is joined and everything is synced
Valerianhas joined
lovetoxproblem is, you absolutly have to sync everything at start with MUC
lovetoxotherwise you just plain accept not delivering messages to your user that he might want to read
lovetoxim not seeing how we can optimize that in any way
marchas left
danielThe problem is that 1 day is pretty random. On some days you just have one message in the last 24h on some days you have 1000
danielI'm considering - for public mucs - to just ditch the entire history instead
danielThen normal backlog scrolling works as intended
danielInstead of trying to fill gaps or what ever
danielBut nothing is ideal. There is no good solution
lovetoxso not storing messages in public muc to db, and making it completly load on demand
danielYes
lovetoxyes the only way back scrolling can work i think
daniel*in public with mam
lovetoxbut this is probably acceptable for a mobile client, but if i do this in Gajim people will scream
danielWhy?
Kevhas joined
tahas joined
lovetoxthey have there 200 MB "i have logs back to 1990" dbs
lovetoxand want to search them
Kevhas left
lovetoxbut yeah indeed nothing speaks against making it default not storing, and if a user wishes he can store for some mucs
lovetoxbut then no backscrolling there
lovetoxmaybe thats a good solution for both worlds
rionhas left
danielYeah I haven't thought this all the way through yet. It's just that idea I'm having
danielEspecially for mobile and like short outages you might still want to have a local history
danielBut certainly not catch up with a week or so
jjrhhas left
lovetoxand the whole backscrolling thing can get pretty easy if client devs could depend on the server using sequential mam ids
lovetoxthen its trivial to fill a whole
lovetoxi still think whatever reason that was why this was dismissed in the XEP, was not worth it at all
jjrhhas left
lovetoxbut mam exists a long time now, maybe we should ask around, and if there is no implementation that depends on mam ids not beeing sequential (because they technically can not do it) then just ditch this, there is no need for something that limiting us, that nobody plans to use anyway
sonnyhas joined
sonnyhas joined
sonnyhas joined
sonnyhas joined
sonnyhas joined
sonnyhas joined
danielIt's complicated on a database level
danielEither pretty expensive or impossible in clusters
lovetoxhm doubt it seriously :D
lovetoxits just that it would be probably considerable more work to make it so
lovetoxbut then again, where are these clusters, are we writing xeps for that one provider in X years that sets up a cluster
lovetoxor for the 1000s who do not
lovetoxbut i guess we had this discussion, the conclusion was, add a disco feature
lovetox"sequential-ids"
sonnyhas joined
lovetoxif i see this i offer back scrolling, if not i dont
jjrhhas left
HolgerWell there certainly are clustered setups in practice and I wouldn't want to tell people "sorry XMPP doesn't support this".
lovetoxis ejabberd not a bad example, as you offer sequential ids :D
Holgerlovetox: I forgot, you actually need sequential IDs or are increasing IDs (i.e. ejabberd's timestamps) good enough to solve the problem?
jjrhhas left
danielIf the use case is to know the gaps you need sequential and not just increasing
lovetoxmaybe im getting my definitions wrong, but sequential and increasing are not counterpars
Holgerlovetox: Yeah these days we just ignore the clustering issue because it's somewhat academic in practice. With microsecond timestamps you won't end up with non-unique IDs, or if you ever manage to, then wow you have a message loss/duplicate. This is XMPP after all.
danielAnd that's complicated even on an single db
Valerianhas left
danielI mean can you tell me the sql command for insert with id=max(I'd) +1?
HolgerDon't SQL engines have this built-in? But that'll obviously be expensive on a cluster, yes.
danielI think the bad ones do
Holgerlovetox: Sequential is 1,2,3,4, incrementing is 1,4,394,1039.
lovetoxthen incrementing is enough
danielBut from my understanding you try to avoid this in db design
daniellovetox: how do you find gaps then?
lovetoxyeah this fixes just the message ordering problem
lovetoxyou still have to track gaps somehow
jjrhhas left
ZashI started writing a thing based on linked lists once
ZashSo what problem can I solve by tagging each message with the id of the previous message?
HolgerYou solve the same problems and run into the same problems as with sequential IDs, no?
ZashGiven a bag of unordered messages, you can shuffle them into sequences, no?
HolgerI guess what you do these days is DAGs, i.e. you can add a merge message that has multiple parents once the cluster notices the conflict. Leave it to clients to cope with it.
lovetoxthe problems we are facing are two fold,
1. have a way to determine where you have a gap in your local storage and fill it efficiently by requesting from mam
2. If you start your client, display all messages in the correct order
tahas left
tahas joined
lovetox2. can be solved by just increasing IDs, or just microtimestamp
flow> 1 day is pretty random
flowmake mam allow query the last N stanzas?
Zashflow: ... <before/N>
lovetoxwe can do this already
Zashwait no, before="" max=N
Zashhigh resolution timestamps has problems too
Zashlike like being unavailable from C stdlib
lovetoxmaybe the server can solve 1. for us, what if we have a query i give 2 mam-ids, can the server tell me if there are messages in between?
Zashand also having no guarantee of being strictly increasing
flowlovetox, then why 1 day and not, say, 100 messages?
lovetoxZash its enough if its most unlikely to produce duplicates
lovetoxi can live with a duplicated timestamp 1 out of a million messages
flowHolger, are you talking about Matrix? :)
flowbut serious, this sounds appealing
HolgerZash: The C standard doesn't return the current time at all, no? So you can't implement MAM with it anyway.
valohas joined
lovetoxflow it can be done, but its not the same thing, last 100 can only be done by backpaging
lovetoxyou get the last 10
lovetoxthen 10 before that etc
Holgerflow: Yeah Matrix and I think various other distributed DBs are doing it that way.
lovetoxwhile from a date, gives you all messages orderd from old to new
HolgerAnd all those DCVSes ...
lovetoxand this is pretty important, because i need the messages sent ordered to me
flowlovetox, ahh so MAM is missing a "give me the last N messages starting with the oldest" query?
lovetoxi dont know if it needs it .. but yes i guess would be nice
flow(I think we possibly have been there before)
lovetoxi more and more think, maybe we dont need this at all, internet gets faster and faster, if i join a muc i show a loading screen and count the messages with a nice UI
Zashflow: I don't think MAM is missing query related things like that
lovetoxso the client needs 30 seconds, if you dont start it a week, so what?
lovetoxshow me an application that does it much better
lskdjfhas left
lskdjfhas left
jjrhhas left
flowZash, possibly, possibly not
flowlovetox, na, that's not what drives me, but I can see why one could be happy with that
ZashFetch the last chunk of messages and show them. Then do the sync thing quietly in the background.
tahas joined
flowZash, fetch using <before/> and max=N?
Zashflow: right
lovetoxi could pull with before say 20 messages, but dont store them to db then sync the db in the background
flowDunno, I think you run in all kinds of oddities with current MAM
lovetoxbut there is no "background"
lovetoxthere is only one connection to the server
lovetoxand it will be slow to the user if i fetch stuff contstantly
lovetoxit would be nice to know what the user wants to do and priorities that
lovetoxbut he could switch to any muc instantly and then i need the full stuff there
flowlovetox, do small chunks of background sync and pause them once such "high priority" things happen?
lovetoxand all that seems rather complex, instead of just a loading screen
lovetox:D
flowor just do small chunks and see if it turns out to be a real issue
flowbefore we are talking about potential solutions for non-issues ;)
lumihas left
matlaghas left
lovetoxjoining 20 mucs is also slow if you dont fetch MAM at all
lskdjfhas left
ZashIt is
lskdjfhas left
flowhmm, dunno, my poezio joins the ~15 MUCs reasonably fast I'd say, but YMMV
404.cityhas left
lovetoxyeah can you give me a time on that?
lovetoxjust so i have something to compare Gajim with
lskdjfhas left
flowlovetox, a few seconds I'd say, but it is really hard to tell as the UI elements are already seen even if the MUC is still in the process of joining
tahas joined
lovetoxhm other topic, nickname conflicts when joining a muc how do clients handle these
tahas joined
lovetoxgajim does a popup and the user has to choose another nick
lovetoxbut im thinking i dont want to ask the user anymore and just join with a added "_" or something like that