[Suggestion] Phone Call Support

[Ryu945]

Can you add the ability to attach a phone number using an ephemeral public/private key. The public key of the account will not be associated with the phone number at all so that any correlation to your ephemeral public key can be dropped when you give up a phone number/ephemeral public key. I see VOIP providers providing this service and linking with Lokinet. From Lokinet's point of view, the VOIP provider is nothing more then a client. The ephemeral public key is nothing more then an ephemeral friend contact code(public key). The VOIP company can decode your messages/voice call just like any contact you seed a message/voice call to. I have heard of free VOIP providers.

In the client itself, there would be a phone dialer. If the phone number you dial happens to be a phone number used by someone in Lokinet, it will instead initiate a lokinet to lokinet voice call and not use the VOIP provider. The same applies for text messages. If that number is not in the Lokinet then it will use the VOIP provider as planned.

Being able to connect to other E2EE using this phone system would also be useful ( for example Signal). You would also skip using the VOIP provider if a number is identified as a Signal number. Signal integration should take a back burner to getting VOIP working in the way I described above.

[eyeberic]

Are you suggesting a Lokinet/Session version of jmp.chat?

Because if you are, I reckon that this should be something an external service should be responsible for architecture-ing the stack.

Having it implemented natively is not recommended as not all users will be using it, especially when it concerns additional personally identifiable, which is against what Session constantly claims.

No, not even as an opt-in feature. Session (and co) should not even put itself / themselves in such a dangerous situation.

If a 3rd-party (in the future) offers such a service, interested users are free to interact with them, and if an incident occurs, the faulty wire should not be able to rope in Session (and co).

[Ryu945]

Something like jmp.chat, yes

The issues with making it entirely external of lokinet is the lack of privacy verse an in lokinet implementation.

1) Your going to need a throw away public key that can be linked with your real phone number but only inside the encrypted environment of Lokinet. This is so your actual public key never gets linked with with the phone number at all.

2) There needs to be a database base linking these throw away public keys with with phone numbers so that if someone dials a phone number of someone who also just so happens to have a Session phone number, the call can be put through with the E2EE over lokinet and never goes through the VOIP provider.

[eyeberic]

Iterating the same point as mentioned in my original comment:

This should not be a "lokinet implementation" as it is not guaranteed that all future Lokinet users / Oxen products and system will leverage on this suggested feature.

The only way this changes is if this is a highly demanded feature, and that users interested in it are well aware and accepting the potential risk since it concerns some critically PII.

[Ryu945]

Iterating the same point as mentioned in my original comment:

This should not be a "lokinet implementation" as it is not guaranteed that all future Lokinet users / Oxen products and system will leverage on this suggested feature.

The only way this changes is if this is a highly demanded feature, and that users interested in it are well aware and accepting the potential risk since it concerns some critically PII.

Since data stored in Lokinet is encrypted, isn't it possible to implement this with zero security risk to the end user? I am not understanding the potential risk you speak of since it will still follow all the same security protocol as currently used and even implements an additional security protocol. It is essentially a Session to Session phone call but people can listen in on the VOIP side of the phone call since that is part of the old phone system. That is actually why I wanted Lokinet to be able to identify if two phone numbers are both in Lokinet and route the call only through Lokinet when it realizes this. Otherwise, it will use the VOIP system after it goes through Lokinet first.

A lot of people are not technically savy or have no motivation to use two apps. This essentially compromises the security of the people that do try to be more secure. What made Signal great was that it was one interface that always tried to accomplish the communication as secure as possible given who your trying to contact. Those concerned with privacy could actually use it with people they know not so concerned with privacy. Those not concerned with privacy did not notice any difference then any other messaging app so they used it.

[eyeberic]

First of all, there is no such thing as "zero security risk".

Even if it is using the same encryption, or bootstrapping additional secure protocols (and increasing overhead).

Secondly, this "VOIP" feature is beyond Lokinet's main focus,and is more of a service provided by a SNapp instead.

Thirdly, the example scenario that you provided will require the user to somehow provide their phone number, going against what Session commonly advertise itself for. Even if you try to push it towards Lokinet side, refer back to the second point.

Fourthly, yes, Signal usually tries the "upgraded security" communication channel if possible, but that is because the data source required for such information look-up is centralized and easily accessible, in comparison against the different underlying architecture that Session (and co) uses.

[Ryu945]

First of all, there is no such thing as "zero security risk".

Even if it is using the same encryption, or bootstrapping additional secure protocols (and increasing overhead).

Secondly, this "VOIP" feature is beyond Lokinet's main focus,and is more of a service provided by a SNapp instead.

Thirdly, the example scenario that you provided will require the user to somehow provide their phone number, going against what Session commonly advertise itself for. Even if you try to push it towards Lokinet side, refer back to the second point.

Fourthly, yes, Signal usually tries the "upgraded security" communication channel if possible, but that is because the data source required for such information look-up is centralized and easily accessible, in comparison against the different underlying architecture that Session (and co) uses.

Even if done through a SNapp, wouldn't lokinet need a way to assign a temporary public key to that service not associated with your main public key? Thus you can drop association with that SNapp at any time. The rest I could see implemented on the SNapp side but that does leave a fragmentation problem. If there is more then one SNapp service providing this service then every SNapp service providing phone service would have to contact every other SNapp service providing phone service to find if a number is in lokinet network. This would be like email in that since. If there is a VOIP number match, the two different SNapp services would have the temporary public keys of the people calling between each other exchanged for E2EE that doesn't go through the SNapp services.

