XSF Discussion - 2024-03-06

Hello where can i find a list of public canal that I can add ?

Hi imsxm15, some are listed here: https://search.jabber.network

Anybody know of an xmpp client for windows that has support for video/audio calls? I dont understand why this should be so hard to find... I found a Dino Windows version here but its not from the official Dino repositories so am hesitant to use it: https://github.com/LAGonauta/dino/releases

alom, Dino for Windows or Movim (web)

MattJ: Thanks this is also what I found. I want an installed client and not web. So it seems am left with an unofficial Dino version for windows. Well you dont seem to have any problem with it so I guess its fine👍 I was just worried it could be malware in disguise or simply not secure/buggy/lack of updates

Movim is a progressive Web App, you can also "install" it on your OS :) /ads

edhelas: Oh ok, thank you so much!😊👍

Same on Android, and there's push notification and a few other "native" features that comes with it

edhelas: Ok! Well I like conversations and cheogram on android so guess I will stick with that there🙂

XMPP, the power of choice ✨

edhelas: Right, nice one!😂😂

xep-0333 is one of the widest implemented XEPs that currently is non-stable (deferred even). I intent to bring this to stable over the coming months. Here is my current proposal on how to achieve that: https://gultsch.de/files/xep-0333.html

(tldr: remove everything but <displayed/>)

Daniel: 👍 I wish we could have more statements like this on our media and show activity. But I would need help for formulation

Daniel, what is reasoning behind removing <received/>? I wonder as I preferred this approach over XEP-0184. I know that with 333 we are losing information that particular message was delivered but I’m not sure people actually expect that or rather expect if „last message” was received/displayed what we get with 333

two reasons. a) I think for reliability tracking a lot of people prefer per message tracking b) 184 is widely deployed and realistically not going to go away

I didn’t see harm in having both in 333 as I’ve sent in clients <received/> from 333 and 184 in a single stanza (when it was possible)

> I didn’t see harm in having both in 333 as I’ve sent in clients <received/> from 333 and 184 in a single stanza (when it was possible) right. Conversations does that. but when implemented that way you literally are just replicating 184

not really, I’ve did 333 only for „live” messages or for last message from the MAM archive if I recall

I did 184 for each message as I’ve had 184 implementation before and was hoping to deprecate it from my clients

How would you notice a message in the middle disapearing into the void then?

> (tldr: remove everything but <displayed/>) 👍

I’m aware that I wouldn’t get when some message would be lost

However, with 184 you may not get ack, if I’m correct, when it was sent to the user when he was offline and user’s client only relies on MAM to sync history (XEP-0184, 5.5). In this case you should assume that those messages were not delivered and that is also not good…

I agree that 0333 received never made sense to me, not sure where I would use that. I know probably no one is implementing acknowledged but it seems safe to keep and the semantics make sense?

At the time '333 was discussed, acknowledged was certainly requested by some folk in certain industries where it's important

Whether they ended up using it, I don't know

I'm also in favour of not duplicating '184, I think the per-message receipts with per-conversation display markers is a good balance between the two models

Today reactions may fill that role (explicit ack)? ✏

Zash: reactions can be a hack for ack, but it doesn't have the same semantics so I'm loathe to consider it a full replacement

I honestly thing 184 per-message receipts and what make 0333 "up to" displayed markers work at all. Otherwise you have no idea what actually came before this?

I guess if all three links have sane sm on them you shouldn't need 184, but that's not where we live today

> I honestly thing 184 per-message receipts and what make 0333 "up to" displayed markers work at all. Otherwise you have no idea what actually came before this? +1

MattJ: I'm not clear at all which one the XSF uses, did you see https://opencollective.com/opensource/updates/regarding-the-announcement-to-dissolve-open-collective-foundation ?

XSF doesn't use any, XSF is its own

^

you can use XSF instead of OCF

(if we let you)

It's very confusing, but it does not affect the XSF or any of our projects

MattJ, singpolyma: what's https://opencollective.com/xmpp

moparisthebest: that is the XSF

opencollective.com != The Open Collective Foundation

This is what's shutting down: https://opencollective.com/foundation

You are right it's very confusing lol, but ok glad we aren't affected :)

i.e. an alternative to the XSF

