IRC channel logs

<cow_2001>woops

<cow_2001>Noisytoot: done! thank you!

<cow_2001>should i replace the list of enemies with a hash table or something?

<cow_2001>and the bullets

<cow_2001>each update i `filter` over it

<cow_2001>which maybe recreates the list

<cow_2001>should not worry about it now, i guess

<ridley>I’m back with another OCapN-related question.

<ridley>From what I can tell, op:start-session is necessary for two things:

<ridley>1. mitigating crossed hellos

<ridley>2. establishing session info needed for third-party handoffs

<ridley>I have come up with a couple cases where I am wondering if we can skip a step:

<ridley>1. We already have an active session with a peer and receive a new connection request from them.

<ridley>2. We have already received a connection request from a peer and are awaiting their op:start-session through that connection when we receive another connection request from them.

<ridley>Unless I’m mistaken, both of these would be cases where the peer is not following protocol correctly.

<ridley>Is it safe in both of these cases to just close the new connection instead of having to wait and process their op:start-session?

<ridley>To be clear I am also saying close the conneciton, not sending an op:abort or anything.

<ridley>I have assumed that when a NetLayer receives a connection request, it will know the PeerLocator of the requester. Thus when the connection request is passed up to CapTP, CapTP will know the PeerLocator of the requester. Is this somehow a problematic assumption?

<dthompson>ridley: crossed hellos is a complicated topic and one that I can't speak to very well. tsyesika is not in this week but knows a lot about this.

<ridley>Okay, thanks

<dthompson>ocapn might actually be underspecified when it comes to crossed hellos mitigation

<dthompson>it *might* be appropriate to just close connections in those cases, but I don't know for sure

IRC channel logs

2025-05-12.log