Meta comment: HN's knee jerk reaction when it comes to certain topics is becoming quite exhausting. Obviously a lot of the current commenters didn't even read what the article was about and just wanted to vent about the good old days of mailing lists and half-assed docs that at best had a code sample, but on average were just a "table of contents" for the source code that you'd ultimately have to read. I for one wish these projects had BBS-es in addition to Discord, but man I love just chatting with people working on the thing I am also interested in and making friends along the way.
Actual comment: When it comes to Watchy, I found the docs to be a good starting point - https://watchy.sqfmi.com/docs/getting-started . They give you the architectural diagrams, have a few code examples for some of the more common use cases, and do a pretty good job at letting you know that this is very much going to be an "adventure" type project with a lot of surface to cover.
They could expand one day and add links to articles/projects other people have made, but I am not sure many of those exist. It is sort of a niche product.
I agree in principle - Discord can only scale that much - imagine having a discord channel instead of docs for Pandas . Obviously it would be best if there were great docs for everything, a lot of easily searchable Q&As + sample projects, and a forum and some form of live chat for the community to discuss ideas.
But those take a ton of time to create, and a ton of skill to write well, and I feel like up and coming niche projects that need to build a community naturally would emphasize Discord over docs.
The greatest communities in technology all have good documentation. There’s no reason to play fast and loose when you can just do the job right and document your tools.
The Unix philosophy has nothing to do with documentation lol. It is actually the exact opposite of your know it all hypothetical "no reason to play fast and loose when you can just do the job right" fantasy :
"Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them."
If anything, it is a lot closer to move fast and break things.
I use a Matrix channel (which is bridged to an IRC channel) for this purpose. I host computing book club meetups in the weekends. While the meetup main page and notes are hosted on a website, I have Matrix and IRC channels where the meetup participants can hang out together, follow schedule updates, make friends, etc. All our communication is in text format, so these open protocols and platforms serve our needs pretty well.
The group members have the freedom to use any free and open source client or one of the popular web interfaces to join the channel and talk to each other. Should something go wrong with the Matrix or IRC network (say, the network becomes user-hostile for some reason), it is a simple matter of moving the channel to another benign network. The group members only need to point their clients to the new address.
In fact, such a thing did happen once in 2021 when Freenode went through major staff changes due to disagreements with how the network was being run. All channel operators (myself included) moved their channels to Libera in a matter of days. It took me only about 5 minutes to complete the migration and hand out the new channel address to the channel members.
>HN's knee jerk reaction when it comes to certain topics is becoming quite exhausting
Yep you can guess comments all the time just by the title alone. There are certain topics that triggeres a lot of people here and no matter what the actual submission is about (they won't read the article either way) they just post their preoccupied comment. I mean when someone makes a throwaway "discordsucks" to comment that says it all.
Honestly, my comment was pretty balanced imho. Discord does provide great UX for what it is good at. That is gaming communities and day to day chatter and such. I even think it has a huge lead in that regard other than maybe being a bit slow on weaker hardware - probably cause electron. It just has inacceptable entry barriers for documentation purposes by collecting your data and severe limits on how much content can be accessed and more importantly retained. I spare you to repeat myself on why I think so. Especially open source projects shouldnt make it a requierement to hand over your data to a entity which has recently been fined for GDPR violations in order to use them.
The Discord instances I've used do have threading. Maybe it's a configurable setting or maybe it's only available in paid versions of Discord. I have heard lots of complaints that the design makes it easy for people to miss that feature.
More broadly, it seems to be a common problem in chat UIs, regardless of what particular product you're on. I think there is a segment of internet users who have been online for a while now and are used to web 1.0 chat rooms where there was only one way to send messages. They do not have the muscle memory of using threads. That's why you see so many dangling responses that should not be standalone messages but rather should have been part of the thread.
> disable one or both as they can take more effort to moderate/maintain.
This is why I don’t consider Discord’s version of threading as true threading. They are temporary channels with all the same admin/moderation requirements that regular channels necessitate.
I have yet to come across a Discord server that lets anyone create threads from posts in their general channels.
Discord sucks. It's propietary and using a CHANNEL (no, they aren't "servers", educate yourselves, FFS) as a documentation source/tool it's the worst thing ever the gen-z had made. Period.
Channels and servers are different things, and both terms are used for discord. A channel is just a single text or voice space where discussions can happen. Many projects will have multiple channels each specialized to a single topic. The whole collection of these is called a "server". The docs also use the term "guild" for the same concept, as the API docs explain [0].
They're called servers because we wanted to pick words that were familiar to what we were originally competing against, which was team-speak/ventrilo/mumble servers.
Picking words people are familiar with in order to convey a concept is a generally smart thing to do. A discord server was meant to be analogous to a ventrilo server. Calling them servers made that idea clear to our users, which helped users understand our product and what purpose a server served. I would say that the term has served its purpose well.
Internally we call them guilds, because having a "server server" is a bit ridiculous.
> a computer or computer program which manages access to a centralized resource or service in a network.
I think by definition you're wrong. By layman's terms you're wrong too. A server serves things, either content, chat text or your meal. Discord servers serve a collection of text channels located on a centralized resource.
Now, for the real lesson: take yourself and everyone else less seriously.
A Discord “server” is neither a computer nor a computer program. All “servers” are serviced by a single program distributed across many actual servers, presumably without any direct mapping.
From what Discord employees have previously said, a guild server is a single Erlang process that's usually fixed to a single host. Voice is handled separately, but again by a single process assigned to that guild server.
I'm not sure what distinction you're trying to draw here. Calling the process that handles communication between users a "server" was already common practice back when IRC was standardized in 1993 (where discord gets the term from). It even appears in the original jargon file, so that definition was common long before even that.
An IRC server has a collection of channels. A discord server has a collection of channels.
It is simple as that. IRC servers don't refer to a single physical server either since IRC servers supported federation allowing multiple servers to act as a single server. There is no need to be so strict on the definition of server considering how loose its usage was already with IRC.
No: an IRC network is a collection of channels. A network is then made up of numerous servers. In IRC parlance a server always in fact did explicitly mean a specific individual server and I would be shocked if you found anyone who hadn't used IRC for more than even a day or so that tried to call, say, EfNet a "server".
That is a specific hostname and is in essence a "server" (though the existence of irc.efnet.net is special in that it is a DNS load balancer address that selects a random server) and isn't EFNet; the concept of "EFNet", in contrast, is being called a "chatnet" in that configuration file, not a server. You might have multiple servers configured for the same network, and irssi will attempt to round-robin the connection between them if they fail. If you want a list of networks in irssi, you use /network list; if you want a list of servers you use /server list.
FWIW, IRC barely exists anymore. To the extent to which to does it has been massively simplified. It used to be that there were massive collections of servers for most networks run by tons of different people, and often if you ran an isolated server for a single-server network people would show up ply you to add their server to your network. I can see how someone who only casually uses IRC and only semi-recently (in the past decade or two) might be left with a really limited or even confused understanding of the lingo.
So like, sometimes networks did have these DNS round-robin load balancer addresses, and I could see someone getting confused by that for a bit. But, they weren't used all that often other than as a server discover mechanism, because--for a number of reasons I will list a few of--it mattered greatly what server you were actually on... enough so that, if you were to actually to use IRC much at all, it would become very very clear that a network and a server are not somehow interchangeable terms.
1) The Internet itself and the software we were using was flakey enough that you would routinely encounter a "netsplit", wherein people who were on one half of the network could still talk to each other but people on the other would see you all disconnect.
(This was also used by people to try to attack and take over channels by denial of service attacking specific servers in the network as the behavior of re-merging channels often gave you moments where you could take chanops.)
2) The latency across the Internet was sometimes higher--particularly if you had to do multiple hops to get to the right server the user was on--and so people who were on the same server as each other had a lot better experience talking to each other.
3) The channel namespace using # was global to the network but many networks supported server-local channels that were prefixed with ##. If you were on a different server you would thereby not be able to see the same server-local channels.
Nowadays, you wouldn't bother with most of this as, administratively, this is madness. The usual server-to-server protocol forms a DAG and so it doesn't actually provide any form of redundancy: your network feels about as stable as the least stable server (weighted by how close it is to the center of the graph). You also don't need lots of servers to try to distribute the connection load, and the core Internet latency isn't a big deal anymore.
Oh it was immediately clear that your original comment was right in the first half. The irssi example isn't intended to rebut that. I was rebutting the second half: that it was obvious. As someone who has thought about IRC for a couple of hours over the course of a decade, it's not obvious. The .irssi example is merely me trying to debug why I might have had that impression.
(It's also not clear to me why people in this thread are getting so pedantic about the distinction between server and service. I'm just here to exercise my pet peeve: nothing about computers is obvious.)
OK, so my argument here is that users aren't using IRC in a bubble: they are connecting to IRC to talk to a bunch of other people; and, because servers mattered SO MUCH, and the clients you were using--including irssi--are so consistent with the terminology split between "server" and "network", they wouldn't have continued to use the wrong term for very long because someone else would have corrected them or they quickly would have needed to do something more complicated with their client and discovered the difference in either the documentation or the output from basic commands like /connect.
Like, what server you were on was a near daily discussion among just about everyone on EFNet in particular, because EFNet was notorious for experiencing netsplits as it was simultaneously enormous and almost entirely unprotected: some networks (I think the big one being Undernet? it's been 25 years so I am likely remembering this poorly... I did a quick search for this and maybe I'm thinking of DALNet?) had come up with this idea of "services" like chanserv and nickserv that would help you register your stuff so it couldn't get stolen; but, on EFNet, every channel worth a damn had to be protected by redundant bots spread across the topology.
FWIW, the reason why the Discord usage of "server" kind of pisses me off is because it actively makes it more difficult for users to come to the correct understanding of terms in general parlance: it trains them to use a term "server" in a way that actively makes them understand the term less because exactly one popular service--Discord--has decided to misuse the term... and they do so with the excuse "we just wanted to be analogous to IRC"; but, somehow, they even got that wrong, and so the whole thing comes across as so incompetent as to be negligent and (thereby) passively malicious :/.
(I also probably am a bit more frustrated about Discord than a random commentator because, in addition to having been screwed during the username upgrade last month, a long time ago I was working on a similar service and even had a similar architecture--hell: I was even building it using Erlang; I don't think it was in Elixir, but I was an early user of that also and it might have been... I had two projects: one in Erlang and one in Elixir, and I don't even remember what the other one was--but then Slack came out and I thought I would never be able to compete against them as they had epic UI people... but then Slack chose a target market I found limited and after a couple years of feeling they would have to enter this space, Discord suddenly became popular and I was all like "damn it why the hell didn't I just assume Slack would be stupid?!".)
Ok that makes sense once you bring up netsplits. (Are they still as prevalent as they used to be? Or did the network grow more robust over time? Or is just the reduced usage of IRC that makes them matter less?)
I like that Millenials have finally gotten old enough to forget their own experience and repeat the age old tradition of blaming everything wrong in the world on the next generation.
Discord themselves call them "servers". If you want to change public opinion, you'll need to start at the source. I just double checked to be sure, and yup, that button at the left says "Add a Server".
I use 'community' because, as someone else mentioned, 'channel' is already in use as a word and an invite-only collection of chat rooms where you can often create a custom profile I think can be called a community.
Server is indeed misleading and inaccurate, though I do fear we lost another war: hacker now means cracker, cloud now means foreign server, crypto now means cryptocurrency, ping used to mean Blackberry Messenger, you name it; these things come and either stay or go again... it might be more confusing to use another term for it (I try to introduce community where possible, but the opportunities are rare) because people have to (be able to) figure out from context what you're talking about.
Help me with my education. I'm just a lowly 4th year SWE major and we haven't covered definitions of servers yet.
Webster's says:
> a computer in a network that is used to provide services (such as access to files or shared peripherals or the routing of email) to other computers in the network
And if a computer is:
> a programmable usually electronic device that can store, retrieve, and process data
How is it not a server? It is a computer, it is used to provide services, it's programmable and electronic, routes content... Do you have to assume each discord instance is running in its own container for you to consider it a server? It serves things.
We may not like the "future", but old software using 20x more resources than usual has been the future for a while, just look at electron apps the growing trend of home computers becoming thin clients over webapps and cloud computing. I despise this trend as much as the anyone else, but I can't see how it isn't the future we are heading towards.
It has always been this way. How many people who grew up on text terminals, and despised GUI-based utilities that are essentially just thin graphical wrappers on top of a CLI tool at 20x the size?
This argument gets repeated by every generation ad nauseam, even though they're oblivious to the fact that it keeps reoccurring. Everyone loves drawing an arbitrary line in the sand.
What does Discord improve over Kopete by using 20x more resources except for the video resolution?
Also, it should run far snappier if the improvement was just a video resolution improvement and a new codec often accelerated by the GPU such as h264. But it doesn't.
Actual comment: When it comes to Watchy, I found the docs to be a good starting point - https://watchy.sqfmi.com/docs/getting-started . They give you the architectural diagrams, have a few code examples for some of the more common use cases, and do a pretty good job at letting you know that this is very much going to be an "adventure" type project with a lot of surface to cover.
They could expand one day and add links to articles/projects other people have made, but I am not sure many of those exist. It is sort of a niche product.