XSF Discussion - 2024-02-13

hmm, https://xmpp.org/extensions/xep-0292.html#contacts first says "If the other person or entity is in the user's roster" and also "SHOULD contain the Jabber ID of the person or entity." but then says "When a client stores items at this node, it MUST include an ItemID set to the bare JID of the contact." so I guess if they don't have a JID then there is a format for them, but they must be stored in some other pep node?

and if they have multiple jids I guess just pick one

Maranda > MIX is just what soon became a Frankensteinian that with good reason will never see the light I think I have an idea on how to urge the transfer to MIX

Why is it so important?

Shortly, what is XSF?

XSF (XMPP Standards Foundation), is an organization that develops open extensions to XMPP (the core communication protocol for instant messaging and presence).

> Why is it so important? pep. I do not know. I do feel inconvenient with the command execution which allows revealing JID.

Can anyone that's speaking French natively find a page with job vacancies on https://www.silverpeas.com/ ? They appear to be using XMPP / eJabberd, which puts it on my xmpp.work radar.

https://www.linkedin.com/company/silverpeas/ ?

Yeah, I found that, but prefer to link to websites of companies directly, rather than go through LInkedIn (or any other job board)

I'm not finding much :/

Ok, thanks. Neither did I though Google Translate

They're even mentioning ConverseJS - anyone know these people?

Guus: they are part of a group which has https://www.oosphere.com/candidat/candidat-consultez-les-offres/ for job offers

Ah, thanks. That's not updated with what they have on LinkedIn though: https://www.linkedin.com/jobs/view/3828858110/

I'll just point at that for now.

(Also re: converse, in a previous company which did not have anything linked to XMPP, we had a client asking for XMPP integration so the developers just dropped in converse and tweaked things until it worked, without really engaging in anything protocol-wise, so they also have the option of not being actively part of the community from my experience)

Sure - it's true for many jobs on xmpp.work that XMPP might be a marginal thing of the overall job. These people, however, also list ejabberd - so that suggest a bit more XMPP in their stack, I suppose.

>> Why is it so important? > pep. I do not know. > I do feel inconvenient with the command execution which allows revealing JID. Schimon: MIX "reveals your JID" at least as much as MUC, maybe more, can't remember ↺

In the sense of less? :)

the fud around MIX seems to be a lot :)

moparisthebest, does it reveal to anyone? My issue is that me and bot are participants in a groupchat where JIDs are not revealed to participants. This can be circumvented by sending an IQ request - to execute a command - to the bot. Is this an intended scenario?

Schimon: I didn't follow that fully but wasn't that a bug?

> the fud around MIX seems to be a lot :) What FUD ? If you send a message to a remote muc/mix service that service has your JID ↺

> wasn't that a bug? I think it is not a bug.

The "can't remember" is muc has semi-anonymous that hides jid from non admins and I can't remember if mix does, iirc it didn't originally

My bot can reveal JID of anyone that attempts to ask it for list of commands

I'm wondering if that's an implementation detail of some server

pep., it happens on every MUC

Which every?

Every MUC I tried the bot at

> My bot can reveal JID of anyone that attempts to ask it for list of commands Then this is 100% a bug, or multiple bugs ↺

On prosody?

Yes, also on Prosody

Because I know prosody forwards iq requests even on semi-anon MUCs so I'm wondering if there's something to look for there

*I will write a bot that will reveal "part" of participant JID upon asking it for command list.* ✏

Yes please share more details so it can be fixed

*I will write a bot that will reveal _part_ of participant JID upon asking it for command list.* *Hi! The <number> letter of yor JID is <letter>.* ✏

Is this a client bug where the client contacts the bot on its actual jid after retrieving the commands through the muc jid?

Possible

I'm not implementing ad hoc commands (especially not with muc participants) but that sounds like a possible way to fuck this up

I don't immediately see how.

Daniel, this is the bot https://gitgud.io/sjehuda/slixfeed It displays JID in the form it offers.

In as much as if the sender doesn't know the bot's JID because it's a semi-anon room, how would it send direct to the bot's JID?

Hmm yeah I guess the muc should rewrite that jid

Kev: the command list has jids to contact, no?

> : the command list has jids to contact, no? Oh, you mean #items?

Isn't that the 'command list' in a way?

I guess the bot sends JID and then the client begins to interact with that bot JID using its own. ✏

Yes.

That sounds plausible.

It is the command list, yes ✏

In which case, it's not really a bug, exactly.

I'm wildly guessing the bot sends it's own jid back (maybe a bug) the muc doesn't rewrite it (maybe a bug) and the client reveals it's own jid (definitely a bug)

Give me an hour and I will provide a bot that realizes this issue. ✏

Can you not just explain the issue

Rather that running commands on an arbitrary JID reveals the sender's JID to the target entity.

Instead of writing a poc

> In which case, it's not really a bug, exactly. Sure. Schimon seems to hint at some clients doing that (meaning command discovery) semi automatically or something

