session management question

[mvayngrib]

is there a way to manage sessions? I have the following scenario:

User A and User B are talking
User B falls off a cliff
User B gets back online, but has different instance tags so User A ignores him.

One way of solving this:

User A's OTR instance can notify it about query messages, e.g. via an event 'query'. Then User A can create a new OTR instance to respond to that new connection

Do you know of a better way?

EDIT: skimmed over OTR spec...it's long :) Here's another option I see, though I'm not sure I see confirmation in the spec:

When receiving a "query" message, if you already know the other party's instance tags, then in addition to re-initializing AKE, like the code already does, reset this.their_instance_tag. Otherwise continuing with AKE has no chance of succeeding.

EDIT: oof, another obvious solution is having persistent instance tags. But if for the sake of argument you don't use persistent instance tags?

[arlolra]

Sorry for being slow here. I'll take a look shortly.

[arlolra]

Right, so we don't really have a great story for session management, but that can be improved.

Your edits above took you to the right places. Ideally, a client has a persistent instance tag. At present we're complying with the spec, but only because it's kind of vague in this area.

Looking at libotr, https://github.com/off-the-record/libotr/blob/master/src/message.c#L996-L1004

/* Get the context for this instance */
if (their_instance >= OTRL_MIN_VALID_INSTAG) {
  context = otrl_context_find(us, sender, accountname,
    protocol, their_instance, 1, &context_added,
    add_appdata, data);
} else {
  message_malformed(ops, opdata, context);
  return 1;
}

The 1 in the arguments to otrl_context_find meaning create one if it isn't found.

When receiving a "query" message, if you already know the other party's instance tags, then in addition to re-initializing AKE, like the code already does, reset this.their_instance_tag. Otherwise continuing with AKE has no chance of succeeding.

Unfortunately, that defeats the whole purpose of instance tags.

User A's OTR instance can notify it about query messages, e.g. via an event 'query'. Then User A can create a new OTR instance to respond to that new connection

That puts the burden of session management on client libraries, which doesn't sound great. Then they'll have to parse messages to decided which session they belong.

I think we need to refactor a bit of code.

[mvayngrib]

@arlolra thanks for getting back to me. I understand...sort of :) Is this something you guys plan on developing in the near future?

[arlolra]

Unfortunately, it's hard to give a timeline. It's just me maintaining this voluntarily. But I'll probably peck away at it in my spare time over the upcoming weeks. Patches welcome :)

To solve your problem immediately though, you can always set ALLOW_V3 = false.

[mvayngrib]

cool, looking forward to it, and thanks for the tip! If you need someone to bounce approaches off of, I'll try to make myself available.

[arlolra]

Thanks for the offer and raising the issue.