-
jonasw
Zash, mhm thanks
-
jonasw
not sure what you expect me to do with it though
-
Zash
jonasw: me neither
-
jonasw
okay :)
-
jonasw
then I’m just going to ignore that for now
-
Ge0rG
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.
-
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.
-
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 ?
-
daniel
edhelas: yes
-
edhelas
oh ?
-
jonasw
edhelas, https://xmpp.org/extensions/xep-0045.html#enter-managehistory
-
jonasw
maxchars='0' is one example
-
jonasw
(I’d set maxchars='0' *and* maxstanzas='0' to be sure; I guess not all services support maxchars)
-
edhelas
oh, so I should explicitely disable them
-
edhelas
thanks jonasw :)
-
jonasw
np :)
-
daniel
jonasw: I think I only set maxchars and I never had problems
-
SamWhited
Ge0rG: https://xmpp.org/extensions/xep-0367.html
-
SamWhited
That was meant for things like that
-
jonasw
daniel, "never", not even biboumi? ;)
-
daniel
Even though maxchar is a very weird metric now that I think about it. I guess back in the day is just copy pasted that from somewhere
-
daniel
This will probably break if you set something other than 0
-
jonasw
agreed
-
daniel
jonasw: didn't know that biboumi was a problem. Never got reported to me
-
Ge0rG
SamWhited: is there a reason for using message ID and not unique ID?
-
jonasw
odd, I had something about that in the back of my head. maybe it was about MAM instead
-
daniel
jonasw: yes. Mam did break the stanza queue for sm
-
SamWhited
Ge0rG: no, I don't think anyone supports unique ID
-
Ge0rG
XEP-0045 is full of quirks
-
SamWhited
But it doesn't matter to me
-
Ge0rG
I'd really love to fix message IDs instead of inventing new unique IDs. But backward compatibility!1!
-
SamWhited
Oh, am I mixing those up? Whichever. I would be fine coupling it to the unique stable message ID thing, whichever that is
-
jonasw
XEP-0359 (<https://xmpp.org/extensions/xep-0359.html>)
-
SamWhited
Right, that.
-
SamWhited
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?
-
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 ?
-
jonasw
edhelas, ask the MUC for history?
-
edhelas
<iq xmlns="jabber:client" type="set" id="S8lR4X"><query xmlns="urn:xmpp:mam:1"><x xmlns="jabber:x:data" type="submit"><field var="FORM_TYPE"><value>urn:xmpp:mam:1</value></field><field var="with"><value>muc@conference.movim.eu</value></field></x><set xmlns="http://jabber.org/protocol/rsm"><max>300</max></set></query></iq>
-
jonasw
(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.
-
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
-
Ge0rG
I tend to process messages when they are received, but that doesn't work with missing references.
-
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
- Ge0rG pulls 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
-
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.
-
Ge0rG
SamWhited: for reactions, I'd go with a separate non-<body> element, because people in here demanded invisibility to incompatible clients
-
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
-
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
-
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 :)
-
Zash
<identity type='text' name='Prosody Chatrooms' category='conference'/>
-
Zash
Impossible to know
-
mathieui
total mystery
-
moparisthebest
It could be lying
-
moparisthebest
Never trust a remote entity