XMPP Service Operators - 2021-12-05

cyberdelia's public MUCs were his target too ... but two days later, with second jid ... but what moparisthebest said is true, malisious reports are a threat too. I did solve it by closing registation and only giving accounts to users that I know and trust, their families and friends, but that's my usecase ... If one of cyberdelia's accounts is causing issues I can take may car and drive to his/her home and have a talk (meaning I really khow who they are) ... but how to solve without making XMPP another email like service administration hell ?

TheCoffeMaker, that's pretty much the use-case Snikket tries to satisfy (a server for family/friends/people-you-know), while trying to make it as easy as possible (easier than email hosting for sure)

moparisthebest: > Like I don't like you so I report everything you say as spam, that kind of thing It's not a system that uses manual reporting, not even content, but bulky traffic.

> setting up a central server to handle reporting and checking is easy, though probably a privacy nightmare It's a distributed system, DCC servers exchange common checksums.

The problem with applying content analysis is that there is often too little data to work with

Which is one reason a bunch of spam senders first send "Hi" or "Hello" (often in Russian)

If you successfully match this, you also flag pretty much anyone starting a conversation as a spammer

I meant to say "the problem with applying content analysis **in IM**"

What works for email doesn't map well to shorter message

> Hi is ping spam.

Private chats are different and should not be monitored (since they should be encrypted anyway).

Spam filtering should be applied to non-members in unmoderated rooms. That way it would keep public MUCs relatively open.

_Monolog prevention_ A related problem are *monologues* - meaning single users spamming public space with preaching/ranting/bulky links. E.g. there was a troll attack in several open MUCs Nov 5th remember? > Hello human!!, I have the best gay porn for you, your friends and family :D! You're welcome! [...] A prevention could be similar to iPhone's brute force mitigation: slow down sending frequency if nobody responds. That would have prevented the infamous Darkijah spam too.

The problem with all the things you are suggesting is that they have a high chance of false positives

You just sent 4 messages with nobody else responding, I sent 5 before that

Rate limits already exist, but there is a line to choose between aggressively stopping/slowing bursts of spam and disrupting normal communication

The truth here is that there is no way to get an universal rule for this, doing things à la IRC (aggressive rate limit on everything) is painful in many cases, the only appropriate way would be to plug some kind of auto moderator that room owners tailor to their needs

> the only appropriate way would be to plug some kind of auto moderator that room owners tailor to their needs That would not be aware of bulk spam in other MUCs. That's where DCC is better.

> You just sent 4 messages with nobody else responding, I sent 5 before that Wouldn't be a false positive for members, if the spam filter is applied to non-members only.

sending a bunch of messages is typical though for a well-formulated support case

and having noone reply initially is also typical

Would false positives even matter much if spam filtering was only applied to non-members as kikuchiyo suggested? Anyone who wouldn't want to be affected by that would just need to convince an admin to make them a member.

kikuchiyo: Oh, you just said the same thing. ^^

me9: 👍

maybe more limits if this is the first message posted at all

emus: What kind of limits do you mean?

Someone who joins a support muc for the first time because he needs urgent help might not be member.

Uhh, but when I think about it, having an annoying and IRC-like rate limit thing that doesn't work all that well, and applying that to every new participant is not a very elegant solution, is it?

Martin: Yeah, right. And limiting such support cases wouldn't be great.

You could have a voting mechanism for members and if $threshold members report it as spam mute the person. But that might be abused.

That's like the community being an admin if "powerful" enough. Meh.

I'm also annoyed by spammers and if I knew a good solution I'd tell you but I think a lot of clever people thought about this and we still have no solution.

This was my experience with IRC > Eg. Distros having IRC for support, install it, have an issue, join...50-100 people on..."hey, can anyone tell me why X isn't working?" > Wait...no answer for a while, neither RTFM nor Hi nor anything. > IRC is dead...

I love seeing the Matrix rooms with 1k+ memebers, but still dead

