XSF Discussion - 2022-04-12

Would it be possible to have a module on the conference module or the user servers to filter out the useless keys for encrypted messages ?

In muc, all the encryption keys for all the participants are broadcasted to everyone, and basically the server only need to send the ones needed for each JID to decrypt its own

I more see that on the receiver servers, basically the server keep track of its users JID OMEMO keys ids and filter on those for each encrypted messages transfered

Yes, that could be done. I'm planning to work on some server-side enhancements for OMEMO, especially in MUCs, so this could probably go in too

What will be the impact of this filter on users in MUC with Multi-Devices

No impact

When retrieving the member-list of a room, https://xmpp.org/extensions/xep-0045.html#modifymember says that the returned items MAY include the 'nick' (and 'role') attribute for each member that is currently an occupant.

I'm wondering if there's a way to get the list of nicknames that has been reserved in a room.

I initially thought that the member-list includes that, but I guess the nickname in use does not need to be the nickname that's reserved?

In any case: knowing the nicknames of members not currently in the room would be nice. How to do that?

Guus, there is no way ..

how would that work if every user can use whatever nick he wants on join

the question is why would you need the nick?

you want to display offline users?

then this would be more of a server feature than a client one

server just needs to send a presence even for offline people with last known nick

i think MattJ did develop something for prosody

Guus, are you thinking that there may be reserved nicknames that is not part of the set of affiliated users?

I'd think that each reserved nickname is attached to an affiliation

Guus, completely unrelated to your issue, but XEP-0463 might be of interest to you.

To retrieve the complete list of affiliations.

Dear XMPP Community, you may have heard about the XMPP Providers project [1] already. It has a new approach to provide a curated list of XMPP providers based on hard and soft criteria. The project also provides the evaluation machine-readable. Client developers can integrate them in their applications. We approach this topic from a user-centric perspective and question what enables a good first start with XMPP when possibly coming from other environments. We created a separate website to present the results in a nice view. That way, it is convenient to read them. Feel free to take a look: https://providers.xmpp.net We put lots of effort, thoughts and discussions into this project to make the listings and evaluations as transparent and clear as possible. All criteria for the categorization are explained on our new website's FAQ section [2]. If you are a server operator and want to add or edit information, please ensure to first update your website. Otherwise, we cannot reference the information in the source file that is used to generate the provider lists. Then follow the contribution guideline to add your information [3]. We will create a MUC soon, so you can get in touch with us. Many thanks to MattJ for the technical backend support and deployment. Looking forward, XMPP Providers Team CC: emus, melvo, wurstsalat [1] https://invent.kde.org/melvo/xmpp-providers [2] https://providers.xmpp.net/faq/#how-are-categories-determined [3] https://invent.kde.org/melvo/xmpp-providers/-/blob/master/CONTRIBUTING.md

that looks nice, emus

where's the CSS though?

looks excellent!

Many thanks! But it is also the work of us three

https://providers.xmpp.net/provider/conversations.im/ is wrongly listed as paid if someone wants to try to beat me to a PR, I won't be able to get to it for awhile

Please first ensure that the information is on the domain website of the operators (transparency)

emus: thanks to you and your colleagues for working on this!!!

🙏️

IMHO we could use the operators chatroom for discussion about this

Yes, that is alright - we wanted to share here first

I look forward to redirecting https://github.com/stpeter/xmppdotnet to the appropriate repository

close *all* the PRs 😀

That too!

stpeter - have you deployed that to a website too? or was xmpp.net this some years ago?

This repository used to feed the list at xmpp.net

the list at https://xmpp.net/directory.php specifically

Okay thanks

As you can see, the repository is quite old and hasn't been maintained because I am a bad person.

bbiaf

all good

you are not 🙂

jonas’, the CSS ?

wurstsalat, it was glaring bright and I might look into how to dark theme it

but I couldn't find it in the repository

I created an issue for this

jonas’, good idea :) https://github.com/xsf/xmpp-providers-website/tree/master/themes/xmpp-providers/assets/css

Small world I didn't know you people were behind the project. :) Gods' work!

Thanks, it was a long time Melvin and me. Wurstsalat join recently regarding the website

Small "bug report": the [Details] button could use some more contrast/prominence and maybe a rename to [Full details]. IMO this would allow a visitor to obtain answers to "What?! Why?!" much more quickly. :))

And another: The 'Shared files are stored up to ...' phrasing seems a bit awkward to me. Do I understand right that total file storage quota is what's meant here?

