Skip to content

Commit

Permalink
Merge branch 'main' into bridge-update
Browse files Browse the repository at this point in the history
  • Loading branch information
kaiserd authored Jan 10, 2025
2 parents b5518aa + dc7497a commit 0e3ec19
Show file tree
Hide file tree
Showing 29 changed files with 764 additions and 105 deletions.
Binary file removed .DS_Store
Binary file not shown.
1 change: 1 addition & 0 deletions .github/workflows/.gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
.DS_Store
6 changes: 2 additions & 4 deletions .github/workflows/.markdownlint.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,4 @@
{
"MD013": {
"tables": false,
"code_blocks" : false
}
"MD013": false,
"MD024": false
}
Binary file removed nomos/.DS_Store
Binary file not shown.
Binary file removed status/.DS_Store
Binary file not shown.
73 changes: 59 additions & 14 deletions status/56/communities.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,7 @@ description: Status Communities allow multiple users to communicate in a discuss
editor: Aaryamann Challani <[email protected]>
contributors:
- Andrea Piana <[email protected]>
- Prem Chaitanya Prathi <[email protected]>
---

## Abstract
Expand Down Expand Up @@ -306,10 +307,31 @@ message CommunityDescription {

Note: The usage of the clock is described in the [Clock](#clock) section.

### Pubsub topic or shard usage

Status network uses static sharding as explained in [Relay Sharding](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md#static-sharding)

All communities by default use the default shard `32` for most of their messages and use shard `64` for a few specific messages like community event messages.

A community can be assigned a dedicated shard (in the range of 1-1024) after creation in which case all messages of the community are sent on that specific shard except for the community event messages.

### Content topic level encryption

-a universal chat identifier is used for all community chats.
<!-- Don't enforce any constraints on the unique id generation -->

All messages are encrypted before they are handed over to waku ir-respective of the encryption explained above.
All community chats are encrypted using a symmetric key generated from universal chat id using pbkdf2.

```js
symKey = pbkdf2(password:universalChatID, salt:nil, iteration-count:65356,key-length:32, hash-func: random-sha256)
```

### Content topic usage

"Content topic" refers to the field in [14/WAKU2-MESSAGE](../../waku/standards/core/14/message.md/#message-attributes),
further elaborated in [10/WAKU2](../../waku/standards/core/10/waku2.md/#overview-of-protocol-interaction).
The content-topic usage follows the guidelines specified at [23/topics](../../waku/informational/23/topics.md#content-topic-usage-guidelines)

#### Advertising a Community

Expand All @@ -334,16 +356,15 @@ for i = 0; i < topicLen; i++ {
contentTopic = "/waku/1/0x" + topic + "/rfc26"
```

#### Community channels/chats
#### Community event messages

The unique identifier for a community channel/chat is the chat id.
<!-- Don't enforce any constraints on the unique id generation -->
The content topic, that Community channels/chats uses,
MUST be the hex-encoded keccak-256 hash of the public key of the community
concatenated with the chat id.
Message such as community description
MUST be sent to the content topic derived from the public key of the community.
The content topic
MUST be the hex-encoded keccak-256 hash of the public key of the community.

```js
hash = hex(keccak256(encodeToHex(compressedPublicKey + chatId)))
hash = hex(keccak256(encodeToHex(publicKey)))

topicLen = 4
if len(hash) < topicLen {
Expand All @@ -357,15 +378,16 @@ for i = 0; i < topicLen; i++ {
contentTopic = "/waku/1/0x" + topic + "/rfc26"
```

#### Community event messages
#### Community Requests

Requests to leave, join, kick and ban, as well as key exchange messages, MUST be sent to the content topic derived from the public key of the community on the common shard.

Requests to leave, join, kick and ban, as well as key exchange messages,
MUST be sent to the content topic derived from the public key of the community.
The content topic
MUST be the hex-encoded keccak-256 hash of the public key of the community.
MUST be the keccak-256 hash of hex-encoded universal chat id (public key appended with fixed string) of the community omitting the first 2 bytes.

```js
hash = hex(keccak256(encodeToHex(publicKey)))
universalChatId = publicKey+"-memberUpdate"
hash = hex(keccak256(encodeToHex(universalChatId))[2:])

topicLen = 4
if len(hash) < topicLen {
Expand All @@ -379,6 +401,30 @@ for i = 0; i < topicLen; i++ {
contentTopic = "/waku/1/0x" + topic + "/rfc26"
```

#### Community Shard Info

If a community is assigned a dedicated shard then the shard info for that community is published on a content topic derived from a specialized key. This is useful for users joining the new community so that they can subscribe to this specific content topic.

```js
chatID = publicKey+"-shard-info"
hash = hex(keccak256(encodeToHex(chatID))[2:])

topicLen = 4
if len(hash) < topicLen {
topicLen = len(hash)
}
var topic [4]byte
for i = 0; i < topicLen; i++ {
topic[i] = hash[i]
}

contentTopic = "/waku/1/0x" + topic + "/rfc26"
```

#### Community channels/chats

All channels/chats shall use a single content-topic which is derived from a universal chat id irrespective of their individual unique chat ids.

### Community Management

The flows for Community management are as described below.
Expand All @@ -391,8 +437,7 @@ according to the wire format "CommunityDescription".
3. The Community owner publishes the Community metadata on a content topic
derived from the public key of the Community.
the Community metadata SHOULD be encrypted with the public key of the Community.
<!-- TODO: Verify this-->
The Community metadata MAY be sent during fixed intervals,
The Community metadata is sent during fixed intervals,
to ensure that the Community metadata is available to members.
The Community metadata SHOULD be sent every time the Community metadata is updated.
4. The Community owner MAY advertise the Community out of band,
Expand Down
36 changes: 18 additions & 18 deletions status/raw/simple-scaling.md
Original file line number Diff line number Diff line change
Expand Up @@ -63,14 +63,14 @@ efficient way will be part of a future document.
Sharding the [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md)
network is an integral part of scaling the Status app.

[51/WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)
[WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)
specifies shards clusters, which are sets of `1024` shards
(separate pubsub mesh networks).
Content topics specified by application protocols can be distributed over these shards.
The Status app protocols are assigned to shard cluster `16`,
as defined in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md).
as defined in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md).

[WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)
[WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)
specifies three sharding methods.
This document uses *static sharding*,
which leaves the distribution of content topics to application protocols,
Expand All @@ -88,7 +88,7 @@ The 1024 shards within the main Status shard cluster are allocated as follows.
| 768 - 895 | 1:1 chat |
| 896 - 1023 | media and control msgs |

Shard indices are mapped to pubsub topic names as follows (specified in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)).
Shard indices are mapped to pubsub topic names as follows (specified in [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)).

`/waku/2/rs/<cluster_id>/<shard_number>`

Expand Down Expand Up @@ -154,7 +154,7 @@ message CommunityDescription {
}
```

> *Note*: Currently, Status app has allocated shared cluster `16` in [52/WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md).
> *Note*: Currently, Status app has allocated shared cluster `16` in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md).
Status app could allocate more shard clusters, for instance to establish a test net.
We could add the shard cluster index to the community description as well.
The recommendation for now,
Expand All @@ -168,7 +168,7 @@ Status communities can be mapped to shards in two ways: static, and owner-based.

With static mapping,
communities are assigned a specific shard index within the Status shard cluster.
This mapping is similar in nature to the shard cluster allocation in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md).
This mapping is similar in nature to the shard cluster allocation in [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md).
Shard indices allocated in that way are in the range `16 - 127`.
The Status CC community uses index `16`
(not to confuse with shard cluster index `16`, which is the Status shard cluster).
Expand Down Expand Up @@ -310,7 +310,7 @@ Light protocols comprise
* [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md) for sending messages
* [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md)
for requesting messages with specific attributes
* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange.md)
* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md)
for discovering peers

## Waku Archive
Expand All @@ -333,7 +333,7 @@ In fact, the archive service can be offered by infrastructure nodes.

## Discovery

Shard discovery is covered by [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md).
Shard discovery is covered by [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md).
This allows the Status app to abstract from the discovery process and
simply address shards by their index.

Expand All @@ -344,7 +344,7 @@ this document suggests using [libp2p rendezvous](https://github.com/libp2p/specs
Nodes can check whether they are behind a restrictive NAT using the
[libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md).

> *Note:* The following will move into [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md),
> *Note:* The following will move into [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md),
or [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md):
Nodes behind restrictive NATs SHOULD not announce their publicly unreachable address
via [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md) discovery.
Expand All @@ -369,9 +369,9 @@ functionality offered by the libp2p circuit relay protocols, and
to upgrade to a direct connection.

Nodes that do not announce themselves at all and only plan to use light protocols,
MAY use rendezvous discovery instead of or along-side [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange.md).
MAY use rendezvous discovery instead of or along-side [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md).
For these nodes, rendezvous and
[WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange.md)
[WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md)
offer the same functionality,
but return node sets sampled in different ways.
Using both can help increasing connectivity.
Expand Down Expand Up @@ -401,7 +401,7 @@ The string conversion SHOULD remove leading zeros.
field is of type string, a more efficient byte encoding is not utilized.

Registering shard 2 in the Status shard cluster (with shard cluster index 16,
see [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md),
see [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md),
the register query would look like

```rs
Expand Down Expand Up @@ -601,7 +601,7 @@ It could be rate-limited with RLN.

This document makes several trade-offs to privacy and anonymity.
Todo: elaborate.
See [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/waku-RFC/informational/adversarial-models.md)
See [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/master/informational/adversarial-models.md)
for information on Waku Anonymity.

## Copyright
Expand All @@ -614,12 +614,12 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
* [55/STATUS-1TO1-CHAT](../55/1to1-chat.md)
* [23/WAKU2-TOPICS](../../waku/informational/23/topics.md)
* [11/WAKU2-RELAY](../../waku/standards/core/11/relay.md)
* [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/relay-sharding.md)
* [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/waku-RFC/informational/relay-static-shard-alloc.md)
* [WAKU2-RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md)
* [WAKU2-RELAY-STATIC-SHARD-ALLOC](https://github.com/waku-org/specs/blob/master/informational/relay-static-shard-alloc.md)
* [30/ADAPTIVE-NODES](../../waku/informational/30/adaptive-nodes.md)
* [19/WAKU2-LIGHTPUSH](../../waku/standards/core/19/lightpush.md)
* [12/WAKU2-FILTER](../../waku/standards/core/12/filter.md)
* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/peer-exchange/peer-exchange.md)
* [WAKU2-PEER-EXCHANGE](https://github.com/waku-org/specs/blob/master/standards/core/peer-exchange.md)
* [13/WAKU2-STORE](../../waku/standards/core/13/store.md)
* [libp2p rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md)
* [libp2p AutoNAT protocol](https://github.com/libp2p/specs/blob/master/autonat/README.md)
Expand All @@ -629,9 +629,9 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
* [DCUtR](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md)
* [scoring](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators)
* [Circuit Relay](https://docs.libp2p.io/concepts/nat/circuit-relay/)
* [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/waku-RFC/informational/adversarial-models.md)
* [WAKU2-ADVERSARIAL-MODELS](https://github.com/waku-org/specs/blob/master/informational/adversarial-models.md)

## Informative

* [Circuit Relay](https://docs.libp2p.io/concepts/nat/circuit-relay/)
* [WAKU2-ENR](https://github.com/waku-org/specs/blob/waku-RFC/standards/core/enr.md)
* [WAKU2-ENR](https://github.com/waku-org/specs/blob/master/standards/core/enr.md)
Loading

0 comments on commit 0e3ec19

Please sign in to comment.