because they're literally 👻️

Martin [13:39]: > You could have a voting mechanism for members and if $threshold members report it as spam mute the person. But that might be abused. We had this feature in an XMPP bot 10 years ago... I guess it didn't take off 🙂

I did use it in the crazy off-topic channel on conference.jabber.org, but I believe it was often gamed

Sorry for the delay ... Had to go to bed 😅 ... too much wine for the night TL:DR: What can we do for the smallest servers? coz this can be a serious issue to get people/communities deploying new XMPP nodes. MattJ: For our use case, while you are not publishing or sharing your domain name it will away from spammers ... mine actually was running with no issues till yesterday ... a good bunch of years, around 10 years now. The problem with spam control in a distributted environment is trust, how can we trust each other? I mean, for big servers it's easy ... but what about the smaller servers like mine or others like MattJ said? ... how can u trust in me? I can take local actions like banning the jids at server level, but If I report a 404.city or jabber.org user in the distributed system but it only spam on my server or what if I deploy lots of servers just to handle the ranking? Sorry for the long message ✏

> That's like the community being an admin if "powerful" enough. Meh. It's better to discriminate *traffic patterns* than jids or content to preserve freedom of speech.

Wenn can do this: https://blog.prosody.im/simple-anti-spam-tips/ https://github.com/JabberSPAM The simpelest thing is, have some burden to register.

Nice article Menel , thx ... Will have a deeper look at it as soon as we can sit and try the recommendations

> The simpelest thing is, have some burden to register. Not if you want to encourage self hosting like snikket. Spammer can be their own operators and you end up discriminating servers/IPs instead of traffic.

I'll of course block the whole server after the steps listed on that github, especially if its snikket. I've no problem discriminating against that server.

Thinking of it... If its snikket and I get spam from multiple accounts there, I'll assume its a server dedicated to spam and will not wait that long for a response

The good thing about an invite system.. Its very unlikely to be a source of spam. Since its not a thing to register anonymously. (Its possible, sharing invites randomly in the internet.., but not the snikket intend) So I don't think I'll see snikket spam

Is there a list of servers that require registration so one can only allow those?

Like ones that meet a criteria for eg. Captcha at a minimum or manual approval

Menel: me neither .. But who knows ... I think that its like u said ... If we see a lot of spamming comming from one server and no other jids seem to be real ... blacklisting the server is a good option ... But again ... We are talking abt trust ... Sapotaceae ... What will happend with nodes like mine that are not providing thos mechanisms? ✏

Menel: me neither .. But who knows ... I think that its like u said ... If we see a lot of spamming comming from one server and no other jids seem to be real ... blacklisting the server is a good option ... But again ... We are talking abt trust ... Sapotaceae ... What will happend with nodes like mine that are not providing those mechanisms? ✏

Why wouldn't one have such mechanisms in place?

Why would you want someone to be able to mass create accounts on your server?

Open question

In my use case .. i dont cause registration is closed and only give accounts to people I know and trust

Yes so that meets the 'manual approval' criteria

But thats my use case

If the federating xmpp network would be as relevant as WhatsApp/email. I'm sure the same bad blocking etc would be nessesary as its in mail. Because the spam would be unbearable otherwise.

> Yes so that meets the 'manual approval' criteria Yeap

Captcha doesn't stop these people at all

Captcha doesn't even stop bots, it's all for training image recognition ai now

It is still some barrier

Combine it with aggressive rate limits

Per IP and global

Barrier for regular users mostly.

Yes captchas are an accessibility hazard

Sapotaceae, we did that on jabber.org, and we were still getting 200 spam registrations in a day

And rate limits for regular users who only have a single IP, while spammers have unlimited IPs.

Yes I remember someone here said that someone did 2000 hcaptchas in a day

Yes, the registrations were from all different IPs, they went through reCaptcha (the original version)

Spam is hard. I'm not an expert. What is the path the community needs to take to further combat it?