[eyeberic]

There are already instructions with regards to the mapping, as well as live SNapps as examples (e.g. cafe.loki).

I'm not sure how well a SNapp might perform in an anycast or HA/FO setting (since there is no live example of one yet), but that is an architectural concern.

Regarding fragmentation, that is an user adoption issue. Even if by some twist of fate, this "feature" is supported natively by Lokinet, there are still situations whereby the user (of Session, Lokinet, or whichever Oxen products) may not even utilize it.

[Ryu945]

There are already instructions with regards to the mapping, as well as live SNapps as examples (e.g. cafe.loki).

I'm not sure how well a SNapp might perform in an anycast or HA/FO setting (since there is no live example of one yet), but that is an architectural concern.

Regarding fragmentation, that is an user adoption issue. Even if by some twist of fate, this "feature" is supported natively by Lokinet, there are still situations whereby the user (of Session, Lokinet, or whichever Oxen products) may not even utilize it.

When I said fragmentation, I was referring to that fact that one SNapp might provide one temporary public key with a VOIP phone number and another SNapp might provide another temporary public key with another VOIP phone number. There needs to be a way for routing to figure out that both of these people are on lokinet and don't send the phone call over the traditional phone system.

From this conversation, it seems that what is important is not so much that Lokinet provides this type of service but that the backbone of Lokinet is setup so a SNapp can provide this service. Perhaps whenever a master public key ( aka the main public key that is basically your account) wants to setup service with any type of SNapp, it should be standard procedure for a temporary public key to be established just for use with that SNapp. Your keep that temporary public key ( and ofcourse the private key associated with it) for as long as you use that SNapp service. This temporary public key essentially becomes your account on that SNapp service. You can close service with that SNapp by removing the temporary public/private key.

I am not expert how it should be done but a solution like this seems like it might work. A device has its main private key and all SNapp private keys for SNapp services it signed up for. Every SNapp service has its own private key for use just with that service and for nothing else. You may want to consider having the public keys used for SNapp services be a different length then public keys used for the main account so that they can be distinguished from one another. This way lokinet knows a public key is a regular public key or a SNapp public key and can treat them different. The hash of these different length public keys will still map on the same number wheel that all public keys map. The user device will not only check the cluster associated with its main private key for messages but will also check all clusters associated with SNapp services it has signed up for messages regarding that service only. It can't be used for messages for anything other that communicating with that SNapp service. This is why Lokinet needs to be able to tell the difference between a main public key and a SNapp public key.

On the cluster associated with the main public key of the account, there will be a permanent database. This database will store the SNapp private keys but they will be encrypted with the main public key. This accomplishes two things. First, the private keys are encrypted so an accounts main cluster is unable to read communication associated with SNapp services. Second, when someone recovers their account for their main private key, they can go to their main cluster and download all the private keys for SNapp services they signed up for. Then they can decrypt those private keys using their main private key. Thus they can start using the SNapp services again. This allows the account recovery system that is already setup to be used to recover all the private keys for services that person signed up for without them having to write down recovery information for every single SNapp service they signed up.

[eyeberic]

The only main takeaway from your above comment is this:

This is why Lokinet needs to be able to tell the difference between a main public key and a SNapp public key.

As far as I can tell, this additional calculation may introduce unnecessary routing delays, which may degrade the performance of Lokinet.

Lokinet is mainly on the Network layer, which should not involve unnecessary features / functions that will degrade the security and speed of routing whatever data that the other layers passes down.

Anything else that fails to fit within that scope should be delegated to the appropriate (sub)systems at their respective layer.

[Ryu945]

The only main takeaway from your above comment is this:

This is why Lokinet needs to be able to tell the difference between a main public key and a SNapp public key.

As far as I can tell, this additional calculation may introduce unnecessary routing delays, which may degrade the performance of Lokinet.

Lokinet is mainly on the Network layer, which should not involve unnecessary features / functions that will degrade the security and speed of routing whatever data that the other layers passes down.

Anything else that fails to fit within that scope should be delegated to the appropriate (sub)systems at their respective layer.

Would the calculation of what cluster to pull data from that happens anyway on top of a length parameter for the key cause that much of an issue on the network layer?

[eyeberic]

I do not know the answer to that, but just reminding you to factor in scalability, in case you missed that out.

Number of clients, number of requests per second, number of Service Nodes, size of the table to perform the lookup, the duration of the lookup, race condition / thread lockup, adjusted specifications of Service Nodes / protocol specification / software, etc.

This is starting to go way beyond the scope of Session client.

[Ryu945]

Would it be better for scalability to have all of a users data only sinking to one cluster or part of their data in cluster 1, SNapp 1 in cluster 2, SNapp 2 in cluster 3, etc...

For SNapp app security in general, we do need a way for a public key to only be temporarily associated with a SNapp app. I assumed the best way to achieve this would be a separate public key for every SNapp app. Applications like VOIP phone service and many other can piggy back on this security.

[KeeJef]

Session now supports voice and video calls, however i don't think there is appetite to integrate real world phone numbers into Session, so closing this for now