KevI don't know. Jabberd the server was the first software, I believe. Gabber, maybe?
ZashWhat's that, archaeology time? /me digs in https://web.archive.org/web/19991013013136/http://jabber.org:80/
mimi89999has joined
phoeboshas joined
ZashLooks like between 1999 and 2002 it went from zero to over 9000
KevThat, sadly, doesn't help does it? By the time (2020) that jabber.org was listing clients there, there were tonnes.✎
phoeboshas left
adiaholichas left
KevThat, sadly, doesn't help does it? By the time (2002) that jabber.org was listing clients there, there were tonnes. ✏
ZashIndeed 😕
TheCoffeMakerhas joined
stphas left
BASSGODhas left
KevAs 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
ZashCambrian explosion?
Danielhas joined
emusPybber 😂 wurstsalat
wurstsalathey, there's even a website from the past: http://pybber.sourceforge.net/
TheCoffeMakerhas left
emushttp://pybber.sourceforge.net/pybshot.jpg
emuswow
gooyahas joined
emuslook at the discussion^^
Zasha tale as old as time
konstantinoshas left
emus^^
neshtaxmpphas joined
konstantinoshas joined
Danielhas left
Danielhas joined
papatutuwawahas joined
kurisuWell 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
KevI think Gabber is a fair bet at this point.
KevCan't say for certain it was the first, but it's definitely up there.
ti_gj06has left
mjkSorry 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
emusmjk: not yet
emuscontact page is WIP
emusyou 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
emusCool!
mjkBy habit, I was first looking to ask if the issue is known, so looked for a chat
mjkQuick glance over the open and closed issues suggested it's not a duplicate :)
restive_monkhas left
antranigvhas joined
raucaohas left
djorzhas joined
emusmjk: thats perfectly fine. we are not yet being flooded, so we appreciate feedback. I mean, even if we would be flooded.
mjk:)
lovetoxhas joined
emusfeel 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
raucaofeedback: 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.
raucaoalso, that unknown upload size limit drags down services for not that good of a reason, too
BASSGODhas left
raucaosry 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
kurisuIn 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?
mathieuikurisu: generally handled through XEP-0160
mathieuiSo a delayed tag will be applied
mathieui(Though "bare XMPP" is always a stretch)
Link MauveAnd the message will usually be stored for all eternity if you don’t connect again.
Link MauveVs. 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
Zashkurisu, 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
mjkraucao: 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)
raucaoi don't know what c.im is
mjkconversations.im, sorry
lovetoxhas left
lovetoxhas joined
raucaoif 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
raucaomaybe a small one, but not a "do not use" one
raucaoand again, doesn't matter how much "not free" drags you down, it should actually lift you up
raucaoimo
raucaolocation being advertised is kind of silly, since anyone can claim any location, but you can easily just resolve their IPs and see for yourself
raucaoso 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
raucaobtw, the info is outdated, too https://twitter.com/marcusdeanadams/status/1508549364876251140
mathieuiraucao: your are not necessarily the target for the declarative location, but we should not expect end users to manually resolve IPs
raucaoi meant that a provider index could do so
raucaoto give accurate information
mjkSure 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)
mjkAlso, the visible IP address might be just your reverse proxy (cloudflare, anyone?)
raucaothat would also be a plus in a lot of cases
TheCoffeMakerhas joined
raucaoi'd rather have someone i trust host the data physically under their control than use a service on some public cloud provider
raucaoeven if it don't trust them
raucaoit's just generally not a useful negative marker imo
Samhas left
raucaolike, would you *want* e.g. riseup to use an american or european cloud provider with full access to their VMs?
adiaholichas left
Samhas joined
raucaomaybe 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
ZashWhat'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
Danielany currated list will be outdated in notime. this one is already outdated at launch. lol
Tobiashas left
HolgerYes. 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
MattJHeh, I was just writing that in another chat...
MattJI agree (and already shared with the project maintainers a while ago) that a manually-maintained list is a terrible idea
lovetoxhas joined
MattJIt has been tried countless times before, and I see nothing particularly different about this new attempt that would make its fate any different
ZashOh hush, let them learn it for themselves
libredevhas left
MattJI can't, it's painful to see it happen *again* :D
ZashThose 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...
MattJI think with some automation, it could become somewhat manageable... and I'm not aware that anyone has really tried that approach as often
MattJI think there have been a couple of automated lists in the past, but they were one-person projects
Tobiashas joined
Link MauveI 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
Zashhttps://xmpp.org/extensions/xep-0309.html
Tobiashas left
Andrzejhas joined
ZashIsn'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
ZashExcept for the part where it's not following the current XSF compliance suite automatically
MattJI was just suggesting in conversations@ as this conversation started, a JSON API that xmpp-providers could pull from
moparisthebestDamnit I was just typing a sarcastic comment that xep-309 didn't have enough json
konstantinoshas left
Tobiashas joined
konstantinoshas joined
adiaholichas joined
MattJMaybe we just need to implement XEP-0309 in Prosody and ejabberd for publishing the information directly, without compliance.conversations.im as the middle-party :)
GuusOn pubsub events, is the message type defined / of interest?
Guusin XEP-0060, I'm finding only a reference that using 'headline' would likely prevent them from being stored in offline storage.
ZashGuus, ^F "pubsub#notification_type"
TheCoffeMakerhas left
HolgerMattJ, +1
lovetoxhas left
ZashMattJ, and then xmpp:providers.xmpp.net to collect them
emusDaniel, it is not outdate if we dont have a reference. We reached out to most providers >several< times
adiaholichas left
GuusZash, thank you.
Holgeremus, I think this is more about keeping it up-to-date in the future anyway.
Danielemus: information on conversations.im seems pretty outdated
Tobiashas left
Tobiashas joined
DanielAnd/or just incomplete. For example the admins / the bus factor has always been displayed on our website
emusWhich 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✎
DanielWhich isn't like a big deal in itself. It just shows that maintaining such a list is hard
emusWhich 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
moparisthebestHow does bus factor relate to reliability? What's the bus factor at atlassian?
BASSGODhas left
emusWell, 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
raucaoif i only have to maintain a single endpoint, that's 10x preferable to notifying whatever lists i don't even know about
emusAnd 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
Danielemus: 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
emusAnd 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
raucaoyou're getting the feedback right now. no need to be defensive about the current state
raucaoeveryone's just trying to help
emusWhich specific ones? I remember looking for such a statement incl. asking them to provide such a statement.
Tobiashas left
Tobiashas joined
emusAnd 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?
emusraucao, 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
wurstsalatemus, having the server announce all the infos instead of the operator notifying lists
Zashserver-DOAP?
emuswuhu, yes more DOAP! 🙂
emusbut 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
wurstsalatwe'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
raucaoit would also make the list opt-in for providers, which is another benefit
wurstsalati.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
emusAnd such an approach now actually offers to improve maintainability through automation incl. update process
restive_monkhas joined
adiaholichas joined
BASSGODhas joined
wurstsalaton 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
emusyes +1
emusI had a quite bad experience because when I started with XMPP I though XMPP = XMPP (never heard of xeps etc)
BASSGODhas left
emusAnd its not that I would not have been capable to understand details to some level (as some non tech-savvy users)
lovetoxhas left
wurstsalatoh, there is a prosody module for '309: https://modules.prosody.im/mod_service_directories.html :)
adiaholichas left
emusand 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?)✎
emusand 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?) ✏
Holgeremus:
> 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
emusIn what regard unrelalistic?
antranigvhas joined
TheCoffeMakerhas joined
MattJThe second link in providers.json is a 404, ironically https://404.city/+/faq.html
emushaha
emusthanks
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.
MattJNice automation ;)
adiaholichas left
konstantinoshas left
stphas joined
melvoOf 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 :)
emusYes!
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
melvoI 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
melvoIn 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)
melvoBy 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
melvoAre 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.?
ZashSounds like a question for DOAP! 🙂
ZashSupported 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
ZashXEP-0157 is* supported in Prosody. Not enabled by default. Majority of servers are expected to be smol private servers where it's less relevant. ✏
ZashI thought the author of XEP-0309 was working on an implementation but I don't see any