status-im / specs

Specifications for Status clients.
https://specs.status.im/
MIT License
14 stars 14 forks source link

Clarification on Status node roles #123

Open Samyoul opened 4 years ago

Samyoul commented 4 years ago

Following from an issue raised in #114 . The language regarding Status nodes is ambiguous and doesn't clearly describe the requirements of a Status node, additionally raises a number of unanswered questions.

See below for the related section:

https://github.com/status-im/specs/blob/56d5a2ff3949f3d2a68c70e1ae6780d2a080f16d/docs/stable/1-client.md#L103-L114


Discussion from https://github.com/status-im/specs/pull/114#discussion_r427233923

Questions / Statements from the discussion:


Pinging @oskarth and @kdeme as you were in the original discussion

oskarth commented 4 years ago

cc @decanus

rajeevgopalakrishna commented 4 years ago

Don't Status Clients HAVE to implement Whisper relayers (along with Mobile node)? If not, who else will relay the p2p envelopes? Unless, the architecture implements specific Whisper relay nodes outside of the Client.

I suppose the current Status Client does implement relaying without an option to disable it - correct?

oskarth commented 4 years ago

It depends on how we define relaying precisely. See

Mobile nodes

This is a Whisper node which connects to part of the Whisper network. It MAY relay messages. See next section for more details on how to use Whisper to communicate with other Status nodes.

Mobile nodes publish their own messages, but they never relay other nodes messages. Only "relay/full nodes" (in our cluster, largely) do this. (Desktop might look different).

rajeevgopalakrishna commented 4 years ago

Agree, if we define relay as "receive and pass on, a particular object" then Mobile nodes today do not relay any envelopes. They only publish their own messages and receive messages (of which some are) meant for them.

So this implies that relaying is only implemented in the Whisper relayers or Full nodes (those listed under whisper/rendezvous in https://fleets.status.im/ ?).

Effectively, Mobile nodes implement Whisper "light" nodes (because they do not relay) and Relay nodes implement Whisper "full" nodes (because they do relay and that is all they do).

So we could consider changing the name of "Whisper Relayers" to "Relay nodes", which might also be pertinent with Whisper being replaced by Waku.

At the same time, we could consider changing "Mailservers" to "History nodes" to make the terminology consistent.

oskarth commented 4 years ago

I forgot to link at the time, but this is probably the best place to continue this discussion

For people who keep thinking about changing names in Vac protocols, this is useful as context for where I think we want to go https://github.com/vacp2p/specs/issues/87

kdeme commented 4 years ago

One thing that creates confusion in the currently defined roles is that some of the roles are purely Waku/Whisper roles and then some are at the level of the Status application.

I think these need to be split off. There are the roles within each protocol (e.g. Waku light node). And the roles as a Status client.