[META] Presence less Raiden Node

[fredo]

Abstract

This issue is to keep track of making the Raiden Client free of keeping the state of other raiden nodes' presences. With the refactoring of the whole Matrix setup up, there is no more presence being shared among the clients. Instead the PFSes become the entity who receives and provides the necessary information of online states and matrix user ids. In fact, for mediating payments we already rely on the PFS' view of the network state. Each client implementation can choose whether to rely more or less on the PFSes information.
As a last resort, a client could completely not rely on the PFS information and try to send messages to all possible matrix users with the disadvantage of generating more load on the servers.

Assumptions

• The PFS is a trusted entity regarding Presence and Matrix User IDs of the raiden nodes. This can be argued that it is in the best interest of the PFS to keep the network healthy as it earns with the number of routes requested by the users.
• meta data which are passed by the clients are not signed

Properties

Following there are some properties described which serve as a fundamental basis of the decisions made.

Integrity of address metadata

Currently, the meta data provided by the PFS are not signed in any way. These information are passed along the route. Thus a malicious node could provide wrong metadata to its peer. If the Raiden node kept the presence state based on these information, false metadata could distort the view of the network and harm it.

Times where matrix users are necessary

There are different use cases when matrix user information is necessary.

• Mediated Payments (Neighbour)
• Direct Payments (Neighbour)
• Creating WebRTC connections (Neighbour)
• Secret Request (Initiator, Neighbour)

Implementation

Implementation follows a certain priority pattern.
First, achieve a working network even though it might not be the most efficient
Second, Optimize regarding Performance
Third, Find and Cover edge cases

Phase 1

As a first step, the Raiden Node stays completely without any presence state keeping of the network. Each payment consists of the next matrix user id to talk to. This means the matrix user id is not bound to a raiden client rather to a specific payment. This avoids the fact that a malicious Raiden node could forge the matrix user ids and somehow break the channel completely. It would only break this single payment.
The Raiden Node must decode the next user id from the message and will blindly send it over.
In this phase, we neglect the possibility of roaming users within one payment.

Issues

• Remove Presence from internal State
• Forward address metadata from PFS route query in messages
• Process route information as a mediator
• Send message to user_id encoded in message
• Disable webRTC for now
• Presence less WebRTC Connection mechanism
• Rename matrix_users to more generic address_metadata
• Rename address metadata (in the PFS)
• Remove the UserAddressManager in Raiden

Phase 2

From the discussions, it became clear that Raiden nodes have a very distinct subset of other raiden users which they talk to. If it were possible to keep reliably track of these user presences and matrix user ids, a Raiden node could decide whether to use the information provided in the route or trust its own presence representation.
Users in the subset are:

• direct channel neighbours
• initiators
  Note, that targets are implicitly known by receiving the secret request in the case of toDevice messages.

Another thought on data integrity is the possibility that the PFS signs the route information.
This is an ongoing Meta Issue. Brain dumps in the comments are welcome

[ezdac]

Some messages that might be missing in our considerations:

• WithdrawRequest

Here we could simply query the PFS on each request, since they are infrequent enough anyways

And then, in conjunction with that:

• WithdrawExpired
• WithdrawConfirmation

Those could be handled respectively by:

• keeping (implicit) state on the withdraw-initiator side
• passing user-id info from the transport to the state machine upon receiving the request to keep implicit state

In general, I have the feeling we go to great lengths to "avoid" state for the address-metadata,
just to pass it through the whole state machine and effectively keeping state implicitly.
Isn't there a better way to handle this in the transport, but introduce scoping, so that the address-metadata is not kept "global"?
This would also keep the transport logic / types away from the state machine..

Downside:
User-ids are not recoverable from the state - for "short-lived" crashes that could be relevant