jdev - 2026-03-08

hm URI question

xmpp.link generates this example uri

https://xmpp.link/#example@server.com%3Fjoin

but reading the fragment definition of https://datatracker.ietf.org/doc/html/rfc3986#section-3.5

it specifically allows "?", so this is unnecessary to quote or?

maybe, but that isn't "the" URL spec https://curl.se/docs/url-syntax.html

Indeed. It's the Uri spec. Which is what was said

I think ? Is allowed in fragments. I mean basically anything is really but probably whitespace and maybe other # are good to escape

not that either as the curl link explains

however no harm in over escaping

... the link you put literally agrees with me

> The official "URL syntax" is primarily defined in these two different specifications: > > RFC 3986 (although URL is called "URI" in there) > The WHATWG URL Specification

Yup

stupid semantic games don't interest me, my point is what RFC3986 says doesn't matter, only what real software people use in the wild does, and the curl page is the best resource I know on that

... ok. Linking to a page and then choosing to ignore what is says is weird but I guess you were only trying to pick a fight anyway

the question was "can I put ? In a fragment" and the answer from both specs and that page is "yes"

Who's picking a fight? The one who "well acksually URI not URL" I think :P

Someone asked a question and gave a reference and you jumped in with "actually look at this page it says not to use that spec" then linked to a page that says curl does use that spec and none of this is an answer to the question asked..m

I didn't have the answer, I did have a link on where to find the answer

Which just turned out to link back to the reference already provided in the question. Cool

Thanks 🙏

> Which just turned out to link back to the reference already provided in the question. Cool nope, because you can't just use what RFC3986 says ↺

Except you can and curl basically does according to that link. So you're still making some other argument not supported by your link

not at all what the link says

it would be sensible for curl to support URLs instead but the link says they choose not to

for this specific use with xmpp.link the only thing that matters is what browsers support

I linked the best resource I had on it because the situation is a mess, that's all, you need to chill out with the aggression

Whatever. I didn't want a fight and I'm done being baited

Is xmpp.link open source and open to contributions? Sounds like it could use the JS URL API to construct the URL without escaping unnecessarily

luca: yep https://github.com/modernxmpp/easy-xmpp-invitation

Thanks

Yes. And I'm sure it uses the JS API which is why that escape is there

Indeed. It appears to use encodeURIcomponent as expected

Yeah and it's perfectly fine. Looks like it's done here https://github.com/modernxmpp/easy-xmpp-invitation/blob/73caa96dd4092634120905b1ae94be6fa54dbd58/scripts/main.js#L343 (with encodeURIComponent) But it could be done with the likes of new URL().hash. Which escapes characters like ` and spaces, but not ?

Hmm. True. At the expense of some old browser support.

Good point. Then the current implementation is resonable

Actually the website already uses fetch which came out after URL.hash in most browsers, so it probably doesn't matter

Hmm. Fetch with no polyfill? Maybe you're right

I realized that the hat XEP only allows setting the hue angle of the color of the hat

This means I can't go for a darker or brighter color, nor for colors on the grayscale either (black/gray/white) ✏

Why was it designed like this?

Probably to match with XEP-0392 (Consistent Color Generation)

I think that's because it's easier to generate a hue angle from a nickname than a RGB

But ideally, we could just skip the whole HSLuv conversion step and let the user choose the RGB color directly in the hat

since we're not dealing with an algorithm

Cynthia, the rationale for '392 was that both saturation and lightness should be controlled by the app, based on the theme.

different lightness values apply for dark/bright themes.

and different saturation values apply depending on the app's overall style.

I don't want someone else picking my colors

I don't know about hats, but similar rationales may have applied there.

> and different saturation values apply depending on the app's overall style. Well how do you ensure consistent colors if you're just given a hue angle to modify as a user ↺

This sounds good for 392, but not really for hats

again, I don't know about hats, I just wanted to point out that for '392, the rationale was not that a hue angle is easier to generate than RGB, but it was a deliberate thought process leading to only generating the hue value.

I see

The colours are consistent given selected saturation and lightness values, but these could be different for different environments/user preferences - you'd want to use lighter colours for a darker background, but darker ones for a lighter background

as someone frequently annoyed by people who send XHTML-IM with `color: black` to my white-on-black terminal client ... I endorse every protocol which takes control over the lightness value out of user's hands :-).

