9.0 KiB
| title | name | status | category | tags | editor | contributors | |
|---|---|---|---|---|---|---|---|
| OP-CHAN | OpChan Decentralized Forum | raw | Standards Track | waku |
|
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 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
Postor otherComment(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.
OpChan uses the 10/WAKU2 network for the distribution forum content amongst peers. The messages, which are 14/WAKU-MESSAGE 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 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.
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:
{
"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:
- Serialize
bodyfields in stable key order. - Construct signing bytes with:
type,timestamp,authorandbody. - 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:
- The client generates a new
browserKey, which is a ED25519 keypair. - The client generates a delegation request to authorize
browserKeyto sign. - The user's wallet signs the delegation request and
returns a
delegationProofwith an expiration timestamp,expiry. - The client stores the
delegationProof,browserKey, andexpiry.
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 aPINfrom a post feed or comment thread.CHANGE_OWNERSHIP: Change theauthorof 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.