jdev - 2026-05-09

Does anyone know if there are any clients that support XEP-0382: Spoiler messages? https://xmpp.org/extensions/xep-0382.html

https://xmpp.org/extensions/#xep-0382-implementations

Ty

is there a standard way to obtain the publish timestamp of a pubsub item?

nevermind, I realized I only listen to publish notifications anyway (and never retrieve items from the node directly), so I can use the current timestamp as a substitute.

Oh sorry, I think my last message was too long... I think I need to split it.

Hi everyone, I hope I'm in the right place if I have a question about the pubsub node from xmppbl.org. Is the PubSub node muc_bans_sha256 intentionally configured to persist only 100 items, or does it contain more items but public retrieval is limited to 100?

i tested bootstrapping xmppbl.org/muc_bans_sha256 from a new subscriber. Subscription works: <subscription jid="adminbot@envs.net" node="muc_bans_sha256" subscription="subscribed" /> However, retrieving historical items always returns the same 100 items.

Test results: - plain <items node="muc_bans_sha256"/>: 100 items - <items node="muc_bans_sha256" max_items="5000"/>: 100 items - XEP-0059 RSM max=5000: 100 items - XEP-0059 RSM max=0 count-only: 100 items, no <count> - XEP-0059 RSM after=<last received item id>: same first and last item again - retry after successful subscribe: still 100 items The first and last item IDs are identical across all fetch variants, so pagination appears unavailable or ignored. Is there an official way for new RTBL consumers to bootstrap the full muc_bans_sha256 node?

I thought it only kept the last 100 items , if so you have them all

Oh okay... that seemed a bit "low" to me compared to the statistics on the website; I would have expected more. And the fact that I only see exactly 100 entries made me suspect that it must have been truncated somehow.

so it's only for multi-muc spam waves and those accounts are always temporary and usually deleted right after, doesn't make sense to keep the bans around forever

Okay, thanks for the explanation. Now I understand. I assumed that the "list" also permanently stores problematic jid hashes so that they remain banned, so to speak, until they are removed from the list.

Yeah there are no stats on the website related to the muc rtbl

I based this somewhat on the reports. The node "spam_source_domains" contains 72 entries out of approximately 90 reports. The node "muc_bans_sha256" contains 100 entries out of approximately 3000 reports. That's why I was wondering if this is correct.

Thank you so much for your quick reply and the explanation.

spam_source_domains is unrelated and based on completely different data for a different purpose