XMPP Service Operators - 2017-11-07

I have more and more accounts created from Indonesia that use movim.eu as money transfer solution

https://software-otomax.com/

https://tigerengine.co.id/

you should have a look at connected sessions on your servers

resources are TigerEngine and OtomaXC

*OtomaX

thoses accounts are now systematically deleted from my server

http://lebamboledirosita.blogspot.nl/2016/10/roket-pulsa-irs-otomax-tiger-engine.html

SIP resources as well by the way

JIDs are often containing "reload", "oasis", "center", "terminal" or "pulsa"

edhelas: I've got a bunch of those too, with gazillions of messages in MAM :(

well time to cleanup them

edhelas: Can you read whatever language that is?

/SIP /OtomaX /TigerEngine

Google Translate

I'm not sure it is really money transfer

also resources that are starting with "FF"

I mean: you can't transfer money over XMPP (yet). So whatever they do is only a kind of information / approval flow.

Maybe people are using it to pay for their daily expenses, and you kick them out?

What if they can't afford their food without our XMPP servers?

<error:payment-required/>

Ge0rG I'm fine with that, the issue is that they are using a server in europe, and those services are not free for some/most of them

also the fact that it's quite ugly and create a lots of MAM messages, I'm talking about 100 of Mb each weeks/months

just hard limit the number of stored messages per account...?

100 Megabytes of mam messages mean hundred of thousands ++, I don't see a usecase for a *normal* user if MAM is about account entities.

I've manually disabled MAM for the accounts with 100k+ messages in the log

edhelas: FWIW, you could tell the server to not enable MAM storage for a given account until a MAM request is issued.

I wish prosdy would just default to MAM=off

Holger how ?

Ge0rG: And let clients auto-enable it?

Well... my server is configured to allow 5000 stored messages per account after which the oldest will be discarded. Also MAM *SHOULDN'T* be enabled by default, but users *SHOULD* enable it with prefs explicitly.

What Maranda said.

Maranda: Clients or users?

Maranda, Ge0rG: Huh. Ugly UX.

edhelas: mod_mam: request_activates_archiving: true

thx

Ge0rG, I implemented MAM so that it's by default disabled until it isn't explicitly enabled by users(/clients).

Holger: it should be automatically enabled by a client doing a MAM query.

but off by default

Since it's not such a used feature tbh.

Well these things should probably be admin-configurable.

I had to shutdown my server today for ~10mins to compact a 5.5GB SQLite database.

sqlite O_o

what's wrong with sqlite?

>.>

and why compact, just remove old ones no ?

Maranda: I have to shutdown / SIGSTOP prosody when working on the DB

Ge0rG, also btw it should be really trivial to change prosody's default mod_mam behaviour, you just need to change the default prefs in the code, if it's not configurable already.

Maranda: I think the trick is to make it auto-enable MAM on the first _read_ access. https://prosody.im/issues/867

Zash doesn't want me to have nice things... :(

I don't agree, there're prefs.

the above would be a hack.

A client or user through it can just change the prefs to enable or change logging.

Maranda: are the prefs a tristate of off/on/not-set?

Nope... you can do much more elaborate things with prefs.

Like don't log anything cept these jids etc.

I mean: can the client determine if the pref is "off" or "not yet set"?

Yes, by retrieving prefs

Not set doesn't exist

https://xmpp.org/extensions/xep-0313.html#prefs

see 6.1.1

I agree it's a hack.

But currently quite useful in practice ...

I don't think it's a hack. We could just standardize it.

Or maybe add a business rule for client-controlled initial activation

Maranda: you lied. "The <prefs> element MUST be present and contain the current default archiving policy."

I didn't lie

‎[16:22:53] ‎Maranda‎: Not set doesn't exist

Tell me where I lied.

So the client can't determine if the prefs were set before or not.

It can query them with an IQ-get.

O_o, why would it need to

Example 19/20 in 0313.

Holger: and the server MUST respond with prefs.

You just retrieve the prefs like I said.

Holger: there is no way for the server to tell "not yet configured"

Ge0rG: Ah right.

16:22:17 Ge0rG> I mean: can the client determine if the pref is "off" or "not yet set"? 16:22:32 Maranda> Yes, by retrieving prefs

that was the lie!

Because that's not a possibility, there're 3 defaults

read the xep >.>

always, never, roster

Maranda: my point is: there is no way for the client to find out "hey, this account never used MAM before, we should enable it"

Maranda: so the server-side hack of enabling MAM on the first query is actually sensible

Maybe I should write a note to the LC thread.

No it's not, you just retrieve prefs, and then eventually set logging accordingly.

And fight against your other client which does it the other way round?

That seems an overcomplication for "I dunno what"

Maranda: you are missing my point

Maranda: I want MAM disabled until the user has a client that supports MAM.

Maranda: and then automatically enabled

No I get it (now), but that's not a server problem, if you use multiple clients kicking each other in the nuts the server shouldn't deal about it for you.

Maranda: because there is no "not yet configured" value, the clients can't know if they need to do the initial activation or if the user is paranoid

You want an element stating when it was last configured? Propose it.

Maranda: so you still are not getting it :(

Maranda: no!

Maranda: I want a UX where the first MAM-capable client can automatically determine that it's the first and either auto-enable or ask the user. Once.

Ge0rG, you ain't getting me bud, they. don't. need. to.

A client needs to figure what's the actual configuration and default, *then* deal with it.

You're overcomplicating something which otherwise is simple.

Maranda: except it's not simple

It's simply not possible without changing 0313 :-)

Ge0rG: Anyway isn't the hack like 5 lines of Lua?

Holger: it's possible on the server side with the "hack"

Yes, so propose it as I said.

and then, a server implementation of MAM may not allowing setting prefs, what would you do in that case...?

Ge0rG: Yes I meant it's not possible for the client to do the right thing with the current 0313.

Maranda: commit suicide.

.

Maranda: but yeah, see. It's getting more and more complicated.

Maranda: I suppose if the MAM policy is enforced by the server, there is no "initial undefined" state

I said that ages ago, that's what the current protocol provides.

Maranda: you said what, where?

‎[16:22:53] ‎Maranda‎: Not set doesn't exist ‎[16:22:53] ‎Maranda‎: Not set doesn't exist

bbl

Ge0rG: "It's not possible with the current protocol." Marzanna: "You're wrong! It's not possible with the current protocol!"

*shrug*

s/Marzanna/Maranda

So "I said that ages ago" was not a post to standards@

Time is relative.