XSF Discussion - 2022-04-14

What was the first xmpp client called?

Like, first ever

I don't know. Jabberd the server was the first software, I believe. Gabber, maybe?

What's that, archaeology time? /me digs in https://web.archive.org/web/19991013013136/http://jabber.org:80/

Looks like between 1999 and 2002 it went from zero to over 9000

That, sadly, doesn't help does it? By the time (2002) that jabber.org was listing clients there, there were tonnes. ✏

Indeed 😕

As of October 2000 Cartoon Messenger 0.22 CloudChat 0.4.6 Gabber 0.7.0 Hotjabber 0.72alfa IRC Transport 0.9.1 JabberIM 0.9.6.1 Jabbernaut 0.5b3 Jabberzilla Alpha 1 Jarl 0.4002 KIM 0.1.399 NewtJab 1.2 Pybber 0.1.0 - The Fly WinJab 0.9.2.25

Cambrian explosion?

Pybber 😂 wurstsalat

hey, there's even a website from the past: http://pybber.sourceforge.net/

http://pybber.sourceforge.net/pybshot.jpg

wow

look at the discussion^^

a tale as old as time

^^

Well now I'm getting nostalgic of a time I didn't experience :) Those screenshots of gnome 1 look so comfy. Ah. I still miss the times of gnome 2 before gnome went to complete corporate shit in 2010 with the release of gnome 3. But gnome 1 looks even better than gnome 2

I think Gabber is a fair bet at this point.

Can't say for certain it was the first, but it's definitely up there.

Sorry to interrupt the nostalgia time... Is there yet a chatroom for providers.xmpp.net discussion? Couldn't find one on the site. In fact, I couldn't find 'Contact' page at all :))

mjk: not yet

contact page is WIP

you can create issues if you have something to report

> mjk: not yet > contact page is WIP Good! > you can create issues if you have something to report I just did :)

Cool!

By habit, I was first looking to ask if the issue is known, so looked for a chat

Quick glance over the open and closed issues suggested it's not a duplicate :)

mjk: thats perfectly fine. we are not yet being flooded, so we appreciate feedback. I mean, even if we would be flooded.

:)

feel free to got to the github for the website mostly. and gitlab for the actual list

feedback: being a paid (and thus more sustainable) service should not just not be a negative marker, but it should actually be the other way around. saying "do not use" a sustainable service that is accountable to its users makes no sense to me.

also, that unknown upload size limit drags down services for not that good of a reason, too

sry for not opening issues. just reporting from mobile 😇

In bare xmpp, without extensions like MAM or anything, what happens if a message is sent to me when I'm offline? Does the server store it? When I come back online, will I be sent the message, and will it be <forward>'ed, will the time at which it was sent be preserved?

kurisu: generally handled through XEP-0160

So a delayed tag will be applied

(Though "bare XMPP" is always a stretch)

And the message will usually be stored for all eternity if you don’t connect again.

Vs. MAM where it’ll stay for one week or two before being deleted.

(Again, in the default configuration of some servers.)

kurisu, so, probably stored on the server and then delivered the next time you come online (and *only* to that client) then deleted from the server

raucao: in case it's about c.im, only being paid would place it in the cat. B (good server, but requires user interaction to register). What really dragged it down there is the other stuff (limits and location not being advertised on the website)

i don't know what c.im is

conversations.im, sorry

if you advertise upload limits you make it easier for malicious users to flood your upload server. i don't know why that would be a *significant* drawback to any normal user

maybe a small one, but not a "do not use" one

and again, doesn't matter how much "not free" drags you down, it should actually lift you up

imo

location being advertised is kind of silly, since anyone can claim any location, but you can easily just resolve their IPs and see for yourself

so yeah, not a single one of the negative points would make it a "do not use" for me personally. but just my feedback, do what you will with it

btw, the info is outdated, too https://twitter.com/marcusdeanadams/status/1508549364876251140

raucao: your are not necessarily the target for the declarative location, but we should not expect end users to manually resolve IPs

i meant that a provider index could do so

to give accurate information

Sure one can do geoip and also connect to the server and ask for http upload limits, but those can chamge at any moment, and the point is for the information to be stable (and one way to ensure that is commiting to it by placing it on the website)

Also, the visible IP address might be just your reverse proxy (cloudflare, anyone?)

