Greetings operators, please review the proposal below for a first Proof of Concept of a decentralised OpChain.
Goal
The goal of this proposal is to build a Proof of Concept (PoC) for a
version of OpChan that uses Waku and Logos technology stack.
The PoC aims to strengthen privacy, censorship-resistance, and remove the
need for centralized infrastructure.
The PoC can then be used to get feedback from the community, dogfood the tech and influence the direction for a Minimum Viable Product (MVP).
Scope
identification
Users identify themselves using a Bitcoin address and wallet. Due to the lack of centralized authority, users will have to verify each other credentials. This means that identifying Bitcoin address will be linked to post and messages.
Introducing a layer of anonymity in a decentralised context is difficult, especially when spam is a possibility. In a centralised system, the centralised entity (servers) can act as the anonymity layer between users, the lack of central server means it goes away.
In a later stage, we can review this and design solutions to enable anonymity while allowing moderation and spam prevention.
To make this happen, we may need the usage of a centralized API that provides the Bitcoin address and ordinal details of current Logos ordinal owners, as processing this locally from a Bitcoin RPC API such as Magic Eden may be too resource hungry.
The user’s Logos ordinal is used as avatar and the operator unique name as username.
A call sign can be added by users to their identity, but logos ordinal information will remain.
OP number display, which are currently off-chain are out of scope.
Content access
Only users owning a Logos ordinal will be able to create cells and post messages. This is to facilitate moderation and prevent spam. Relaxing this restriction can be considered at a later stage.
Only public cell will be implemented, meaning that any user, logged in or not, will be able to see all the cells and read all the posts.
Only text content is supported.
Cells
Logos ordinal holders will be able to create cells. Cells are only public. The cell creator is the only admin, cells ownership is tightly linked to the Bitcoin wallet used at creation.
Cells will have a name, description and icon size; Icon size will be restricted.
Users do not join or leave cells, they can open cells to read content, and post in cells.
The “number of users” in a given cell will be deduced from recent activity (posts, comments and upvotes).
Moderation
As per content access policy, only logos ordinal holders will be able to create cells, post, comment or upvote.
Any user can “block” another user by their Bitcoin address. Which means that the blocking user will not see the content created by the “blocked” user anymore. Because it is a decentralised system, this is done locally in the “blocking” user web page.
Cell owners, acting as solo admins, can mark users, comments and posts as “moderated”. “Moderated” users, comments and posts are not shown to other users by default. Again, the filtering is done locally by the reading user web app. Data is not blocked or removed from the network.
Reliability
Data on the Waku network is ephemeral, meaning that older posts will be lost over time.
Building such a PoC will enable us to dogfood latest Waku protocols to understand the impact on content durability.
Network-level DoS Protection
Network level DoS protection ensures that no user can come in, send million of messages and hog the bandwidth of legitimate users. The current solution, and only decentralised solution that exist, RLN Relay, involves the usage of an EVM smart contract for zero-knowledge tech usage.
We assume that this is out of scope for the web app, using RLNaaS.
FURPS (Functionality, Usability, Reliability, Performance, Supportability)*
FURPS is a framework to express software requirements, they act as the true commitment of the Waku team on this proposal. Please see the FURPS for this PoC below:
Functionality:
- Users identify themselves by signing with their Bitcoin key
- Only users owning Logos ordinal can participate; usage of a centralized API to get current Logos ordinal owners may be needed.
- Any user (authenticated or not) can see the content; basic encryption functionality
- Existing cells can be listed
- Cell can be created with a name, description, icon; icon size will be restricted; created is solo admin
- Post can be created in a cell with a title and body; text only
- Comments can be made on posts and other comments; text only
- Posts can be upvoted
- Users can setup a call sign; bitcoin identity operator unique name - remains - ordinal used as avatar; OP number out-of-scope (not onchain)
- Cell admin can mark posts and comments as moderated
- Cell admin can mark users as moderated
Usability:
- A user can see all topics through all cells
- A user can see the number of active members per cell; deduced from retrievable activity
- Users can bookmark posts and topics; local only
- Users can sort topics per new or top
- The ordinal picture and information are used to identify user, in addition to the custom nickname
- Moderated users, comments, and posts are hidden
- Users do not need to sign every message with their wallet
- Users do not need any software beyond a Bitcoin wallet browser extension
- This includes a prototype UI to dogfood the PoC; Nice UI will be handled by Comms Hubs team
- A library with clear API is produced to enable frontend developers to use it with a nice UI
Reliability:
- Data is ephemeral; and will disappear after some time; No effort spent on topic or comment durability, out of scope for now.
- End-to-end reliability strategy will be employed to enable app instance to know about missing messages and attempt to retrieve them.
Performance:
None
Supportability:
- Web app with Bitcoin wallet browser extension
Future Work
After the PoC, there are a number of potential directions we can take:
- Privacy: review the privacy requirements and explore technology to enable anonymous poster while maintaining Logos Ordinal requirement
- Identification: Review other ways to identify users, but this needs to be done in a way where identity churn is difficult (if the identity is just a fresh bitcoin address, then one can just generate a new one for free when they are getting moderated)
- Message retention/durability: Review usage of e2e reliability protocol (SDS), store sync and Codex to improve message content durability
- Curation: Build filtering strategy to better curate content for users, similar to a Twitter feed algorithm applied locally
- Follow: One option for better curation is to include a “follow” concept, this can also be useful for message retention, where followers help re-distribute content generated by their followees
- Media: Review whether images could be added to the type of content, and the role Codex may have
- Network level spam protection: Review if users are open to EVM usage to better protect the network, meaning interaction with an EVM chain
- Encryption: Review the feasibility of implementing restricted or private cells.
- Bitcoin RPC API: review the best way to collect information about Logos ordinal operators without relying to a hosted Logos Ordinal API.