[HN Gopher] Simplicity of IRC
___________________________________________________________________
Simplicity of IRC
Author : susam
Score : 296 points
Date : 2022-01-09 12:06 UTC (10 hours ago)
(HTM) web link (susam.net)
(TXT) w3m dump (susam.net)
| pkulak wrote:
| I've never really played around with IRC, but I've definitely had
| the experience the author talks about with Matrix. The server
| (like mentioned about IRC) is complicated, but interfacing with
| it as a user or a bot is mostly a few REST endpoints. I've
| started using Matrix as my go-to interface for new projects. You
| get IO for free, plus auth, user accounts, and multi-device;
| leaving just the fun stuff.
| bullen wrote:
| If you want an even simpler and more scalable chat you can use my
| multiplayer online system:
|
| http://github.com/tinspin/fuse
|
| The HTTP server is written in Java with a custom JSON database
| and it has clients in C++, C# and HTML5.
| dan-robertson wrote:
| It's a real shame how difficult programming is. I don't mean that
| it is difficult to write difficult things, but that it is
| difficult to write simple things. Once upon a time, one could
| download visual studio, click about to make a new project in
| (e.g.) Visual Basic, draw a gui in the gui editor, and click the
| run button. One could then start adding simple functionality
| (e.g. working through a book). Or even longer ago when a computer
| might dump you practically straight into BASIC when you turned it
| on or you might get access to a mainframe/minicomputer with
| programming tools already set up. Nowadays, an 'easy'
| introduction could involve the horrific process of installing and
| setting up python on windows (where it is hard to do things other
| than input/output text) or editing some html/JavaScript files
| where there are more easily possible interactive things but lots
| of things are difficult like 'just drawing things' or anything
| that requires a server side.
|
| P.S. if you, like me, were wondering what Libera Chat is, it's
| the moral successor of Freenode with Freenode now being a shell
| of its former self.
| 323 wrote:
| Rose tinted glasses?
|
| Visual Basic (classic) that you mentioned, discontinued in
| 2008, was not free, unless you pirated it.
|
| > _'just drawing things'_
|
| For that you have much more amazing things today, like
| Shadertoy, or various artistic programming languages like
| Processing, ...
|
| Programming is easier than ever, computers are extremely cheap,
| software is free, documentation on the internet is free,
| YouTube is full of tutorials, there are literally no obstacles
| if you want to do it.
|
| Back in my day I had to pay for computers, for programming
| software, for books, Internet cost a fortune, ...
| layer8 wrote:
| However, today there is no VB-like experience for modern
| development regardless how much you'd be willing to pay for
| it.
| rahen wrote:
| Have you tried Lazarus?
|
| https://www.lazarus-ide.org
| 323 wrote:
| Delphi still exists:
|
| > _Build Native Apps 5x Faster With One Codebase. For
| Windows, Android, iOS, macOS, and Linux_
|
| https://www.embarcadero.com/products/delphi
|
| And it's free if you don't make a lot of money of what you
| build.
| gavinray wrote:
| And if you don't need/want to compile to x64 bit
|
| Delphi Community Edition only allows x32 compilation
|
| I downloaded it to try. It's not a huge limitation for
| most usecases I would imagine.
| Nextgrid wrote:
| Do they make an exception for Mac, considering recent
| macOS no longer supports 32-bit binaries?
| Mister_Snuggles wrote:
| I remember Delphi being pretty close back in the day, and
| it's still around[0] if you're willing to pay for it.
| Lazarus[1] is another option.
|
| Apart from the underlying language, the experience is
| pretty close.
|
| [0] https://www.embarcadero.com/
|
| [1] https://www.lazarus-ide.org/
| boondaburrah wrote:
| I believe there were some visual basic books you could get
| that would have a CD-ROM with a limited version in the back,
| but I may not be remembering correctly. Of course, you could
| also check those books out of the library and online
| activation wasn't really a thing then, so that's how I
| remember starting.
| denton-scratch wrote:
| > Programming is easier than ever
|
| Really, it's not. This trade has got much, much harder since
| I started. The languages are harder, because the targets are
| both more complicated and more various. Computers were mainly
| used to do sums (I worked on accounting systems written in
| COBOL).
|
| I mean, it's easier if you take into account the complexity
| and richness of the modern computing environment, USB, PCI,
| caches, what have you. You are producing more powerful
| programs. But the onboarding ramp for modern programming is
| steep.
| Iv wrote:
| > on windows
|
| This is the mistake. Linux and, I believe, OSX come with
| several tools pre-installed including python.
| AnIdiotOnTheNet wrote:
| Windows comes with PowerShell, which is a pretty fully
| featured programming language that can interface directly
| with the .NET ecosystem.
| fivea wrote:
| > Windows comes with PowerShell (...)
|
| It might be just me, but PowerShell feels outright
| developer-hostile even when compared to Bash. Perhaps it's
| their approach to rely primarily on .NET stuff which makes
| things so arcane, but when given the option it's far
| simpler and better to go with, say, python than PowerShell.
| AnIdiotOnTheNet wrote:
| I couldn't disagree more, I think bash is a
| _horrifically_ bad programming language. Honestly I 'm
| incredibly surprised anyone could compare PowerShell and
| bash and think that PowerShell is the arcane one.
| williamtwild wrote:
| The problem is that you think bash is a programming
| language.
| majkinetor wrote:
| Its bad even for one liners.
| cxr wrote:
| The person who you're responding to is engaging with the
| person who _they 're_ responding to in the terms chosen
| by the latter. If the original commenter hadn't written,
| "PowerShell feels outright developer-hostile even when
| compared to Bash", then we might have some reason to find
| fault with the person who replied. Considering that's
| what did happen, however, this comment of yours--which is
| both snarky and implicitly demands the wrong person to
| take responsibility for the comparison--just comes across
| as annoying.
| fivea wrote:
| > I couldn't disagree more, I think bash is a
| horrifically bad programming language.
|
| Bash is described as a "command language" and not a
| programming language per se.
|
| Bash is what you use to type in commands, and automate
| said commands if you need to whip out a quick script that
| runs what you would otherwise run manually. Bash,
| scripting-wise, is command line glue.
|
| If all you want to do is run commands with some logic,
| PowerShell is simply dreadful and outright developer-
| hostile. I doubt there is a single person on earth who
| uses PowerShell as a command shell like Bash is used.
| AnIdiotOnTheNet wrote:
| Again, I disagree and regularly use PowerShell as a
| command language --as do many Windows admins-- and _much_
| prefer its object-based pipelining and relatively
| sensible and consistent command and argument naming to
| bash 's error-prone text pipeline and mixture of 2-letter
| abbreviations and complete nonsense names. But whatever,
| to each their own.
|
| This subthread was specifically about programming
| languages being available out of the box in OSs, so when
| you brought up bash my natural assumption was that meant
| as a programming language.
| majkinetor wrote:
| chungy wrote:
| PowerShell is the worst of bash and perl combined. It's
| like Microsoft took a look at each of those, "We can do
| that!" and implemented them.... worse.
| majkinetor wrote:
| Totally. Bash is such nonsense. Its little better then
| batch on Windows.
|
| PowerShell is such joy that it should be there on any
| Linux as default interactive shell.
| enumjorge wrote:
| A tool shouldn't need to come preinstalled with the OS in
| order to be useable. And "switch to a different OS" is not a
| good solution especially for cases where you don't control
| the OS you run.
|
| For a long time MacOS came with only Python 2.x installed. I
| looked up what the latest version of MacOS comes with and
| came across an Apple support forum post with several
| responses posting conflicting answers [0]. One person got an
| Xcode related error. Having to install a heavyweight IDE just
| to get a language to run correctly is the type of needless
| complication the parent comment is talking about.
|
| [0] https://developer.apple.com/forums/thread/691403
| lloeki wrote:
| > Having to install a heavyweight IDE
|
| xcode-select --install pulls in the CLT, which is a fairly
| reasonably sized download given that it includes various
| essential dev tools including python3 but without Xcode.
|
| This is hinted at by attempting to run python3 before any
| install, which calls a stub prompting you to do just that.
|
| py2/ruby/perl/etc... are part of the base OS for backwards
| compatibility/expectations (because they were so before
| Xcode/CLT were even a thing) but have been marked as due
| for removal from base for something like half a decade. My
| bet is that at some point they will move to the CLT (or
| some other optional download) as well.
| young_unixer wrote:
| Which creates more problems than solutions.
|
| If the Python version that comes with your OS is not the one
| you want (e.g. it's outdated), then you'll have to:
|
| 1. Install the version you want anyway, and all the tools
| required (that usually don't come preinstalled in the OS)
|
| 2. Try to not make them collide, which, last time I tried,
| was a PITA, because the OS depends on original version of
| Python being in the the $PATH or something.
|
| Python on Ubuntu is notoriously misleading for newbies,
| because even if you apt install python3 and it tells you that
| it's already installed, it's not fully installed. For
| example, venv is not installed, you have to `sudo apt install
| python3-venv` and do that for every Python module that's not
| installed by default.
|
| It would be easier if Linux didn't come with Python, and then
| people simply installed the actual, full version of Python
| they wanted.
| emeth wrote:
| > Scripting language runtimes such as Python, Ruby, and Perl
| are included in macOS for compatibility with legacy software.
| Future versions of macOS won't include scripting language
| runtimes by default, and might require you to install
| additional packages.
|
| https://apple.stackexchange.com/questions/406244/will-
| macos-...
| pmarreck wrote:
| That's probably for the best, as the ones that ship are
| often old and buggy, and Apple doesn't seem to care for
| maintaining them (even if they pretend to care about
| developers). As long as there's a way for actual developers
| to install these tools themselves (such as Homebrew),
| things will work out fine.
| dan-robertson wrote:
| I wanted to focus on a 'first introduction to programming'
| which on average means windows. Obviously installing and
| running python can be easier on Linux but you still have
| problems with anything not-just-text.
| throwhauser wrote:
| Anytime I do anything with python on Linux or MacOS I
| encounter python, python3, pip, pip3, venv, virtualenv,
| conda, poetry... so much machinery around the code. Throw in
| your platform-specifc package manager of choice as well (apt,
| brew, etc)
|
| EDIT: Oh and pipenv!
| magpi3 wrote:
| > Once upon a time, one could download visual studio, click
| about to make a new project in (e.g.) Visual Basic, draw a gui
| in the gui editor, and click the run button
|
| The world that lived behind that experience - COM & Active X
| Controls - was extremely complex. If you needed to build a new
| active x control for your app, god save you.
|
| It's been said a million times, but in programming there is
| always complexity. Sometimes it is just well hidden.
| qsort wrote:
| I think there's a difference between intrinsic complexity and
| accidental complexity, though.
|
| You're right to observe that programming involves irreducible
| complexity (one of the reasons why so many low code/no code
| tools fail is the refusal to accept this, imo), on the other
| hand modern toolchains are extremely complicated and could be
| a little more streamlined.
|
| It's a meme at this point, but there's no way having six
| different pythons on your machine or whatever the hell modern
| JS toolchains do -- just to pick two examples -- is the
| simplest it can possibly be.
|
| Older machines and toolchains certainly had their problems
| (arguably even worse ones), but I completely understand the
| complaints.
| ok123456 wrote:
| >If you needed to build a new active x control for your app,
| god save you.
|
| regsvr32 coolcontrol.ocx
| erwincoumans wrote:
| Python is just one installer on Windows and there are tons of
| pip installable packages, for 2d or 3d graphics, GUI,
| sound/midi, math/data and whatever you can think of. Tons of
| docs and tutorials or colabs.
|
| How is that not easy?
| gbear605 wrote:
| A friend of mine was recently taking a course on machine
| learning and she had to use Python with some packages for the
| homework assignments. She downloaded VSCode and installed
| Python on her machine and then attempted to get the packages
| installed with pip. They weren't showing up in the VSCode
| terminal though. Somehow she had six different installations
| of Python, one of Python 3 living inside of a VSCode
| namespace, one each of Python 2 and 3 living in a global
| location, and one each of Python 2 and 3 living in a user-
| specific location, and a Python installed by Anaconda.
| Calling python, python3, pip, and pip3 in all went to
| different Python installations. The VSCode installation
| didn't seem to have pip at all, even with python -m pip. I
| managed to eventually sort it all out for her, but it took me
| over two hours to figure it out, and I'm a professional
| programmer who uses Python in my daily job. I admittedly
| don't use Windows everyday, but it was a huge mess and I have
| no idea how it happened.
|
| Computers are complex, and people who don't work closely with
| them daily can easily get very confused.
| erwincoumans wrote:
| In such cases, it maybe better to just use Google Colab.
| einpoklum wrote:
| > ... difficult to write simple things...
|
| and
|
| > Once upon a time, one could download visual studio,
|
| don't seem to agree very well. Visual Studio is a behemoth and
| usually results in stuff that's non-standard, non-portable and
| with lots of dependencies.
| layer8 wrote:
| That certainly wasn't the case with Visual Studio VB6 (or
| earlier) that the GP alluded to.
| dan-robertson wrote:
| Visual studio won at the zero-to-interactive-program metric.
| People who have never programmed are not going to care so
| much about portability as they are about not getting stuck
| trying to figure out how to install/make things work properly
| on their systems. The modern 'getting started' choice is
| often python which doesn't give you such an easy path to
| interactivity and has its own portability problems.
| lambdaba wrote:
| Bash is the Basic of our era, the fact that it's so easy to do
| simple things explains why people are so often ready to use it
| despite its perceived and real shortcomings. Hopefully one of
| the new shells gains enough popularity to "flip" usage and give
| us a renaissance of powerful scripting interfaces.
| cout wrote:
| Why bash over the browser javascript console? It is
| everywhere and allows interactive editing of a "program",
| much like the BASIC interpreters of old.
| lambdaba wrote:
| Yeah but how do I pipe to other programs? How do I schedule
| something and integrate it with my filesystem? Also the
| syntax is complicated (don't underestimate this, for many
| of us trouble parsing syntax is a distant memory). Also
| easy interop between many programming languages.
|
| Maybe when the browser fully swallows the OS but I hope it
| won't be JavaScript or it would have morphed into something
| else.
| ripe wrote:
| Yes! I learned BASIC on the BBC Micro. You turned it on, and
| you got a BASIC interpreter. It was the most painless, most fun
| experience. Graphics, sound,, etc., were all available by
| reading the User Guide.
|
| I couldn't have afforded buying one, but my university had half
| a dozen.
|
| I wish kids today could get that.
| akkartik wrote:
| This was my attempt at providing easy graphics to kids
| inspired by the BBC Micro:
| https://github.com/akkartik/mu/tree/main/shell
|
| Here's a 6-minute demo: https://archive.org/details/akkartik-
| mu-2021-06-09
|
| Requires Qemu, though. And no sound yet, unfortunately. I'd
| love contributions there or elsewhere.
| Sophira wrote:
| The closest I've found to having a modern experience to
| programming in that manner is DragonRuby Game Toolkit [0].
| It's not free (with some exceptions for eligible users and
| indie game developers), but it does offer a standard version
| for a one-off payment, which is the version I have. It's sold
| as a game dev toolkit but it brings back those same memories
| of BASIC for me. I firmly believe that it could be a very
| viable method of introducing programming as well.
|
| If you bought either of the two itch.io bundles "Bundle for
| Racial Justice and Equality" or "Indie bundle for Palestinian
| Aid", then you have the Standard license already included in
| that bundle. It's well worth a look IMO.
|
| (Not affiliated other than a very happy user.)
|
| [0] https://dragonruby.org/toolkit/game
| ryandrake wrote:
| Reminds me of this visualization[1]. The amount of code it
| takes to simply draw a triangle in OpenGL 1.x, OpenGL 3+, and
| Vulcan
|
| The learning curve has been sacrificed. It's now a learning
| cliff for everything. We've used to have computers that make it
| simple to do simple things and hard to do complex things. Now,
| just so it can be slightly less hard to do complex things,
| we've made it hard to learn and do simple things.
|
| 1: https://twitter.com/sol_hsa/status/1174233868536356866
| anthk wrote:
| TBH GLIDE was the Vulkan of its era.
| surajrmal wrote:
| In the case of graphics, the only thing that's changed is the
| abstraction layer which is stable. Most folks won't use
| Vulkan directly, but rather through a layer which they have
| control to optimize or fix bugs in if they need to. Learning
| graphics programming will never start directly with Vulkan
| programming. I suppose there are benefits to make the
| standard, stable API easy to work with as a beginner, but
| there are plenty of great open source projects that fill that
| niche.
| mdoms wrote:
| I have never written for Vulkan and have only done bits and
| pieces of OpenGL but this can't possibly be an honest
| representation can it?
| 323 wrote:
| Even conceptually using Vulkan is much more complicated.
|
| In old GL it's basically glClear, glBegin, glVertex,
| glVertex, glVertex, glEnd and a bit of window setup.
|
| In Vulkan you need to know what these things are: queues,
| command buffers, image/geometry buffers, memory locations
| (constant, uniform, varying), resources, bindings, shader
| programs, fences, swap chains, and how they all coordinate
| together.
|
| And until they are all properly coordinated together,
| you'll just be staring at a black image or just get errors.
| seoaeu wrote:
| No, not entirely. Each version does progressively more
| error checking / debug output. Also the first two output a
| static single color triangle, while the Vulkan sample
| outputs a _rotating_ triangle with different colors for
| each vertex.
| anthk wrote:
| TCL/TK >>>>>> VB. By a huge margin. VB would work great under
| Windows, but TCL/TK kits would work everywhere.
| rahen wrote:
| Indeed, just like VB6, tcl/tk is a great reminder of the late
| 90s.
|
| Tcl was such an expressive yet minimalist language. Probably
| the only fast and easy way back then to create GUI
| applications on *nix systems. I guess Python + QT has killed
| it now, but with a massively larger footprint and resource
| usage obviously.
| denton-scratch wrote:
| I liked VB6 when I first tried it. You drew a UI, then you
| double-clicked the components to get a menu of stub code-
| blocks. It was good for making UIs.
|
| Then suddenly there were masses of weird, undocumented APIs,
| including APIs from any application installed on the machine.
| Unfortunately I was making my living from VB6 at the time, so
| I had to learn it all. (And then MS withdrew support for VB6,
| forcing me to learn a new trade, which is only one driver of
| my animus against MS)
|
| Long ago I owned a Sinclair QL. That toy had a rather nice
| BASIC editor. I think their dialect was called QBasic. You
| selected a function in the left pane, and it appeared for
| editing in the right pane. (I also loved that it used a 68K
| processor; that chip had a sweet instruction set)
| locusofself wrote:
| IRC was fun. I do miss that period of time (and being a teenager
| who could learn things very quickly). I'm not particularly
| nostalgic about the protocol or the user experience though. Maybe
| we will find a good middle ground some day, fast native clients
| with media rich experience and great searchability. I use Teams
| every day and find it to be just fine for most things.
| almogbaku wrote:
| Stampo00 wrote:
| I've been forced to use Slack for the past 5 or 6 years in my
| professional life and I despise it. It gives me absolutely no
| ability to customize or automate my workflow without my employer
| giving me the keys to the kingdom, which they rightly won't do.
| Slack's service is where the value is. The client is only a means
| to an end. And yet they guard it with such zeal, threatening
| those who develop augments or alternatives.
|
| I have the skills. Just let me automate my own machine without
| making me have to fight you tooth and nail!
| mycodepedia wrote:
| andrewmcwatters wrote:
| I never used IRC growing up, to my knowledge, though I'm sure I
| used it by proxy in software that used it under the hood.
|
| Instead, I grew up with AOL Instant Messenger, and then MSN
| Messenger which later became Windows Live Messenger, then Skype,
| Xfire, Pidgin and Trillian as clients, then back to Skype again,
| and now Discord, which is where I still reside most of the time
| today.
|
| When I thought about existing chat protocols I wanted to use in
| game engines and websites that would allow one to connect through
| existing clients without having to join the game or navigate to
| the website in question directly, I thought about IRC.
|
| But it seems like people use Matrix now, and it just hasn't
| caught on to my circle of friends. If I'm not mistaken, it almost
| seems like FOSS Discord.
|
| I was recently introduced to it by a member of a community of
| very friendly Quake Mappers. I wonder if there is primarily first
| a cultural barrier to these technologies and not a technical one.
| As usually I find more technical people on IRC than on Discord.
| mycodepedia wrote:
| yetihehe wrote:
| In the beginning was the command line. Then work of bright people
| of Xerox PARC was used to hide from users the reality that
| underneath their beloved GUI, computers are just passing around
| strings of text. Now we yearn for a time when you were just one
| INT and several MOV away from putting a pixel on a screen,
| instead of downloading multi-GB IDE to fiddle for a weekend
| before you can show a simple window.
| davisr wrote:
| You don't understand what happened at Xerox PARC or what their
| "GUI" was. Smalltalk wasn't a language, it wasn't a GUI, it was
| an _environment_, and its whole point was that it didn't hide
| anything! It was a completely different paradigm to how
| computers and their programs are architected today. A Smalltalk
| system was always meant to be so simple that one could
| understand, and change, everything about it.
| yetihehe wrote:
| That's why I've said that their work was used, not that they
| did it.
| userbinator wrote:
| Everyone should write an IRC client as an exercise in network
| programming due to its simplicity. The other IM protocol for
| which I've written a client is early MSNP, which is also text-
| based and not immensely more complicated than IRC. IMHO all the
| newer web-based stuff is a horrible mess of abstraction bloat.
| TCP, and TLS if you want encryption, should be a sufficient base
| to build upon.
| pmarreck wrote:
| Somehow I never heard of Matrix until now. I'm now running
| Element with a bridge to the Libera IRC network. Thanks!
| Ntrails wrote:
| Could someone with more insight summarise how this compares to
| xmpp as an open chat protocol?
| h2odragon wrote:
| Prior to IRC becoming an accepted protocol, the "talker BBS
| systems" tried to avoid the need for a user to have a "client
| application." I'd say it was AOL that put an interface on chat
| and sold (a) the idea of a chat client and (b) the idea of
| _online chat_ to less technical users.
| open-source-ux wrote:
| IRC might be designed around a simple protocol, but it is not
| simple in operation. The plethora of command line options
| explains why IRC is only loved by (some) developers and nobody
| else.
|
| I suspect some IRC users like the high barrier to entry (but
| would never admit to it): it keeps out all those clueless 'non-
| technical' users.
| janc_ wrote:
| There are GUI clients for IRC that don't need any "command line
| options" (some don't even support them).
|
| And there are (and certainly were) plenty of people on IRC who
| aren't very technical. Seriously, around 20 years ago it was
| often used as a "dating app" by regular users, or for radio
| listeners & DJs to chat, etc.
| c0l0 wrote:
| A number of moons ago, I switched from a company that used IRC
| for its internal, real-time, ephemeral communication needs to an
| enterprise shop that used Microsoft Teams to do that (and of
| course other communication stuff, as the boundaries for what was
| better kept in Sharepoint, Confluence, Email/Exchange, the legacy
| Wiki, and/or Teams were never quite clear :)) there.
|
| In the old shop, we eventually had all kinds of important
| subsystems hooked up to our internal IRC server: Monitoring and
| alerting. Source control and Wiki activity. The deployment
| pipeline. Ticket activity reports. All these services were pretty
| much effortlessly set up to provide useful, real-time status
| information broadcast to topic-specific channels users could idle
| in. Everyone could stay informed on topics of their interest, in
| real time, with no barrier to entry. It was really good, and the
| implementation completed in a few hours total, for all use-cases,
| due to irc's incredible simplicity.
|
| Due to the benefits I had reaped from that setup before, I tried
| to implement parts of it on/for the MS Teams platform at the
| then-new job. Getting the Teams Python SDK to implement a bot-
| like entity running alone proved to be a days-long ordeal, and
| whatever followed wasn't much more pleasant.
|
| In the end, we let someone set up two email-to-teams-channel-
| forwards which kinda worked, but suffered from obnoxious, multi-
| minute relay delays.
|
| As a consequence of the tedious bringup and the latency
| shortcoming, the "effortless notification" initiative never
| really got traction.
|
| Not only because of this particular experience I am a firm
| believer that software/system simplicity is a virtue that can
| neither be overstated in importance, nor substituted by anything
| else.
| badrabbit wrote:
| Modern apps have modern requirements like better security.
| Better UX, quality and security beats dev convenience every
| time.
| Nemi wrote:
| I tend to agree. I have the same reservations with HTTP2 to a
| lesser degree. I won't deny that the complexity added by HTTP2
| will greatly improve speeds in certain cases, and this may very
| well be needed to keep the greater interwebs working at
| comfortable speeds moving forward, but a part of me is greatly
| saddened by losing the sheer simplicity that is HTTP1.1.
| littlecranky67 wrote:
| the problem is that HTTP2 mostly does _not_ bring the
| expected advantages that connection multiplexing promised, as
| HTTP /1.1 connection multiplexing over multiple tcp sockets
| are in many cases better performance wise. Only HTTP/3 with
| QUIC addresses this, so I have mixed feelings about HTTP/2.
| tomsmeding wrote:
| Are we going to _lose_ the simplicity of HTTP /1.1? I think
| that would only happen when we get servers that support
| _only_ HTTP /2, and I hope those will be limited to hobbyist
| use for a while yet.
| spenczar5 wrote:
| gRPC servers, which are increasingly common and certainly
| not a hobbyist thing, are http/2 only.
| littlecranky67 wrote:
| I think it is unfair / nonsensical to compare Teams (or Slack
| or Discord) to IRC. IRC is an open protocol for creating chat
| networks, not a desktop client. The user expierence from IRC
| could differ vastly depending on which client you use (mIRC,
| xchat, irssi...). But it shows how in todays world we create
| this silos/islands of proprietary solutions that are not inter-
| operable.
| harikb wrote:
| GP is comparing the integration experience and API layer.
| erikbye wrote:
| I find Matrix a fine substitute for IRC. Very simple to write
| clients and bots for. And you get modern features IRC either
| lack or does not do well.
| tarkin2 wrote:
| With your IRC system, how did you deal with channel history,
| i.e. seeing messages that were delivered to the channel while
| the user wasn't there, something that slack and teams does
| well?
| Fuzzwah wrote:
| I'm not the OP, but the usual method is that everyone runs an
| irc client in a screen on a server that they SSH into from
| their workstation.
| pmarreck wrote:
| I did this years ago and this was indeed one way to do it
| (apparently still is)
| c0l0 wrote:
| We had an internal instance of ZNC for human users to connect
| their clients to (at their option - but that was the
| documented and preferred way of getting onto the IRC
| network). Creating ZNC user profiles was part of the semi-
| automated onboarding/setup procedure, whilst ZNC
| authentication was done against the dovecot IMAP/SASL server
| we had for email. More casual IRC users in the company
| (marketing etc.) usually preferred to use an intranet-hosted
| web application (The Lounge) to access it from their browser,
| while most IT people had native clients of their choice set
| up (hexchat, irssi, etc.). Worked well.
| tarkin2 wrote:
| Thanks, I was inspired by your post and looked at irc
| servers. The main problem, vis-a-vis slack, was the channel
| history. There are modules but they have timestamp and
| limit problems. And irssi in gnu screen would only work
| while screen is running and would only work for those happy
| with the setup. ZNC, although sadly adding more complexity,
| seems to be the way to go.
| progval wrote:
| > There are modules but they have timestamp
|
| You need a client and bouncer (or server, if you connect
| directly) that supports this extension:
| https://ircv3.net/specs/extensions/server-time
|
| > and limit problems.
|
| ditto, but https://ircv3.net/specs/extensions/chathistory
| if I understand you correctly.
| zacmps wrote:
| ZNC has its own issues. We had a repeatable crash that
| happened every time a particular user connected (it took us
| a while to figure that out).
| c0l0 wrote:
| Sure, most software projects and products have their
| share of flaws and bugs :)
|
| I do not claim ZNC or our whole IRC setup was perfect,
| but for me and many others, it did a very decent job of
| providing effective, no-frills, getting-things-done means
| of communicating, all while consuming little resources on
| both server and clients, and being simple,
| underestandable, and easy to hook other software into.
|
| I really miss it, and personally dislike (especially the
| client UX of) most trendy/recent alternatives.
| jethro_tell wrote:
| We had a similar thing going, people could set up a packages
| znc bouncer but the general rule was to assume everything was
| pretty much ephemeral to anyone not there. the best part to
| me about irc rooms is that they are allowed to be considered
| ephemeral, just like hallway talk and coffee breaks.
|
| If something comes of the discussion. Update docs, post the
| chat log in the wiki, send an email with cliff notes and ask
| if others care to discuss, halt and get the right people in
| the room.
|
| When you decide, 'hey, we have an idea, or a change in
| direction' you'd then document or make the case in a way that
| is more clear and user friendly than a mile of ephemeral
| chat. This is the same reason people send out meeting
| summaries instead of transcripts.
|
| We've moved to this point where nothing is ephemeral. But a
| random chat isn't a good way to understand why things are
| being done. It's just too much to parse. And at some point
| new people are looking for a needle in a haystack and they
| just kinda checkout.
|
| I thing documentation should be intentional, the why should
| be clear in a doc that doesn't waste time and is formated in
| a way that we have come to understand as the best practices
| of technical documentation. You'd start with a quick overview
| of both the problem and proposed or adopted solution and the
| reader can decide if they need more info.
|
| Especially with remote work, I think it's important to have
| ephemeral areas for discussion without expectations that
| everyone keeps up on the whole chat. Thinking every team
| member needs to know every word of discussion is ludicrous.
| lambdaba wrote:
| 100%, the fact that you can literally pipe some data in a
| command-line IRC client is 1000x more conducive to such
| tweaking than using custom APIs/SDKs
|
| long live the Unix model!
| michaelt wrote:
| Doesn't that mean you get a channel join/leave for almost
| every message?
| lifthrasiir wrote:
| It is possible to post a message without joining if the
| channel has -n set (not the default for the obvious
| reason).
| crest wrote:
| So clients can read lines from a pipe as stdin.
| ferdowsi wrote:
| I don't see why you couldn't do the same in a Slack command-
| line program as well? Not hard to find simple examples of
| that.
|
| https://github.com/csabapalfi/slackcat
| littlecranky67 wrote:
| I think the op meant on the protocol level, not client. You
| can literally do `cat mycommands.txt > /dev/tcp/...`. IRC
| is pretty simple, I remember using telnet just for fun to
| connect (also the PING message replies are annoying to type
| yourself) and at one time, (ab)used an FXPable FTP server
| data port trickery in ASCII mode to send a message to a
| channel.
|
| Due to its simplicity I could see its application as a
| falback for global communication downtime/outages (as we
| had with FB/Insta recently).
| userbinator wrote:
| _Due to its simplicity I could see its application as a
| falback for global communication downtime /outages_
|
| I remember when the solution to this, when everyone was
| still working in an office, was "pair of netcats".
| codys wrote:
| Slack has made using their API much trickier over time:
| getting a token to post these days (officially) is under
| the control of the server admin (as one needs to add a
| "slack app" to get one). One can extract a token and some
| cookies from a web browser slack session still, but it's
| not as clean as it used to be (where one could just
| generate account associated tokens that didn't randomly
| expire).
|
| In other words:
|
| - to use the slack APIs, you probably need company level
| buy in _before_ any code is written against the API from IT
| folks
|
| - in contrast, with IRC one could just try something out
| and at some point in the future _maybe_ create a seperate
| IRC account for it, if your IRC server even has logins
| enabled. If it doesn't, which when I worked for IBM was the
| case, one can just pick a new username for the IRC bot.
| jacobolus wrote:
| Beyond that, (a) implementing enough of the IRC protocol to
| support simple bots isn't that hard, and (b) there are
| already IRC protocol implementations everywhere.
| alufers wrote:
| I once needed to create a bot that sent notification and I just
| used the webhook feature in a Team channel. Not defending Teams
| though, it is a horrendous piece of software.
| c0l0 wrote:
| Maybe that wasn't possible/enabled for our particular
| deployment (that was in the IT dept. of a big European bank),
| as we had what I've been told was a strange bastardization of
| O365 and other MSFT services - a mix of on-prem and cloud
| services unlikely to be found elsewhere.
|
| At any rate, for the IRC server at the shop I was at
| previously, I had "webhook" support/a http(s)->irc gateway
| implemented on my own in much less than an hour via CGI ;)
| arbaal wrote:
| Isn't your comment then very specifiy for that installation
| of yours? When you use MS Teams in a "normal" O365
| environment, then every feature you described for IRC is
| possible with weebhooks and the cards API. Simple CURL
| based integration.
| 41b696ef1113 wrote:
| I will second with another anecdote at mega corporation -
| Teams is entirely locked down and any of the useful
| integration points are disabled.
| flatiron wrote:
| Same with slack webhooks. I make custom software and everyone
| wants slack webhooks and they are pretty easy to implement
| and people love them.
| mcfedr wrote:
| I've not used teams, but both slack and Google chat make it
| very easy to post messages, a simple curl call has often been
| more than enough in lots of scripts
| lloeki wrote:
| That is, unless the enterprise has policies to abide by
| disallowing API calls, in which case you're stuck with the
| official client and vetted integrations.
|
| Same for mobile, the advantage vanishes once enterprise
| requires your (usually personal) phone to be surrendered to
| corp IT via MDM (which I sure as hell won't do).
|
| The whole value proposition of Slack and Teams for their
| customers is control.
| deberon wrote:
| Would IRC even work in that nameless enterprise?
| singron wrote:
| IRC might be run by engineering there for themselves. 3rd
| party chat would got through procurement and be provided
| by IT for the whole company, and after the last SOC2
| audit, they had to lock it down.
| lloeki wrote:
| Technically, yes. In real life, no.
|
| I don't even blame such enterprises because most of the
| time it comes from regulations or outside policies that
| customers mandate, something like all enterprise data
| (and thus communication) has to be firmly under control
| of the enterprise with hard guarantees, otherwise you
| just don't get to work with those customers. So you get a
| locked down Slack/Teams, and the email+calendar system
| disallows any native app unless the device is MDM'd, and
| even that is only with first party clients such as the
| Gmail app or Outlook.
|
| TBH I think most companies are trying to do their best
| there, but they're stuck with some kafkaesque liability
| system.
| franga2000 wrote:
| What's more "under control of the enterprise" than a
| self-hosted IRC server?
| u801e wrote:
| It doesn't prevent clients from logging communications in
| that server. I know the same is possible in slack or
| teams, but they don't consider that from a legal
| perspective.
| lloeki wrote:
| Also legal: doing it in house it's on you vs being a
| Slack feature means it's on them. CYA by outsourcing.
|
| And consider this also: "hey we're quite sure pur
| homegrown system is as leak proof as it can be, trust us
| or fire up an audit team for 5 sprints to asses
| compliance" vs "Slack has the box checked already"
|
| The fact that folks can e.g technically fire up a
| headless browser and programmatically interact with the
| app via capybara or whatever to rebuild a makeshift API,
| or just take pictures with their phones because the
| compliant system is inconveniencing them daily is
| immaterial.
| deknos wrote:
| that's really funny. because i did this for CYA reasons..
| with different methods, but mostly with screenshotting or
| autohotkey stuff.
| franga2000 wrote:
| From a legal, practical and technical perspective, any
| window displayed on any screen is equally succeptible to
| logging. I can't imagine the fact that the company
| disabled ctrl+c in the policy settings making any
| difference in a liability case.
| jethro_tell wrote:
| *print screen and phone cameras.
| oarsinsync wrote:
| > I can't imagine the fact that the company disabled
| ctrl+c in the policy settings making any difference in a
| liability case.
|
| Taking reasonable measures absolutely does absolve the
| company. At that point, it becomes a rogue employee who's
| deliberately circumvented policies and technical
| enforcements, who is now potentially personally liable.
|
| It's garbage, but hey ho.
| efdee wrote:
| > That is, unless the enterprise has policies to abide by
| disallowing API calls
|
| ...What?
| tl wrote:
| Welcome to enterprise, where breaking things is a feature
| so commonly used Microsoft has documentation for it [1]
| and things are often deployed by people whose sole
| concern is "minimize attack surfaces". Our Teams
| installation not only disables API calls (official Teams
| client only), chat sessions are deleted if no one posts
| to them meaning most chat history is lost every weekend.
|
| [1] https://docs.microsoft.com/en-
| us/office365/troubleshoot/acce...
|
| Microsoft uses these anti-features as a selling point,
| and in a large enough organization, it's not immediately
| clear who turned them on or who can turn them off.
| tomrod wrote:
| What a perfect way to describe the situation.
|
| Imagine an enterprise disallowing all VCS service
| providers -- whether hosted on-prem or cloud -- because
| they use SSH instead of HTTP.
| lloeki wrote:
| You think you're joking but I've lived through exactly
| that. Reason: SSH cannot be examined by a HTTP proxy. The
| moment we raised that HTTP CONNECT is a TCP passthrough
| thus equivalent we got to install a bespoke root
| certificate on our machines for the proxy to MITM every
| single connection.
| tomrod wrote:
| Yep. Sounds like a common-enough pattern then. (I wasn't
| joking in my post).
| userbinator wrote:
| If the official client can still post and receive
| messages, what's preventing anyone else from doing it in
| the exact same way...?
|
| Or is this something stupid like a user-agent check?
| tptacek wrote:
| It's self-evidently false that the whole value proposition
| of Slack is control. The value proposition is, obviously,
| "IRC but more stuff, with searchable, durable messages".
| Which is why all sorts of groups that don't care about
| control at all still use Slack, rather than IRC, to
| coordinate.
| miked85 wrote:
| In my experience, Teams has been a terrible alternative to most
| every option out there, including IRC. The entire UI/UX seems
| like an afterthought at best.
| folkhack wrote:
| Agree - it's just Microsoft buy-in at this point. Every
| product from Office 365 to Teams to just Windows itself is
| suffering.
|
| To think people build their businesses on this is mind
| boggling.
| trixie_ wrote:
| The integrations are a neat trick, but often end up spamming a
| channel where people are trying to communicate.
|
| Teams seamlessly works across platforms, and mobile with video
| chat, files, outlook integration, and screen sharing. Maybe IRC
| could of been that, but it never happened.
| laumars wrote:
| Teams is by far and away the worst UI of any chat system I've
| used.
|
| I get why it's designed the way it is, it's trying to be
| Sharepoint, Slack, Zoom and Outlook. And as a result it does
| every single one of them worse.
|
| Sometimes integration is better left as event handlers rather
| than trying to make IRC behave like a Wiki.
| trixie_ wrote:
| Yea, but it works cross platform and on mobile. With the
| ability to carry voice connections from one to the other.
| Or even switch from wifi to mobile data without dropping.
| Even view people sharing their screen from mobile. For
| large teams and businesses I haven't used anything better
| yet and we've gone through a lot over the years. Also Teams
| has met some strict Infosec reqs we need for mobile.
| laumars wrote:
| I cannot comment on the switching between WiFi and data
| aspect because I've not tried that myself (though it
| didn't work on my MBP switching between Ethernet and
| WiFi) but everything else you've described is pretty
| standard features for video conferencing solutions these
| days.
|
| I'd like Teams more if it just focused on the video
| conferencing side of things. It's chat and Sharepoint
| integration just adds more frustration than anything.
| trixie_ wrote:
| Seamlessly going from a chat about a problem, to a video
| meeting, to screen sharing, to sharing files, and then
| continuing the conversation on mobile, to scheduling a
| teams meeting later in the week to follow up and fully
| integrated into outlook is what I'm talking about.
| laumars wrote:
| Which is fine if your chat UI doesn't totally suck for
| 99.9% of the other use cases. I'd readily take the
| additional pain of switching applications if it means I
| don't have to deal with Teams for chat.
|
| Also all video conferencing and chat applications support
| sharing files. This isn't some unheard of feature that
| Microsoft have pioneered. It's been possible since the
| BBS days. It's possible in XMPP and IRC. It's possible in
| every other commercial service I've used. And I happen to
| think Teams does it the worst out of everyone of them
| because of the weird UI decisions and Sharepoint
| integration. Compare Slack to Teams and you see what I
| mean. Files are in lined in Slack and it's easy to
| preview and work with them. It's a pain in the arse in
| Teams. Slack also has all the other features of Teams
| that you're boasting about. And Slack isn't even perfect
| itself yet it still runs circulars around Teams in terms
| of usability.
|
| Literally the only thing Teams gets right is the way of
| marking the confidentiality of shared content. But that
| doesn't justify the mess Microsoft have made of Teams UI.
|
| I'm not one of these FOSS evangelists who throws their
| toys out of the pram if we don't use IRC. But Teams UI is
| really just a clusterfuck of bad design decisions. It's
| easily the worst designed solution out there. Except
| maybe WebEx - which is a pretty fucking low bar, scraping
| the barrel really.
|
| Microsoft know they automatically win the enterprise
| because of AD and Office integration. So they don't need
| to compete on quality. They just need to be present.
| lambdaba wrote:
| There are nice IRC clients out there. I don't use them and I
| haven't used them in a group, because even in programming
| language communities many have moved to Discord/Slack, but I
| would prefer working with multiple simple tools than a
| monolith, different tools for different uses, and glue them
| together when needed (it doesn't need to be complicated, and
| if it is, than some additional effort is justified)
| hiptobecubic wrote:
| If you look at these communities, there is basically only
| one feature of Discord/Slack that they use that IRC does
| not easily provide and that's ephemeral/mobile. If I go
| offline for an hour in IRC, I lose a bunch of messages
| unless I've done some backflips to set up some kind of
| archiving/replay in a separate failure domain (e.g. znc
| running on gcp). With chat services, the service is
| essentially znc for free.
|
| The rest of the shift is explained by discord being popular
| for other use cases (e.g. as a twitch companion),
| overwhelmingly dominated by younger users. IRC isn't
| getting _new_ users and over time, this means the community
| will migrate due to turnover. Thank god we at least have
| things like matrix bridges, but discord is a lost cause.
| lambdaba wrote:
| I think the latter argument is 90% of the reason. Too bad
| this new generation doesn't have an opensource base of
| software to work with, or rather somehow didn't get
| acculturated to the existing one. Actually, that's
| probably because there were those few "killer features"
| such as offline messages that the existing systems didn't
| have.
| LinuxBender wrote:
| There are web front-ends to IRC that can mitigate message
| loss without having to run bouncers. Convos [1] and
| TheLounge [2] come to mind but there are others [3]
|
| [1] - https://convos.chat/
|
| [2] - https://thelounge.chat/
|
| [3] - https://www.ilmarilauhakangas.fi/irc_technology_new
| s_from_th...
| hiptobecubic wrote:
| It did happen, though. Just not in the same way. When it gets
| to the point where notifications are too spammy, it's very
| _very_ easy to direct things to use a different channel and
| it works at huge scale. Anyone who uses IRC more than
| casually via some web portal is capable of being in more than
| one channel at a time. Google SRE still uses IRC internally
| specifically because it always just works and does what
| people need it to do.
|
| One of the downfalls of IRC is the notion that everything
| should happen _in_ the chat. There 's no reason you can't
| have a pastebin and a file server and screenshot sharing
| service, most of which don't matter anymore after 5 minutes
| anyway. It works really well and in fact, we _kept_ using
| them after switching to fat chat because it was a better
| experience. There are reasons to want a fat chat client
| (primarily mobile, imo), but having used both for many years,
| the featureful chat client ends up being worse than just
| sharing links most of the time.
| igetspam wrote:
| I find that the "fat" clients encourage bad behavior that
| IRC used to allow people to handle independently. Examples:
|
| * bot spam that I can't /ignore
|
| * "inviting" people to channels tht you can't opt out of
| (invite is slack terms is yank. there is not option to say
| no)
|
| * inline sharing of screenshots of article snippets that
| support an argument but not sharing links to the source
| material
|
| * so... many... channels...
| giantrobot wrote:
| > so... many... channels...
|
| To compound the problem of many channels the UI uses an
| insipid three column layout. I like to arrange chat
| windows, tail -f terminal windows, and other monitoring
| things in a "dashboard" layout in a workspace. That way
| it can update in the background and if I am curious about
| the state of something I can decide to context switch and
| bring up that workspace to get an update. I can then deal
| with an issue or go back to the task at hand.
|
| Slack and HipChat and all the other Electron-based
| attention siphons do not let me arrange their UI in a way
| that works for me. I _hate_ notifications with the heat
| of a thousand suns and turn just about all of them off on
| all my devices. Slack et all hide the state of all but
| one channel by default and want to use notifications or
| stupid icons to show there 's unread activity. It's the
| worst UI on the dumbest system but animated emojis!
| evilhackerdude wrote:
| Are netsplits still a thing in modern IRC network deployments?
| TekMol wrote:
| IRC is great!
|
| I like the interface way more than Discord.
|
| And it seems to attract more knowledgeable people.
|
| If you are into startups, check out #startups on Libera!
| jokoon wrote:
| I love IRC, unfortunately it doesn't work properly with
| smartphones because they have a "loose" connectivity (4G towers
| data etc). I'm not sure IRC apps can deal with this already. It
| would be nice to have some update to the IRC RFC.
|
| If it was well supported for smartphones, I'm still wondering if
| it would cause some bandwidth costs to servers.
|
| EDIT: I know about bouncers, but I would prefer to do without.
| raydev wrote:
| I just pay $5/month for IRCCloud. The iOS app could be a lot
| better, but not only does it make IRC work like any standard
| chat app that allows messages while you're away, it also offers
| some modern bare minimum UX like inline images and link cards.
| progval wrote:
| > I'm not sure IRC apps can deal with this already. It would be
| nice to have some update to the IRC RFC.
|
| They can do it with some help from the IRC server:
| https://ircv3.net/specs/extensions/chathistory +
| https://github.com/ergochat/ergo/blob/master/docs/USERGUIDE....
|
| If the server itself doesn't support it, you'll need to add a
| bouncer inbetween, which is still very common, unfortunately.
| superkuh wrote:
| It'd be nice if as a society we stopped making all software
| worse in order to make up for smartphone's many limitations.
| Ekaros wrote:
| IRC clearly had same problems already back in the day when
| many users were still on dial-up connections...
| YetAnotherNick wrote:
| You can use IRC bouncer for that. e.g. https://wiki.znc.in/ZNC
| jokoon wrote:
| It's not free, and it add hardware and software and
| bandwidth.
| petschge wrote:
| It works well for me by using screen and irssi on a server and
| then using mosh on the smartphone to connect there, as well as
| irssi-notifier for notifications. Has worked well around the
| work, including traveling in africa, from high speed trains in
| Europa and airplanes above the Atlantic. And before you say
| "but that needs a server". Yes it does. A little VM as a shell
| host that is cheaper be month than the cheapest nitro package
| on Discord. Not even one coffee per month. If you don't think
| it's worth to have control over your communication for that
| price, I can't help you.
| tenebrisalietum wrote:
| If you are into self-hosting, thelounge is a great web-based
| IRC client that works well on my iPhone. It does its magic by
| staying connected to servers on the backend, similar to a
| bouncer.
| DogLover_ wrote:
| I used IRC for gaming around 2004 - fond memories!
|
| I recently tried Discord to find programming communities but I
| just don't get it. When you join a server you are automatically
| subscribed to all the channels. And apparently you can't leave
| them, you can only 'silence' them by manually doing that for each
| channel. After a few days I just gave up as I could not keep up
| with all the notifications.
| grishka wrote:
| Discord is horrible and I don't understand why so many people
| like it so much.
|
| First thing I do when joining a new "server" is to mute all and
| any broadcast (@everyone/@here/roles) mentions. Broadcast
| mentions should have never been invented.
| EamonnMR wrote:
| People like it because people enjoy ownership and power. That
| and it's way more user friendly for newcomers. Also before
| Zoom got popular, it was the best voice chat for a while.
| cout wrote:
| An IRC network can have thousands of channels; a discord server
| typically has dozens.
|
| Think of a discord channel as a permanent thread or a topic and
| a discord server like an irc channel. I find discord's model
| more manageable than irc for a large number of users; irc
| channels become a mess around 50-100 active users. Dividing the
| conversations into topics helps a lot.
|
| (I have been using irc since around 1994 and am still somewhat
| active.)
| LinuxBender wrote:
| I would imagine one could tweak the web frontends like Convos
| or TheLounge to make IRC look and behave like Discord at
| least in terms of text chat and channel/user visibility. I
| theorize that's what they are doing behind the scenes.
| akpa1 wrote:
| Discord does allow you to set notifications across an entire
| community to "all messages" (which is the default), "only
| mentions" or "nothing" if you right-click on the community
| icon.
| DogLover_ wrote:
| I was not precise when I said notifications. I already set it
| to "only mentions". My problem was that each channel will
| "light-up" when anyone is commenting in them. I have to mute
| each channel or mark all as read for the whole server to
| avoid this. On IRC you opt in to channels.
| Minor49er wrote:
| If you think about it like this, it makes more sense:
|
| A server is to IRC what Discord is in its entirety
|
| A channel is to IRC what a server is to Discord
|
| If IRC let you subsection a channel, those would be channels to
| Discord
|
| And instead of obnoxious netsplits, you get annoyed with popups
| to buy Nitro or whatever other crap whenever you log in
| tiffanyh wrote:
| Speaking of 'simplicity', this blog has a fantastic design. The
| CSS is only ~30 lines and is largely just applying
| spacing/padding.
|
| No JS, no custom font, etc.
|
| https://susam.net/css/main.css
| lambdaba wrote:
| It's pretty nice indeed. I like the use of keywords for sizes
| "thin", "large", and the shorthand hex for colors, and the fact
| that there's zero boilerplate and only styling what's actually
| used.
| hiptobecubic wrote:
| Agreed, but I _hate_ this:
|
| a:link, a:visited { color: #00e; }
|
| Why do this?
| lambdaba wrote:
| Oh, yeah, that should be illegal.
| Mezzie wrote:
| Right to jail.
|
| Also to a mandatory review of WCAG standards.
| janc_ wrote:
| Fortunately that's easy to override with some custom CSS,
| but I also don't understand the reasoning behind that...
| susam wrote:
| Thank you for pointing this out. I have fixed it now. You
| should no longer see this issue after a hard refresh.
| nine_k wrote:
| I'd say it's in the same general box as the simplicity of 8-bit
| computers booting into Basic interpreter, and the simplicity of
| Legos.
|
| It's wonderful when you can have your toys in a sandbox where you
| use and develop them mostly for fun, and for scratching your own
| itch, away from well-moneyed interests. No need to carefully
| identify participants. No need to encrypt, or otherwise
| complicate the implementation. No need to efficiently serve
| millions of users. No need to add bling to attract more of those
| who barely cares. (The latter is not the case with Legos lately,
| though.)
|
| This is why I think that a lot of innovation starts in the
| fringe, and looks like mostly useless toys, until one of these
| toys proves very useful for "real world" needs.
| hammyhavoc wrote:
| I use Matrix and bridge in IRC, and third-party platforms
| whenever necessary. So much less cognitive load having it all in
| one place.
| bitwize wrote:
| Have we learned nothing from the iPod and Dropbox? Simplicity
| doesn't matter. What matters are:
|
| 1) How easy is it to use?
|
| 2) What features does it offer me?
|
| 3) How well does it integrate into my lifestyle?
|
| 4) Do my family and friends use it? Can I get them to?
|
| Slack and Discord win on ALL FOUR of the above points vs. IRC.
| IRC is a dead horse... stop beating it, please.
|
| "The only thing that matters in software is the experience of the
| user." --Ryan Dahl
| agumonkey wrote:
| I still have discord somewhere.. but I don't use it. I think the
| technical simplicity of IRC also leads to chiller chans (and I
| know there are toxic people on IRC but it feels like an open
| garden unlike tiny realms with a lot of efforts put in setting up
| servers and rules by the original team)
| remram wrote:
| I don't know if a snippet of IRC shows it being simple. The
| colons are quite mysterious, especially to anyone who's seen
| HTTP/POP/SMTP. They look out of place with whitespace _before_
| rather than _after_ , and are used for two separate things...
| lambdaba wrote:
| Write programs that do one thing and do it well.
|
| Write programs to work together.
|
| Write programs to handle text streams, because that is a
| universal interface.
|
| ; basically.
|
| (https://en.wikipedia.org/wiki/Unix_philosophy)
| alkonaut wrote:
| While some of those guidelines offer some value still, end-user
| programs dealing with text just aren't ever going to be a
| thing.
|
| People expect to be able to paste a photo or screenshot just as
| easily as they post a sentence. Requiring a second app to do it
| (posting a link) isn't nearly as good a UX as simply pasting in
| pictures.
| lambdaba wrote:
| Well, in practice you can have binary input, as many programs
| do, but human-readable free-form text is the simplest
| interface there is.
|
| We just need more modern terminals that can handle that.
| alkonaut wrote:
| > We just need more modern terminals
|
| Yeah like smartphone apps , webapps, and desktop guis...
| lambdaba wrote:
| Those are apps, I mean a glue / universal interface layer
| that's 100% owned by the user
| yjftsjthsd-h wrote:
| Then have the chat client automatically upload to a service
| and generate a link behind the scenes.
| alkonaut wrote:
| That's what any client does of course. But the default
| should be to also display the images (or clickable
| miniatures). Nothing that can't be solved in any protocol -
| but you are both having to duct tape several services (a
| poor UX for the maintainer of the service) and what you are
| creating is basically converging on any of the modern
| alternatives.
| u801e wrote:
| > Requiring a second app to do it (posting a link) isn't
| nearly as good a UX as simply pasting in pictures.
|
| But what about the UX of other people in the channel? Someone
| posts an image and the previous text is moved off screen. Now
| they have to scroll up to read what they were just reading.
| What about the case where someone posts an animated gif which
| becomes a distraction that requires you to stop the animation
| or hide it? What about the case where multiple animated
| images are posted which forces your client to use a lot of
| CPU resources to render them[1]?
|
| [1]
| https://mobile.twitter.com/slackhq/status/879755518843252736
| alkonaut wrote:
| Auto playing animation can be a client setting. As can
| rendering pictures at all.
|
| Regardless, the UX of slack, discord, teams etc. is
| different from IRC because it's what people expect from an
| IM client
| u801e wrote:
| That may be true for personal use, but not necessarily
| true for business related use. That's because the former
| case is limited to users who want to use the product
| precisely because of its features. In the latter case,
| users are required to use the product as part of their
| job. Given that, the ideal case would be to not introduce
| features that lead to a negative user experience.
| Blikkentrekker wrote:
| The simplicity also comes with problems, such as nickname
| registration in practice being implemented with bots that have
| administrative rights, which can lead to social engineering
| exploits and poor standardization of their interfaces, or the
| fact that the protocol does not seem to support sending an
| encoding so it relies on the gentleman's agreement that everyone
| use UTF-8, which works until that one user using latin-1 enters
| and starts sending characters that appear strange to everyone
| else.
|
| It could be a little bit more complex in my opinion. Perhaps it
| is time for servers to start supporting an i.r.c. 2.0 protocol
| but otherwise allow 1.0 and 2.0 users to still communicate with
| each other to facilitate the migration.
| janc_ wrote:
| You mean IRCv3? It's not all ready/implemented yet, but some of
| it is already in daily use.
|
| https://ircv3.net/
|
| For example a server can tell the client that it only accepts
| UTF-8: https://ircv3.net/specs/extensions/utf8-only
| Blikkentrekker wrote:
| Well I am still sometimes seeing this user that is sending
| latin-1, confusing everyone else.
|
| I also wish that nicknames would not be handled via the hack
| of bots, as this sysem allows one to take a nickname one does
| not own, at least for a short while, but simply no identify
| it and ignore that message, and thus impersonate another
| user.
| tenebrisalietum wrote:
| IRC, the protocol, is really simple. It's so simple it's almost
| the most minimal chat protocol you could possibly layer on top of
| TCP - it's literally a live message routing protocol with the
| least support for the notion of persistent users possible.
|
| There was a joke on bash.org that IRC is basically multiplayer
| Telnet and ... they aren't really too far off.
|
| This has good and bad things about it:
|
| Good: it's extremely flexible.
|
| Good: it's extremely efficient - your major IRC servers at there
| peak were probably one machine, possibly single core, and handled
| 20,000+ active connections. Protocol is extremely proxyable and
| tunnelable.
|
| Good: It works well over dialup. If you can get .002Mbit/sec
| between you and the server you can use IRC.
|
| Bad: no real concept of identity - everything is based on IP
| addresses and current connections. Connection drops, you're gone.
| Things have arisen to address this (NickServ, etc.) and using a
| bouncer has always been a thing.
|
| Good: no real concept of identity - if your IP is cloaked or
| you're not accessing from your home IP, you're very anonymous.
|
| Bad: First user on a channel is it's op and it's owner and can
| control the channel. If all ops connections drop, someone can
| take it over. DoSes/DDoSes to disrupt channels have been a thing.
| Things have arisen to address this on modern IRC (ChanServ) but
| before then, any really serious channel had to have a network of
| bots with out-of-band coordination to protect it (eggdrop).
|
| Bad: Doesn't support file transfer directly. This is done with
| another protocol DCC which is hard to work with over firewalls,
| etc.
|
| Bad: Media and link support is up to clients and requires non-IRC
| protocols to be effective. You're not posting pictures in IRC
| channels unless you are using a client that supports it such as
| thelounge, and even then what thelounge does is upload your
| pictures to a local server.
|
| Good: Mature IRC clients give you a lot of control.
|
| Bad: Mature IRC clients are complicated.
|
| Bad: IRC is one of those protocols that arose before encryption
| was considered a basic need. Modern IRC supports SSL but all it
| takes is one client connecting non-SSL to ruin it like email,
| unless the server is SSL only.
|
| Bad: Mature IRC servers tend to be from the age where the
| Internet was ruled by universities. So, DNS is relied on for
| security and identity far more than it should be. Configuration
| of mature IRC server daemons I find somewhat complex and
| difficult.
| epalm wrote:
| As an aside, can I just say how refreshing this website is? It's
| 100% content, just text. Now view the html source, and be amazed.
| I daresay the author actually wrote the html by hand. I suppose
| it could be a very conservative and conscientious site generator
| that even respects line length, but I'd be surprised. Short css
| file for minimal style tweaks, and readable markup. Fitting that
| the article is about simplicity. When I first learned html (late
| 90s) this is what it looked like. Very nice.
| Iv wrote:
| Possibly a pandoc generated html from markdown. My favorite way
| of doing things.
| Jorengarenar wrote:
| Source code [0] is available on GitHub; looks like they wrote
| their own simple site generator.
|
| I've been thinking about something similar (maybe even simpler)
| for my blog too.
|
| [0]: https://github.com/susam/susam.net
| susam wrote:
| Thank you for sharing the link to the source code. My simple
| site generator is based on my wife's project makesite.py[1].
| In fact, I used her site generator for a few years. Later I
| reimplemented makesite.py in Common Lisp. As a result, it
| inherits the design, layout, minimalism, and simplicity of
| makesite.py.
|
| [1] https://github.com/sunainapai/makesite/
| signal11 wrote:
| It does appear to be handcrafted HTML, generated using [1].
|
| > This is a static website generated using a Common Lisp
| program. See github.com/susam/maze for the source code of this
| website[2]
|
| > Just like the original website, every line of HTML and CSS
| that appears in the website is handcrafted.[3]
|
| [1] https://github.com/susam/maze/blob/main/site.lisp
|
| [2] https://susam.net/maze/about.html
|
| [3] https://github.com/susam/maze
| Zababa wrote:
| It seems like the CSS used is shared under the MIT license by
| the author here: https://github.com/susam/spcss.
| pxeger1 wrote:
| Unfortunately, the inline code is dark blue, unreadable in dark
| mode.
| susam wrote:
| Thanks for commenting about this issue here. I had
| accidentally removed the CSS code for pre, code, etc. in a
| recent commit. Fixed it now.[1] You should no longer see this
| issue after a hard refresh.
|
| [1] https://github.com/susam/maze/commit/1d58e13
| badrabbit wrote:
| I am if the opinion that IRCv3 is horrid and has taken the email
| route of (forgive the language) "polishing turd". You cannot have
| a secure irc that is backwards compatible, you can have separate
| default ports and uri schemes like http vs https, but you can't
| connect to http and opportunistically redirect 301 to https and
| call that an improvement of securiry because it is actually
| worsening security by introducing false assurances of securiry.
|
| I also believe it is possible to have a protocol that has proper
| E2EE and simple enough to where you can use netcant and one other
| tool to use IRC.
|
| Trust-on-first-use authentication (like signal or ssh) is also
| terrible in practice on its own. Keep it simple. Let the servers
| handle public key distribution and certification so that
| compromise of the server/mesaaging infrastructure is required to
| mount identity attacks, then do the normal TOFU authentication so
| users won't have to trust middleware. Have a commandline tool
| that "connects" to the other user (like ssh or sendmail) and
| opens a socket/fd you can use with a proper frontend or just
| echo/netcat to it.
| hoyd wrote:
| Nice article, thanks :-) I grew up with IRC and realize that it
| isn't the same any longer. It isn't the place where everyone is,
| which some social networks seem to be today. The local
| communities on IRC, a channel for a town used to be the place to
| be and meet others.
| erk__ wrote:
| IRC is probably used by more people now than ever before,
| though in a very different way than before. The whole of
| Twitch's chat infrastructure is running on it and it have
| hundreds of thousands of concurrent users. Though for most
| people it is running though a websocket instead of a raw
| socket, but the commands are the same a long way
| Jasper_ wrote:
| The IRC protocol is for the bot API only. The chat on the
| website uses a custom protocol, and the IRC daemon has always
| been a custom implementation with weird quirks.
| erk__ wrote:
| It is a custom protocol that follows IRC very closely, they
| just have a lot of extensions on it to add support for the
| things on twitch. to start a connection you send PASS,
| NICK, USER and then JOIN, over the websocket so I would not
| really call it a custom protocol. The url it uses is
| wss://irc-ws.chat.twitch.tv/ as well.
| prox wrote:
| I think Discord took over the role of IRC. It has a lot of same
| functions and terminology.
| mnd999 wrote:
| Discord is internet relay meme.
| stavros wrote:
| Same with SMTP and POP, I would routinely send or get email via
| telnet when I wanted to debug or delete some messages. They're
| all very simple protocols.
| anthk wrote:
| Usenet too. Getting news and discuss stuff "offline" and
| fetching/sending the messages once a week it's magical and
| resting.
| mrweasel wrote:
| The fall of Usenet more and more looks like a mistake. I'd
| love to have hyper-localized newsgroups, in place of
| Facebook.
|
| Often local stuff like: "Why does is smell like somethings on
| fire", "Has the water been turned of" or is "Is soccer
| cancelled this week?" is only posted on Facebook. So if you
| don't have Facebook, you can't get those information. Then
| again the Facebook algorithm will hide it for three weeks
| before deciding that you need to know that the hot water will
| be turned of for quarter of the town at three o'clock.
|
| I feel that Usenet would be ideal for this.
| anthk wrote:
| On Usenet, MUDs, and IRC, look what could be achieved back
| in the day by tweaking the source code of a MUD: they
| converted it into a full groupware tool thanks to TCL/TK
| and some glue here and there.
|
| https://paparisa.unpatti.ac.id/linux_journal_archive_1994_2
| 0...
| u801e wrote:
| Some newsgroup messages have a distribution header. But I
| don't really recall that feature being used at all during
| the time I was on Usenet (late '90s till about 7 years
| ago).
| mrweasel wrote:
| I was just suggesting having a group or two for your
| town, rather than just having them for major cities.
| apples_oranges wrote:
| In my experience, email protocols are anything but simple as
| soon as some security or authentication comes into play.
| fulafel wrote:
| Depends on the auth mechanisms in use, the simplest ones are
| still still pretty straightforward. Nowadays you just use the
| TLS equivalent of telnet (openssl s_client).
|
| POP3: 1. run openssl s_client -connect
| myserver.example.com:995 2. enter two commands: "user
| myusername" "pass mypassword" 3. profit
|
| SMTP & AUTH PLAIN is only slightly more complicated but
| similarly just an additional protocol command, connecting
| with s_client. (You need to generate the auth string in
| another shell window with: echo -ne
| "\0username\0password"|openssl base64)
| thenerdhead wrote:
| I miss IRC. The simplicity in design is one thing. I think the
| other part I miss is the pseudonyms and having an identity not be
| directly attached is another.
|
| I remember joining so many IRC channels to learn about everything
| in college. You'd get help and be humbled by the many regular
| names in each channel. There was more of a human element to it as
| most people simply acted as extensions of themselves.
|
| You think about Slack, Discord, and Teams today and there's a
| whole corporate or personal identity attached behind each name.
| You can't always act like you would in IRC. You can't always be
| blunt and to the point. You can't call someone an idiot or to
| RTFM in the most sincere way possible.
|
| When things were simple with a single pseudonym and a message,
| things were great. Now things are much more complex. Threads,
| DMs, notifications of mentions, bots, gifs, etc. It's definitely
| been changing quickly, but it was nice when everyone's attention
| was in one place instead of fragmented in each of these new apps
| that are just glorified IRC.
| jjulius wrote:
| Totally agree! Just one ever-so-minor nitpick...
|
| >When things were simple with a single pseudonym and a message,
| things were great. Now things are much more complex. Threads,
| DMs...
|
| IRC has DMs too, /msg
| beanjuiceII wrote:
| I've finally migrated away from the last of my irc channels the
| last remaining people except for one holdout agreed it's time to
| move on. Things have been way better since the switch..I wouldn't
| go back, a new bar has been set
| Rendello wrote:
| Preferred chat notwithstanding, at least the holdout didn't go
| the xkcd route: https://xkcd.com/1782/
| iqanq wrote:
| >I often remark how simple the Internet Relay Chat (IRC) protocol
| is and how that has fostered creativity in the lives of young
| programmers growing up in the late 90s and early 2000s. For many
| of us who were introduced to the Internet during that time,
| writing an IRC bot turned out to be our first non-trivial hobby
| programming project that involved network sockets, did something
| meaningful, and served actual users.
|
| While that is true, most of those who wrote bots did not
| meaningfully interact with the protocol because they used
| abstractions (eggdrops, mirc scripts, etc). The simplicity of the
| protocol was unrelated, as a well abstracted library for any
| other protocol or even service (such as twitter) can be as
| simple.
| corobo wrote:
| Admittedly my first bot was indeed in mIRCScript and its
| abstractions but it wasn't long before I had a !spawn command
| that was a function that connected sub-bots directly to IRC as
| a protocol because why not I guess
|
| Also wrote a script that sent email directly for tinkering
| purposes, later used that protocol knowledge to get my first
| tech job haha "how does email work?" "how in-depth do you
| want?"
| FemmeAndroid wrote:
| Is this true? It's not my experience. My first meaningful
| programs were raw socket IRC clients as a teenager explicitly
| because they were simpler to figure out than using things like
| egg drop.
|
| That isn't to say that most fully featured tools were written
| from scratch -- I can't speak to that one way or another. But I
| know a lot of people who were learning about internet protocols
| by using telnet to interact directly with IRC servers then
| transferring that knowledge into a socket-level
| reimplementation of the protocol.
|
| RFC1459 certainly proved to me that RFCs can be simple and
| worth reading. And the whole experience taught me early that a
| simple enough, well documented protocol could be easier to use
| than a wrapper library in a foreign language. I certainly use a
| lot of libraries these days, but those lessons have served me
| extremely well.
| anthk wrote:
| With ii you can write a bot today with any language reading
| and writting to files. Even with sh.
| [deleted]
| lewiscollard wrote:
| I dunno, I was there in the very early 2000s and as I remember
| it, for the subset of programmers I knew on IRC at the time, it
| was as Susam says: writing a shitty IRC bot - not a script,
| something from "scratch" that actually spoke the IRC protocol -
| was almost a rite of passage back then. From rose-tinted me-
| tinted glasses, I seem to remember that IRC-bot-related
| questions were a plurality of the questions asked in #vb on
| Dalnet back in the day!
|
| You are also right to some extent as well; I wonder how much
| mIRC scripting has been underestimated as the gateway drug to
| programming for thousands.
|
| (Rose-tinted/me-tinted disclaimer: the first non-trivial
| program I wrote was an IRC quote bot, in Visual Basic. I later
| rewrote it into Python, because I wanted to learn Python, which
| eventually led to my day job today...)
| littlecranky67 wrote:
| Equally rose-tinted user here. My first unix service ever
| configured and started, was eggdrop (and it took me hours to
| get it running on a shell account).
___________________________________________________________________
(page generated 2022-01-09 23:00 UTC)