You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently irssi-otr (git master) ties contexts down to "account" of form [email protected] and to "user" which is the peer's nickname. I think that this approach is flawed mostly because nicks and servers on IRC change often, causing excessive key regeneration and loss of trusted connections.
However, I am not very familiar with OTR and much less with the needs of Bitlbee integration, so I want to ask from those who are more knowledgeable before making any changes on this code.
Is there any reason to have multiple local identities? Why should I have more than one "account"?
If different contexts for different networks are deemed necessary, they should most likely be tied to network names (server->tag) rather than to server hosts (server->connrec->addr). Should the user have multiple connections to the same network, each connection will not only have its own nickname (because nicks within the network must be unique) but each of them will also have a different tag (IRCNet, IRCNet2, ...) despite possibly using the same server.
The use of local user's nickname in these bindings seems completely unnecessary and only harmful. Using the ident string (Irssi setting user_name) would seem to make more sense, but since this is a global setting not configurable per server/connection, it makes things not very different from just leaving out the value.
The contexts are also tied with peer nicknames which may cause trouble when nicks are changed for whatever the reason. Instead of this we could use peer's ident which tends to be more stable although also a bit less unique. The big drawback is that we need to /whois or /userhost to get the ident string.
Is it a problem if different people end up in the same context? Or even if everybody just goes into one big global context, and we only rely on the key fingerprints to tell them apart?
Thanks for any input.
The text was updated successfully, but these errors were encountered:
There are reasons for users to have different OTR keys per account and/or server. Security wise, keys on different device, ...
So yes on IRC, nickname can change quite often. I love the idea of using the "user_name" instead. However, this means that when a user would want a different key for a server, the user_name will have to be changed for that server in irssi config so the otr plugin knows which key to use. I think it's doable by adding "user_name = <...>" in the servers = {} array but I'm not 100% sure.
I'm wondering here if by default we should map "user_name" if possible or "nickname@server" (best effort) and provide an OTR config file with something like "<server_name> = <otr_fp>" which will tell the right key to use for the specified server.
I came here because I'm also unhappy that I have at least 4 keys for OFTC now due to different servernames. An option to tie the key to $nick@$network instead of $nick@$server sounds nice to me.
Currently irssi-otr (git master) ties contexts down to "account" of form [email protected] and to "user" which is the peer's nickname. I think that this approach is flawed mostly because nicks and servers on IRC change often, causing excessive key regeneration and loss of trusted connections.
However, I am not very familiar with OTR and much less with the needs of Bitlbee integration, so I want to ask from those who are more knowledgeable before making any changes on this code.
Is there any reason to have multiple local identities? Why should I have more than one "account"?
If different contexts for different networks are deemed necessary, they should most likely be tied to network names (server->tag) rather than to server hosts (server->connrec->addr). Should the user have multiple connections to the same network, each connection will not only have its own nickname (because nicks within the network must be unique) but each of them will also have a different tag (IRCNet, IRCNet2, ...) despite possibly using the same server.
The use of local user's nickname in these bindings seems completely unnecessary and only harmful. Using the ident string (Irssi setting user_name) would seem to make more sense, but since this is a global setting not configurable per server/connection, it makes things not very different from just leaving out the value.
The contexts are also tied with peer nicknames which may cause trouble when nicks are changed for whatever the reason. Instead of this we could use peer's ident which tends to be more stable although also a bit less unique. The big drawback is that we need to /whois or /userhost to get the ident string.
Is it a problem if different people end up in the same context? Or even if everybody just goes into one big global context, and we only rely on the key fingerprints to tell them apart?
Thanks for any input.
The text was updated successfully, but these errors were encountered: