7 ms·

> you can't innovate features independently That's also the case with open protocols like IRC. Sure you can write an IRC client with reaction emoji support, an

> you can't innovate features independently That's also the case with open protocols like IRC. Sure you can write an IRC client with reaction emoji support, and it will look great in your client, and anyone using a different client will just see garbage metadata. You can only innovate by getting "everyone" to agree on a new standard, and that's hard.

zAy0LfpBZLC8mAC 7y ago
> That's also the case with open protocols like IRC. No, it's not. > Sure you can write an IRC client with reaction emoji support, and it will look great in your client, and anyone using a different client will just see garbage metadata. Then you are bad at protocol design. > You can only innovate by getting "everyone" to agree on a new standard, and that's hard. No, you innovate by being backwards compatible with established standards. Now, maybe IRC has reached the limits of its flexibility and should be replaced, I dunno, but the idea that it is somehow impossible to evolve protocols incrementally with partial adoption of new features is just bullshit.
- tom_mellior 7y ago
  I think you read too much into my post. I didn't claim anything about protocols in general. You yourself admit that it might not be flexible enough to evolve. It has certainly had a lot of time to try.
  - zAy0LfpBZLC8mAC 7y ago
    > You yourself admit that it might not be flexible enough to evolve. I don't really think so, but I don't really know, I haven't every tried to do anything in that direction. > It has certainly had a lot of time to try. Except that people have to do it? As far as I am concerned, IRC is good enough, so I don't feel like putting any effort into "improving" anything, and it seems like a lot of people using IRC feel this way. Those who feel it's not good enough, though, seem to prefer building non-interoperable systems or just using proprietary lock-in vendors. Obviously, that's not gonna result in anything new in IRC.

zAy0LfpBZLC8mAC 7y ago

> That's also the case with open protocols like IRC. No, it's not. > Sure you can write an IRC client with reaction emoji support, and it will look great in your client, and anyone using a different client will just see garbage metadata. Then you are bad at protocol design. > You can only innovate by getting "everyone" to agree on a new standard, and that's hard. No, you innovate by being backwards compatible with established standards. Now, maybe IRC has reached the limits of its flexibility and should be replaced, I dunno, but the idea that it is somehow impossible to evolve protocols incrementally with partial adoption of new features is just bullshit.

tom_mellior 7y ago
I think you read too much into my post. I didn't claim anything about protocols in general. You yourself admit that it might not be flexible enough to evolve. It has certainly had a lot of time to try.
- zAy0LfpBZLC8mAC 7y ago
  > You yourself admit that it might not be flexible enough to evolve. I don't really think so, but I don't really know, I haven't every tried to do anything in that direction. > It has certainly had a lot of time to try. Except that people have to do it? As far as I am concerned, IRC is good enough, so I don't feel like putting any effort into "improving" anything, and it seems like a lot of people using IRC feel this way. Those who feel it's not good enough, though, seem to prefer building non-interoperable systems or just using proprietary lock-in vendors. Obviously, that's not gonna result in anything new in IRC.