From 1ae8c0d5704606214e45603a2e214d73ddbd5bc6 Mon Sep 17 00:00:00 2001 From: Jimmy Debe <91767824+jimstir@users.noreply.github.com> Date: Thu, 11 Dec 2025 18:15:54 -0500 Subject: [PATCH 1/4] Create op_Chan rfc --- standards/application/op-chan.md | 148 +++++++++++++++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 standards/application/op-chan.md diff --git a/standards/application/op-chan.md b/standards/application/op-chan.md new file mode 100644 index 0000000..26f90a7 --- /dev/null +++ b/standards/application/op-chan.md @@ -0,0 +1,148 @@ +--- +title: OP-CHAN +name: OpChan Decentralized Forum +status: raw +category: Standards Track +tags: waku +editor: +contributors: + - Jimmy Debe +--- + +## Abstract + +This document specifies the architecture of OpChan. +OpChan is a decentralized forum application built on the Waku protocol. + + +## Background + +OpChan supports ephemeral anonymous sessions and wallet- +backed identities, identity key delegation, and stores content locally +while distributing messages over the Waku network. +All user data persists locally +and syncs via Waku messages to peers. +- Authentication and user publishing are provided either by ed25519 stored in the client or +wallet signature. + +## Terminology + +- Forum: A discussion board (analogous to a forum or channel) that groups + posts and moderation controls. +- Post: Top-level user content created within a forum. +- Comment: A reply to a `Post` or other `Comment` (threaded discussion). +- Participant: Any actor able to publish or consume messages (anonymous or + wallet-backed). +- Anonymous session: A browser-generated ed25519 keypair used as + identity for a user without a wallet. + + +## Specification + +The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, +“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and +“OPTIONAL” in this document are to be interpreted as described in [2119](https://www.ietf.org/rfc/rfc2119.txt). + +OpChan uses [10/WAKU](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) +as the transport for peer-to-peer distribution of messages, +as [14/WAKU-MESSAGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md). +The messages are cryptographically signed using ed25519 keys generated locally in the broswer window. +Wallet users MAY create a token signed by the wallet's private key. + +OpChan messages fall into two broad classes: + +1. Content messages +2. Control messages + +Message routing and +discovery are handled by [23/WAKU2-TOPICS](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/23/topics.md). + +### Message Format (high-level) + +All messages transmitted over the Waku network MUST include the following envelope fields: + +``` js + +id: string +type: enum { CELL_CREATED, POST_CREATED, COMMENT_CREATED, VOTE, BOOKMARK, MODERATION, DELEGATION } +timestamp: uint64 +author: string // author public key or wallet address +signature: bytes // ed25519 signature of the canonical serialized body +delegationProof?: bytes // optional wallet signature authorizing the browser key +body: object // + +``` + +Rules for signing: + +1. Serialize `body` fields in stable key order (JSON canonical form or + protobuf deterministic encoding). +2. Construct signing bytes with: `type`, `timestamp`, `author` +3. Sign with the browser key registered for the session. + +OpChan MUST verify the `signature` against the `author` and, +when present, verify `delegationProof`. + +### Identity + +There are two types of identity options, +anonymous session and wallet delegation. +An anonymous session generates an ed25519 keypair locally with the client. +The key is used to sign all messages. +- The session may include a Call Sign. *** +A wallet delegation connects a user's wallet to OpChan. +The wallet produces a short-lived delegation signature as the key. +That delegation proof is attached to each message and +verified is by peers in the network. + +#### Delegation flow: + +1. Client generates a new ed25519 keypair and a delegation request. +2. Wallet signs the delegation request and returns a `delegationProof` with an + expiration `timestamp`. +3. The client stores the `delegationProof`, `browserKey`, +and `expiry`. +The `delegationProof` SHOULD be included in outgoing messages until `expiry`. + +- `delegationProof` verification, +verify the wallet signature over the delegation request matches the wallet public key, +the `author` public key in messages + +### Moderation & Permissions + + +A post has metadata (id, name, +creator, admins, admins can moderate (hide, remove, or penalize content within the forum). + +Moderation events are control messages with types like `MODERATION_ACTION`: + +- action: enum { HIDE, REMOVE, PIN, UNPIN, CHANGE_OWNERSHIP }, + +Moderation messages MUST be signed by a recognized post admin. +Clients MUST validate the admin membership before applying moderation actions locally. + + +OpChan + +- posts +- comments +- votes +- users (identities, call signs, delegation proofs) +- bookmarks +- moderations + +Incoming Waku messages are validated + +If delegation is revoked, +peers should ignore subsequent messages from the revoked delegation key. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +## References +- [10/WAKU](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) +- [14/WAKU-MESSAGES](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md) +- + + From 4ebec4b4f34b6df3194adc05e1f8f1c07cca18cb Mon Sep 17 00:00:00 2001 From: Jimmy Debe <91767824+jimstir@users.noreply.github.com> Date: Thu, 18 Dec 2025 19:50:49 -0500 Subject: [PATCH 2/4] update OpChan.md --- standards/application/OpChan.md | 226 +++++++++++++++++++++++++++++++ standards/application/op-chan.md | 148 -------------------- 2 files changed, 226 insertions(+), 148 deletions(-) create mode 100644 standards/application/OpChan.md delete mode 100644 standards/application/op-chan.md diff --git a/standards/application/OpChan.md b/standards/application/OpChan.md new file mode 100644 index 0000000..4e4e5ad --- /dev/null +++ b/standards/application/OpChan.md @@ -0,0 +1,226 @@ +--- +title: OP-CHAN +name: OpChan Decentralized Forum +status: raw +category: Standards Track +tags: waku +editor: +contributors: + - Jimmy Debe +--- + +## Abstract + +This document specifies the architecture of OpChan. +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. +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, +but by distributing the messages peer to peer. +OpChan supports ephemeral anonymous web sessions, +supporting a locally generated ED25519 keypairs 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. + +- WAKU-LIGHTPUSH + +## Terminology + +- Cell: A discussion board or channel that hosts posts and moderation controls. +- Post: User content created within a forum. +- Comment: A reply to a `Post` or other `Comment` (threaded discussion). +- Participant: Any user able to publish or consume messages (anonymous or + wallet-backed). +- Anonymous session: A client-generated ed25519 keypair used as + identity for a user without a wallet identity. + +## Specification + +The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, +“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and +“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. +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. +The message types include the following: + +- Channel: Metadata information like name, description, admins of a forum board. +- 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. +- 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, +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 + pin/unpin a post or comment. + Also 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. + +All messages transmitted over the Waku network MUST include the following envelope fields: + +``` js +{ + "id": "string", + "type": "CELL_CREATED | POST_CREATED | COMMENT_CREATED | VOTE | BOOKMARK | MODERATION | DELEGATION", + "timestamp": "uint64" + "author": "string" // author public key or wallet address + "signature": "bytes" // ed25519 signature of the canonical serialized body + "delegationProof": "bytes" // optional wallet signature authorizing the browser key + "body": object // The message content +} + +``` + +Every message SHOULD be signed using ED25519 keys from the publishing user. +Clients SHOULD verify the signature against the `author` public key and, +when present, verify `delegationProof`. + +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. + +- channel admin + +### Identities + +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. +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. + +A wallet delegation uses the user's wallet private key to sign a delegation message, +the `delegationProof`. +The `delegationProof` SHOULD be a short-lived message, +RECCOMENDED a few minutes to a few hours. +Once a `delegationProof` is generated, +the client SHOULD be able to sign messages, +without the need for repeated wallet prompts requesting to sign. + +#### Delegation Flow: + +1. The client generates a new `browserKey`, which is a 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`. +4. The client stores the `delegationProof`, `browserKey`, +and `expiry`. + +A `delegrationProof` could become revoked by the wallet owner or +after the `expiry` time. +If a wallet delegation is revoked, +clients SHOULD ignore subsequent messages from the revoked delegation key. + +### Moderation & Permissions + +A post MAY be have moderation message types assigned by the channel admin. +The moderation types include: + +- `HIDE` : To hide a post or comment. +- `REMOVE` : To permanently remove a post or comment. +- `PIN` : To pin a post to the top of a channel feed or pin a comment to the top of a thread. +- `UNPIN` : To remove a `PIN` from a post feed or comment thread. +- `CHANGE_OWNERSHIP` : Change the `author` of a post or comment. + +Moderation messages MUST be signed by an admin, +which recognized `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. + +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. + +- 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 + +Engagement score include different user activites 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. +These two values are added together. + +For identity verification scores, +participants of post or comment 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. + +- Participants of who has a verified ENS name gains 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 comment participants the multiplier is 0.05. + +There is a time decay that reduces the relevance score over time. +The older a post or comment was made the lower its score. + +$$ +\text{timeDecayMultiplier} = e^{-\lambda \cdot \text{daysOld}} +$$ + +Where $$\( -\lambda \)$$ is the time-decay rate per day. + +There SHOULD be a moderation penalty that reduces the score when a post or +comment is moderated with a value of 0.5(50%). +This penalty is applied once a post is `HIDDEN`, `REMOVED` or `FLAGGED` by a moderator. + +$$ +\text{moderationPenalty} = \begin{cases} 0.5, & \text{if moderated} \\ +1, & \text{otherwise} \end{cases} +$$ + +Total + +RelevanceScore = (basic + engagement + verifiedUpvote) * (1 + verifyIdentity) * timeDecay * moderationPenalty + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +## References +- [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) +- [14/WAKU-MESSAGES](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md) +- [23/WAKU2-TOPICS](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/23/topics.md) +- diff --git a/standards/application/op-chan.md b/standards/application/op-chan.md deleted file mode 100644 index 26f90a7..0000000 --- a/standards/application/op-chan.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: OP-CHAN -name: OpChan Decentralized Forum -status: raw -category: Standards Track -tags: waku -editor: -contributors: - - Jimmy Debe ---- - -## Abstract - -This document specifies the architecture of OpChan. -OpChan is a decentralized forum application built on the Waku protocol. - - -## Background - -OpChan supports ephemeral anonymous sessions and wallet- -backed identities, identity key delegation, and stores content locally -while distributing messages over the Waku network. -All user data persists locally -and syncs via Waku messages to peers. -- Authentication and user publishing are provided either by ed25519 stored in the client or -wallet signature. - -## Terminology - -- Forum: A discussion board (analogous to a forum or channel) that groups - posts and moderation controls. -- Post: Top-level user content created within a forum. -- Comment: A reply to a `Post` or other `Comment` (threaded discussion). -- Participant: Any actor able to publish or consume messages (anonymous or - wallet-backed). -- Anonymous session: A browser-generated ed25519 keypair used as - identity for a user without a wallet. - - -## Specification - -The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, -“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and -“OPTIONAL” in this document are to be interpreted as described in [2119](https://www.ietf.org/rfc/rfc2119.txt). - -OpChan uses [10/WAKU](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) -as the transport for peer-to-peer distribution of messages, -as [14/WAKU-MESSAGE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md). -The messages are cryptographically signed using ed25519 keys generated locally in the broswer window. -Wallet users MAY create a token signed by the wallet's private key. - -OpChan messages fall into two broad classes: - -1. Content messages -2. Control messages - -Message routing and -discovery are handled by [23/WAKU2-TOPICS](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/23/topics.md). - -### Message Format (high-level) - -All messages transmitted over the Waku network MUST include the following envelope fields: - -``` js - -id: string -type: enum { CELL_CREATED, POST_CREATED, COMMENT_CREATED, VOTE, BOOKMARK, MODERATION, DELEGATION } -timestamp: uint64 -author: string // author public key or wallet address -signature: bytes // ed25519 signature of the canonical serialized body -delegationProof?: bytes // optional wallet signature authorizing the browser key -body: object // - -``` - -Rules for signing: - -1. Serialize `body` fields in stable key order (JSON canonical form or - protobuf deterministic encoding). -2. Construct signing bytes with: `type`, `timestamp`, `author` -3. Sign with the browser key registered for the session. - -OpChan MUST verify the `signature` against the `author` and, -when present, verify `delegationProof`. - -### Identity - -There are two types of identity options, -anonymous session and wallet delegation. -An anonymous session generates an ed25519 keypair locally with the client. -The key is used to sign all messages. -- The session may include a Call Sign. *** -A wallet delegation connects a user's wallet to OpChan. -The wallet produces a short-lived delegation signature as the key. -That delegation proof is attached to each message and -verified is by peers in the network. - -#### Delegation flow: - -1. Client generates a new ed25519 keypair and a delegation request. -2. Wallet signs the delegation request and returns a `delegationProof` with an - expiration `timestamp`. -3. The client stores the `delegationProof`, `browserKey`, -and `expiry`. -The `delegationProof` SHOULD be included in outgoing messages until `expiry`. - -- `delegationProof` verification, -verify the wallet signature over the delegation request matches the wallet public key, -the `author` public key in messages - -### Moderation & Permissions - - -A post has metadata (id, name, -creator, admins, admins can moderate (hide, remove, or penalize content within the forum). - -Moderation events are control messages with types like `MODERATION_ACTION`: - -- action: enum { HIDE, REMOVE, PIN, UNPIN, CHANGE_OWNERSHIP }, - -Moderation messages MUST be signed by a recognized post admin. -Clients MUST validate the admin membership before applying moderation actions locally. - - -OpChan - -- posts -- comments -- votes -- users (identities, call signs, delegation proofs) -- bookmarks -- moderations - -Incoming Waku messages are validated - -If delegation is revoked, -peers should ignore subsequent messages from the revoked delegation key. - -## Copyright - -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). - -## References -- [10/WAKU](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) -- [14/WAKU-MESSAGES](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md) -- - - From b73d5fff413db09fe5d431eaee50d50ac38be097 Mon Sep 17 00:00:00 2001 From: Jimmy Debe <91767824+jimstir@users.noreply.github.com> Date: Sun, 21 Dec 2025 20:40:19 -0500 Subject: [PATCH 3/4] Fix issues in OpChan.md --- standards/application/OpChan.md | 71 +++++++++++++++++---------------- 1 file changed, 37 insertions(+), 34 deletions(-) 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 From de0720a38c4c62d500c2a02e82ee6e975798da7c Mon Sep 17 00:00:00 2001 From: Jimmy Debe <91767824+jimstir@users.noreply.github.com> Date: Mon, 22 Dec 2025 18:07:37 -0500 Subject: [PATCH 4/4] Fixes op-chan --- standards/application/OpChan.md | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/standards/application/OpChan.md b/standards/application/OpChan.md index 0933beb..12cc8a1 100644 --- a/standards/application/OpChan.md +++ b/standards/application/OpChan.md @@ -34,7 +34,7 @@ content stored locally while distributing messages using the [10/WAKU2](https:// ## Terminology -- Cell: A discussion board or channel that hosts posts and moderation controls. +- Channel: A discussion board or channel that hosts posts and moderation controls. - Post: User content created within a forum. - Comment: A reply to a `Post` or other `Comment` (threaded discussion). - Participant: Any user able to publish or consume messages (anonymous or @@ -51,16 +51,16 @@ The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL N OpChan uses the [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) 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. +are cryptographically signed using Ed25519 keys generated by the client locally. +Users SHOULD use the [19WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) 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. The message types include the following: -- Channel: Metadata information like name, description, and admins of a forum feed. -- Post: User content created within a cell. +- Channel: Includes the metadata information like name, description, and admins of a forum feed. +- Post: User content created within a channel. - 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. @@ -89,17 +89,17 @@ All messages transmitted over the Waku network MUST include the following envelo ``` js { "id": "string", - "type": "CELL_CREATED | POST_CREATED | COMMENT_CREATED | VOTE | BOOKMARK | MODERATION | DELEGATION", + "type": "CHANNEL_CREATED | POST_CREATED | COMMENT_CREATED | VOTE | BOOKMARK | MODERATION | DELEGATION", "timestamp": "uint64" "author": "string" // author public key or wallet address - "signature": "bytes" // ed25519 signature of the canonical serialized body + "signature": "bytes" // ed25519 signature "delegationProof": "bytes" // optional wallet signature authorizing the browser key "body": object // The message content } ``` -Every message SHOULD be signed using ED25519 keys from the publishing user. +Every message SHOULD be signed using `signature` owned by the publishing user. Clients SHOULD verify the signature against the `author` public key and, when present, verify `delegationProof`. @@ -107,9 +107,7 @@ 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 cryptographic keys for the session. - -- channel admin +3. Sign with the user's cryptographic keys, `signature`, for the session. ### Identity @@ -122,10 +120,10 @@ a username MAY choose a username attached to the post or comments. 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`. +A wallet delegation is a user blockchain wallet's private key used to sign a message, +which is the `delegationProof`. The `delegationProof` SHOULD be a short-lived message, -RECCOMENDED a few minutes to a few hours. +RECOMMENDED a few minutes to a few hours. Once a `delegationProof` is generated, the client SHOULD be able to sign messages, without the need for repeated wallet prompts requesting to sign. @@ -165,7 +163,7 @@ 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 over an anonymous session identity. -There are a few RECCOMENDED areas that collect points when calculating the relevance score of a post: +There are a few RECOMMENDED areas that collect points when calculating the relevance score of a post: Basic points include the activities that each user is able to engage in. @@ -204,14 +202,14 @@ Where $$\( -\lambda \)$$ is the time-decay rate per day. There SHOULD be a moderation penalty that reduces the score when a post or comment is moderated with a value of 0.5(50%). -This penalty is applied once a post is `HIDDEN`, `REMOVED` or `FLAGGED` by a moderator. +This penalty is applied once a post is `HIDDEN`, `REMOVED` or flagged by users to be reviewed by a moderator. $$ \text{moderationPenalty} = \begin{cases} 0.5, & \text{if moderated} \\ 1, & \text{otherwise} \end{cases} $$ -Below is the final relevance score based on the RECCOMENDED points above: +Below is the final relevance score based on the RECOMMENDED points above: $$ \text{Total RelevanceScore} = (\text{basic} + \text{engagement} + \text{verifiedUpvote}) @@ -224,6 +222,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References - [10/WAKU2](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/10/waku2.md) +- [19WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) - [14/WAKU-MESSAGES](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/14/message.md) - [23/WAKU2-TOPICS](https://github.com/vacp2p/rfc-index/blob/main/waku/informational/23/topics.md) -