jonaswnot sure what you expect me to do with it though
Zashjonasw: me neither
jonaswokay :)
jonaswthen I’m just going to ignore that for now
Steve Killehas left
goffihas joined
Steve Killehas left
Flowhas left
la|r|mahas joined
jcbrandhas joined
Flowhas joined
jubalhhas joined
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
Alexhas joined
ralphmhas joined
ralphmhas joined
ralphmhas joined
Martinhas joined
Martinhas left
danielhas left
danielhas joined
jubalhhas left
efrithas joined
ralphmhas joined
la|r|mahas joined
la|r|mahas joined
jubalhhas joined
Alexhas left
stefandxmhas left
sonnyhas joined
sonnyhas joined
Alexhas joined
stefandxmhas joined
jonaswhas left
Steve Killehas left
Steve Killehas joined
stefandxmhas left
stefandxmhas joined
stefandxmhas left
stefandxmhas joined
jubalhhas left
efrithas left
efrithas joined
lskdjfhas joined
danielhas left
danielhas joined
efrithas left
efrithas joined
lskdjfhas left
lskdjfhas joined
jcbrandhas left
stefandxmhas left
stefandxmhas joined
jcbrandhas joined
Vaulorhas joined
lumihas joined
Guushas left
efrithas left
jubalhhas joined
efrithas joined
Guushas left
ralphmhas joined
Guushas left
Tobiashas joined
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
Wiktorhas joined
blablahas left
blablahas joined
stefandxmhas left
stefandxmhas joined
efrithas left
jubalhhas left
Zashhas left
Tobiashas joined
jcbrandhas left
nycohas left
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
nycohas joined
ralphmhas joined
fp-testerhas left
fp-testerhas left
fp-testerhas joined
jcbrandhas joined
jubalhhas left
danielhas left
danielhas joined
danielhas left
danielhas joined
Guushas left
jcbrandhas left
ralphmhas left
stefandxmhas left
stefandxmhas joined
jerehas joined
Yagizahas joined
Guushas left
Wiktorhas joined
danielhas left
danielhas joined
jcbrandhas joined
dwdhas left
ralphmhas joined
jjrhhas left
stefandxmhas left
stefandxmhas joined
uchas left
jjrhhas left
jjrhhas left
jjrhhas left
Flowhas left
jjrhhas left
jjrhhas left
jjrhhas left
jjrhhas left
ralphmhas joined
waqashas joined
Ge0rGIs there any way to mark a message as related to some other message, without specifying the exact type of relation? We have 0372 for explicit references, <thread>s, LMC, but they all imply a certain relationship
jonaswwhat is the use-case?
Ge0rGjonasw: MAM - when a given message is asked for, it is useful to provide all the related messages as well.
lovetoxhas joined
jonaswI’m not convinced
jonaswat least not as default behaviour
Ge0rGjonasw: some messages only make sense on top of others, e.g. reactions or LMC
jonaswsure
Ge0rGjonasw: it would be impractical to deliver only the addon message but not the original one
jonaswfor reactions, I’d simply omit those
jonasw(in the view that is)
Ge0rGjonasw: if your client receives a reaction message with a dangling reference, you need to store the XML and process it later when the actual message is obtained.
jonaswyes.
jonaswI don’t necessarily see an issue with that
jonaswwhile handling out-of-order messages is more annoying
edhelasthe new CSS breaks horizontal scrolling on some XEPs https://xmpp.org/extensions/xep-0385.html
jonaswscrolling works, but indeed it’s an issue that it’s required
jonaswedhelas, can you make an issue on the xeps repository?
Ge0rG385 is just too wide.
emxphas joined
edhelasjonasw done
jonaswedhelas, thanks
jonaswGe0rG, we can’t go over all XEPs to fix that
Ge0rGjonasw: we could define a common mechanism to cross-reference messages and use that?
jonaswwell, we could, but ...
Ge0rGbut.
jonaswGe0rG, sure, yet-another-standard? :)
Ge0rGjonasw: stop spoiling the fun!
edhelasit's possible in CSS to break lines properly
jonaswedhelas, auto-breaking of lines in code examples sounds like a bad idea
edhelasI also have a question
jonaswGe0rG, you’d want to rebase the existing use-cases (LMC etc.) on that, and especially with LMC I see a lot of breakage from that...
edhelasI'm planning to use MAM to retrieve MUC histories, is it possible to disable the default messages pushed by the server on login ?
SamWhitedYah, in that case the real reason this doesn't support it is that HipChat doesn't support it and I was never going to be able to convince them to let me ad even more stuff.
SamWhitedGe0rG: Do you think you'd want to use it for something? If so I wouldn't mind updating it to use the unique ID stuff
Ge0rGSamWhited: some weeks ago, the topic of grouping messages when delivering MAM data came up here
moparisthebestjust curious, how do you know messages are related?
Ge0rGmoparisthebest: that's the challenge
moparisthebestlike these might be in response to your stuff, in fact they are, but they might just be a random unrelated topic
SamWhitedOh, this is for grouping messages sent in reply to another message? That seems different to me
moparisthebestthat seems like an unsolvable challenge from an automated perspective, so a xep to support the grouping seems useless
SamWhitedactually, maybe not…
Ge0rGSamWhited: it's about finding out which messages are related to each other
SamWhitedI agree with half of what moparisthebest said; it seems unsolvable if you're trying to automate it. That doesn't mean you can't have a good UI that leads the user to do the work for you.
moparisthebestI don't think you can and that's why it just returns the last X or whatever
moparisthebestSamWhited, if I respond to you like this I guess you could call those grouped (by putting your name first)
jonaswthe relation is already spelled out in the XML (LMC, Reactions...)
jonaswthere’s just no unified way to detect it
jonasw(it’s, from my understanding, not about generic replies)
SamWhitedmoparisthebest: That seems like a sensible guess
SamWhitedThis seems more like what <thread> is for though
Ge0rGSamWhited: I'm not speaking about message that have content that relates to other messages
Ge0rGSamWhited: I'm speaking about technical dependencies, like "this message is a reaction to message XY"
Ge0rGso it doesn't make sense to parse / display the message without also having XY
SamWhitedoh yes, that's what I thought you meant originally, yah, that's totally what this is for
SamWhitedI think… you mean things like clients having a +1 button or a party hat button or something?
Ge0rGso it would make sense, in the context of MAM, to use unique IDs
jonaswSamWhited, yes
Ge0rGSamWhited: yeah
SamWhitedCool, yah, moparisthebest was confusing me :)
SamWhitedThat is indeed what this was made for
jonaswso let’s rebase xep-0367 on stable & unique message IDs and build a reactions XEP on top of that
Ge0rGjonasw: +1
Ge0rGExcept...
jonaswyou want me to do the work, right? ;P
Ge0rGYou still don't know the unique message ID of outgoing messages.
SamWhitedI don't remember the MID spec, but it allows clients to assign one too, right?
jonaswSamWhited, indeed
SamWhited¯\_(ツ)_/¯ problem solved
jonaswso called origin-id
Ge0rGBut MAM operates on the server-assigned ID
SamWhitedThat seems fine; MAM operates on server assigned ID, this operates on client assigned ones.
jonaswit would be convenient if the client could query MAM for the message if MAM doesn’t support grouping
jonasw(the proposed grouping that is)
jonaswalternatively, we could modify MAM to adopt the client-generated origin-id for sent messages iff it doesn’t conflict with any existing ID (and maybe reject delivery otherwise or something)
Ge0rGI'm sure somebody will pull the "omg security!1!" card on that.
moparisthebestGe0rG: "this message is a reaction to message XY" -- how do you know that though?
jonaswmoparisthebest, reaction as in "+1 button"
jonaswnot as I react to your message right now
jonaswGe0rG, how?
jonasw(and isn’t that usually your job?)
moparisthebesthe said 'this message is a reaction' not 'I hit a +1' (is +1 a thing in xmpp or any clients?)
jonaswnot yet, that’s the point
jonaswand those "+1 buttons" are usually called reactions
jonaswe.g. on github
Ge0rGjonasw: let's see... if the server is using a typical hash-table implementation, a client could DoS it by contructing specially-chosen UUIDs.
jonasw(I don’t know of any non-biboumi MUCs which support that)
edhelaslooks like I'm wrong somewhere
jonaswedhelas, also, this may be better suited in jdev@
Ge0rGjonasw: yeah. Because it's a good thing to have three different IDs on each message.
edhelasa true
edhelassory
jonaswGe0rG, m(
jonaswwhy exactly is a mam query a type='set' operation?!
Ge0rGoh, wait. those IDs are all insufficient in some ways. Let's create a new XEP with a fourth, universal ID!
jonaswGe0rG, any other suggestion? other than getting a sent-carbon for your own message with the MAM ID >.>
SamWhitedhmm, I guess querying MAM for "a message and all of its reactions" would be sort of nice. I'm not sure if it's strictly necessary though.
Ge0rGjonasw: that was exactly what I proposed back then.
SamWhitedIt seems to add another dimension of complication for something that could easily be lived without.
Guushas left
Ge0rGSamWhited: the problem is not "a message and all of its reactions" but rather "the message and all the messages you need to properly understand it"
SamWhitedWhy would you ever actually need to do that? I don't dislike the idea of making sure that's queryable, it just doesn't seem like a common enough thing to worry about.
Ge0rGSamWhited: if you receive a reaction message with an unresolved reference ID, you need to delay processing until you know what it is a reaction to
SamWhitedI suspect 90% of people will just sync history and you'll see new reactions appearing as history gets updated
SamWhitedThat seems fine
jonaswI tend to agree
Neustradamushas joined
Ge0rGI tend to process messages when they are received, but that doesn't work with missing references.
waqashas left
jonaswthe argument Ge0rG makes is in the spirit of the "simple clients, complex servers" principle though
SamWhitedDoes MAM not guarantee delivery order?
SamWhitedOh, nevermind, stupid question
jonaswok :)
SamWhitedIf you have a reaction and *then* you sync history it doesn't matter what MAM does.
Ge0rGSamWhited: it only guarantees the order for the subset you request.
SamWhitedyup, yup
SamWhitedSo in that case though you end up having to make a MAM query, then for each message make another query asking if there are any reactions you haven't received yet
Ge0rGif there are any messages for a given reaction.
jonaswSamWhited, no, the idea would be that the original MAM query would give you all messages to which there have been reactions in the result setd
jonasw(even though they may be outside the range of messages you requested)
Ge0rGjonasw: but that would violate message order, and lead to interesting results.
SamWhitedThis seems like a lot of additional complexity when you could just store your reactions somewhere on the client and when you get a message if you have reactions in storage already display them.
SamWhitedOr when you get a reaction, if you have the message its linked to, also display it.
Ge0rGexample: you request 50 messages before #103. you get #53-#102 and #40 because it was reacted to. Next, you request 50 messages before #40, because it is the earliest in your history. #41-#52 are lost
jonaswGe0rG, all depends on the sanity of your implementation
Ge0rGSamWhited: that makes (limited) sense if you store the original message XML somewhere
jonaswGe0rG, do you really need the XML? I don’t think so.
SamWhitedGe0rG: I don't think the storage format matters
Ge0rGSamWhited: but then you end up searching your storage for a reference to each new message you receive.
SamWhitedGe0rG: That seems fine
Alexhas left
Ge0rGpulls the client DoS card.
jonaswI pull the "use a proper storage backend" card
SamWhitedThere is no client DoS card.
jonaswe.g. a simple sqlite database
jonaswjust add a column "reaction_to" with a stable message ID thing
jonaswadd an index to it
jonasw-> reasonable lookup time
jonaswyou also only need to do that for messages you fetch from the archive
SamWhitedFlat XML files are probably fine, you are going to get a bunch of stuff to store, that's just how XMPP works. If you're worried about scans and lookup times, its your job to do something intelligent and make sure you don't dos yourself.
SamWhitedMaybe that means creating an "unknown references" file to make scanning quicker, maybe it means using a database. That's up to you.
Ge0rGI wish for the times when XMPP servers were complicated and XMPP clients were simple.
SamWhitedI agree with that in general, but this doesn't make the XMPP client complicated; it makes it a dumb display layer that doesn't have to have a ton of logic about doing crazy MAM queries.
SamWhitedIt can just keep doing whatever it was already doing and process things as they come in. It might be processing the reaction, or it might be processing the message in terms of reactions it already has.
moparisthebestdo clients generally do mam queries reversed like that?
moparisthebestconversations doesn't seem to, it seems to start loading from your last message and go forward
moparisthebestin which case everything *just works*
Ge0rGmoparisthebest: I think there are two models of MAM usage: (a) query for everything since your last connection, (b) query a given channel / user history on demand when opening the tab
edhelashas left
edhelashas joined
moparisthebestoh I was waiting for b until I just realized gajim made that into a beer...
Ge0rG"Clients and servers MUST NOT include an <attach-to/> element on messages with a non-messaging payload unless they are including it on an error which may be attached to the message that caused the error to be generated."
What is a "non-messaging payload"?
SamWhitedNo idea, no <body> I guess? That should probably be fixed.
SamWhitedOr just removed, I don't see the point in that restriction anymore.
stefandxmhas left
stefandxmhas joined
sonnyhas joined
ralphmhas joined
waqashas joined
la|r|mahas joined
jubalhhas left
danielhas left
jubalhhas joined
danielhas joined
edhelashas left
Ge0rGSamWhited: for reactions, I'd go with a separate non-<body> element, because people in here demanded invisibility to incompatible clients
stefandxmhas left
sonnyhas joined
Ge0rGAnd because it will be awesome to have to change all the implementations that filter out body-less messages as "unimportant".
SamWhitedyah, just removing those lines from message attatching seems reasonable
XSF Discussion - 2017-09-21