jdev - 2026-01-11

Not sure, if this question fits well in this MUC. I'm open to move elsewhere. How are PubSub subscriptions supposed to expire? Case 1: Users subscribe to a PubSub node, e.g. a blog service. Then some users delete their accounts. The subscription is still present on the PubSub service, right? Forever? Case 2: Users use a web client to subscribe. If they subscribe with their full JID, which might change with every login, all the subscriptions are still in the services databases? Forever?

(case 1) yes though after getting delivery failures for months the service could certainly choose to disable it (Case 2) similar and yeah. In this case there may not even be delivery errors? Just silently ignoring these messages forever

singpolyma I wonder, if this behaviour could be abused to put a burden on a PubSub or PEP service? Even DoS it? I.e. automatically register an XMPP server, subscribe to nodes in large numbers of phantasy full JIDs and then replace the service? How should a service deal with that? Force unsubscribe on persisting errors?

Sure you could do that even without unsub. Just make a component and subscribe 1000000 different jids to one pubsub node

Or join 1000000 jids to a muc and watch the fireworks

you can just make 1000000 accounts in open-reg servers, ez pz :P

That's slightly harder but sure also could

I wonder, which tools servers like prosody or ejabberd have in place to detect such problems (attack or accidental does not matter) and solve them. If any. So far XMPP didn't really take of as a social platform (Buddycloud and Jappix are dead, Libervia and Movim not yet as famous as they should be), but in case of more adoption, "ghost mass subscription" might become an issue.

none, we have no defense against all sorts of trivial to pull off attacks simply because no one has done them yet

debacle: Movim exposes switching between "anybody can subscribe" and "only your contacts can subscribe" iirc

which edits the pubsub ACL for you

like a trivial example I've brought up a ton of times: current servers, tools etc support blocking bare JIDs (user@example.org) and whole domains (example.org), but none of them support blocking wildcard domains (*.example.org) so super trivial to get a free LE cert for *.example.org and join each muc or spam each user 9999999 times all from bob@randomsubdomain.example.org and 0 currently existing tools can mitigate it

when I bring this up someone inevitbly whines something like "stop telling people attacks" and then nothing ever gets fixed, I suppose it'll take an actual attack to get actual fixes

Yeah that kind of basic spam cannon stuff is what we need to be thinking about. So much time is spent trying to make the good actors very squeaky clean right now. I think because we have no competent bad actors. But yes ultimately you need ways to handle spam. In the easy wildcard subdomain spam cannon case I would do it at iptables. But that's me as an admin if they target only one user we need a tool for that of course. And it will be a never ending treadmill you can never win just keep fighting

For "lots of people sub or join a muc at once" yeah I guess rate limits will help but it's not magical

You could do the same thing in AP of course and they are even less efficient so taking down a node is probably easy until the admins come and manually block your traffic

yea iptables and then they start routing over tor and same but yea... it'll always be a back and forth but right now there are these huge holes we could easily patch but just don't

being able to block wildcards, multiple levels of wildcards, and maybe cert or pubkey would be easy first starts

IP in blocklist might not be crazy to try also. Though hard to know the real effect until we're up against someone real and see how they respond

yea, but both mucs and servers would have to be able to say "block this server by IP" or something like that, right now only the server admin can do this

Right

moparisthebest: in some cases, they even neuter features from XEPs that are useful against spam

like the privacy lists XEP letting you block any users from DMing you if they're not subscribed yet

that XEP got deprecated and replaced by the blocking commands, which had completely removed that feature ✏

now you can only block specific JIDs or domains

not by subscription status or anything

It got deprecated because no one ever implemented it

Someone still could

except prosody and psi+ :P

prosody's privacy lists module is completely broken now btw, and nobody will ever fix it because "the XEP is deprecated" ✏

(it got broken by a major update in prosody) ✏

> It got deprecated because no one ever implemented it https://xmpp.org/extensions/#xep-0016-implementations some did :) ↺

Someone could fix it. Lots of community modules are under maintained and broken

> 15:00:47 Guus> You're not supposed to have `<ul>` as a child of `<p>` I think? In HTML, <p><ul> is actually parsed into <p></p><ul></ul> in the DOM.

↑ edhelas, singpolyma, kapad, theTedd.

