| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
The default of 0.001..100.0 did not feel suitable here. This might be
better. Longer is better and hold times less than a few seconds is
generally undesirable.
|
|
|
|
| |
Mirroring the internal API
|
|
|
|
|
| |
Previously it would default to exit with 0 as status code, meaning
success, which is weird.
|
|
|
|
|
|
| |
Per the unspoken internal standard of -1 as priority for most built-in
event handlers, since this makes it easy for 3rd party plugins to
override behavior by hooking at the default priority of 0.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This line was copied from mod_mam, where `origin.username` made sense,
less so here.
|
|
|
|
|
|
|
|
| |
This is becoming more common in XMPP as people experiment with a MIX-like
model where the bare JID joins a group chat instead of a full JID.
Specifically right now this is being added to help with processing
notifications from mod_muc_offline_delivery.
|
| |
|
|
|
|
| |
Remember to remove the compatibility things in some future version
|
|
|
|
|
|
|
|
|
|
| |
XEP-0045 states:
> Affiliations are granted, revoked, and maintained based on the user's
> bare JID, not the nick as with roles.
Therefore inclusion of a full JID in affiliation queries is invalid.
Thanks to Ge0rG and Poezio for discovering this issue.
|
|
|
|
| |
Ref #1643
|
| |
|
|
|
|
|
| |
Added in 03714861f8fc but it did not appear to be used anywhere until
offline message "handling" was added to mod_mam in 8141645e3865
|
| |
|
|
|
|
|
| |
Since this stanza-id was generated elsewhere in mod_mam, there should be
no need for normalization.
|
|
|
|
|
| |
In order to allow monitoring. Especially as there's not much in the way
of hard numbers on how much space gets used.
|
| |
|
|
|
|
| |
In this case I need them for 227 import/export.
|
|
|
|
|
| |
Error in util.human.units.format because of B(nil) when the global quota
is unset.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, maximum storage usage (assuming all users upload as much as they
could) would depend on the quota, retention period and number of users.
Since number of users can vary, this makes it hard to know how much
storage will be needed.
Adding a limit to the total overall storage use solves this, making it
simple to set it to some number based on what storage is actually
available.
Summary job run less often than the prune job since it touches the
entire archive; and started before the prune job since it's needed
before the first upload.
|
|
|
|
| |
And to follow existing naming practices better than 'legacy_ssl' did.
|
|
|
|
|
| |
Following the style of other options like (c2s|s2s)_require_encryption,
s2s_secure_auth etc.
|
|
|
|
|
|
| |
Mirroring the c2s 'direct_tls'. Naming things is hard.
direct_tls_s2s_ports = { 5269+1 }
|
|
|
|
|
| |
This could be done with multiplexing, or a future additional port
definition.
|
|
|
|
|
| |
Goal is to call this if the connection is using Direct TLS, either via
multiplexing or a future Direct TLS S2S port.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Global modules aren't quite considered loaded onto hosts, which
causes confusion in some cases. They are also reported in the log as
being served on http://*:5280/foo which is also a bit confusing, and
can't be clicked.
Global modules also have to have their paths configured in the global
section, which could be confusing and unexpected.
This global+shared method should be the best of both worlds.
|
|
|
|
| |
(thanks mjk)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Examples in XEP-0060 suggest that items should be listed in
chronological order, but we get them from the archive in reverse
order.
However when requesting specific items by id the results keep that
order and we don't want to flip it again.
At some point it would likely be best to use the archive API directly
instead of this util.cache-compatible wrapper.
|
| |
|
|
|
|
| |
As suggested by RFC 7590
|
|
|
|
|
|
|
| |
Should no longer be used by anything since the conversion of mod_offline
to the archive API in 0.10.0, which was 4 years ago. The line clearing
the property is left for a bit longer in case someone has very old
offline messages or archived data.
|
|
|
|
|
|
|
|
| |
MattJ on 09:34:24
> Zash: I think as a first step, offline messages should not be sent to
> clients that request MAM
https://chat.modernxmpp.org/log/modernxmpp/2021-08-31#2021-08-31-8518a542bd283686
|
|
|
|
|
|
| |
Otherwise a message archived by a remote server would be incorrectly
silently discarded. This should be safe from spoofing thanks to
strip_stanza_id earlier in the event chain.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Along with the previous commit, allows building the XML thing yourself,
should you wish to send it yourself or use it in a different context than
an iq reply.
API change: The 'reply' is removed from the event.
|
|
|
|
|
| |
This way you get the _prepared_ services and don't have to do that mapping
yourself.
|
|
|
|
| |
Please don't be accidentally quadratic.
|
| |
|
| |
|
|
|
|
|
| |
Since version 0.4 of XEP-0313, the <fin/> element is sent with the IQ
result and no longer has a queryid attribute.
|
|
|
|
|
| |
Could allow e.g. a XEP-0198 implementation to efficiently send ack
requests at optimal times without using timers or nextTick.
|
|
|
|
|
|
|
|
| |
Signals that any pending outgoing stanzas that were in the write buffer
have at least been sent off to the Kernel and maybe even sent out over
the network.
See 7a703af90c9c for mod_c2s commit
|
|
|
|
|
| |
Not currently used for anything, but allowed and could be used in the
future and might be used by other servers.
|
|
|
|
|
|
|
|
| |
Makes it so that global values set in the environment are kept longer
than within one line, and thus can be used until the session ends. They
still don't pollute the global environment, which is an error anyway.
Thanks phryk for noticing.
|
|
|
|
|
| |
This makes unlimited_jids also work for s2s connections, assuming the
remote server has been identified.
|
|
|
|
| |
Also enables reuse for s2s, which we will add next.
|
|
|
|
|
| |
So that we get single point where shared session properties can be
added. But not now. One day. Maybe. Patches welcome.
|