[OTR-dev] irssi-otr 0.1 released

Ian Goldberg ian at cypherpunks.ca
Wed Jul 16 08:34:21 EDT 2008


On Tue, Jul 15, 2008 at 11:08:00PM +0000, Uli M wrote:
> 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.

And that's because the other end thinks it's talking XMPP?  It doesn't
know that the buddy is actually on 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.

Unfortunately, the latter is too ugly, even for me.  :-) Not to mention
that it would be nice if the MMS value were authenticated.  And the
former doesn't quite work, since the initial key exchange messages
themselves need to be fragmented on IRC.

> 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.

I guess the question is what delivery claims is bitlbee making?  It's
performing fragmentation, but it looks to me like it's up to every IRC
client to do the defragmentation.  Most of the time, the clients just do
nothing, and display the fragmented messages to the user, which is close
enough for plaintext, I suppose.

   - Ian



More information about the OTR-dev mailing list