mirror of
https://github.com/logos-messaging/specs.git
synced 2026-01-02 14:13:06 +00:00
Fix issues in OpChan.md
This commit is contained in:
Jimmy Debe
GitHub
parent
4ebec4b4f3
commit
b73d5fff41
@ -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
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user