[OTR-dev] Using libotr

Alex Burzyński alex.burzynski at gmail.com
Tue Mar 11 19:33:37 EDT 2014


Hi Martin,

Thanks for answering, but that triggers more questions!

I'm trying to draw some use-cases for those different policies and decide
if they even should be exposed to the end-user.

So as I understand the fragmentation, the plain text is encrypted and then
split into fragments.

And in my mind the app's inject_message callback merely sends the message
fragments to the other end, there shouldn't be any extra logic in there.
convert_msg looks like a place for that extra logic.

So in case of ALL_BUT_LAST what else could the app do with the last
fragment other then send it? I'd imagine that without the last fragment the
message wouldn't be readable at all on Bob's end.

Could you explain what that hook you've mentioned might want to do with
that last fragment?

Thanks,
Alex



On 11 March 2014 12:06, Martin Milata <b42-ml at srck.net> wrote:

> Hi,
> not sure about the other questions but perhaps I can at least answer
> this one:
>
> On Tue, Mar 11, 2014 at 01:14:53 +0000, Alex Burzyński wrote:
> > Fragmentation policy
> > I don't fully understand the how
> > OTRL_FRAGMENT_SEND_ALL_(BUT_FIRST|BUT_LAST) work, where those fragments
> are
> > stored and why?
> > how my use of otrl_message_sending/receiving() should change depending on
> > OtrlFragmentPolicy?
>
> When you use one of the two policies, the fragment that is not sent is
> returned in the messagep pointer passed to otrl_message_sending. The
> other fragments are sent using the inject_message callback you provided.
>
> The OTRL_FRAGMENT_SEND_ALL_BUT_LAST is useful when you are calling
> otrl_message_sending from some kind of a hook that expects you'll have
> modified message to send at the end (i.e. the application itself handles
> the last fragment). Not sure when OTRL_FRAGMENT_SEND_ALL_BUT_FIRST can
> be useful.
>
> Hope that helps,
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20140311/b4b8a5cb/attachment.html>


More information about the OTR-dev mailing list