Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Respect history preferences on MUC join #1

Open
lovetox opened this issue Oct 5, 2019 · 6 comments
Open

Respect history preferences on MUC join #1

lovetox opened this issue Oct 5, 2019 · 6 comments
Assignees
@woj-tek @bmalkow

Comments

@lovetox
Copy link

lovetox commented Oct 5, 2019

Describe the bug

history preferences are not respected on MUC joins

To Reproduce
Steps to reproduce the behavior:

  1. join [email protected]
<presence xmlns="jabber:client" to="[email protected]/lovetox" id="5f6ce1f8-df8a-4b66-b340-082d6f4ff181" from="[email protected]/gajim.GLEU3VID">
<c xmlns="http://jabber.org/protocol/caps" hash="sha-1" node="http://gajim.org" ver="qxfoxERhMvHS+QzDA/Q5OlnOavU=" />
<x xmlns="http://jabber.org/protocol/muc">
<history maxchars="0" />
</x>
</presence>
  1. Server still sends all MUC history
<!-- Incoming 05.10.2019 10:06:08 ([email protected]) -->
<message xmlns="jabber:client" xml:lang="de" to="[email protected]/gajim.GLEU3VID" from="[email protected]/Holger" type="groupchat" id="350594463731">
<delay xmlns="urn:xmpp:delay" from="[email protected]" stamp="2019-08-27T16:51:58.556Z" />
<body>patrik and me have seen issues with querying the OMEMO nodes of sure.im users.  But I didn't get to looking into details yet.  (Plus I was under the impression that the OMEMO code is still known not to be incomplete and wasn't sure whether bug reports are appreciated at this point.)</body>
</message>

<!-- Incoming 05.10.2019 10:06:08 ([email protected]) -->
<message xmlns="jabber:client" xml:lang="en" to="[email protected]/gajim.GLEU3VID" from="[email protected]/hse" type="groupchat" id="0a945a75-c962-4a01-8075-409c1417f2b7">
<origin-id xmlns="urn:xmpp:sid:0" id="0a945a75-c962-4a01-8075-409c1417f2b7" />
<delay xmlns="urn:xmpp:delay" from="[email protected]" stamp="2019-08-27T16:53:30.955Z" />
<body>...dismail.de is running Prosody</body>
</message>

<!-- Incoming 05.10.2019 10:06:08 ([email protected]) -->
<message xmlns="jabber:client" xml:lang="en" to="[email protected]/gajim.GLEU3VID" from="[email protected]/hse" type="groupchat" id="d84bc982-ff9d-4fa1-93bd-45f6b98a5be5">
<origin-id xmlns="urn:xmpp:sid:0" id="d84bc982-ff9d-4fa1-93bd-45f6b98a5be5" />
<delay xmlns="urn:xmpp:delay" from="[email protected]" stamp="2019-08-27T16:55:12.298Z" />
<body>I mean I read about Siskin to be OMEMO ready, so I startet some test. You know, IM is interessted for such Apple clients</body>
</message>
@woj-tek woj-tek transferred this issue from tigase/tigase-server Oct 7, 2019
@woj-tek
Copy link
Contributor

woj-tek commented Oct 7, 2019

#muc-124

hantu85 added a commit that referenced this issue Oct 8, 2019
@hantu85
Added support for requesting no history on join with "maxchars" #muc-…
010c93d 
…124 #1
@hantu85
Copy link
Contributor

hantu85 commented Oct 8, 2019

This issue is now fixed with support for requesting no history from the MUC room with maxchars attribute set to 0.

As for the maxchars attribute, I personally feel that it is not needed in current implementations and it should be no longer used. In a time when conversations in MUC rooms can be encrypted with OMEMO, limiting the number of history messages returned by the number of chars of the XML stanza is not in place. I think that clients should be using maxstanzas or since attributes to have behavior more suited to the current state of XMPP and MUC.

@lovetox
Copy link
Author

lovetox commented Oct 8, 2019

Hi,

I dont see how encryption has anything to do with the way we request history.

That is the spec, and it especially asks for that behavior

see: https://xmpp.org/extensions/xep-0045.html#enter-managehistory

If the client wishes to receive no history, it MUST set the 'maxchars' attribute to a value of "0" (zero).

@hantu85
Copy link
Contributor

hantu85 commented Oct 8, 2019

I know the spec and I know what is in it. Changes in Tigase were made to match the XEP. I've just pointed out that in my opinion usage of maxchars is not a great idea in current times.

Looking from the client perspective and the XEP, what is the difference between maxchars set to 0 and maxstanzas set to 0? In both cases, you will get no messages from the room history.

@lovetox
Copy link
Author

lovetox commented Oct 8, 2019 •
edited
Loading

I think its not worth to spend and thought on that.

This is an almost 2 decade old spec, and it has much bigger problems than the attribute name that signales no history.

Anyway thanks for the fast fix :)

@Neustradamus
Copy link

@lovetox: It has been solved?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@woj-tek woj-tek

@bmalkow bmalkow

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@Neustradamus @woj-tek @bmalkow @lovetox @hantu85