I know few people even bother with implementing the jabberspam blocklist

it also doesn't help with egress spam at all ✏

The Tor network has a function where newly added nodes aren't advertised until a period of time has passed and then it starts slowly ramping up traffic towards then. What about a function where new users have no voice by default until they've been manually allowed, but if they get approved on one well-known/longstanding server then they are in the future granted voice by default.

Sapotaceae, has the same issue as the reverse approach, really.

(also, it isn't working really well with Tor, or so I hear (KAX17))

Sounds pretty hostile towards new users though

🤷

Also, how would you know how old an user on a remote server is?

I'm not trying to shoot down every idea, it's just a hard problem, I haven't seen anything that's not a dial between "super real user hostile vs free spam"

Yep

relevant: https://craphound.com/spamsolutions.txt

🤣

Why do people spam XMPP anyway? I get that it’s easy in some sense, but there aren’t that many users on public servers, are there? Seems like you would have very few (if any) people biting for a scam. Is it really profitable?

All of that is too real lol

This one made me laugh out loud: > It will stop spam for two weeks and then we'll be stuck with it

Calvin, [x] Extreme profitability of spam ;)

lol

Calvin: my gut feeling is the same as yours, it shouldn't be profitable, but obviously is or it'd stop on it's own

It's cheap to spam so even if it only ever works 1/1000000 of the time it was profitable.

IRC has a bunch of spam and I can't imagine people going "oh that's something i'm interested in!" but clearly it does work or they wouldn't do it.

Matrix too

moparisthebest: my gut feeling is there's a first mover / early adopter cohort for everything—roughly definable as the ones who try things out that *aren't* profitable in hopes that they just aren't profitable *yet*....

moparisthebest: well, that and "what do I have to lose vs. what do I have to gain" risk/reward calculations.

Really though, how much does it cost to spam XMPP?

You can probably make a spam bot in 30mins

So $0

Interestingly the "daniel" person who mass-pinged MUCs the other day with "I... can accept money" got some "WTF are you doing?" type responses... and engaged with those people; rather than being a send-only "visit this URL" or "contact this address" mass-poster.

Seems to be a meatbot. 😃

Yeah.

In any case, I see something like 1 spammer every 6 months or something on XMPP..., which makes me doubt the "risk/reward" calculations of people jumping to "fix the spam problem with XMPP".

My concern is that it could get worse at anytime and we'll be headless chicken

... though my personal favorite idea is something like "just block any service that has more than 1000 users". ✏

Projects lile Snikket that could radically increase the hoster/user ratio are of great interest for me.

I think a simple central 'block list' and a server module that checks it for updates would be fine.

jjrh: then we get back on the _general_ definition of spam and get ready to have removal requests

I feel like that was probably a more interesting line of inquiry 30 years when it was a new idea in e-email administration.

Eh I think it's a trust thing, if say conversations, XSF, and prosody main muc's all block the same person I can be pretty certain that is spam

> I think a simple central 'block list' and a server module that checks it for updates would be fine. You mean a bit like the one mattj just wrote while we were talking? https://modules.prosody.im/mod_muc_rtbl.html

sure.

Oh wow

70 mins ago? Where was it mentioned?

I think people just find spam to be a interesting technical problem to solve.

I assume it has more bits in snikket?

BTW I'm still trying to figure out this "e-mail spammers apparently don't use DNS" phenomenon that I noticed a couple of years ago.

What is snikket anyways? Just a easy to install XMPP server?

Yes

Along with tons of polish on top

More on snikket.org

Yeah i'm looking at the website it's unclear to me.

> moparisthebest wrote: > When I read DCC I immediately think of the bad old days lol https://en.wikipedia.org/wiki/Direct_Client-to-Client You mean Jingle before there was XMPP? :)

I feel like they could explain their technology stack a bit more. Like it's not even clear to me what the server is (I can guess by the modules it's prosody)

