Talk:Move Archiveteam to Hackint

From Archiveteam
Jump to navigation Jump to search

Counterpoints to the pro-EFnet arguments

I want to elaborate a bit on why the EFnet arguments don't hold.

  • IRC Services: Inherently leads to a certralisation of permissions vs current system. – This is not inherently true any more than it is on EFnet. Anyone with ops can still grant anyone else ops, and those with channel control permissions can also set it up in the services such that the recipient gets autoopped etc.
  • It has Always Been EFNet, we shouldn't uproot our long-standing relationship and work with that network. – AT has been on EFnet for a decade, yeah, but other than that, what 'relationship'? I'm not aware of there having ever been communication with EFnet staff regarding the countless issues we're having and limits we're hitting, for example.
  • EFNet is the longest-lived Network, showing it's here to stay. – I'd rather say that EFnet has been on a decline the past few years at least. Some servers have been taken down forever by the respective operators. Others aren't properly maintained and don't support current technologies (e.g. modern TLS versions, IPv6). The webchat breaks frequently and sometimes isn't fixed for weeks.
  • We should just engage with EFNet to make them more hospitable for Archive Team needs. – Good luck with that. It appears to be essentially impossible to reach any EFnet staff beyond some of the individual server ops (e.g. to report spammers). The forums are pretty much dead (and actually broken at times). Most of the things that are bothering us would need approval and action from all server ops, which will certainly never happen.
    • Topic length limit: an increase was requested on the forums in 2003[IAWcite.todayMemWeb], and it was already bothering people for years at that point. The limits were actually different per server at the time (haven't checked whether they still are). The answers to that request can be summarised as 'just use one of the servers which has a higher limit' (leading to more centralisation and outages, plus people connecting through other servers would only see a truncated topic), 'nobody needs longer topics except for stupid colours and stuff' (seriously?) and 'but if we increase the limit, people will demand even more!' (ridiculous thing to say at the current limit).
    • Nick length limit, channel join limit, etc.: People have been complaining about this on the forums for a long time (at least since 2007, but probably earlier as well). It's obvious that nothing's going to change about this.
    • NickServ, IRCv3, and other useful features will never arrive on EFnet either. It's stuck in the early 90s experience of IRC.

JustAnotherArchivist (talk) 13:57, 23 August 2020 (UTC)

Out of curiosity, if "it's stuck in the early 90s experience of IRC" is a bullet point, why continue to stick with IRC instead of moving to Discord (people will complain because massive data collection, fingerprinting, nonfree), Matrix (?), Telegram groupchats (people will complain because bullshit homegrown broken crypto and unencrypted supergroups), or run your own Mattermost instance?
Why continue to work around an "ancient" protocol with all sorts of cruft bandaged on top of each other instead of something that supports webhooks, threading, images, etc.
Tl (talk) 06:25, 27 August 2020 (UTC)
At the core, I think the issue not in IRC itself but rather in how EFnet implements/uses it. That's not to say that IRC is perfect. Of course it isn't. The lack of user authentication in particular is an issue – the main issue of the original IRC, I'd argue –, but that's something that was mostly solved less than two years after the creation of IRC (Aug 1988) with the introduction of NickServ (July 1990). So I suppose I should correct my statement and say that EFnet is stuck in the late 1980s experience of IRC. IRCv3 added many other improvements related to authentication (SASL, account-notify, extended-join, etc.), and even those things have existed for about a decade now.
There are a number of other issues and annoyances on IRC, e.g. the hard 512-byte line length limit (solved this year by multiline messages in IRCv3, which also adds support for messages containing line breaks), lack of server-side chat history (in development in IRCv3), threading (reply draft in IRCv3), and the lack of verification that a message was sent successfully (echo-message spec in IRCv3).
So I'd argue that IRC, if IRC network operators don't bury their head in the sand and refuse to even consider protocol development, is suitable and comparable to more recently developed chat systems. Every one of those went through the same process, but they could do so faster due to proprietary clients or not supporting/caring about third-party clients. But just like the late-1980s IRC version deployed at EFnet, nobody will want to use the early versions of those protocols in 30 years (or even now) either.
There are also a couple key advantages of IRC. One is that the protocol is extremely simple. You can implement a basic functional IRC client in 1-2 dozen lines of code in any programming language capable of establishing network connections. This also means that developing bots is quite trivial. I'm not aware of any other chat protocol that is comparable in that regard. Second, as a consequence of that (and the protocol's age), there is a vast choice of clients, many with great customisability if you so desire.
As for your suggested alternatives: I won't waste any time on Discord. Matrix didn't seem very mature last time I tried it. Further, many features were only available in the reference client Riot/Element, partially because they were quite (and according to claims I've seen: overly) complicated to implement; this appears to still be true (e.g. E2E encryption, cross-signing devices). Telegram is yet another centralised, proprietary system. Mattermost has various single points of failure (unless you get the Enterprise version, in which case refer to Telegram but involving money in addition), and the mobile version of the official and only client depends on non-free software (unless patched out on every release, which is not sustainable). Further, adding more things to our already undermaintained infrastructure does not seem like a good idea.
JustAnotherArchivist (talk) 16:03, 27 August 2020 (UTC)