diff --git a/standards/application/OpChan.md b/standards/application/OpChan.md index 4e4e5ad..0933beb 100644 --- a/standards/application/OpChan.md +++ b/standards/application/OpChan.md @@ -16,16 +16,16 @@ OpChan is a decentralized forum application built on the Waku protocol. ## Background -In a decentralized forum content is hosted on multiple nodes, -making it difficult for user's post to be censorship resistant. +In a decentralized forum, content is hosted on multiple nodes, +making it difficult for a user's post to be censored. Users own their post data, so data cannot be removed by a third party, and forum boards will not rely on moderators remaining active. OpChan is a web application hosted by some party through a web server. -The content being published by users are not stored by the server, +The content being published by users is not stored by the server, but by distributing the messages peer to peer. OpChan supports ephemeral anonymous web sessions, -supporting a locally generated ED25519 keypairs for identity and +supporting a locally generated ED25519 key pair for identity and signing. Wallet-backed identities, identity key delegation, and content stored locally while distributing messages using the [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) protocol. @@ -49,40 +49,40 @@ The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL N “OPTIONAL” in this document are to be interpreted as described in [2119](https://www.ietf.org/rfc/rfc2119.txt). OpChan uses the [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) -network for the distribution forum content amongst peers. +network for the distribution of forum content amongst peers. The messages, which are [14/WAKU-MESSAGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md) objects, are cryptographically signed using ED25519 keys generated by the client locally. Users SHOULD use the [19WAKU2-LIGHTPUSH]() protocol to send messages to Waku nodes storing the forum's content. OpChan supports two types of messages, content and control messages. -Content messages are user generated content on the forum. +Content messages are user-generated content on the forum. The message types include the following: -- Channel: Metadata information like name, description, admins of a forum board. +- Channel: Metadata information like name, description, and admins of a forum feed. - Post: User content created within a cell. - Comment: Users reply to a post or another comment. - Vote: To cast upvote or downvote for a post or comment. -- User: Includes username, delegation proofs and identities. -See [identities](#identities) for more information. +- User: Includes username, delegation proofs, and identities. +See the [Identity](#identity) section for more information. - Bookmark: A user bookmarking a post or comment. Control messages consist of the user activity/interactions on the forum. -This includes the manage of the current forum state, +This includes the management of the current forum state, permissions, and moderations. The message types include the following: - Create Channel: The initial event of creating a new channel within the forum. - Delegation Events: Channel admins granting or revoking channel rights. -- Moderation Events: Channel admins able to hide, remove and +- Moderation Events: Channel admins are able to hide, remove, and pin/unpin a post or comment. - Also can promote new admins and change the ownership of a channel. + Also, it can promote new admins and change the ownership of a channel. ### Message Format Message routing and discovery are handled by [23/WAKU2-TOPICS](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/23/topics.md). -Each content are assigned a `pubsub_topic` that clients MUST subscribe to discovery messages of from the channel. +Each content is assigned a `pubsub_topic` that clients MUST subscribe to discovery messages from the channel. All messages transmitted over the Waku network MUST include the following envelope fields: @@ -107,20 +107,20 @@ Signing Flow: 1. Serialize `body` fields in stable key order. 2. Construct signing bytes with: `type`, `timestamp`, `author` and `body`. -3. Sign with the user's cryptograhic keys for the session. +3. Sign with the user's cryptographic keys for the session. - channel admin -### Identities +### Identity There are two types of identities for users, anonymous session and wallet delegation. A wallet delegation MAY be an ENS(Ethereum Name Service) verified user. -An anonymous session generates an ed25519 keypair locally with the client. +An anonymous session generates an Ed25519 keypair locally with the client. The key is used to sign all messages and a username MAY choose a username attached to the post or comments. -An anonymous user SHOULD NOT granted an admin role, -create moderation events or create a channel. +An anonymous user SHOULD NOT be granted an admin role, +create moderation events, or create a channel. A wallet delegation uses the user's wallet private key to sign a delegation message, the `delegationProof`. @@ -132,7 +132,7 @@ without the need for repeated wallet prompts requesting to sign. #### Delegation Flow: -1. The client generates a new `browserKey`, which is a ED25519 keypair. +1. The client generates a new `browserKey`, which is an Ed25519 keypair. 2. The client generates a delegation request to authorize `browserKey` to sign. 3. The user's wallet signs the delegation request and returns a `delegationProof` with an expiration timestamp, `expiry`. @@ -156,41 +156,41 @@ The moderation types include: - `CHANGE_OWNERSHIP` : Change the `author` of a post or comment. Moderation messages MUST be signed by an admin, -which recognized `author` of the channel. +which recognized the `author` of the channel. Clients SHOULD validate the admin before applying moderation events locally. ### Relevance Score A post can gain better visibility on the forum channel and the forum's search through the content relevance score. -Clients with verified wallet identities MUSt be favored when anonymous session. +Clients with verified wallet identities MUST be favored over an anonymous session identity. There are a few RECCOMENDED areas that collect points when calculating the relevance score of a post: -Basic scores include the activites that each user is albe to engage in. +Basic points include the activities that each user is able to engage in. - A channel has a score value of 15 - Each post within a channel has a score value of 10 -- A base value if comments are present within a post boost the relevance score by a value of 5 +- A base value if comments are present within a post boosts the relevance score by a value of 5 -Engagement score include different user activites for each post or comment. +Engagement points include the different user activities for each post or comment. - Each wallet delegation upvote adds a score value of 1. -- Each comment indiviual comment adds a score value of 0.5. -- The total number of of post multipled by 0.5. -The total number of upvotes multiped by 0.1. +- Each individual comment adds a score value of 0.5. +- The total number of posts multiplied by 0.5. +The total number of upvotes multiplied by 0.1. These two values are added together. -For identity verification scores, -participants of post or comment that use wallet-based identities, +For identity verification points, +participants of posts or comments that use wallet-based identities, including an optional ENS, the score is boosted over the anonymous identities. If a participant has a verified ENS and a verified connected wallet, -only the ENS multipler SHOULD be applied. +only the ENS multiplier SHOULD be applied. -- Participants of who has a verified ENS name gains a value multiplier of 1.25(25%). +- Participants who have a verified ENS name gain a value multiplier of 1.25(25%). - For wallet connect participant the multiplier is 1.1(10%). -- For verified upvote participants the multipler is 0.1. +- For verified upvote participants the multiplier is 0.1. - For verified comment participants the multiplier is 0.05. There is a time decay that reduces the relevance score over time. @@ -211,9 +211,12 @@ $$ 1, & \text{otherwise} \end{cases} $$ -Total +Below is the final relevance score based on the RECCOMENDED points above: -RelevanceScore = (basic + engagement + verifiedUpvote) * (1 + verifyIdentity) * timeDecay * moderationPenalty +$$ +\text{Total RelevanceScore} = (\text{basic} + \text{engagement} + \text{verifiedUpvote}) +\cdot (1 + \text{verifyIdentity}) \cdot \text{timeDecay} \cdot \text{moderationPenalty} +$$ ## Copyright