Add encrypted access tokens

[cammellos]

This commit modifies the spec so that instead of passing a list of SHA3 public_keys to the server for filtering, the user will pass instead a list of access_token encrypted with the allowed contact DH PK(bob) PK(alice).

It also removes the blocked_user_list, so all the filtering is done based on the chat_id field.

Effectively both were used a sort of a spam prevention mechanism, but the cost of keeping blocked_user_list is that a user will need to disclose their identity to the server, and is trivial to circumvent for any determined attacker, so keeping only filtering on chat_id achieves a similar naive prevention of spam without compromising the privacy of other users.
Spam prevention is something that we don't have a solution in status app and this reflects the same behavior.

These changes effectively means that:

1. The server has no way to know which users are in allowed_user_list.
2. The client can query the server anonymously, so at no point they have to disclose their identity to the server.

Addressed some leftover feedback
@rajeevgopalakrishna

[cammellos]

@rajeevgopalakrishna I have addressed the feedback in the closed PR here, we can probably keep the conversation here.

I have changed the protocol so that the access_token is generated client side and passed to the server.

I want to change how allowed_user_list works, and instead of passing a list of hashed public keys, the user can encrypt the token with all the public keys of the allowed users in a blob and push that to the server.

When querying users can just pull this blob and look for a token by decrypting the message, so that we don't have to communicate to the server which users are actually allowed, and conversely the users don't have to communicate their real identity to the server.
But likely I will address that in a different PR.

[oskarth]

Generally seems fine to me, but I'd rather see core and security take ownership of these reviews and getting them merged. One review from core and one from security seems reasonable to me

[oskarth]

Removing reviewers to avoid diffusion of responsibility, pinging @andremedeiros @Samyoul @0kok0 @rajeevgopalakrishna for reviews

[rajeevgopalakrishna]

More privacy now with encrypted tokens - nice work! Just a few minor (formatting) suggestions to address for now.

[rajeevgopalakrishna]

Can we rename this to "Push Notification Node" to start avoiding further usage of the term server?

[Samyoul]

I'm curious, what is the benefit of avoiding the term "server"?

[cammellos]

I don't mind either, technically the lines are a bit blurred, as they both operate as waku clients, but there's definitely a client/server relationship, so happy to go with any that we decide

[rajeevgopalakrishna]

Ok, just that it's confusing/misleading to see a client/server relationship in a p2p network (e.g. mailserver vs history node). We can cast this as a special type of node that is queried by others today with the potential to merge this functionality into other nodes in network later.

[rajeevgopalakrishna]

Replace "public key" with "chat key"?

[cammellos]

That's a bit tricky,
I'd say, let's park the renaming for now and we will do in a different PR if it that's ok with you.
The thing I am not sure is that not always this will be chat keys, for example in anonymous mode this are just keys that a user creates specifically for push notifications, but they are not chat keys.

[cammellos]

ok, so I have updated the references where we refer 100% to a chat key

[rajeevgopalakrishna]

access_token should perhaps not be bundled under PushNotificationPreferences. Consider renaming or splitting message.

[cammellos]

I might do that in a separate PR if it's ok, I will be getting rid of a few messages in order to simplify and we can shuffle things around at that point if that's ok.

[Samyoul]

Great work. Just a few points of clarification that I feel need addressing.

Also sorry for the late review @cammellos , I actually read through this whole PR on Monday, but got sidetracked with Nim 😬

[Samyoul]

I'm curious, what is the benefit of avoiding the term "server"?

[Samyoul]

Does this sentence describe communication between a Push Notification Server and a client node? Or are we talking about p2p comms between clients?

The section seems to be about server / client querying, but this sentence seems to be about p2p comms. Perhaps add a sentence or subsection header to describe the difference between directly querying the server and client to client querying. Though I may be misunderstanding / missing the part where this distinction is made

[cammellos]

This describe a client querying a server,
although the definition of a server is a bit lose, any client can act as a push notification node(server) if it wishes to do so, but that's probably a different matter.

Basically you pull the encrypted data from the server, and then you decrypt it taking into consideration your pk and the pk of the user who has registered with the server, but no direct communication between the two clients.

[rajeevgopalakrishna]

We could think of these as capabilities (history, relaying, notifications etc.) that can be implemented/enabled by various nodes without enforcing a strict client-server relationship.

[Samyoul]

I has to Google that "monotonically" term.

[Samyoul]

Suggested change

	- The fact that is interested in sending push notification to a given client,
	but their public key is not disclosed
	- That it is interested in sending push notification to another given client,
	but the querying client's public key is not disclosed

[cammellos]

@rajeevgopalakrishna @Samyoul I should have addressed all the outstanding feedback.
There's still some considerable changes that I need to make, but I will do in a different PR (getting rid of some of the messages, specify encryption etc), so there will be still time for feedback at a later round.
thanks