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] 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) -- - -