@sir IRC is kind of broken as designed; the server pretty much expects to be talking directly to the user, so there are fundamental things missing, like knowing which past request an error message is a response to, or knowing whether a message you see or sent has been truncated because it was too long (or even what the length limit is)
@sir @lain @ciaby on the contrary: scaling problems are very often protocol problems, and even more often are much easier to solve by protocol changes than by implementation changes. HTTP scaled better than telnet, gopher, or FTP for protocol reasons; NNTP scaled better along some dimensions than HTTP for protocol reasons; HTTP/2 scales better than HTTP/1 for protocol reasons; TCP/IP scales better than NCP for protocol reasons; and I think, though I'm not sure, that the IRC protocol beats AP
@kaniini @sir @lain @ciaby Well, I was thinking also about AP's individual messages being a bit heavierweight than IRC's, and about it not having a native channel mechanism to limit the number of copies of a given message that any given server has to make. But at least it doesn't have netsplits, right?
@kaniini @sir @lain @ciaby The example messages in https://www.w3.org/TR/activitypub/ have 160 bytes or more of apparently mandatory per-message overhead, which is about 4× the size of an average IRC message. At the point where we hit bandwidth limits this means a 5× scalability penalty. But presumably we have to improve other bottlenecks a lot before that becomes the problem
@kaniini @sir @lain @ciaby But I was saying that the IRC protocol seemed likely to be more scalable than AP, not that AP's improvements over IRC and other messaging protocols weren't worth those putative scalability penalties. And as you probably saw in the other thread, IRC has substantial scalability problems of its own.
@kaniini @sir @lain @ciaby Scalability is only one axis of design quality. It's totally possible for one design to be more scalable than another despite being worse in other ways. Happens constantly, in fact. IRC servers routinely serve 10,000 concurrent clients (and, say, 1000 concurrent active users, and about 10 k messages per second) on sub-gigabyte hardware. ØMQ and AMQP implementations can beat those message rates by an order of magnitude; Kafka by 2.
All friendly creatures are welcome. Be excellent to each other, live humanism, no nazis, no hate speech. Not only for nerds, but the domain is somewhat cool. ;) No bots in general! (only with prior permission)