[OTR-dev] irssi-otr 0.1 released

Uli M a.sporto+bee at gmail.com
Tue Jul 15 19:08:00 EDT 2008


On Tue 15.07.08 17:31, Ian Goldberg wrote:
> On Tue, Jul 15, 2008 at 03:25:30PM +0000, Uli M wrote:
> > IIRC bitlbee splits IRC messages longer than 512 bytes (note that an IRC
> > message also contains other stuff like nick and server, so the actually
> > payload should be less than that). I can be very thankful for that
> > because irssi-otr wouldn't exist if bitlbee would cut the messages off
> > (which I'm sure some IRC servers do). By splitting I mean making two
> > messages out of it, so for example
> > 
> > :nick!nick at irc.server.net PRIVMSG ulim : FOO.........BAR.......
> > 
> > becomes
> > 
> > :nick!nick at irc.server.net PRIVMSG ulim : FOO.........
> > :nick!nick at irc.server.net PRIVMSG ulim : BAR.......
> > 
> > How does irssi-otr detect and reassemble this:
> 
> Ah, I see.  So there's no actual framing, saying "this is fragment 1/3"
> or anything like that.  I guess what you're doing is about all you can
> do, in that event.

Yeah, the whole thing is only a workaround. The real problem is that the
MMS on the other end is too high for IRC. Which wouldn't be the case if
libotr chose the smaller MMS of the two peers on both ends. I imagine an
additional field for the MMS in the initial message exchange would
suffice. Or maybe even in the query message...something like
?OTR?MMS=416. Then all the other end has to do is compare its value and
choose the smaller number.

Such a change probably wouldn't be reasonable just for irssi-otr but I
can imagine that this problem arises in other contexts where gatewaying
or proxying is done as well.

Uli




More information about the OTR-dev mailing list