Modern XMPP project discussion - 2024-11-24

> And it doesn't take everything into account. So some servers are at the top of the list which I would never recommend, and some good reputable servers receive a terrible rating From your experience, what are some good, reputable, and reliable servers that has a good userbase and has existed for a long time? Right now I'm on hookipa.net. Is it any good?

Looks OK here, fwiw, polkadot https://compliance.conversations.im/server/hookipa.net/

I see

I see

Glad I picked correctly lol

That test suite is pretty focused on protocol features needed by Conversations. I'd suggest taking those tests with a grain of salt and consider that they rarely give a complete picture of everything that may be relevant.

In other words: every attempt to grade and rank servers will be opinionated 🙂

https://providers.xmpp.net/overview/ does have a lot more info than just protocol features enabled, that you could with some amount of work rank by your own criteria.

Nice overview 👌

Ask why they don't commit and answer, > From your experience, what are some good, reputable, and reliable servers that has a good userbase and has existed for a long time?

> https://providers.xmpp.net/overview/ does have a lot more info than just protocol features enabled, that you could with some amount of work rank by your own criteria. In a short time an A rated service has moved to D, based on one statement. Odd. ↺

Conversations.im is now D because of another odd reason. They are often recommended. And, Snikket is not listed, why?

Snikket is not a single server

opinionplatform.org, all the oddities can be well explained. you're welcome to join xmpp:support@chat.xmpp-providers.org?join

> Those rankings are primarily aimed at client developers, not users ↑ ↺

Are they though? What makes you think they are? Most of the criteria were chosen to have easier onboarding (e.g. inband registration) and less frustration after registration (e.g. upload limit too low)

Pre-filtered lists are available for client developers _if_ they want to use them. Developers are free to use an unfiltered version and apply their own criteria. That's what I see as aimed at client developers

Don't we have Compliance Suites?

Why not rank according to Compliance Suites?

leke, that can be a part of a rating, yes. But a fully compliant server may have undesirable properties as well

It's what compliance.conversations.im does?

No, compliance.conversations.im does not check for Compliance Suites. It does check for its own set of supported XEPs

cal0pteryx [14:19]: > Are they though? What makes you think they are? Demoting servers without IBR, for example

also > Security (C2S) is listed for some reason

specifically that is

or the fact that captchas and and free of charge are "A". or bus factor 1 person. some of the reasons i can see with a quick browse

> cal0pteryx [14:19]: > > Are they though? What makes you think they are? > Demoting servers without IBR, for example But onboarding is easier for users if they can do it directly from their app ↺

> Are they though? What makes you think they are? Most of the criteria were chosen to have easier onboarding (e.g. inband registration) and less frustration after registration (e.g. upload limit too low) In app onboarding is not something well run servers actually want. ↺

Its only client developers that think that is a good idea.

MSavoritias (fae,ve), I don't understand, C2S and S2S properties are not used for ratings. They used to, but the service providing these ratings went away.

>> cal0pteryx [14:19]: >> Demoting servers without IBR, for example > But onboarding is easier for users if they can do it directly from their app Not really, it is an annoying extra step you want to avoid. ↺

> MSavoritias (fae,ve), I don't understand, C2S and S2S properties are not used for ratings. They used to, but the service providing these ratings went away. read my message. i said: > is listed for some reason nobody cares about C2S security whatever that means except developers. in the sense that servers that dont have it shouldnt be listed at all to be for non-devs. ↺

MSavoritias (fae,ve), as I said, as a client developer, you're free to combine these infos to your own rating, if you think they fit your users better

for the list to be for non-devs

of course :)

I'd be careful to say "nobody cares about x". If it's part of why a provider is rated down or up, it becomes relevant to the user

>> But onboarding is easier for users if they can do it directly from their app > Not really, it is an annoying extra step you want to avoid. The only exception being apps that are primarily distributed through stores and use centralized servers. ↺

> The only exception being apps that are primarily distributed through stores and use centralized servers. That depends on where a user's entry point is? If you download the app first, you wouldn't want to be redirected to a website for registration (that is an extra step) ↺

> I'd be careful to say "nobody cares about x". If it's part of why a provider is rated down or up, it becomes relevant to the user they do care. but in the sense that if its secure its shown, if its not secure its not shown. Its not for "non-devs" if I have to figure out what C2S means ↺

> I'd be careful to say "nobody cares about x". If it's part of why a provider is rated down or up, it becomes relevant to the user Well, there should be minimum requirements for c2s secutity, and servers that don't fulfill them are better hidden and not down-ranked. ↺

