This topic is to discuss the proposal submitted by @chrlyz .Please see below for the details of the proposal and discussion.
18th Sep,2024 Current status: Funded. This proposal is approved for funding. The timelines for this zkApp are longer to deliver as we acknowledge this is a complicated undertaking. The impact and risk are classified as low due to the timelines. The budget is in line with the work proposed. We appreciate the author’s transparency in the proposal regarding timelines and are happy to support the improvements suggested.
08th Sep ,2024 Current status: Under Consideration. Opened for community discussion on :08th Sep, 2024.
This is a continuation of “WrdHom: the auditable social-media platform”, a project that got kickstarted during zkIgnite Cohort 2 and Navigators Season 1, successfully delivering all milestones, and that has kept advancing on its own.
The project is building a social-media platform, where users get auditable and customizable feeds, free of censorship or content manipulation like artificial boosting or deboosting of certain content or accounts, and black-box moderation systems. Providing a credibly neutral platform, where content propagation is fair for everyone, and content, groups, or individuals aren’t treated in a biased way. Also increasing the agency of users, by enabling them to customize their feeds and see the content they want, instead of just prioritizing the content that increases engagement and revenue for the platform to the detriment of its users.
Furthermore, users truly own their accounts by owning their private keys and by storing all the necessary data to power the platform in open and decentralized protocols like Filecoin, while the root state that can only be updated by following the rules established on Smart Contracts and zkPrograms lives on the Mina blockchain. Securing the proper behavior of the platform.
Proposal Overview
Problem
Currently the platform relies on immediate evaluation of every server response by the user’s client. This negatively impacts the user experience, since each time the user’s feed updates, the audit of the response gets triggered, so the user needs to wait until the audit finishes to keep navigating through the feed.
On top of this, since each server response needs to be audited immediately against the current onchain state, it’s not possible for the server to serve content that hasn’t been included in the onchain state, so the user isn’t able to see the most recent content, which depending on how many platform actions need to be proven and how fast the next block is produced, could result in a content delay of dozens of minutes.
Additionally, the current design doesn’t allow users to go back to already audited queries in their feed; and immediate evaluation creates a race condition between the server response and the fetch of the onchain state, which sometimes can result in an audit failure even though the server response was valid.
So overall, the user experience can be greatly improved by addressing these issues.
Solution
To solve these issues we will change the current architecture from immediate evaluation to lazy evaluation, by storing the server responses of a session (in-browser up to a certain amount of data and then giving the option to unload them into a file), so they can be audited later.
We will also decouple the auditing functionality from content navigation, so users get a smoother and faster experience, and are able to see more recent content that hasn’t been recorded onchain yet, but its inclusion has already been committed and it’s just a matter of finishing creating the associated proofs and including them in a future block.
Furthermore, by changing from ephemeral server responses to a more persistent design, we will enable the user to go back to already audited (or to be audited) server responses, improving navigation even further. We also get rid of potential race conditions.
With these changes we also open the door for the implementation of Smart Contracts and zkPrograms that are able to take these stored responses as inputs and generate proofs of invalid responses, rewarding people that are able to prove invalid responses, and therefore creating more incentives for people to audit the platform, which may produce an invalid response at a predictable frequency, to provide a constant reward for consistent auditing.
Impact
Radically improving the user experience of our auditable social-media platform is a further step into delivering a product with the potential for mass adoption in the Mina ecosystem. A unique product that leverages the unique properties of Mina.
Audience
The main audience for this proposal are the eventual end users of the auditable social-media platform, which deserve the best possible user experience, but also the potential developers that could build on top of the open platform.
Architecture & Design
Detailed Design/Architecture
The WrdHom project aims to provide an alternative by building an open, auditable, and accountable platform by default. Guided by the following principles:
Users sign messages to authenticate their actions on the platform. This way users own their digital identity, since they own the keys to their accounts.
These signed messages are the input to zkPrograms that verify signatures, order actions on the platform, and generate proofs to update the state of the platform by following the established rules encoded in the zkPrograms. Then the associated smart-contracts verify that the proofs are valid and timestamp the moment of their inclusion.
The state of the platform is composed of on-chain and off-chain state. Our on-chain state lives in the Mina blockchain, and can be seen as the root of the whole state of our platform. This state is updated through the proofs generated by our zkPrograms, and can be used to verify that the off-chain state is valid.
The off-chain state lives in open and decentralized storage platforms like Filecoin. Data should be stored publicly and redundantly, so users have the guarantee that their data and the platform will remain available.
When users get content from the platform, the server responds with the content and the Merkle Map witnesses associated with each piece of content, so the client uses this to automatically calculate the roots for the state of the platform. The client also fetches the on-chain roots, and compares them with the calculated roots to make sure that the server response is valid according to our settings, and behaves as expected.
Mina also makes it possible to implement native zkApp-specific rollups, so we don’t have to make an on-chain transaction every time a user does something in the platform, which would be slow and expensive. Instead, we merge the proofs that we create to update the on-chain state, into a single proof that can be submitted to the network (e.g. The server receives 1,000 post requests, so it generates 1,000 proofs that then are merged, and the server uses the resulting proof to update the on-chain state for 1,000 posts in a single transaction). These proofs can also be generated in parallel, allowing the platform to scale.
For this proposal we will modify the server and the client. The server will still respond with the Merkle Map witnesses and the content, but also with signed metadata for each response, which will be composed by the query of the user and the block length for which the response should be valid.
The client will quickly verify that the metadata is signed by the server and that it matches its query parameters, to then store each of these responses in-browser up to a certain amount of data and will offer the option to unload them into a file for longer term storage and auditability. Then the user can trigger the heavier auditing of any of these responses later, either by triggering an audit of a response still in the browser’s memory, or by uploading a response from a file.
During an audit, the client will retrieve from an archive node the onchain state at the block length for which each response indicates it should be valid, and perform the audit against them.
The client will also be modified to enable an intuitive and smooth navigation of different server responses through an in-app navigation history, and “go back” and “go forward” arrows. Additionally, we will implement URL Route Params, so users can bookmark and share links, making content easier to save and share, and improving caching and search engine indexability.
Vision
A successful long-term vision for this project would be establishing a popular social-media platform with millions of users. Normalizing the expectations for transparency, auditability, credible neutrality, user-owned identity, resiliency, and composability in our general internet experience. Improving freedom of speech and our collective intelligence for better decision making, free of signal corruption. Creating a better world.
Existing Work
Production Timeline
Around a year for a devnet release, and around 18 months for mainnet.
Budget & milestones
Deliverables
Server with the new functionality to serve auditable responses for lazy evaluation.
Client with the new functionality to lazily audit the server responses, download them into a file, decoupled auditing and navigation, and the ability to navigate through the stored responses, plus being able to bookmark and share queries.
Mid-Point milestones
Server with the new functionality to serve auditable responses for lazy evaluation.
Client able to store and lazily evaluate the server responses.
Project Timeline
3 Months
Budget Requested
30,000 MINA
Budget Breakdown
62.5 MINA x 480 Hours = 30,000 MINA for one Software Engineer for 3 Months
This will cover the running costs of software design, development, and testing.
I’ve been building on the Mina ecosystem since December 2022.
Team Members
Currently the team consists only of the proposer.
Achievements
Successful delivery of all milestones during zkIgnite Cohort 2 and Navigators Season 1.
Risks & Mitigations
One of the major risks for a platform like this is it being abused by some users to post illegal or unwanted content (like spam or unlabeled sensible content), which could bring legal risks to operators and an undesirable environment for users.
To mitigate this risk a moderation system will be developed. Following the ethos of the project, this moderation system will focus on auditability and neutrality, looking for an optimal point that maximizes freedom of speech and minimizes legal risks and content that users don’t want on their feeds.
Another risk is that the smart contracts could get “bricked” if we lose offchain data or it gets corrupted in a way that we can no longer create proofs to keep updating the onchain state. Plus guaranteeing to users the long term availability of their data and the platform is in itself one of the goals of the project.
To mitigate this we will follow a redundant offchain storage strategy supported by decentralized storage networks. This is a risk that many zkApps face, so we will keep an eye on what other teams are doing and work on establishing a solid solution.
Finally, there’s always the risk of bugs or security vulnerabilities in the system, so thorough analysis and testing is necessary. This is why the platform will first launch on devnet for a period, to make sure that we catch any dangerous issues before launching on mainnet, through the feedback of alpha testers, auditors, and bounty hunters.
This proposal is approved for funding. The timelines for this zkApp are longer to deliver as we acknowledge this is a complicated undertaking. The impact and risk are classified as low due to the timelines. The budget is in line with the work proposed. We appreciate the authors transparency in the proposal regarding timelines and are happy to support the improvements suggested.
Hey, everyone. Just checking in for a quick update.
The original plan was to simply make the server responses to be able to be audited at a later time instead of immediately, without modifying the contracts, by getting the older states from archive nodes, but on an effort to improve the provability of the server responses among some other advantages, I decided to go ahead and start working on the contracts even if this wasn’t within the scope of the proposal, since it will help with the goals of the proposal and will help with some future features, without putting the current milestones at risk.
I’m almost done with implementing this for Posts end to end (from contracts to server to client) and I’ll be working on the implementation for the other content types (Comments, Reactions, and Reposts) and on the decoupling of the navigation and auditing later.
First I want to explain a little bit about why I decided to work on the contracts too. As mentioned in my last post, the original idea was simply to retrieve older states from archive nodes, but this presented some issues:
State history retrieved from an archive node isn’t provable by default, so users would be trusting the archive node they would be using to validate server responses.
Adding archive nodes as a dependency would add complexity and overhead to the project.
Without provable state history, potential future features like users being able to prove that they received an invalid response and get a reward for it, wouldn’t be possible to implement.
So in order to solve these issues I decided to implement provable state history for all the contracts of the project.
Now, over the past few weeks, I was planning to work on the other content types, and then focus on the decoupling of audits and navigation, since I was almost done with the Posts content type, but while working more on the client-side for Posts, it seemed like a better option to implement the decoupling of audits and navigation for Posts, plus the ability to navigate through the stored responses and the respective UI. This way I would have a closer approximation to the final product of this proposal, on top of which it would be easier to iterate to implement the rest of the content types.
This whole implementation for Posts has now been completed and I plan to iterate on it to implement the remaining content types.
Over the past few weeks I’ve been mostly reviewing the architecture of the client since I’ve identified some potential improvements to make the UI more efficient, smoother, and easier to understand.
I was thinking about making this refactoring part of the work for the next weeks but after careful consideration I’ve decided to focus on completing the milestones of the current proposal and postpone such work, in order to make sure that everything is delivered on time.
The lazy auditing implementation for Posts, Reactions, and Comments has been completed. The implementation for Comments and Reposts was a little more involved than anticipated, due to how the fetching and rendering of the feed works in the current design (this is one of the reasons I’m planning a client refactor in the near future as mentioned in my last post).
I’ll be completing the lazy auditing for Reposts; the storage of server responses into a file for portability; and implementing URL Route Params to enable bookmarking, sharing links, and better search engine indexability, over the next few weeks for the final delivery and presentation of the milestones of this proposal.