Don't know if here is the right place to share this, but I think u will find it interesting (from Meta): > "Taking the example of WhatsApp, third-party clients will connect to WhatsApp servers using our protocol (based on the Extensible Messaging and Presence Protocol – XMPP). The WhatsApp server will interface with a third-party server over HTTP in order to facilitate a variety of things including authenticating third-party users and push notifications." https://engineering.fb.com/2024/03/06/security/whatsapp-messenger-messaging-interoperability-eu/

xmpp for c2s, http for s2s

"our protocol (based on...)" Gives me some pause, also why should my clients connect there instead of my server

I assume because that gives them a bunch more data to sell

> I assume because that gives them a bunch more data to sell this ↺

> This allows users of third-party providers who choose to enable interoperability (interop) to send and receive messages with opted-in users of either Messenger or WhatsApp haha, opted-in 🙃

🙈

moparisthebest: well, I expect they won't let you connect from a server mostly due to e2ee preservation bs

also they dont want to bother with keeping up with standards

and dealing with spam/abuse from other servers

"hi this is the XSF, we'd like to opt in for the entire public XMPP network, so just turn on S2S on your end kthx"

from what i have seen from my partner whatsapp has less spam than the federated xmpp network as it currently stands

so i would expect facebook and people that use whatsapp to object to that

meta products hide all the spam in a different ui place. I get lots on messenger but I never see it

> from what i have seen from my partner whatsapp has less spam than the federated xmpp network as it currently stands MSavoritias fae.ve: are they in public channels? Do those even exist in WhatsApp? ↺

no idea

> meta products hide all the spam in a different ui place. I get lots on messenger but I never see it that sounds like the moderation panel from yesterday :D

> When a third-party user registers on WhatsApp or Messenger,

100% of XMPP spam is on public channels though

i dont see why public channels have to make spam worse

if they do its a failure of moderation tools

moparisthebest: uh, most spam is 1:1 ✏

Not in XMPP in my experience

I don't think any meta product has public channels

moparisthebest, Your experience is (surprise!) subjective :)

moparisthebest: it's just a statistical fact. spam on 1:1 outnumbers MUC spam by over 100:1 ✏

I get a ton of 1:1 spam with SMS and email

i have blocked sms from non contacts at this point

email is thing i want to delete at some point. if only for guix using email :/

despite all the caveats, this meta thing is still interesting. but someone(tm) is gonna have to actually try the process with them. I guess we'll start by seeing what the requirements docuement says

moparisthebest, your JID is either on the spammers' lists or it isn't. If it isn't, you'll obviously get zero spam, and JIDs are not enumerable like phone numbers are.

That's the strange part though, my jid is actually public on xmpp.org and years and years ago I got a bunch of 1:1 spam but not again

Family/friends I have on XMPP have never seen spam

you're the lucky ones then :)

admittedly spam on xmpp is currently not very sophisticated

yeah i wish i was that lucky

There are at least two different lists around - for each spam wave generally one set of users or a second set of users will receive the spam (from, we believe, different spammers)

its waves personally

The wave that started a few weeks ago has been targeting user accounts that haven't been targeted for a long time, which is why everyone is suddenly caring about it again

Is it only XSF members or are your family/friends also getting them?

It's far from only XSF members

but more likely to get spam as a longer-time user of course than on a fresh jid

My own family don't receive spam, but I've heard from people who do have that problem

I get spam to lots of jids that don't even exist but are email addresses, so they're sharing lists with someone

🍯

🤫

It's likely my family have never shared their JID with anyone but it's the same as their email and they have certainly shared that

Maybe you have mod_block_strangers? or mod_firewall with the anti-spam ruleset in prosody-modules?

> My own family don't receive spam, but I've heard from people who do have that problem Yes my family members receive spam and they never published their jid anywhere

But it is the same address as their semi public email address

yeah. sharing jid spam with email spam lists is definitely happening some

No blocking here except to the kid's JIDs, but then I'd get a message that someone spammed them and I haven't either

You all need to be more explicit 🤣 you said "spam" and I thought we were just talking about MUC trolls, oops

nah, I honestly barely consider any of the MUC abuse we've seen as spam. I'm not sure any of it is even automated yet

whereas the 1:1 spam is clearly automated

Yeah, same, when I say "spam" I'm generally referring to the mass 1:1 spam that resembles email spam

Not MUCs, though we occasionally see manual MUC spam (which I also consider separate to flooding)

Having not had 1:1 spam since 2016 or whatever I would never have imagined that's what you meant haha

none of my users are having spam issues... maybe it's linked to server's popularity and jid using simple words and not fantasy nick names picked by users

