5 ms·

I'm no IRC expert, but I do know that some IRCds do support sending a scrollback / channel history. For example, InspIRCd's chanhistory module: https://wiki.ins

by ReidZB 12y ago

I'm no IRC expert, but I do know that some IRCds do support sending a scrollback / channel history. For example, InspIRCd's chanhistory module: https://wiki.inspircd.org/Modules/2.0/chanhistory https://wiki.inspircd.org/Modules/2.0/chanhistory How it actually accomplishes that within the framework of the "protocol," I don't know.

scrollaway 12y ago
The messages are sent as extra messages, duplicating timestamps and faking senders and overall it's pretty ugly. The Quassel protocol supports this, unfortunately it looks like the quassel team doesn't care about taking it further than where it is.
- grawity 12y ago
  Timestamps – there's a standard extension for this (see IRCv3 above). ZNC has been using it for maybe a year. Senders – there's absolutely no reason to fake senders, since it was always valid for messages to come from people not in the channel.
- SaberUK 12y ago
  Full disclosure: I am one of the developers on the aforementioned IRC server. In a future release InspIRCd will adopt support for the server-time extension which will allow us to get rid of the timestamp duplication if a user's client supports it.
  - scrollaway 12y ago
    Interesting. Can you tell me what you think of Quassel as a protocol?
    - nenolod 12y ago
      It's very specialized and last time I looked at it, it was based on Qt types and other ugly things. It would not be realistic as an alternative protocol for IRC itself.
      - richm44 12y ago
        Just a note that the QDataStream format is documented, and has been implemented in other languages such as Java. That doesn't mean that the Quassel protocol should replace IRC of course. :-)
nenolod 12y ago
It sends some channel messages after the JOIN. The new IRCv3.2 specification (being formally ratified across vendors soon!) adds a BURST type to make the protocol transactional which will allow displaying the messages in the right order with a little bit of work on the client side.

by ReidZB 12y ago

scrollaway 12y ago

The messages are sent as extra messages, duplicating timestamps and faking senders and overall it's pretty ugly. The Quassel protocol supports this, unfortunately it looks like the quassel team doesn't care about taking it further than where it is.

grawity 12y ago
Timestamps – there's a standard extension for this (see IRCv3 above). ZNC has been using it for maybe a year. Senders – there's absolutely no reason to fake senders, since it was always valid for messages to come from people not in the channel.
SaberUK 12y ago
Full disclosure: I am one of the developers on the aforementioned IRC server. In a future release InspIRCd will adopt support for the server-time extension which will allow us to get rid of the timestamp duplication if a user's client supports it.
- scrollaway 12y ago
  Interesting. Can you tell me what you think of Quassel as a protocol?
  - nenolod 12y ago
    It's very specialized and last time I looked at it, it was based on Qt types and other ugly things. It would not be realistic as an alternative protocol for IRC itself.
    - richm44 12y ago
      Just a note that the QDataStream format is documented, and has been implemented in other languages such as Java. That doesn't mean that the Quassel protocol should replace IRC of course. :-)

nenolod 12y ago

It sends some channel messages after the JOIN. The new IRCv3.2 specification (being formally ratified across vendors soon!) adds a BURST type to make the protocol transactional which will allow displaying the messages in the right order with a little bit of work on the client side.