Conversation
| 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 key pair for identity and |
There was a problem hiding this comment.
should ED25519 also be a reference link? I seem to recall we had it in one of the previous RFCs.
There was a problem hiding this comment.
Yea I remember this I want to keep the same reference for the Ed25519 through all our specs. I just can't remember what spec had this reference. When I find it, I will update this later. 👍
standards/application/OpChan.md
Outdated
| 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. |
There was a problem hiding this comment.
Be wary of ambiguity - I think we used "channel" somewhere before, when explaining the cell and here it is mentioned as a standalone subject. Cell and channel should be differentiated.
There was a problem hiding this comment.
This was an error, in the codebase a cell is used to define a feed of posts. I decided it would better to name it channel. A cell and channel are the same. I removed any mention of cell now. 👍
standards/application/OpChan.md
Outdated
| "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 |
There was a problem hiding this comment.
Does signature cover the entire signing flow? Here it mentions just body, but below in line 106 it mentions that constructing signing bytes with 4 different fields.
There was a problem hiding this comment.
This is explained in the next statement (updated to be more clear):
"Every message SHOULD be signed using signature owned by the publishing user."
In the signing flow, step 3 creates the signature.
standards/application/OpChan.md
Outdated
| 2. Construct signing bytes with: `type`, `timestamp`, `author` and `body`. | ||
| 3. Sign with the user's cryptographic keys for the session. | ||
|
|
||
| - channel admin |
There was a problem hiding this comment.
Should this be under 4? Looks like there is some missing info.
| - `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. | ||
|
|
There was a problem hiding this comment.
I saw FLAGGED mentioned as well, should it be listed here?
There was a problem hiding this comment.
No, FLAGGED is used by any user identity. I will update this to not confuse a FLAGGED event with a moderation event.
|
Added some review points - also maybe to think about adding Security Considerations and Error Handling. After fixing the above even without those, if we all agree, it can go as a first RAW version. |
|
I see the changes - after the spellchecker workflow is fixed (not sure where it fails), I will approve this one @jimstir . |
|
FYI, it probably doesn't make much sense for me to review this, so I'm trying to get clarity on who to add here: https://discord.com/channels/973324189794697286/1419640127025840219/1458062964752912397 :) |
jm-clius
requested review from
danisharora099
and removed request for
jm-clius
|
hi, @danisharora099 can you please have a look at this or recommend another reviewer ? |
|
Apologies for the delay here. The web implementation for OpChan was deemed deprecated, considering the macro deprecation and reprioritisation of browser platform, org-wide. CC @fryorcraken who might have better visibility into how to move forward. |
fryorcraken
left a comment
fryorcraken
left a comment
There was a problem hiding this comment.
Make it mostly Waku agnostic - apart from content topic usage - and clarify content toic usage.
| “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) |
There was a problem hiding this comment.
This spec can and hence should be Waku agnostic.
|
|
||
| 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 is assigned a `pubsub_topic` that clients MUST subscribe to discovery messages from the channel. |
There was a problem hiding this comment.
Make it mostly Waku agnostic.
Just have a small section "Waku as delivery" and specify how content topics are formed when Waku is used for transport.
There was a problem hiding this comment.
Actually, even content topic definition can be agnostic to Waku, and can be framed as "how to identify messages on the delivery provider".
| 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. |
There was a problem hiding this comment.
The browser/web platform is irrelevant to the spec which should be agnostic to the platform.
6 participants
An rfc for the OpChan Waku web application.