[OTR-dev] irssi-otr 0.1 released

[Ian Goldberg]

[Moved to otr-dev.]

On Tue, Jul 15, 2008 at 01:09:02PM +0000, Uli M wrote:
> From irssi-otr's viewpoint the other end's MMS is at least when used
> with bitlbee in 99% of the cases too high. Jabber clients use 2
> kilobytes, IRC needs something below 500 bytes. That's why irssi-otr
> needs to do reassembly by itself and potentially on top of libotr
> reassembly (the fragmentation is done by bitlbee). If libotr would
> negotiate the MMS between the two parties the whole reassembly code in
> irssi-otr would be unneccessary.
> 
> Now the problem was that the reassembly code in irssi-otr tried to
> reassemble messages fragmented by libotr that didn't need reassembling.
> It depended on messages being terminated by '.' but fragmented messages
> are terminated by ','. That wasn't a problem before because irssi-otr
> has the same MMS as irssi-otr (obviously,so no reassembly) and all other
> clients don't fragment messages at all (since they don't need to). The
> exception being communication with pidgin over IRC - and here the bug
> occurred.
> 
> The code was something like 
> 
> 	if len(msg)>MMS and msg[len(msg)-1]!='.' then reassemble
> 
> which I corrected by
> 
> 	if len(msg)>MMS and msg[len(msg)-1]!='.' and
> 		msg[len(msg)-1]!=',' then reassemble
> 
> It ain't pretty but it works. Prettier would be MMS negotation ;)

Is this "then reassemble" doing libotr reassembly or bitlbee reassembly?
What does bitlbee fragmentation look like?

If the sender (pidgin-otr for example) fragments the message, and
bitlbee refragments it, why could irssi-otr not do bitlbee-reassembly
to recover the otr fragment, then pass that to otrl_message_receiving as
usual, which will automatically perform the appropriate otr reassembly?

Thanks,

   - Ian