jjrh: its prosody in a docker, preconfigured with special modules for family and friends. Has a admin_web interface, coturn in docker, and advanced forks of other apps for android and iOS

Would be nice if they explained that a bit more - like going to the website it's not even clear it's based on XMPP 😛

That said, it's a great idea 🙂

jjrh, Snikket isn't really aiming at people who already know what XMPP is. In fact if you already know what XMPP is, you very likely know enough to configure Prosody or ejabberd yourself

Still, there are some more detailed explanations, such as https://snikket.org/about/goals/

and https://snikket.org/open-source/

jjrh: > Would be nice if they explained that a bit more - like going to the website it's not even clear it's based on XMPP 😛 If you care what's under the hood, you are not the target audience

> Along with tons of polish on top It's mostly English, not Polish :)

That's fair. I guess it's more a question of if there is anything Snikket offers that is of benefit or interest to someone like myself. I gather not.

The only thing it has that can't easily be replicated in a DIY XMPP setup is the web interface

What do you use for a web client?

It doesn't have an official web client right now

I seems you're not recommending any desktop clients either?

There's no official desktop client either. See https://snikket.org/faq/#q-can-i-use-the-snikket-apps-with-a-non-snikket-server for alternative client suggestions

Please don't take what I say as negative or critical - I think Snikket is a fantastic idea and exactly what the XMPP ecosystem needs.

Haha, no, it's nothing I've not heard before... believe me :)

Snikket does not present itself the same as other XMPP projects, does not target the XMPP community, and therefore is often misunderstood by XMPP folk when they first encounter it

I mostly am interested in what you guys are doing to overcome the problems I run into which are mostly windows, osx and ios clients.

And webclient - but converse.js is pretty good, could just use a bit of UI love.

iOS has been quite a journey, but we ended up building on top of Siskin (including sponsoring some stuff)

Web is probably the next focus, just because it's an easy way to reach every platform. And yes, Converse.js is definitely one of the options.

iOS is by far the most difficult I have run into - a coworker who would like to use xmpp on his iphone has basically given up.

Right. That's the story I've heard so many times, and have spent most of my time this year trying to fix :)

The latest Siskin release seems miles better at least (as a sad iOS user who has given up many times)

Yes, definitely

Converse.js really just needs someone to make it look like matrix/slack/discord/whatsapp/messenger. A young hipster webdev basically 🙂

jjrh, I did that once, it’s the concord theme.

My inspiration was Discord back then, from a few screenshots people provided.

I was fed up of everyone calling it “not modern”, so I just copied all of the colours and some other elements, and they were all “woah it looks modern!” afterwards. ^^'

:D

So dull grey > orange.

got a screenshot? google isn't giving me much

With > meaning “looks more modern than”.

jjrh, https://github.com/conversejs/converse.js/pull/1167

nice!

It changed a bit since then.

Personally I /hate/ the whatsapp/messenger/discord style where all the chats are grouped together and you can't distinguish between a chatroom and 1-1 and there is no roster and what not, but I know others really like that.

MattJ, you mentioned converse is /one/ of the options, what else are you looking at?

https://snikket.org/faq/#q-what-about-a-web-client

(guess the questions I get asked a lot)

heh

Any of them other than converse do omemo?

Movim does, I think JSXC... might? Would have to check. xmpp-web does not.

Isn’t movim’s omemo server-side?

Most of Movim is server-side, so it wouldn't surprise me. Note that the Movim server != the XMPP server though (e.g. you could run Movim locally or whatever)

Why is there is no support for traffic discrimination, but for other forms of anti-spam?

> And rate limits for regular users who only have a single IP, while spammers have unlimited IPs. DCC discrimination against repetitive content patterns avoid this pitfall.

kikuchiyo: I think you are right that there is no reason for the same message to be pasted across multiple mucs, now: 1. How do you share this info in a privacy respecting way? 2. Once spammers catch on, how does it handle slightly changing messages?