[OTR-dev] Re: Requirements for libotr4

Kjell Braden fnord at pentabarf.de
Thu Jun 19 07:22:53 EDT 2008


> 2. No hardcoded strings at all. I don't know if your point about error
> codes covers the case "The following message ... was not encrypted:
> [...]". Here one would need an error code plus the message that was
> received.
> 
-snip-
> 
> 4. The 3 line spanning OTR announce message, ironically also called
> "better message" in the code. This is again a hardcoded string I would
> like to see disappear. The really really bad thing about it is that it
> is a 3 line message and in IRC we don't have newlines. So in order to
> eat this message up and not present it to the user I had to hardcode
> the second and third line in irssi-otr. Bad!
> 

4. should be part of 2. It would be best if we had an additional
function in OtrlMessageAppOps that is used for translating codes to any
human-readable string that may occur in the whole lib, which will then
be used by the lib, eg. passed to notify() or similar.

> 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see
> disappear. Because of it, it is impossible to transfer OTR
> conversations over OTR...and also complicated to talk about OTR in an
> OTR session...I always find myself writing "if you wanna restart OTR
> write <question mark>OTR....". A function otr_restart would be the
> right thing here I believe.

This will probably complicated: we need something that the lib can use
to identify it's messages, and since we don't know what kind of protocol
will be used, it's hard to find some sort of tag that
  a.) is protocol independent (an additional stanza in XMPP will not
work on OSCAR/IRC/whatever)
  b.) will never interfere with messages manually written by the user

> 6. SMP handling. Ian said this would be reworked but it's missing in
> the 4 points below. E.g. applications really shouldnt mess around with
> variables that libotr touches as well (smstate->nextExpected).

IMO SMP should just call a callback (or return a TLV or similar which
can be identified by the client) from otlr_message_receiving for a SMP
request (on TLV_SMP1*), abort (something went wrong, like
SMP_PROG_CHEATED, or wrong TLV order) and finish (TLV_SMP[34]). The
implementation can then check the SMProgState and display the results.

> 7. Maximum message size handshake. Currently, each end uses its own
> MMS. This is a bad thing if you use something like jabber transports
> because the jabber end will likely have a too large MMS for the other
> end (ICQ,...). For irssi-otr it's always a problem in conjunction with
> bitlbee since IRC has a limit of about 500 and the other end might be
> playing with 2k. The only reason why this currently works at all is
> because OTR messages (except the 'better' msg under 4.) start with
> "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr.
> The solution is simple: Each end advertises its own MSS during the
> initial handshake and both use the minimum of the two.

Sounds like a good thing to me. If I read that correctly it wouldn't
even need work from the clients, the lib can do this on it's own.

> > *** 2. Custom message stripping function ***
> > otrl_message_sending and otrl_message_receiving will be having an
> extra
> > optional argument (a callback function) to give the IMs the
> flexibility to
> > strip/convert the messages that are sent/received. For example, the
> > conversion function could strip the HTML tags out of the original
> message in
> > order to be guaranteed an HTML-free message.

I don't think the receiver should remove HTML from the message. What if
I want to send a HTML-snippet to my friend using jabber? Currently,
pidgin would escape the HTML tags to < and >, and proper clients
would display those entities in plaintext, which is very bad. If we
would implement a stripping method on the receiving side, they would
change that back to < and >, but they would also strip anything which
was initially in < and >. So if a proper client sends HTML tags (in
plaintext, not intended to be formatted!) to another proper client, they
would strip the HTML tags, which is even worse.
The right thing to do here would be to make the sender send information
about what kind of message it is (maybe using MIME-Types or whatever, so
they would send text/html or text/plain or text/x-aolrtf) and to make
the receiver convert them to the right format.

So that means:
  purple-client sends text/html to gajim: gajim would convert this to
text/plain
  gajim sends text/plain to another gajim: no conversion necessary.


Thanks,
Kjell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20080619/3aef9ca3/attachment.pgp>


More information about the OTR-dev mailing list