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
This is a huge step but it's needed more than ever. Servers currently have a relationship graph of all users in rosters. We should get rid of them (maybe keep them only for contacts outside of the network) and instead rely on client-to-client collaboration. For example, you may send a message to someone only if you have their public key (which was requested earlier and must have been approved and sent by that someone). ~~~This might be enforced by the server by checking the encryption key of the message, however this won't work for PFS encryptions (OTR, OMEMO, ...).~~~
This has some other side effects:
presence subscriptions must be on demand (since rosters are not used...)
no way to block public key requests (we should disable usernames since it's metadata leak, use an iq directly to the client instead)
In general this would mean that the client is responsible for security instead of the server. But since we are all going to become a server-less (as in peer-to-peer) world, this is a step toward that.
Blocking lists are still kept by the servers though. Those we can't really get rid of. Unless we use client voluntary blocking.
The text was updated successfully, but these errors were encountered:
This is a huge step but it's needed more than ever. Servers currently have a relationship graph of all users in rosters. We should get rid of them (maybe keep them only for contacts outside of the network) and instead rely on client-to-client collaboration. For example, you may send a message to someone only if you have their public key (which was requested earlier and must have been approved and sent by that someone). ~~~This might be enforced by the server by checking the encryption key of the message, however this won't work for PFS encryptions (OTR, OMEMO, ...).~~~
This has some other side effects:
In general this would mean that the client is responsible for security instead of the server. But since we are all going to become a server-less (as in peer-to-peer) world, this is a step toward that.
Blocking lists are still kept by the servers though. Those we can't really get rid of. Unless we use client voluntary blocking.
The text was updated successfully, but these errors were encountered: