XMPP Service Operators - 2018-08-23

huhu showing hidden rooms for server admins enabling superuser switch brought interesting results.

(in disco#info that is)

*repeats question here* anyone knows if ChatSecure or Conversation or some other client do something like creating hidden members only persistent rooms, with a random name (node). To emulate some "crypto-junk groups"?

Maranda: Yes, Conversations creates room JIDs with random node parts, and makes them members-only, hidden and persistent by default.

ChatSecure as well I guess, but I'd have to double-check.

Holger: 👍

I'm vaguely fought on adding auto-wiping of persistent rooms inactive for more than x time, but I guess that first or later I'll have to do it.

Yes I'm doing that as well.

How much time?

Is it really necessary?

MattJ, that's the tricky question

MattJ, and that's the other tricky question.

On my servers one year.

I guess there may be a MAM archive to remove for privacy reasons?

Yes. And JIDs on affiliation lists,

MattJ, in my case that wouldn't be a problem everything gets wiped when room is destroyed

Sure, I'm not saying it's a problem - I'm thinking of reasons why you should remove the room in the first place

Same here, the point was that this is one of the reasons to not keep around dead rooms forever.

Besides data hyhiene I see neither strong reasons to remove nor to keep.

MattJ, me too honestly, on lightwitch.org maybe not much but on a busier service if people with those clients start creating a dozillion of "private crypto clubs" like those then ditch 'em and forget about 'em... maybe it starts to become a problem.

I work on a service that probably has over a million MUC rooms (plus archives)

But yes, data hygiene :)

Maranda, AIUI the goal is more to emulate groups of friends than cryptoanything.

The model here is WhatsApp AFAIK.

Link Mauve, yeah I got that much, but I thought somehow it could start involving OMEMO :P

It probably does, but that's separate - using generated names for MUCs is quite an old approach, I'm sure some desktop clients do it too

Gajim for instance, when you “invite more people to a 1 to 1 conversation”.

Alongside the upload of the previous history.

Link Mauve, *upload of the previous history* 🤔 🤔 🤔

Maranda, this protocol: https://xmpp.org/extensions/xep-0045.html#continue

ohh

it may sound cruel but I think I'll default the inactivity expiral to the usual ChanServ one on IRC (it's configurable of course)

(aka one month)

(and there's a configurable whitelist as well, also cleaning has to be explicitly enabled) ✏

As long as you say you're doing it in your policies, I don't see the issue. Re removing old inactive rooms

and what counts as "inactive"?

No messages? or nobody joined?

MattJ: I'd go with "no messages"

So in this case you just notify everyone in the room that the room has been destroyed?

I do "nobody joined".

This already catches the vast majority of dead rooms for me.

Good to know

MattJ: "nobody joined" I count only stanzas from occupants as last activity

Licaon_Kter, it seems JabberFR has had the same attack as draugr.de, at least against a user named the same way.

I just handled it.

Ohh that's why it hickupped yesterday

Link Mauve: link?

https://statut.jabberfr.org/incident/20

Thanks, Link Mauve!

Already half of them sent an automated reply that this mailbox doesn’t exist. :|

On freaking abuse@…

sigh

Test