Is 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
jonasw
what is the use-case?
Ge0rG
jonasw: MAM - when a given message is asked for, it is useful to provide all the related messages as well.
lovetoxhas joined
jonasw
I’m not convinced
jonasw
at least not as default behaviour
Ge0rG
jonasw: some messages only make sense on top of others, e.g. reactions or LMC
jonasw
sure
Ge0rG
jonasw: it would be impractical to deliver only the addon message but not the original one
jonasw
for reactions, I’d simply omit those
jonasw
(in the view that is)
Ge0rG
jonasw: 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.
jonasw
yes.
jonasw
I don’t necessarily see an issue with that
jonasw
while handling out-of-order messages is more annoying
edhelas
the new CSS breaks horizontal scrolling on some XEPs https://xmpp.org/extensions/xep-0385.html
jonasw
scrolling works, but indeed it’s an issue that it’s required
jonasw
edhelas, can you make an issue on the xeps repository?
Ge0rG
385 is just too wide.
emxphas joined
edhelas
jonasw done
jonasw
edhelas, thanks
jonasw
Ge0rG, we can’t go over all XEPs to fix that
Ge0rG
jonasw: we could define a common mechanism to cross-reference messages and use that?
jonasw
well, we could, but ...
Ge0rG
but.
jonasw
Ge0rG, sure, yet-another-standard? :)
Ge0rG
jonasw: stop spoiling the fun!
edhelas
it's possible in CSS to break lines properly
jonasw
edhelas, auto-breaking of lines in code examples sounds like a bad idea
edhelas
I also have a question
jonasw
Ge0rG, 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...
edhelas
I'm planning to use MAM to retrieve MUC histories, is it possible to disable the default messages pushed by the server on login ?
Yah, 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.
SamWhited
Ge0rG: 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
Ge0rG
SamWhited: some weeks ago, the topic of grouping messages when delivering MAM data came up here
moparisthebest
just curious, how do you know messages are related?
Ge0rG
moparisthebest: that's the challenge
moparisthebest
like these might be in response to your stuff, in fact they are, but they might just be a random unrelated topic
SamWhited
Oh, this is for grouping messages sent in reply to another message? That seems different to me
moparisthebest
that seems like an unsolvable challenge from an automated perspective, so a xep to support the grouping seems useless
SamWhited
actually, maybe not…
Ge0rG
SamWhited: it's about finding out which messages are related to each other
SamWhited
I 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.
moparisthebest
I don't think you can and that's why it just returns the last X or whatever
moparisthebest
SamWhited, if I respond to you like this I guess you could call those grouped (by putting your name first)
jonasw
the relation is already spelled out in the XML (LMC, Reactions...)
jonasw
there’s just no unified way to detect it
jonasw
(it’s, from my understanding, not about generic replies)
SamWhited
moparisthebest: That seems like a sensible guess
SamWhited
This seems more like what <thread> is for though
Ge0rG
SamWhited: I'm not speaking about message that have content that relates to other messages
Ge0rG
SamWhited: I'm speaking about technical dependencies, like "this message is a reaction to message XY"
Ge0rG
so it doesn't make sense to parse / display the message without also having XY
SamWhited
oh yes, that's what I thought you meant originally, yah, that's totally what this is for
SamWhited
I think… you mean things like clients having a +1 button or a party hat button or something?
Ge0rG
so it would make sense, in the context of MAM, to use unique IDs
jonasw
SamWhited, yes
Ge0rG
SamWhited: yeah
SamWhited
Cool, yah, moparisthebest was confusing me :)
SamWhited
That is indeed what this was made for
jonasw
so let’s rebase xep-0367 on stable & unique message IDs and build a reactions XEP on top of that
Ge0rG
jonasw: +1
Ge0rG
Except...
jonasw
you want me to do the work, right? ;P
Ge0rG
You still don't know the unique message ID of outgoing messages.
SamWhited
I don't remember the MID spec, but it allows clients to assign one too, right?
jonasw
SamWhited, indeed
SamWhited
¯\_(ツ)_/¯ problem solved
jonasw
so called origin-id
Ge0rG
But MAM operates on the server-assigned ID
SamWhited
That seems fine; MAM operates on server assigned ID, this operates on client assigned ones.
jonasw
it would be convenient if the client could query MAM for the message if MAM doesn’t support grouping
jonasw
(the proposed grouping that is)
jonasw
alternatively, 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)
Ge0rG
I'm sure somebody will pull the "omg security!1!" card on that.
moparisthebest
Ge0rG: "this message is a reaction to message XY" -- how do you know that though?
jonasw
moparisthebest, reaction as in "+1 button"
jonasw
not as I react to your message right now
jonasw
Ge0rG, how?
jonasw
(and isn’t that usually your job?)
moparisthebest
he said 'this message is a reaction' not 'I hit a +1' (is +1 a thing in xmpp or any clients?)
jonasw
not yet, that’s the point
jonasw
and those "+1 buttons" are usually called reactions
jonasw
e.g. on github
Ge0rG
jonasw: let's see... if the server is using a typical hash-table implementation, a client could DoS it by contructing specially-chosen UUIDs.
jonasw
Ge0rG, meeeh :P
jonasw
just don’t tell clients your hash seed?
la|r|mahas joined
Ge0rG
This one! https://arstechnica.com/information-technology/2011/12/huge-portions-of-web-vulnerable-to-hashing-denial-of-service-attack/
jonasw
that’s a general vector, and afaict choosing a random hash seed is sufficient to fix that
Ge0rG
jonasw: I'm sure it's possible to extract the seed via side-channel attacks
jonasw
Ge0rG, *sigh*
jonasw
then we’ll have to operate on the client-generated ID. it’s saner anyways, because it works without MAM
jonasw
MAM will have to interpret these IDs then and intrenally store their relatedness for queries
edhelas
what is the correct request to get MAM history from MUC ?
(I don’t know of any non-biboumi MUCs which support that)
edhelas
looks like I'm wrong somewhere
jonasw
edhelas, also, this may be better suited in jdev@
Ge0rG
jonasw: yeah. Because it's a good thing to have three different IDs on each message.
edhelas
a true
edhelas
sory
jonasw
Ge0rG, m(
jonasw
why exactly is a mam query a type='set' operation?!
Ge0rG
oh, wait. those IDs are all insufficient in some ways. Let's create a new XEP with a fourth, universal ID!
jonasw
Ge0rG, any other suggestion? other than getting a sent-carbon for your own message with the MAM ID >.>
SamWhited
hmm, 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.
Ge0rG
jonasw: that was exactly what I proposed back then.
SamWhited
It seems to add another dimension of complication for something that could easily be lived without.
Guushas left
Ge0rG
SamWhited: 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"
SamWhited
Why 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.
Ge0rG
SamWhited: 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
SamWhited
I suspect 90% of people will just sync history and you'll see new reactions appearing as history gets updated
SamWhited
That seems fine
jonasw
I tend to agree
Neustradamushas joined
Ge0rG
I tend to process messages when they are received, but that doesn't work with missing references.
waqashas left
jonasw
the argument Ge0rG makes is in the spirit of the "simple clients, complex servers" principle though
SamWhited
Does MAM not guarantee delivery order?
SamWhited
Oh, nevermind, stupid question
jonasw
ok :)
SamWhited
If you have a reaction and *then* you sync history it doesn't matter what MAM does.
Ge0rG
SamWhited: it only guarantees the order for the subset you request.
SamWhited
yup, yup
SamWhited
So 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
Ge0rG
if there are any messages for a given reaction.
jonasw
SamWhited, 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)
Ge0rG
jonasw: but that would violate message order, and lead to interesting results.
SamWhited
This 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.
SamWhited
Or when you get a reaction, if you have the message its linked to, also display it.
Ge0rG
example: 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
jonasw
Ge0rG, all depends on the sanity of your implementation
Ge0rG
SamWhited: that makes (limited) sense if you store the original message XML somewhere
jonasw
Ge0rG, do you really need the XML? I don’t think so.
SamWhited
Ge0rG: I don't think the storage format matters
Ge0rG
SamWhited: but then you end up searching your storage for a reference to each new message you receive.
SamWhited
Ge0rG: That seems fine
Alexhas left
Ge0rGpulls the client DoS card.
jonasw
I pull the "use a proper storage backend" card
SamWhited
There is no client DoS card.
jonasw
e.g. a simple sqlite database
jonasw
just add a column "reaction_to" with a stable message ID thing
jonasw
add an index to it
jonasw
-> reasonable lookup time
jonasw
you also only need to do that for messages you fetch from the archive
SamWhited
Flat 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.
SamWhited
Maybe that means creating an "unknown references" file to make scanning quicker, maybe it means using a database. That's up to you.
Ge0rG
I wish for the times when XMPP servers were complicated and XMPP clients were simple.
SamWhited
I 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.
SamWhited
It 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.
moparisthebest
do clients generally do mam queries reversed like that?
moparisthebest
conversations doesn't seem to, it seems to start loading from your last message and go forward
moparisthebest
in which case everything *just works*
Ge0rG
moparisthebest: 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
moparisthebest
oh 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"?
SamWhited
No idea, no <body> I guess? That should probably be fixed.
SamWhited
Or 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
Ge0rG
SamWhited: for reactions, I'd go with a separate non-<body> element, because people in here demanded invisibility to incompatible clients
stefandxmhas left
sonnyhas joined
Ge0rG
And because it will be awesome to have to change all the implementations that filter out body-less messages as "unimportant".
SamWhited
yah, just removing those lines from message attatching seems reasonable
jcbrandhas left
edhelashas left
dwdhas left
edhelashas left
Vaulorhas left
dwdhas left
jjrhhas left
ralphmhas joined
Guushas left
jjrhhas left
jjrhhas left
jjrhhas left
zinidhas left
tuxhas joined
jubalhhas left
jjrhhas left
stefandxmhas joined
jjrhhas left
jjrhhas left
sonnyhas joined
jjrhhas left
jjrhhas left
Steve Killehas left
Steve Killehas left
Guushas left
waqashas left
goffihas left
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
Steve Killehas joined
Guushas left
waqashas joined
danielhas left
danielhas joined
Steve Killehas left
jcbrandhas joined
peterhas joined
mimi89999has left
jjrhhas left
Ge0rGhas left
Yagizahas left
Ge0rGhas left
lumihas left
Ge0rGhas joined
jabberatdemohas joined
jjrhhas left
jcbrandhas left
jabberatdemohas left
emxphas left
emxphas joined
jjrhhas left
jjrhhas left
waqashas left
waqashas joined
Guushas left
tim@boese-ban.dehas left
tim@boese-ban.dehas joined
jjrhhas left
danielhas left
jubalhhas joined
sonnyhas joined
jjrhhas left
danielhas joined
jabberatdemohas joined
sonnyhas joined
ralphmhas joined
goffihas joined
jabberatdemohas left
sonnyhas joined
Guushas left
Ge0rGhas left
Guushas left
jubalhhas left
Guushas left
Alexhas joined
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
xnyhpshas left
ralphmhas joined
sonnyhas joined
Kevhas left
sonnyhas joined
Ge0rGhas left
vanitasvitaehas left
vanitasvitaehas joined
Guushas left
sonnyhas joined
Ge0rGhas left
sonnyhas joined
zinidhas left
jabberatdemohas joined
jabberatdemohas left
lskdjfhas joined
jerehas joined
ralphmhas joined
SamWhitedhas left
Ge0rGhas left
jerehas joined
lumihas joined
jjrhhas left
jjrhhas left
Flowhas joined
Ge0rGhas left
jjrhhas left
jjrhhas left
ralphmhas left
valohas left
goffihas left
valohas joined
pep.has left
jubalhhas joined
danielhas left
goffihas left
goffihas joined
Tobiashas left
Tobiashas joined
Ge0rGhas left
Flowhas left
Guushas left
jerehas left
jerehas joined
Ge0rGhas left
jubalhhas left
tim@boese-ban.dehas left
tim@boese-ban.dehas joined
goffihas left
fp-testerhas joined
Ge0rGhas left
Guushas left
jcbrandhas joined
jcbrandhas left
Ge0rGhas left
edhelashas left
ralphmhas left
jcbrandhas joined
edhelashas left
edhelashas joined
jubalhhas joined
moparisthebesthas joined
Ge0rGhas left
tuxhas joined
Tobiashas left
edhelashas left
Ge0rGhas left
edhelas
muc.xmpp.org doesn't supports mam:1/mam:2 yet ?
MattJ
No
Zash
-version xmpp.org
Bunneh
Zash: xmpp.org is running Prosody version 0.9.12 on Linux
edhelashas left
jjrhhas left
Ge0rGhas left
ralphmhas left
moparisthebest
-version muc.xmpp.org
Bunneh
moparisthebest: muc.xmpp.org doesn't reply to version requests
edhelas
yeah that seems to be the problem
edhelas
I don't see caps for muc.xmpp.org in my db
moparisthebest
Yea so we don't actually know what it's running :)