Yes that's correct

thanks mjk

we'd appreciate feedback from native speakers! :)

Alas, I'm not one! Just my english sense tingling

😊️ is alright!

I dunno how to say it _elegantly_, but 'Shared files are stored until the quota of X is exceeded' would be much clearer

And render the unlimited case as 'Unlimited file storage quota'

Thanks, yes we had our discussions on this, too 🙂 We will review this topic

:thumb-up:

https://github.com/stpeter/xmppdotnet updated - all issues and PRs closed, README updated to point to the new repository!

Hmm. 'You cannot register on this provider' for disroot.org seems false. I know they have a "non-realtime" registration procedure, but there _is_ one (onless they closed xmpp registrations specifically)

bbiab

mjk: Thanks for the detailed review. Please have a look at https://invent.kde.org/melvo/xmpp-providers/-/blob/master/providers.json#L773 for disroot.org's web registration.

If I suggest that provider to someone on Friday and that person tries to register on Saturday, it will fail. That is the reason why it is set to `false`. ✏

melvo: oh, right, it's on weekdays only, now I remember. Still a long way to 'you cannot'. Maybe needs a note to be rendered on the page?

Can still be counted as 'false' formally ✏

Yes, we saw a wide spectra if implementation beyond want what common sense may expects

Haha, that's free federation for you :))

Another visualization: UWPX deployed a reference implementation hiw this could look like in the end: https://twitter.com/UWPX_APP/status/1408512845248188428?s=20&t=q1-JCnH3g2yG3bS-KeWTNg

"Registrations only on rainy Thursdays!"

> mjk escribió: > Haha, that's free federation for you :)) Yes it is. we just had to adjust the tool to cases we didnt expect ✏

Right, a boolean is alright

> mjk escribió: > Right, a boolean is alright often we thought its sufficient 🤷‍♂️

but reality is a greyzone

https://github.com/xsf/xmpp-providers-website/pull/35

> https://twitter.com/UWPX_APP/status/1408512845248188428 That's very cool

mjk: Here is the outcome of your feedback :)

melvo: thanks!

Thank you for spotting that!

My nitpicking duty!

👍

emus: as a server operator I do feel like getting down from A to C because http uploads are limited to 10 MiB is a bit too much opinionated. Especially when the service is fee of charge

(Not that I care too much, but getting a "bad" rating means we will get annoyed to death with requests to change our limits to fit that arbitrary standard)

just make the checkbox green mmkay

(But the website looks great and it will prove a very useful resource when people want to choose a server, so thanks for the work :p)

mathieui: We recommend to possibly increase the filesize limit, but decrease the totalfilesize storage. So you can still keep it to a level but let user have more space to send bigger files. Videos often expand this easily for example. Would that be an option for you?

> mathieui escribió: > (But the website looks great and it will prove a very useful resource when people want to choose a server, so thanks for the work :p) Thanks still!

emus, we might want to take advantage of what is available in the new prosody file share module, yes

Yes, we have that on our review too

The limit-per-upload always seemed kinda silly for me as a user. "So, I can upload a thousand 10-MiB photos? Cool! :))" Technically, I understand that it comes from implementations handling the whole file in memory, and possibly also from the lack of (better) quota calculation. With these things out of the way, what's still technically stopping operators from lifting the per-upload limit entirely?

Next problem is that uploads of very large files might get interrupted and can't be resumed.

mjk, can't answer for other implementations but with Prosody 0.12+ it's just a matter of configuration.

Nice. Also, clients would need to start displaying the total limit in addition to/instead of the per-file one.

Problem: That's not communicated in the protocol

There's a way to say "you have to wait until $time before you can upload a file of that size" but no way to communicate quotas or such

Aha, as I feared ✏

> Next problem is that uploads of very large files might get interrupted and can't be resumed. Right, but let clients worry about communicating this risk to people, mwahaha

XEP patch welcome 😉

:)

I'd think that (interrupted uploads) a HTTP problem rather than an XMPP problem.

Yes, but I'm sure google can fix that in their next revision of http

If they didn't already!

Inb4 moparisthebest points out that HTTP/3 already fixes everything somehow

Zash i actually think you can communicate the wait to date thing

its in the xep

lovetox, that's what I said. you can communicate that, but not anything else

ah ok i misread

and that's in an error, when you already tried to ask for a slot

Nothing stops you from implementing resumable uploads with http, or even compressed uploads

There's just no already existing spec for it