Which would probably be a bug

Daniel, Once requested (queried) for command-list, I suppose that the bot (slixmpp) reveals its JID. Then the requesting JID (you or me) sends back our own JID to the bot or negotiating with the bot JID directly. P.S. I am a lawyer, not a programer. ✏

> Which would probably be a bug I think a note to the user is in order, more than anything else.

The description I gave is a guess, after observing and reading your comments here

Do you - the owner of the bot - want to avoid this or are you (bot) actively malicious in that scenario?

> I think a note to the user is in order, more than anything else. You mean a warning message?

If a) return the muc jid instead of the real jid if b) fix the client to display appropriate warnings

> Do you - the owner of the bot - want to avoid this. Yes. > are you (bot) actively malicious in that scenario? No.

Then see (a)

> a) return the muc jid instead of the real jid This is what I expected to see, when I first made that attempt a couple of days ago. > b) fix the client to display appropriate warnings This is up to Gajim, Psi, Conversations etc.

> a) return the muc jid instead of the real jid I am intending to look into this, once I am done structuring the Ad-hoc forms or once Gajim has a new release.

Daniel, we still can not prevent others from abusing this mechanism; so, at the very least, this should also be taken care of by clients (i.e. display warning to user).

I think this is yet another case of underspecified semi-anon in 0045, I think services should plainly drop ad-hoc requests going to participant JIDs

> Daniel, we still can not prevent others from abusing this mechanism; so, at the very least, this should also be taken care of by clients (i.e. display warning to user). A agree. It's just that the angle of "this is a muc bug we need mix" was very confusing

> I think this is yet another case of underspecified semi-anon in 0045, I think services should plainly drop ad-hoc requests going to participant JIDs I don't think this is ad hoc specific. If anything you are making a point to disallow iq routing

I don't see how MIX vs MUC would help in this example.

Which has always been weird anyway

Daniel, ad-hoc is a bit specific because answers by your client exposes your JID

> > I think this is yet another case of underspecified semi-anon in 0045, I think services should plainly drop ad-hoc requests going to participant JIDs > I don't think this is ad hoc specific. If anything you are making a point to disallow iq routing I think it's disco#items specific, kinda.

*I am intending to write a bot as a Proof of Concept to present this issue, be it an exploit or not.* *I sense we would all benefit from utilizing such software.*

most IQ payloads don’t, AFAIK ✏

> Daniel, ad-hoc is a bit specific because answers by your client exposes your JID Can, anyway, does in this case ↺

It's arguably a bug in the clients not to show a warning or anything. But hardly anything to do with MUC protocol wise. It's the same if I send an xmpp uri to the channel rnd someone clicks it

> I think this is yet another case of underspecified semi-anon in 0045, I think services should plainly drop ad-hoc requests going to participant JIDs Hmm. I mean if we're going to have bots in chrnnels then we probably want this to work. I'm not the biggest bot fan always but yeah ↺

I understand MUC iq is messy but if you allow semi anon then it's an essential feature

A warning would be nice. I have received this revelation with a big surprise.

Schimon: do you understand how to fix the bot now?

singpolyma, the issue I have here means that as a library developer I have to either keep track *in 0050* of what constitues a semi-anon MUC and what does not, or keep a global state doing the same thing ✏

mathieui: you can either keep track of if it is semi anon or just keep track of if it is a MUC if you prefer

You don't have to, but if you don't want to ask people for their jid then you need to yeah

or count on clients showing a warning when doing ad-hoc inside a MUC (which does not help cases where you do not want to expose the bot JID)

> Schimon: do you understand how to fix the bot now? singpolyma, I think I do, but I am not sure yet. I would have to test. I will make the bot to fetch MUC JID instead of sharing real JID (and consequently directly negotiate)

There's nothing to "fetch" you know your MUC jid already based on your nick

To be clear if a bot can trick a client into exposing their jid that's a client bug too

Yes for sure

Are there any council minutes about for recentish council meetings?

Does the MUC have mam?

minutes != logs tho

True, but paging back week by week on https://logs.xmpp.org/council/ is helpful. The meetings are typically pretty concise.

(The've been on Tuesdays, recently)

are there any clients that support disabling all storage of chat logs client side?

I _guess_ Profanity or Poezio

profanity has logs for me by default, maybe you can turn it off

they're in ~/.local/share/profanity/chatlogs

> Are there any council minutes about for recentish council meetings? I haven't even thought about council minutes in years, longer than I've been on it 🤣 ↺

also ~/.local/share/profanity/database/jid/chatlog.db

grin: how do you turn it off? besides deleting that file sometimes which isn't quite the same I guess

i have no clue :/ sorry

apparently gajim can, just found it in account settings

Link Mauve could you do whatever needs to be done so I can speak in the OSM chat, please?

I get an error in Moving saying that "Only occupants can send messages", whatever that means.