Yes ?

but the chances of that happening is close to zero because it was removed from prosody following its deprecation, and has been abandoned ever since

which is a shame. the only recourse i have against mass DM spams (which i have faced before), is not giving out my JID at all ✏

> &gt; 15:00:47 Guus&gt; You're not supposed to have `&lt;ul&gt;` as a child of `&lt;p&gt;` I think? > In HTML, &lt;p&gt;&lt;ul&gt; is actually parsed into &lt;p&gt;&lt;/p&gt;&lt;ul&gt;&lt;/ul&gt; in the DOM. HTML RFC be like: ↺

https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/k1TBotVi9TuI/chat_image.png

because there is no countermeasures against it

(which wasn't always true)

> but the chances of that happening is close to zero because it was removed from prosody following its deprecation, and has been abandoned ever since It's a community module. I don't think it was ever part of prosody ↺

I wonder if mod antispam would solve your need. Or develop the ability to

all i really wanted was the ability to block DMs from unsubscribed users

mod firewall can of course but I understand that's rather advanced for most users with no ui

nothing more complicated than that

Sure, I get it. There are a few modules that can do that but not sure what would be best in your case

mod antispam is almost that except it will allow the message also if it's from a server not known to ever send spam

Maybe ok maybe not

edhelas, not at all no, HTML5 actually defines a strict algorithm for parsing HTML, which all browsers follow when in HTML5 mode.

Cynthia, the actual reason that module got moved from Prosody to prosody-modules is that it was extremely inefficient at scale, to apply arbitrary rules defined by the users on all incoming and outgoing stanzas.

i see

You could propose a much simpler XEP with a toggle between I-want-to-receive-subscription-requests and I-don’t, that would fit the bill.

I’m sure that could reach a lot more approval and implementations than the whole of XEP-0016.

more like i don't want to receive DMs from people whom i haven't accepted their subscription request first (if they have sent it)

but still i get your point :P

Subscription requests can include a subscription message though.

oh true, but i haven't seen an attacker spam subscription requests

Much better to act on the server and reject spammy subscription requests, as singpolyma recommends. :)

I wouldn't say better. But there's trade offs

Subscription message could be stripped or ignored but that's a trade off too

What I do for myself is put spammy stuff in a different part of the client UI so I can mostly ignore it and clear it out with a single button press. But this also won't work for everyone's needs. We're all different

How do you detect spammy stuff client-side?

In servers we have vastly more knowledge than in clients.

Client knows everything server does plus more. For example one of my rules is that if the message is in a different alphabet than my OS language settings it is probably spam

Right.

But no, the client only knows stuff about this specific account, the server knows about all accounts on the server.

Current spam rarely targets just one user, but many of them.

If I needed to I could have server add a tag meaning "this is probably spam" to help but I've never found any data the server had that I don't so haven't needed it yet ✏

Sure yes. I get spam at dozens of jids on my server and it's all the same ✏

You mean just a dozen JIDs get spammed?

In the worst case I have a toggle to consider everything from a non contact as spam. But I don't use that setting myself ✏

I mean I only have a few dozen jids heh.

I see.

Many that get spam don't even exist and never did. But they get spam anyway

Here with hundreds of thousand, we get a vast amount of data we can use to better fight spam than if every account had to handle it itself. :)

Yeah, spammers don’t necessarily know whether a JID actually exists.

I expect even with your hundreds of thousands the same half dozen rules catch most of it? Alphabet not matching target. Long messages. Messages with links. Etc

I don’t actually know which of my users don’t speak Russian. :p

Advantage of being the client is I do (sort of) know that

We generally act way earlier than those long spam messages.

imagine if XMPP servers had bayesian filtering for DMs :P

based on what it knows as spam or ham

> none, we have no defense against all sorts of trivial to pull off attacks simply because no one has done them yet Depends on use case. If I have a public blog with my dozens of followers (ha!), I don't want to have any ACL. But the server admin (not me) might want to unsubscribe on error. ↺

singpolyma, you may be interested that Gajim in the next version supports the link preview opengraph stuff cheogram sends

Ooh! Fun!

Sending it too or just showing it?

but for now only showing, not yet sending

Cool

but its also planned to send in a later version