How do you ensure it doesn't come out too oversaturated or undersaturated

Set saturation somewhere in the middle third

> as someone frequently annoyed by people who send XHTML-IM with `color: black` to my white-on-black terminal client ... I endorse every protocol which takes control over the lightness value out of user's hands :-). Well you could invert the background color if it detects the text is dark ↺

or in graphical clients, gives the text a little outline

It might sound dumb :P

What colour background for #808080 ?

White

And #7F7F7F ?

Also white :P

I'm pretty sure that #808080 on white violates some accessibility contrast rules...

it does indeed.

(but only by a hair)

It's poor contrast either way, which is why humans are bad at choosing 'good' colours

not by a hair, actually, it's 3.94:1 instead of the recommended minimum contrast ratio of 4.5:1.

(unless bold or large text, that may go down to 3:1)

(but that doesn't apply to chat content normally)

(#808080 on black is ok tho)

Also on an unrelated topic, can a <body> in a message have multiple child elements in it?

like <body>Test <b>Test</b></body>

not unless you're <body xmlns="http://www.w3.org/xhtml/1999">..</body>

(the normal message body in the jabber:* namespaces only allows text content)

I thought XHTML is deprecated

it is but people still use it and the answer's still true regardless isn't it

But technically that's a different 'body' than the plain message body because it's in a different namespace

indeed

Cynthia, XHTML-IM is deprecated, but it should never have been.

it should've been improved instead.

XSF just gives out deprecations to any XEP, don't they :P

What has XHTML-IM been deprecated in favor of?

LEt's deprecate XEP-0045

excellent question.

Cynthia, it was a crazy time.

the Markup Wars

I love how they deprecate a XEP, but don't say why

don't say what replaced it

it's just deprecated

Cynthia, I can look it up, it's been years ago.

> What has XHTML-IM been deprecated in favor of? 0393 and 0394 i think depending on personal preference ↺

both of which are bad in their own way.

and I say that as the original author of '394

0393 is annoying and i don't need or want full XHTML for IM so i quite like 0394 as a middle ground

what's wrong with it though?

I can't make giant texts for one

smh

XMPP will never be popular until you can write your message in 111111 point font

wait i thought they meant like a lot of text i was so confused 😭

Oh no no

I can't write like a text so big, that most people won't be able to see more than a fraction of a glyph ✏

and that sucks

truly a feature every IM needs

XMPP is falling off

Cynthia, so https://logs.xmpp.org/council/2018-02-14#2018-02-14-dfb88ae585eaf6a7 has the discussion of the XMPP council

which I am thankful to find ou I was not part of during that specific vote :D

there's also lots of mailing list discussion around this

but the archives seem to be (currently?) inaccessible

I'm not too keen on digging deeper, but if there's genuine interest on the history, I might do some research and find a summary.

So uhh, how can we make custom emojis for one

Without the flexbility of an entire XHTML and CSS renderer

Cynthia, bits-of-binary!

supported by pidgin for example!

Yeah we know, bits of binary

But where would you put the bits of binary link in

(and pidgin also uses it, for example, for rendered LaTeX equations, which is quite neat)

custom emojis in the middle of a message? don't get greedy! ;-)

B-But.. discord :(

> But where would you put the bits of binary link in 0394 markup element? i'd have to read BoB i don't actually know how it works ✏ ↺

> markup element? i'd have to read BoB i don't actually know how it works Bits of binary is for storing little bits of binary files directly in XMPP ↺

You give people a CID

and they query you with the CID, and you give them binary data in base64

It's not like a file upload (for large files)

oh neat

the CID is a hash of the file itself, so the client can cache it for later

yeah what if you had like a markup element where the original body text contains the closest approximate emoji(or just the shortcode) and the element just says "yo replace this emoji with this image instead" 🧌

can't decide if that's stupid or not

I think discord does that with mentions

I mean they do, but i don't know if they do it too with custom emojis ✏

https://github.com/AnIdiotsGuide/discordjs-bot-guide/blob/master/coding-guides/using-emojis.md#whats-an-emoji

me when my markdown file is all html 😭

Okay so custom emojis are roughly the same thing, they're like <:my_special_emoji:309810398120912809>

oh i do remember timestamps being typed like that too before they added an official way to write them

We could just borrow this design from Discord, and switch the ID with a BoB ID

personally i prefer using the closest approximate emoji so it works better for clients without custom emoji support

like <:coolemote:cid:sha1+8f35fef110ffc5df08d579a50083ff9308fb6242@bob.xmpp.org>

> personally i prefer using the closest approximate emoji so it works better for clients without custom emoji support I just wonder if you can get away with encoding things in the <body> :P ↺

I'm sure the XSF members have something to say about that

The RFC has something to say about that

What does it say?

"If you do this, we will find you, and we will hurt you!"

.... Let's do it anyway!

> personally i prefer using the closest approximate emoji so it works better for clients without custom emoji support ``` <message from='me@example.com' to='you@example.com' type='chat'> <body>hehe 🧌</body> <markup xmlns='urn:xmpp:markup:0'> <emoji xmlns='urn:xmpp:emoji-markup:0' cid='cid:sha1+8f35fef110ffc5df08d579a50083ff9308fb6242@bob.xmpp.org' start='5' end='6' /> </markup> </message> ``` is i think what i'd want to do? or something like it at least, where the custom emoji is the funney meme troll face ↺

> What does it say? > The <body/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]). — RFC 6121 §5.2.3 ↺

pro tip just make a new body under a new namespace which can 🧌 ✏

Then clients can safely ignore it

(whether they actually do, is a different question)

out of curiosity who do you query for the custom emoji data with bob? can you query muc users themselves? i tried skimming 0045 for whether you can send iqs to muc users, but only saw that it may or may not be allowed in a muc; how often is it allowed vs not? should the query go to the muc itself?

if any user can send any emote it'd be like matrix or discord nitro, while if the emojis come from the muc ig it'd be like discord without nitro 🤔

BoB was made for 1:1, so you'd request directly from the sender; that could only work in a semi-/anon MUC if the MUC server forwards the request, but then they'd get hit by an avalanche of requests, so it would obviously be nicer if the MUC cached it the first time ✏

icic, is it common for mucs to forward them though? i assume it'd be a pretty simple server plugin to write considering this XEP seems to already include all the relevant stuff about caching lol

The server will forward certain payloads, according to what it supports - it doesn't just decide how it feels on that day

So if there is support for this specific extension, that would provide the forwarding

by common i meant more like how often will any arbitrary muc actually do it (not up to how the service feels)? like would either prosody or ejabberd restrict this by default, or would they _have_ to explicitly allow it?

Only if there is support for that specific extension, which there can't be before it exists

icic, i was hoping the muc would be fine with just forwarding it without knowing what it is, and letting the receiver decide whether they wanna deal with it or not 😔

That would be equal to forwarding everything every time

i guess its not as big a problem here if the muc should _really_ have support for caching anyways, but it makes yet another idea i had for mutual rooms kind of pointless as a default 😭

> If the data to be shared is particularly small (e.g., less than 1k), then the sender MAY send it directly by including a <data/> element directly in a <message/>, <presence/>, or <iq/> stanza oh we can just do this who needs caching anyways 🧌

not like any reasonable emote should ever be that large

Animated images tend to be larger

that is a good point i never use those so i forgor abt them

> BoB was made for 1:1, so you'd request directly from the sender; that could only work in a semi-/anon MUC if the MUC server forwards the request, but then they'd get hit by an avalanche of requests, so it would obviously be nicer if the MUC cached it the first time I mean the MUC should cache it ↺

the ID of the BoB is a hash of the file, so it's easy to verify for end-users, and a middle-man to cache it without security concerns

> ``` > <message from='me@example.com' to='you@example.com' type='chat'> > <body>hehe 🧌</body> > <markup xmlns='urn:xmpp:markup:0'> > <emoji xmlns='urn:xmpp:emoji-markup:0' > cid='cid:sha1+8f35fef110ffc5df08d579a50083ff9308fb6242@bob.xmpp.org' > start='5' > end='6' /> > </markup> > </message> > ``` > is i think what i'd want to do? or something like it at least, where the custom emoji is the funney meme troll face Just stick to a text representation of the custom emoji, instead of a emoji ↺

Otherwise what's the point :P

<body>haha :a-parrot-shaking-its-head-side-to-side-dancing-while-rapidly-cycling-through-psychedelic-colours:</body>

almost every emoji i know of can be roughly expressed in terms of an existing one, and its always super jarring when i see people send custom emojis now and i get to read :some-random-emoji: in the middle of their text; it'd be even more jarring to just see a random cid instead imo

although i understand not all of them can be expressed and as a _fallback_ i wouldn't mind shortcodes

technically this'd be a purely client-side thing so a ui when adding an emoji could just have like a required shortcode field and an optional alt emoji field, then messages would use the alt emoji if provided and the shortcode if not

then the receiving client will hopefully be able to handle replacement of either one

> <body>haha :a-parrot-shaking-its-head-side-to-side-dancing-while-rapidly-cycling-through-psychedelic-colours:</body> <body>:birdparty: :birdparty: :birdparty: :birdparty: :birdparty: :birdparty: :birdparty: :birdparty: </body> ↺

try to figure out what that emoji looks like :P

Cake everywhere

> almost every emoji i know of can be roughly expressed in terms of an existing one, and its always super jarring when i see people send custom emojis now and i get to read :some-random-emoji: in the middle of their text; it'd be even more jarring to just see a random cid instead imo How do I know you're talking about a frankenstein looking thing (that what it looks like to me), or a trollface ↺

because either way i'm already using 🧌 as a substitute for a trollface emoji; its a close enough equivalent that i and a lot of people i know already use it 🧌

and if you _really_ want to be sure, the markup element could include a `name` attribute containing the shortcode, which you could display when hovered or something idk

nevermind that's stupid the entire point is this is for clients that don't support the markup element

> because either way i'm already using 🧌 as a substitute for a trollface emoji; its a close enough equivalent that i and a lot of people i know already use it 🧌 Well what about some random person who doesn't know that's supposed to be a trollface ↺

and is thinking you're just talking about frankenstein :P

Honestly just say :trollface:

and have the makeup replace that with a BoB picture of a trollface

this is still entirely a client decision so i'm just gonna trust that a user who sets an alt emoji in a client that lets them is confident enough that they'll be understood either way 🤷

either way is fine i just think it'd be nice to let users of unsupporting clients have a nicer representation for custom emojis that can reasonably be represented in unicode too

So how do you amend XEP-0394 to include this?

> pro tip just make a new body under a new namespace which can 🧌 Luckily we have one. XHTML-IM ↺

'Course you do :P

>> pro tip just make a new body under a new namespace which can 🧌 > > Luckily we have one. XHTML-IM Which is deprecated ↺

And also hard to implement and sanitize

You need to implement a XHTML+CSS renderer

I get it's only CSS 1.0, but there's a lot you need to go through for stylized messages

>>> pro tip just make a new body under a new namespace which can 🧌 >> >> Luckily we have one. XHTML-IM > > Which is deprecated Who the fuck cares? Replies and reactions are experimental too. It's just a word ↺

> You need to implement a XHTML+CSS renderer No CSS. And html support is usually built into UI toolkit ↺

never expected a response like that from you of all people, but yes you could say that if people want to implement it then there's no problem

> Who the fuck cares? Replies and reactions are experimental too. It's just a word based based ↺

who cares about what XSF thinks

I honestly would consider a deprecated xep *more* legitimate for use than an experimental one

because deprecated means it was accepted before that

> No CSS. And html support is usually built into UI toolkit Really? Because the XHTML XEP is filled with CSS stuff ↺

experimental is just whatever random thing

CSS 1.0 at least

Also sometimes you don't have HTML support (maybe because of your UI tookit)

If you want to support some CSS you can. I support text colour. But you certainly don't need to

So writing a HTML renderer yourself would be a massive pain in the ass

Ill admit the html thing built in on iOS sucks so I made my own in an hour

supporting the 5 tags that matter

if I needed a lot more I might go back to the built in one

Well good thing the HTML in XHTML is old as fuck

If it's modern HTML5, you'd be really screwed

good thing html hasn't changed in a way that would matter to us since I was born

> Well good thing the HTML in XHTML is old as fuck i think that's fine because realistically you shouldn't be having gigantic interactive things in your messages

HTML5 is the same thing. I don't understand why people think it's new and scary. It's still b/strong/I/em/IMG/a

to be honest, the only actual use of XHTML-IM i've seen in regular use is someone sending a gigantic "FUCK YOU" in red letters

I'd like servers to bring back privacy lists at least

It got deprecated in favor of some subset of it that sucks ass

It's just a blocklist of domains and JIDs now

Cynthia: do you mean Blocking Command?

it was almost never fully implemented but nothing stops you from doing so now

> Cynthia: do you mean Blocking Command? Yes, the "successor" to Privacy lists ↺

I like the old archiving xep too but we're stuck with mam unless I want to go implement it

> it was almost never fully implemented but nothing stops you from doing so now I just wanna block strangers from PMing me or sending subscription requests ↺

So mod_block_strangers?

Now that the privacy lists module for Prosody has been completely broken in latest versions of Prosody, there isn't much I can do now ✏

could fix it

Kontribute!

> So mod_block_strangers? Try to convince a public server admin to add that ↺

Especially since it applies to EVERY stanza received

Not just people who want this

>> it was almost never fully implemented but nothing stops you from doing so now > I just wanna block strangers from PMing me or sending subscription requests what if the other user has the same module ↺

how do either of you send a subscription request

Well make it optional not every user. Or don't use so called "public" server

> Well make it optional not every user. Or don't use so called "public" server You need to modify mod_block_strangers to do that ✏ ↺

> how do either of you send a subscription request Can't. It's a problem with mod antispam too ↺

>> Well make it optional not every user. Or don't use so called "public" server > You need to modify mod_block_strangers to do that Indeed. ↺

Also mod_block_strangers breaks MAM

Even if you wanted to use it for yourself

> So how do you amend XEP-0394 to include this? https://git.isekai.rocks/snit/protoxeps/tree/emoji-markup.xml like this? 0394 explicitly makes allowance for further specifications to extend it ↺

note that this is a VERY rough draft and just my personal preference lol

i should really look at how the existing clients do this though

this is pretty gud

but you should add in a note for animated emojis

Clients SHOULD expect to handle animated emojis, if the file can hold it (GIFs, Animated PNGs, etc.)

ah good point ty :D

out of curiosity do you have any specific intention with "expect to handle", or could that include just ignoring the markup element altogether if an animated emoji is sent?

> out of curiosity do you have any specific intention with "expect to handle", or could that include just ignoring the markup element altogether if an animated emoji is sent? Show the first frame at least ↺

Like for example, if you give a PNG parser that can't handle APNGs an animated PNG, they just display the first frame

this makes sense

i guess the idea of ignoring the element makes sense as like a general "if the filetype is unsupported" statement rather than specifically for animated ones

> i guess the idea of ignoring the element makes sense as like a general "if the filetype is unsupported" statement rather than specifically for animated ones Also the client is allowed to slow down the playback of an animated emoji ↺

Anti-epilepsy and stuff

smart smart

pushed those changes

also feel free to take this and do whatever you want with it :) i like writing these but idk how many i'll actually want to submit and actually be responsible for 🧌

