Clarification on Status node roles

[Samyoul]

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:

specs/docs/stable/1-client.md

Lines 103 to 114 in 56d5a2f

	#### Node discovery and roles
	There are four types of node roles:
	1. Bootstrap nodes
	2. Whisper relayers
	3. Mailservers (servers and clients)
	4. Mobile nodes (Status Clients)
	To implement a standard Status client you MUST implement both 2. and 4. node types. The
	other node types are optional, but we RECOMMEND you implement a mailserver
	client mode, otherwise the user experience is likely to be poor.

---

Discussion from #114 (comment)

Questions / Statements from the discussion:

• I realize this was in old code, but is this true?

• If you implement a mobile node, do you also need to implement a relay node?

• It is true we get forwarded envelopes on mobile (but don't relay further).

• What do we mean by mobile node in that case?

• Yeah, I guess it should rather be something like:
  "A Status client MUST implement the Mobile node role and MAY implement Whisper/Waku relayer and Mailserver roles."

• Are there circumstances when a Status node would be active and not be using p2p messaging?

---

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

[oskarth]

cc @decanus

[rajeevgopalakrishna]

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]

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]

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]

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]

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.