that would also be a plus in a lot of cases

i'd rather have someone i trust host the data physically under their control than use a service on some public cloud provider

even if it don't trust them

it's just generally not a useful negative marker imo

like, would you *want* e.g. riseup to use an american or european cloud provider with full access to their VMs?

maybe this could be solved by categories for lists. for example privacy vs free accounts vs cooperatively run, etc.. just thinking out loud here

What's that? Everyone has their own priorities and criteria?

any currated list will be outdated in notime. this one is already outdated at launch. lol

Yes. I think if we need such a list it would make most sense to think about how the relevant data could be auto-queried.

Heh, I was just writing that in another chat...

I agree (and already shared with the project maintainers a while ago) that a manually-maintained list is a terrible idea

It has been tried countless times before, and I see nothing particularly different about this new attempt that would make its fate any different

Oh hush, let them learn it for themselves

I can't, it's painful to see it happen *again* :D

Those who do not learn from the countless XEP comparison tables are doomed to make their own instantly outdated comparison table

I think with some automation, it could become somewhat manageable... and I'm not aware that anyone has really tried that approach as often

I think there have been a couple of automated lists in the past, but they were one-person projects

I guess it seems easier to scrape the clients’ pages once than to build automation.

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

Isn't https://compliance.conversations.im/ an automated thing?

Except for the part where it's not following the current XSF compliance suite automatically

I was just suggesting in conversations@ as this conversation started, a JSON API that xmpp-providers could pull from

Damnit I was just typing a sarcastic comment that xep-309 didn't have enough json

Maybe we just need to implement XEP-0309 in Prosody and ejabberd for publishing the information directly, without compliance.conversations.im as the middle-party :)

On pubsub events, is the message type defined / of interest?

in XEP-0060, I'm finding only a reference that using 'headline' would likely prevent them from being stored in offline storage.

Guus, ^F "pubsub#notification_type"

MattJ, +1

MattJ, and then xmpp:providers.xmpp.net to collect them

Daniel, it is not outdate if we dont have a reference. We reached out to most providers >several< times

Zash, thank you.

emus, I think this is more about keeping it up-to-date in the future anyway.

emus: information on conversations.im seems pretty outdated

And/or just incomplete. For example the admins / the bus factor has always been displayed on our website

Which isn't like a big deal in itself. It just shows that maintaining such a list is hard

Which exactly? that it is for free now? Well, as said we did not find the statement on the website. Can you link regarding the bus factor? What is outdated there ✏

How does bus factor relate to reliability? What's the bus factor at atlassian?

Well, regarding the discussion: Yes, we want to automate more and also prefer this too. However, our focus in general is now to check how such criteria work, what people think and what could work out to automate. We had many discussions what makes sense in what manner. now simply rolling out some quick thoughts and then every two months asking to update the server info / implementations of such an automation will not be accepted by most operators, too. (I assume)

if i only have to maintain a single endpoint, that's 10x preferable to notifying whatever lists i don't even know about