or maybe reduce the constrast of the GIF? (since seizures are primarily caused by super rapid constrast changes, idk i'm not epileptic)

> also feel free to take this and do whatever you want with it :) > i like writing these but idk how many i'll actually want to submit and actually be responsible for 🧌 too bad I can't submit it for you :P ↺

> or maybe reduce the constrast of the GIF? (since seizures are primarily caused by super rapid constrast changes, idk i'm not epileptic) maybe a more vague "implementations MAY post-process the file for color-deficiency, epilepsy, or other accessibility reasons" 🤔 ↺

yes :P

that's much better

but then again providing specific examples of post-processing would probably help too

> too bad I can't submit it for you :P "can't"? ↺

i'm a moth! anything I make is uncopyrightable

that's so real

i usually put everything i make in public domain but i'm not sure if that works with the XSF

you need to transfer your copyright over to them

yeah but can you do that still with public domain stuff? i figure not at least

also that's not a pondering emoji >:(

that's a little red dot you drew in GIMP

actually its just the example stuff in the original bob xep 🧌

like i said, VERY rought draft hehe

fair

> Also mod_block_strangers breaks MAM what? how? ↺

> what? how? https://issues.prosody.im/1410 ↺

hah. that's a fun bug. though I don't see how the mod privacy lists could be any different? unless it just happens to not have the bug

mod_privacy_lists is worse after modern versions of Prosody

it completely blocks groupchats

right. makes sense. that's what I'd sort of expect it to do naively. so bugs all around

I think Prosody API behavior changes lead to that

you can't even do anything else without tracking joins

unless you want spammers to be able to trivially bypass it

> you can't even do anything else without tracking joins what are you talking about ↺

well you could allow group chat type. But that's insufficient for this mam case and probably other things. And tracking joins is easy ✏

is moparis talking about groupchat blocking?

No about your block strangers case

oh

still doesn't make sense, what are joins

subscription acceptances?

MUC joins. The thing you were talking about

ohhhh

though even track joins would break mam if the app does it before join. Hmm

this is why I block strangers at the client level. Doing it on the server is complicated heh

whitelist MUCs on your bookmark?

blocking only to bare jid might get pretty much there actually

yes

you don't have to track joins

just stick to the user's MUC bookmarks

and whitelist those

what if they join and don't bookmark?

uhhhhh

> this is why I block strangers at the client level. Doing it on the server is complicated heh let me ask you a question ↺

if a spammer fakes their message as a groupchat message to get through the filter

will the client actually take it?

yes, that's what I was saying

like will it check "oh we're not in this room, so let's just ignore it"

I don't think clients should but all the ones I tested did

what the absolute FUCK

that is so fucking dumb

fine, we'll track joins in a session store

and also MAM requests (taking the ID of the stanza and query) ✏

> I don't think clients should but all the ones I tested did why do clients do the most dumbest shit ↺

like i know Conversations still blindly accepts invites without even prompting the user

also there's no way to tell if a message is a MUC PM or a 1:1

>> I don't think clients should but all the ones I tested did > why do clients do the most dumbest shit Lack of battle testing ↺

you think spammers have already done a decent amount of battle testing

You would think so yeah but not enough spammers

not enough? heh no, there's one too many

Gajim certainly does drop a type=groupchat message from a not joined MUC

i'm working on my own Prosody module that does stranger blocks and stuff, and if clients are really this dumb, then it'll take much more code than it would to actually make it

i'm not gonna hold a crappy client's hand too much, but i dont' have much of a choice if most of them are really this bad

maybe tone it down a little bit, why would it matter if a client accepts a type=groupchat message?

why would the spammer do this, and not simply send instead a type=chat

to get through filters

ideally we would be able to let through any groupchat messages because well, ideally clients can filter out messages from rooms they're not in

I reported some MUC PM bugs privately to conversations & dino, conversations fixed immediately, still nothing months later from dino I should just send morph the scripts lol

Lmao

> I reported some MUC PM bugs privately to conversations & dino, conversations fixed immediately, still nothing months later from dino I should just send morph the scripts lol maybe you should :P ↺

> ideally we would be able to let through any groupchat messages because well, ideally clients can filter out messages from rooms they're not in they can filter out these messages, so why do you care? ↺

> they can filter out these messages, so why do you care? they can.. but if moparisthebest is right, most of them don't ↺

> You would think so yeah but not enough spammers hire the spammers on matrix 🧌 ↺

> they can.. but if moparisthebest is right, most of them don't then there is maybe a reason or its the clients problem, nothing you need to fix on the server ↺

alright, fair

i won't filter groupchat messages then

if a dogshit client ends up not filtering it themselves, that's their problem

and i highly encourage spammers to exercise clients this way

sorry

try all the different type=normal etc that muc forwards and arguably shouldn't

best one was jingle calling via muc PM, it looks like the muc is calling you and you can't tell what nick it was

this should be a server

like badxmpp

I have code to publish for all these and more

Honestly make it into a public server

I always do this, make poc, report, forget about it while waiting far too long for fixes lol

it would be much easier if it was like badxmpp, a server you could connect to with the client

and see how it would fare

call it a client stresstesting suite or something

that would get much more attention than just reporting to some client devs ✏

i'd love more things i can just throw an implementation at to stress test it both for like spec compliance and also just against possibly malicious entities

could rework to just attack anyone who joins a muc

yes, that would be amazing ✏

for really any future client devs

or client devs.. right now

That's a good idea I'll add it to the todo pile

so anyway, i'm gonna write my module in a naive way

i'm not gonna fucking do vulnerability mitigations for clients

I think if you allow through only stuff to fulljid you're pretty safe anyway for this use case

the MUC pm workaround won't work for mucs you aren't even in etc

most of my personal spam filters allow through everything to fulljid