new RFC: 57/STATUS-Simple-Scaling #580
Conversation
content/docs/rfcs/57/README.md
Outdated
| > *Note*: This is not planned for the MVP. | ||
|
|
||
|
|
||
| # Light Clients |
There was a problem hiding this comment.
I'm not sure if necessary, but we previously tried to move away from the binary sounding "light" vs "full" nodes in terminology (though people seem to fall back to these familiar terms). Reasoning then was that we really provide a spectrum of options for nodes, who can choose based on either resource restrictions or own motivations what level of service they want to provide/consume. I'm OK with using "light" here, as long as we don't set this in stone as a special type of client - i.e. nodes can choose to fully relay for one community, but only use the light protocols for another, etc.
There was a problem hiding this comment.
I will rename this section to light protocols, and adjust accordingly.
| Nodes can request history messages via the [13/WAKU2-STORE](/spec/13/). | ||
|
|
||
| The store service is not limited to a Status fleet. | ||
| Anybody can run a Waku Archive node in the Status shards. |
There was a problem hiding this comment.
Although we don't have proper capability discovery defined here yet - in other words, nodes would simply assume such Archive nodes "store everything".
There was a problem hiding this comment.
I will add a note :).
|
|
||
| # Infrastructure Shards | ||
|
|
||
| ## Control Message Shards |
There was a problem hiding this comment.
If I understand correctly, general control messages will still be relayed by default in the main Community shard? This section just discusses "special" control message sharding, for large messages. For clarity it may be worth being explicit here (or earlier) about which traffic goes to the static community shard ("all" by default), and that this separate sharding is not a requirement for all control messages? E.g. renaming this section to Sharding for large Control Messages. Hoping this makes sense. 😅
There was a problem hiding this comment.
Agreed. Wdyt about keeping the name control message shard,
but making explicit that control messages CAN be routed via control message shards, but don't have to be?
There was a problem hiding this comment.
Makes sense! In other words, the way I read this RFC is that it starts with general description of static shard allocation per community and moves to specific further shard separation techniques which may or may not be required based on community size/need.
There was a problem hiding this comment.
I added more context in dd23486
Wdyt? Imo, with this it should be obvious that other messages are still relayed as per normal operation.
I can rephrase if it is not clear yet.
There was a problem hiding this comment.
Yes! Looks good and is clear. Thanks.
Co-authored-by: Hanno Cornelius <[email protected]>
Co-authored-by: Hanno Cornelius <[email protected]>
| ```protobuf | ||
|
|
||
| syntax = "proto3"; | ||
|
|
||
| message CommunityDescription { | ||
| // The Lamport timestamp of the message | ||
| uint64 clock = 1; | ||
| // A mapping of members in the community to their roles | ||
| map<string,CommunityMember> members = 2; | ||
| // The permissions of the Community | ||
| CommunityPermissions permissions = 3; | ||
| // The metadata of the Community | ||
| ChatIdentity identity = 5; | ||
| // A mapping of chats to their details | ||
| map<string,CommunityChat> chats = 6; | ||
| // A list of banned members | ||
| repeated string ban_list = 7; | ||
| // A mapping of categories to their details | ||
| map<string,CommunityCategory> categories = 8; | ||
| // The admin settings of the Community | ||
| CommunityAdminSettings admin_settings = 10; | ||
| // If the community is encrypted | ||
| bool encrypted = 13; | ||
| // The list of tags | ||
| repeated string tags = 14; | ||
| // index of the community's shard within the Status shard cluster | ||
| uint16 relay_shard_index = 15 | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Maybe show the diff here so it is clear that the relay_shard_index is being added?
There was a problem hiding this comment.
Agreed, the change should be explicit. Added a clarification in 00dcaab
wdyt?
(Imo, the protobuf should be copyable and not a diff.)
| ```protobuf | ||
|
|
||
| syntax = "proto3"; | ||
|
|
||
| message CommunityDescription { | ||
| // The Lamport timestamp of the message | ||
| uint64 clock = 1; | ||
| // A mapping of members in the community to their roles | ||
| map<string,CommunityMember> members = 2; | ||
| // The permissions of the Community | ||
| CommunityPermissions permissions = 3; | ||
| // The metadata of the Community | ||
| ChatIdentity identity = 5; | ||
| // A mapping of chats to their details | ||
| map<string,CommunityChat> chats = 6; | ||
| // A list of banned members | ||
| repeated string ban_list = 7; | ||
| // A mapping of categories to their details | ||
| map<string,CommunityCategory> categories = 8; | ||
| // The admin settings of the Community | ||
| CommunityAdminSettings admin_settings = 10; | ||
| // If the community is encrypted | ||
| bool encrypted = 13; | ||
| // The list of tags | ||
| repeated string tags = 14; | ||
| // index of the community's shard within the Status shard cluster | ||
| uint16 relay_shard_index = 15 | ||
| } | ||
| ``` |
There was a problem hiding this comment.
syntax = "proto3";
message CommunityDescription {
// The Lamport timestamp of the message
uint64 clock = 1;
// A mapping of members in the community to their roles
map<string,CommunityMember> members = 2;
// The permissions of the Community
CommunityPermissions permissions = 3;
// The metadata of the Community
ChatIdentity identity = 5;
// A mapping of chats to their details
map<string,CommunityChat> chats = 6;
// A list of banned members
repeated string ban_list = 7;
// A mapping of categories to their details
map<string,CommunityCategory> categories = 8;
// The admin settings of the Community
CommunityAdminSettings admin_settings = 10;
// If the community is encrypted
bool encrypted = 13;
// The list of tags
repeated string tags = 14;
// index of the community's shard within the Status shard cluster
+ uint16 relay_shard_index = 15
}
There was a problem hiding this comment.
You could add an empty line before line 129 to separate the new field from other fields.
| ```protobuf | ||
|
|
||
| syntax = "proto3"; | ||
|
|
||
| message CommunityDescription { | ||
| // The Lamport timestamp of the message | ||
| uint64 clock = 1; | ||
| // A mapping of members in the community to their roles | ||
| map<string,CommunityMember> members = 2; | ||
| // The permissions of the Community | ||
| CommunityPermissions permissions = 3; | ||
| // The metadata of the Community | ||
| ChatIdentity identity = 5; | ||
| // A mapping of chats to their details | ||
| map<string,CommunityChat> chats = 6; | ||
| // A list of banned members | ||
| repeated string ban_list = 7; | ||
| // A mapping of categories to their details | ||
| map<string,CommunityCategory> categories = 8; | ||
| // The admin settings of the Community | ||
| CommunityAdminSettings admin_settings = 10; | ||
| // If the community is encrypted | ||
| bool encrypted = 13; | ||
| // The list of tags | ||
| repeated string tags = 14; | ||
| // index of the community's shard within the Status shard cluster | ||
| uint16 relay_shard_index = 15 | ||
| } | ||
| ``` |
There was a problem hiding this comment.
You could add an empty line before line 129 to separate the new field from other fields.
| Infrastructure nodes are especially important for providing connectivity in the roll-out phase. | ||
|
|
||
| Infrastructure nodes are not limited to Status fleets, or nodes run by community owners. | ||
| Anybody can run infrastructure nodes. |
There was a problem hiding this comment.
In the context of Status MVP, to ensure good UX, one need will need to run a node with postgres and some minimal requirements. Should we mention this in the RFC?
This PR addresses vacp2p/research#160