> they do care. but in the sense that if its secure its shown, if its not secure its not shown. > Its not for "non-devs" if I have to figure out what C2S means "if it's not secure it is now shown" I don't understand that message ↺

if a server is not secure it is not shown on the list as Kris said

Ah you mean a provider is shown depending on that. Yes, sure. But this has be done in a transparent manner ;)

>> The only exception being apps that are primarily distributed through stores and use centralized servers. > That depends on where a user's entry point is? If you download the app first, you wouldn't want to be redirected to a website for registration (that is an extra step) Yes, but from a server admin perspective you really do not want the app to be the primary entry point. ↺

Does the user care?

that they have to pick a server from a random list? yes. i repeateadly had the experience where "picking" a server in the app was confusing

even with ratings and such

At the moment it's a difference of A or B depending on whether IBR is active or not. Both colored green

because ok I have like 5 servers that are "A" rating. that means nothing for me really

It means you did not pick one from D, which might bring you a really bad experience

Depends. Prople complain that it is hard to chose a server, and that is partially because clients hide away context that is necessary to make an informed decision about which server to choose. ✏

> Depends. Prople complain that it is hard to chose a server, and that is partially because clients hide away context that is necessary to make an informed decision about which server to choose. Right, that's what the project tries to achive. Enabling users to make an informed decision ↺

A ranking is a very poor substitute for visiting the server website, reading about their values, privacy policy etc.

exactly

servers are about communities, otherwise they are not really sustainable

And if you want people to do that you can better have them register on the website then.

Sure, that's a thing we offer in Gajim for example. We always link the website

Both A (IBR enabled) and B (no IBR) providers are listed for browsing. As soon as a provider is selected, additional info plus a website link is shown.

For as long as well-maintained servers like conversations.im and yax.im receive a 'D' rating I'll always question the rating system 🙂

> For as long as well-maintained servers like conversations.im and yax.im receive a 'D' rating I'll always question the rating system 🙂 me too ↺

For yax.im there is no support chat listed (that would be easy via xep-0157), and for conversations.im it's http upload storage size, which cannot be automatically determined as of now (that's why the "providers file" was invented until that property can be queried automatically)

All properties which cannot be retrieved automatically at the moment are covered by a provider file: https://providers.xmpp.net/provider-file-generator/ If a provider offers this file, its info is automatically updated

60% of all providers listed at providers.xmpp.net already offer such a file

> For yax.im there is no support chat listed (that would be easy via xep-0157), and for conversations.im it's http upload storage size, which cannot be automatically determined as of now (that's why the "providers file" was invented until that property can be queried automatically) Doesn't it? https://paste.debian.net/hidden/5d921137/ ↺

It looks like today's scan of yax.im did not receive an answer for the '157 query. It did before. Should be fine tomorrow?

I’m curious to know when we can expect to see messages that display both images and text simultaneously. I’ve heard that this was a compromise made in the past for compatibility with other clients, but the protocol actually allows for it.

With http upload there are no images per se. It is a hidden message with a link that tells clients that the link contains an image.

You could put additional metadata into that message, like a title or a image description, but that would require clients to agree on a format for that.

something like xhtml for example :P

I think it is just considered very low priority as you can just send a second message after sharing the image link.

Dino just received support for XEP-0447

https://xmpp.org/extensions/xep-0447.html

Kris, there is a format for that since 2002, the problem is simply that the most popular implementation didn't support it

and everyone else wanted to remain compatible

But now people are looking to more advanced formats anyway, which have even more features (again, the limit is simply implementations)

I see. So a C problem as usual 🤦‍♂️

> Dino just received support for XEP-0447 Seems nice. Basically it is just missing chunked file sharing and you have a bit torrent like function 😅 ↺

Dino is the only client implementing this?

> Seems nice. Basically it is just missing chunked file sharing and you have a bit torrent like function 😅 it doesnt have? :( ↺

Also it might be interesting to write a server module that attaches another source, so that accounts connected to that server can preferr that.

> Dino is the only client implementing this? https://xmpp.org/extensions/#xep-0447-implementations ↺

MSavoritias (fae,ve): it's not mentioned in the specs, but it has multi file support, so I guess if both sides know how to disassemble and reassemble files it could work purely client side with the current specs

meh. so i need to write a XEP on top of that then if it is widely adopted instead of SIMS

to make it aware of pieces of files

and framing possibly

cal0pteryx: thanks. The usual list of not actually practical to use clients sadly.

MSavoritias (fae,ve): yeah I would guess that is the best way forward

Well, some client needs to make a start right? In Gajim we already prepared the database for multiple possible formats. Now Dino made the first step

Yeah, thats good of course