> are they in public channels? Do those even exist in WhatsApp? afaik WhatsApp only knows private groups, they only become public if the invite link becomes publicly shared. The invite link can be invalidated at any time by the group admin however.

sounds like that invite xep that gets shared around

Then there read-only broadcast channels and so called "communities", which just bundle several related group chats together. ✏

TheCoffeMaker, it's not linked to server popularity - I am the only person on this domain and I receive spam

🙇️

Again, JID == email though, so it's probably scraped that way

While many XMPP services don't have JID == email

MattJ: perhaps you have a few enemies...

Seeing how many JIDs are sending spam - thousands ;)

🤣️

> TheCoffeMaker, it's not linked to server popularity - I am the only person on this domain and I receive spam I'm sure you're just downplaying your popularity :)

Hmm, no... someone voted "no" to me being an XSF member. So I have at least one enemy :P

MattJ: also your JID is literally everywhere no? Unless it's a secret one :)

moparisthebest, yeah, it's my everywhere JID. I have a separate JID for family, and that's spam-free of course.

> > TheCoffeMaker, it's not linked to server popularity - I am the only person on this domain and I receive spam > I'm sure you're just downplaying your popularity :) lol not intended at least

I did some more minor adjustments to https://gultsch.de/files/xep-0333.html including adding some business rules and some design considerations that explain what happened to ack and received

my goal here is to get this through last call as quickly as possible. so any feedback that helps achieve that is welcome

You could mention occupant-id

But not that important to this xep I guess

lovetox, how does the occupant id relate to the xep?

Attributing it to the right user

fair enough. let's see if i can come up with something

I would think just a note in security consideration?

That the MUC xep does not on its own prevent forgery and if that's important occupant Id should be validated ✏

How much do you even need <markable> ?

Not much. But 184 has it too

In theory you save traffic

By having it or by not having it?

The idea is if it's not on the message the client is not interested in a marker

So one less stanza to send

Yeah I think it makes sense to have some signaling at least in 1:1

But of course we use it also for read state sync so I'm sending it anyway for my other clients

> But of course we use it also for read state sync so I'm sending it anyway for my other clients Not anymore with mds

FWIW I think the MUC markers/RAI plugins for Prosody depend on <markable> in MUC

>> But of course we use it also for read state sync so I'm sending it anyway for my other clients > Not anymore with mds https://gultsch.de/files/xep-mds.html

Daniel: do we have some mitigation to endless growing pep node with that xep?

I guess at some point someone will run into a server limit what happens then ?

Which item will be dropped?

I hope the oldest one

Yes

i don’t know. I was considering adding something along the lines of 'when a client deletes a chat it MAY delete the item' or so

which doesn’t exactly fix the issue

but at least points people in some direction

however if the server deletes the oldest item this seems like relatively acceptable behaviour

> I hope the oldest one Wasn't that unspecified?

https://bpa.st/UFDA Date: Sun, 06 Oct 2019 14:12:44 +0200 on standards@

probably most people wont' get to 10k chats anyway so hopefully we can set limits high enough to not be an issue

> probably most people wont' get to 10k chats anyway so hopefully we can set limits high enough to not be an issue I've not read back for context, so I'm not sure if this is relevant, but: not all XMPP entities are human end-users.

I've been bitten before by limits that I never imagined would ever be hit.

Will this be relevant for those tho?

> probably most people wont' get to 10k chats anyway so hopefully we can set limits high enough to not be an issue Challenge accepted ↺

Yeah I think non-human users mostly shouldn't need private PEP at all, especially not for this kind of thing

famous last words...

I don't get how https://xmpp.org/extensions/xep-0474.html#hash is actually secure. If Eve (that is doing the MITM attack) can actually change the stanzas she can: 1. Change the SASL mechanisms list initially sent by the server 2. Calculate her own hash and replace the d= parameter in the base64 provided by the server 3. Also inject her own hash in the d= parameter provided by the client I'm missing something there 🤔

edhelas: it depends on the existing mutual authentication of SCRAM. Eve does not have the user's credentials and cannot calculate the correct proof for the modified 'd' hash.

Ah !

> Hash S using the same hash mechanism as used for the SCRAM mechanism currently in use and encode the result using base64

So this means that it's more than a simple sha* of the string, but the complete SCRAM flow applied to it (number of iterations...). So indeed it is unique.

edhelas: no, just one iteration