I don't know. Jabberd the server was the first software, I believe. Gabber, maybe?
Zash
What's that, archaeology time? /me digs in https://web.archive.org/web/19991013013136/http://jabber.org:80/
mimi89999has joined
phoeboshas joined
Zash
Looks like between 1999 and 2002 it went from zero to over 9000
Kev
That, sadly, doesn't help does it? By the time (2020) that jabber.org was listing clients there, there were tonnes.✎
phoeboshas left
adiaholichas left
Kev
That, sadly, doesn't help does it? By the time (2002) that jabber.org was listing clients there, there were tonnes. ✏
Zash
Indeed 😕
TheCoffeMakerhas joined
stphas left
BASSGODhas left
Kev
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
Danielhas left
L29Ahhas left
L29Ahhas joined
Zash
Cambrian explosion?
Danielhas joined
emus
Pybber 😂 wurstsalat
wurstsalat
hey, there's even a website from the past: http://pybber.sourceforge.net/
TheCoffeMakerhas left
emus
http://pybber.sourceforge.net/pybshot.jpg
emus
wow
gooyahas joined
emus
look at the discussion^^
Zash
a tale as old as time
konstantinoshas left
emus
^^
neshtaxmpphas joined
konstantinoshas joined
Danielhas left
Danielhas joined
papatutuwawahas joined
kurisu
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
BASSGODhas joined
Kev
I think Gabber is a fair bet at this point.
Kev
Can't say for certain it was the first, but it's definitely up there.
ti_gj06has left
mjk
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 :))
ti_gj06has joined
emus
mjk: not yet
emus
contact page is WIP
emus
you can create issues if you have something to report
stphas joined
mjk
> mjk: not yet
> contact page is WIP
Good!
> you can create issues if you have something to report
I just did :)
marc0shas left
marc0shas joined
emus
Cool!
mjk
By habit, I was first looking to ask if the issue is known, so looked for a chat
mjk
Quick glance over the open and closed issues suggested it's not a duplicate :)
restive_monkhas left
antranigvhas joined
raucaohas left
djorzhas joined
emus
mjk: thats perfectly fine. we are not yet being flooded, so we appreciate feedback. I mean, even if we would be flooded.
mjk
:)
lovetoxhas joined
emus
feel free to got to the github for the website mostly. and gitlab for the actual list
raucaohas joined
konstantinoshas left
antranigvhas left
konstantinoshas joined
pasdesushihas left
tykaynhas left
Titihas left
adiaholichas joined
djorzhas left
wladmishas joined
antranigvhas joined
raucao
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.
raucao
also, that unknown upload size limit drags down services for not that good of a reason, too
BASSGODhas left
raucao
sry for not opening issues. just reporting from mobile 😇
Samhas joined
adiaholichas left
lovetoxhas left
debaclehas joined
adiaholichas joined
mhhas left
վարյաhas left
վարյաhas joined
Samhas left
stphas left
Samhas joined
mhhas joined
antranigvhas left
xnamedhas joined
Yagizahas left
Samhas left
kurisu
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?
mathieui
kurisu: generally handled through XEP-0160
mathieui
So a delayed tag will be applied
mathieui
(Though "bare XMPP" is always a stretch)
Link Mauve
And the message will usually be stored for all eternity if you don’t connect again.
Link Mauve
Vs. MAM where it’ll stay for one week or two before being deleted.
BASSGODhas joined
Link Mauve
(Again, in the default configuration of some servers.)
Titihas joined
Zash
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
adiaholichas left
restive_monkhas joined
Titihas left
lovetoxhas joined
adiaholichas joined
Titihas joined
mjk
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)
raucao
i don't know what c.im is
mjk
conversations.im, sorry
lovetoxhas left
lovetoxhas joined
raucao
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
raucao
maybe a small one, but not a "do not use" one
raucao
and again, doesn't matter how much "not free" drags you down, it should actually lift you up
raucao
imo
raucao
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
raucao
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
Tobiashas left
Tobiashas joined
Samhas joined
raucao
btw, the info is outdated, too https://twitter.com/marcusdeanadams/status/1508549364876251140
mathieui
raucao: your are not necessarily the target for the declarative location, but we should not expect end users to manually resolve IPs
raucao
i meant that a provider index could do so
raucao
to give accurate information
mjk
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)
mjk
Also, the visible IP address might be just your reverse proxy (cloudflare, anyone?)
raucao
that would also be a plus in a lot of cases
TheCoffeMakerhas joined
raucao
i'd rather have someone i trust host the data physically under their control than use a service on some public cloud provider
raucao
even if it don't trust them
raucao
it's just generally not a useful negative marker imo
Samhas left
raucao
like, would you *want* e.g. riseup to use an american or european cloud provider with full access to their VMs?
adiaholichas left
Samhas joined
raucao
maybe this could be solved by categories for lists. for example privacy vs free accounts vs cooperatively run, etc.. just thinking out loud here
adiaholichas joined
ti_gj06has left
TheCoffeMakerhas left
Zash
What's that? Everyone has their own priorities and criteria?
Sevehas left
libredevhas joined
Sevehas joined
Fishbowlerhas left
Fishbowlerhas joined
Tobiashas left
Tobiashas joined
lovetoxhas left
Tobiashas left
Tobiashas joined
adiaholichas left
adiaholichas joined
Tobiashas left
Tobiashas joined
Daniel
any currated list will be outdated in notime. this one is already outdated at launch. lol
Tobiashas left
Holger
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.
Wojtekhas joined
MattJ
Heh, I was just writing that in another chat...
MattJ
I agree (and already shared with the project maintainers a while ago) that a manually-maintained list is a terrible idea
lovetoxhas joined
MattJ
It has been tried countless times before, and I see nothing particularly different about this new attempt that would make its fate any different
Zash
Oh hush, let them learn it for themselves
libredevhas left
MattJ
I can't, it's painful to see it happen *again* :D
Zash
Those who do not learn from the countless XEP comparison tables are doomed to make their own instantly outdated comparison table
Zashscans XEP list for the one...
MattJ
I think with some automation, it could become somewhat manageable... and I'm not aware that anyone has really tried that approach as often
MattJ
I think there have been a couple of automated lists in the past, but they were one-person projects
Tobiashas joined
Link Mauve
I guess it seems easier to scrape the clients’ pages once than to build automation.
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
Paganinihas joined
adiaholichas left
TheCoffeMakerhas joined
Zash
https://xmpp.org/extensions/xep-0309.html
Tobiashas left
Andrzejhas joined
Zash
Isn't https://compliance.conversations.im/ an automated thing?
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
Zash
Except for the part where it's not following the current XSF compliance suite automatically
MattJ
I was just suggesting in conversations@ as this conversation started, a JSON API that xmpp-providers could pull from
moparisthebest
Damnit I was just typing a sarcastic comment that xep-309 didn't have enough json
konstantinoshas left
Tobiashas joined
konstantinoshas joined
adiaholichas joined
MattJ
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 :)
Guus
On pubsub events, is the message type defined / of interest?
Guus
in XEP-0060, I'm finding only a reference that using 'headline' would likely prevent them from being stored in offline storage.
Zash
Guus, ^F "pubsub#notification_type"
TheCoffeMakerhas left
Holger
MattJ, +1
lovetoxhas left
Zash
MattJ, and then xmpp:providers.xmpp.net to collect them
emus
Daniel, it is not outdate if we dont have a reference. We reached out to most providers >several< times
adiaholichas left
Guus
Zash, thank you.
Holger
emus, I think this is more about keeping it up-to-date in the future anyway.
Daniel
emus: information on conversations.im seems pretty outdated
Tobiashas left
Tobiashas joined
Daniel
And/or just incomplete. For example the admins / the bus factor has always been displayed on our website
emus
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 outdate there✎
Daniel
Which isn't like a big deal in itself. It just shows that maintaining such a list is hard
emus
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 ✏
antranigvhas joined
moparisthebest
How does bus factor relate to reliability? What's the bus factor at atlassian?
BASSGODhas left
emus
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)
Tobiashas left
Tobiashas joined
lovetoxhas joined
Tobiashas left
Tobiashas joined
raucao
if i only have to maintain a single endpoint, that's 10x preferable to notifying whatever lists i don't even know about
emus
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
BASSGODhas joined
Daniel
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
emus
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
raucao
you're getting the feedback right now. no need to be defensive about the current state
raucao
everyone's just trying to help
emus
Which specific ones? I remember looking for such a statement incl. asking them to provide such a statement.
Tobiashas left
Tobiashas joined
emus
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?
emus
raucao, yes that's alright. But I tried to rather explain our intentions and procedure
BASSGODhas left
emus
> 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
lovetoxhas left
marc0shas left
marc0shas joined
wurstsalat
emus, having the server announce all the infos instead of the operator notifying lists
Zash
server-DOAP?
emus
wuhu, yes more DOAP! 🙂
emus
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?
marc0shas left
marc0shas joined
wurstsalat
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
lovetoxhas joined
restive_monkhas left
papatutuwawahas left
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
raucao
it would also make the list opt-in for providers, which is another benefit
wurstsalat
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
papatutuwawahas joined
emus
And such an approach now actually offers to improve maintainability through automation incl. update process
restive_monkhas joined
adiaholichas joined
BASSGODhas joined
wurstsalat
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
emus
yes +1
emus
I had a quite bad experience because when I started with XMPP I though XMPP = XMPP (never heard of xeps etc)
BASSGODhas left
emus
And its not that I would not have been capable to understand details to some level (as some non tech-savvy users)
lovetoxhas left
wurstsalat
oh, there is a prosody module for '309: https://modules.prosody.im/mod_service_directories.html :)
adiaholichas left
emus
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 on all cases. Operators should be invited to review this on a regular basis (monthly, quarterly, annually?)✎
emus
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?) ✏
Holger
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.
Half-Shothas left
Matthewhas left
homebeachhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
neshtaxmpphas left
neshtaxmpphas joined
Tobiashas left
Tobiashas joined
antranigvhas left
adiaholichas joined
emus
In what regard unrelalistic?
antranigvhas joined
TheCoffeMakerhas joined
MattJ
The second link in providers.json is a 404, ironically https://404.city/+/faq.html
emus
haha
emus
thanks
konstantinoshas left
L29Ahhas left
L29Ahhas joined
TheCoffeMakerhas left
konstantinoshas joined
BASSGODhas joined
antranigvhas left
lovetoxhas joined
BASSGODhas left
վարյաhas left
antranigvhas joined
Tobiashas left
melvo
> 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.
MattJ
Nice automation ;)
adiaholichas left
konstantinoshas left
stphas joined
melvo
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 :)
emus
Yes!
ti_gj06has joined
debaclehas left
TheCoffeMakerhas joined
moparisthebesthas left
konstantinoshas joined
Tobiashas joined
florettahas left
pasdesushihas joined
Tobiashas left
BASSGODhas joined
moparisthebesthas joined
florettahas joined
BASSGODhas left
TheCoffeMakerhas left
Tobiashas joined
marc0shas left
konstantinoshas left
konstantinoshas joined
melvo
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 :)
Andrzejhas left
neshtaxmpphas left
melvo
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.
Tobiashas left
Tobiashas joined
Andrzejhas joined
APachhas left
APachhas joined
lovetoxhas left
marc0shas joined
mjk
> 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)
melvo
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!
melvo
>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 :)
lovetoxhas joined
BASSGODhas joined
konstantinoshas left
konstantinoshas joined
Andrzejhas left
chipmnkhas joined
BASSGODhas left
վարյաhas joined
melvo
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.?
Zash
Sounds like a question for DOAP! 🙂
Zash
Supported in Prosody. Not enabled by default. Majority of servers are expected to be smol private servers where it's less relevant.✎
sbachhas left
sbachhas joined
վարյաhas left
lovetoxhas left
BASSGODhas joined
BASSGODhas left
Zash
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. ✏
Zash
I thought the author of XEP-0309 was working on an implementation but I don't see any