And also here: The list is setup from a user centric view and how user might approach a service. is it complete, is are the criteria final yet or near perfect? I assume not, and likely never will be. But we have a new attempt with the .json file and the criteria and we would like to evolve this with as much as support we can get for this. And on the `freeofcost` key - we dont blame professional services. But we saw already devs going only for free of cost servers. If we dont separate they will just use the list and filter themselves. What I assume anyway many will do (we don't recommend, as we took a look at all these servers and there are some with sever issues). I personally would be happy if devs highly professional xmpp operators in their registrations. So this list also enables this in the end if one goes this way. I hope it got a bit more clear

emus: does not mentioning any cost mean it's free? If so then conversations.im is free. If not a lot of the servers on your list don't mention it either

And yes - things change all the time - but we try to get this process going and close a big gap in xmpp. This must not be the end of the story. If we integrate a common query for servers thats really great I assume. But maybe lets test this a bit first

you're getting the feedback right now. no need to be defensive about the current state

everyone's just trying to help

Which specific ones? I remember looking for such a statement incl. asking them to provide such a statement.

And as said. We don't want to make decisions for maintainers, we just provide information from their public websites. Otherwise this ends in arbitrariness and intransparency on how we act in the end, right?

raucao, yes that's alright. But I tried to rather explain our intentions and procedure

> if i only have to maintain a single endpoint, that's 10x preferable to notifying whatever lists i don't even know about I think I dont fully understand

emus, having the server announce all the infos instead of the operator notifying lists

server-DOAP?

wuhu, yes more DOAP! 🙂

but that is maybe a next step. Now we have a basis to discuss what should be in such a DOAP etc. or what ever we are going to do?

we're looking forward to automate as much as possible in order to reduce maintenance gaps. doing a one-catches-all server query would be fantastic

it would also make the list opt-in for providers, which is another benefit

i.e. using https://xmpp.org/extensions/xep-0157.html for contact addresses, and https://xmpp.org/extensions/xep-0309.html for server stuff + vcard, and further disco info processing for file size limits and so on

And such an approach now actually offers to improve maintainability through automation incl. update process

on the other hand I value transparency, and I think server operators _really should_ place infos on their website for new users to make an informed decision

yes +1

I had a quite bad experience because when I started with XMPP I though XMPP = XMPP (never heard of xeps etc)

And its not that I would not have been capable to understand details to some level (as some non tech-savvy users)

oh, there is a prosody module for '309: https://modules.prosody.im/mod_service_directories.html :)

and there are other things which automation cannot ensure: Are admins able to reach? Do all the evaluation spectra fits the real-life spectra? we had many cases where we had to rethink how we measure specific criteria. So automation is not the gold-standard in all cases. Operators should be invited to review this on a regular basis (monthly, quarterly, annually?) ✏

emus: > Operators should be invited to review this on a regular basis (monthly, quarterly, annually?) My assumption would be that this part is just completely unrealistic in practice, I'm afraid.

In what regard unrelalistic?

The second link in providers.json is a 404, ironically https://404.city/+/faq.html

haha

thanks

> The second link in providers.json is a 404, ironically https://404.city/+/faq.html Thanks, I am aware of that: https://invent.kde.org/melvo/xmpp-providers/-/jobs/290978 I just wanted to wait a bit until they set it up again.

Nice automation ;)

Of course, it is not perfect and should be run periodically. The same applies to many other ideas mentioned here. But I would like to remind you that we just wanted to share our project even if there is a lot potential for improvement :)

Yes!

I think that a good solution should automate as much as possible but in such a way that providers could use the data to embed them in their websites. So, we could fetch the data from their servers to include them in our lists and they could also fetch the same data to display details such as limits on their websites for transparency to the users. I know that most of you could easily fetch the data by yourself and do not need any of it, neither on https://providers.xmpp.net nor on any of the providers' websites. But keep in mind that our goal is to make XMPP usable for everyone :)

In the end, there would be only one source of truth (the server's configuration file) and many parts of XMPP Providers would be automated.

> I think that a good solution should automate as much as possible but in such a way that providers could use the data to embed them in their websites. So, we could fetch the data from their servers to include them in our lists and they could also fetch the same data to display details such as limits on their websites for transparency to the users. All of my yeses! Alternatively, you could provide an html snippet for embedding this info (kinda like the current badge, but much extended)

By the way, there is also an issue for automation aspects: https://invent.kde.org/melvo/xmpp-providers/-/issues/32 If someone could write scripts, implement things for server software or even provide a way to trigger the (Conversations) Compliance Tester or the IM Observatory, that would be really nice!

>All of my yeses! Alternatively, you could provide an html snippet for embedding this info (kinda like the current badge, but much extended) Nice idea. Yes :)

Are there more XEPs than https://xmpp.org/extensions/xep-0157.html and https://xmpp.org/extensions/xep-0309.html for automation? And are they supported / enabled by default by ejabberd, Prosody etc.?

Sounds like a question for DOAP! 🙂

XEP-0157 is* supported in Prosody. Not enabled by default. Majority of servers are expected to be smol private servers where it's less relevant. ✏

I thought the author of XEP-0309 was working on an implementation but I don't see any

The author being stpeter?

Yes.

Zash: https://modules.prosody.im/mod_service_directories.html ?

Ah, you found it!

emus, melvo, is your project translatable btw?

> Link Mauve escribió: > emus, melvo, is your project translatable btw? We plan to support this in the future

Ok, thanks. :)

Zash: Thanks. Holger, what is with ejabberd?

Beware, translation/i18n is one of those things that seem a million times harder to add later on, than having it from the start

+1

but i'll gladly offer weblate hosting