Integrating Anonymity Features into Freedit with Semaphore

[sripwoud]

originally on https://talk.zketh.io/post/1/4

Introduction

Freedit is a secure, lightweight forum application built with Rust, Axum, and sled. The platform currently supports features like user authentication, subgroup creation (inns), personal spaces (solos), and private encrypted messaging. To enhance user privacy and flexibility, there is a desire to integrate an anonymity feature that allows users to anonymize some of their actions within the platform. This document outlines a potential UX and product requirements for this feature, explores a potential architectural solutions, and provides a high-level step-by-step implementation plan.

Requirements

Anonymity Toggle

Feature: Introduce a toggle switch within the user interface that allows users to switch between anonymity modes:

• Anonymous Mode:
  • Behavior: All user actions (e.g., voting, feedback) are submitted as Semaphore signals, ensuring that these actions are recorded without linking them to the user’s identity.
  • Indication: Clearly indicate to the user that they are operating in anonymous mode.
• Doxx Mode:
  • Behavior: User actions are tied to their username or unique identifier, allowing for accountability and traceability.
  • Indication: Clearly indicate to the user that they are operating in identifiable mode.

Requirements:

• Accessibility: The toggle should be easily accessible, preferably placed prominently in the header or settings module.
• Feedback: Users should receive immediate visual feedback when switching modes.
• Persistence: The selected mode should persist across sessions, either through user settings or persistent storage (e.g., cookies, local storage).

Anonymous Actions

The following actions can be performed anonymously:

• creating a post
• comment an existing post
• voting on a post
• voting on a comment

Security and Privacy

• replay prevention: (granular?) management of nullifiers to ensure each anonymous action is unique and cannot be duplicated
• compliance: adhere to data protection regulations?

Possible Architecture Solution

Implement a single, global Semaphore group dedicated to handling all anonymous actions across the platform. Users who enable anonymous mode will send semaphore signal as member of this group. The freedit platform will generate and validate semaphore proofs accordingly.

Alternatives

Multiple semaphore groups: assign dedicated Semaphore groups for specific actions or contexts? (e.g., a separate group for voting). Users can toggle anonymity on a per-action basis, allowing for more granular control.

Comparison

Solution	Pros	Cons
Global semaphore group	simple, scalable, consistent anonymity	no granular control (do we even need it?)
Different Semaphore group per action type	more customization, granular control (do we even need it?)	complex, user confusion

High Level Implementation Plan

Enhance/Define DB Schema

There will be additional entities to manage, especially:

• user identities (semaphore identity commitments)
• semaphore group roots
• nullifiers
• semaphore signals: the messages (or any serialized forum action) sent anonymously?

The previous yeap application used a relational DB (see schemas/migrations), while freedit uses sled which a key value embedded database.
We’ll need to decide whether we want to keep using sled or if we switch to a relational DB.

Integrate Semaphore Into Backend

1. Implement a semaphore v4 rust library.
2. Assign semaphore identities on signup
   Modify signup workflow (handler) to store a semaphore id commitment (generated client side)
3. Manage semaphore groups
   It should not be necessary to implement this from scratch. We just need handlers to communicate with (forward requests to) bandada backend.
4. Handle anonymous signaling

• validate nullifier: does not exist yet
• validate group root/fingerprint: is different from latest and has not expired (see fingerprint challenge)
• verify groth16 proof
• perform any necessary CRUD operation (insert nullifier, insert signal etc…)

5. Develop anonymity toggle API? Ideally the backend should be able to detect whether the action is being done in anon or doxxed mode (check a toggle state payload).

Frontend

1. Move away from template rendering to a JS framework (see server: implement json api layer #5 server: remove template rendering logic and deps #6 chore: scaffold monorepo #4)
2. Implement anonymity toggle interface
3. Handle Proof Generation (already done in https://github.com/sripwoud/yeap, semaphore js packages are available and ready, should not change much/at all)
4. Update action submission logic Depending on toggle state, include proofs in payloads instead of doxxed content with author data.

[sripwoud]

re sharing comments from @jacque006

Great writeup! Overall I think this is a solid plan of attack.

One of the big things I was thinking about with this switch is, do we even need the user to have an account when using Anonymous Mode? There is the chicken/egg problem of gatekeeping how they are added to the Semaphore group, but after that there is no reason they need an account to interact. Some users may even prefer to generate their post/comment/voting proofs outside of the application if they don’t fully trust it with their keys.

Either way, there are going to be some practical issues with managing data generated in Anon mode:

How do I keep track of the Anon interactions I have made? Is that moved into the web app? What if my local storage gets wiped?
How do I receive notifications/alerts when someone responds to me without linking it to an identity?
If I respond to someone’s comment on my Anon post, how would I be able to respond so they know it is from the original poster? If I have a comment chain running, do I want people to see that the comments are Anon but from the same Anon user?

Some implementation Q’s/thoughts:

compliance: adhere to data protection regulations?

I think this is outside the scope for the time being, and could be quite the rabbit hole to go down. There is currently no PII I’m aware of (maybe username). Did you mean something more specific?

Start with a default Semaphore group (configurable per server/instance). I could also see Inn admins wanting to use most specific groups or other qualifying credentials in the future. If so, there are already some permission roles baked in that we can leverage.

I would stick with Sled as the DB. Appears to have the needed feature set and refactoring to another DB adds time & complexity that could be better spent elsewhere.

Does worldcoin/semaphore-rs support Semaphore v4? If not we would need to use ark-circom or Semaphore v3. Would the latter option could cause compatibility issues w/ Banada?

[sripwoud]

do we even need the user to have an account when using Anonymous Mode i think we do, I don’t how to solve these other questions otherwise: How do I keep track of the Anon interactions I have made? Is that moved into the web app? What if my local storage gets wiped?

Local storage to manage semaphore id private key: I would really prefer to avoid this approach… precisely because local storage gets wiped. What about:

• in the beginning, to quickly integrate with semaphore: we keep the existing password auth workflow, we generate a semaphore identity, we use the user’s password to hash the semaphore private key, we store the hashed private key server side?
• eventually I’d like us to implement a no password auth workflow:
  in yeap it works like this:
  signup > magic link > creation of an embedded smart account with turnkey > can use a signer client side > use that signer to sign any message > that becomes your semaphore id (which can then be recovered any time with a magic link)

How do I keep track of the Anon interactions I have made?
Can’t we store them anyway, just without any author or identifier field? Couldn’t we have data structures with an Optional author? Or is this too naive?

#[derive(Serialize, Deserialize, Debug)]
struct Vote {
    post_id: u64,
    comment_id: u64,
    vote: bool, // true for upvote, false for downvote
    author: Option<String>, // Some(author) or None for anonymous
    timestamp: DateTime<Utc>,
}

#[derive(Serialize, Deserialize, Debug)]
struct Post{
    post_id: u64,
    content: String,
    author: Option<String>, // Some(author) or None for anonymous
    timestamp: DateTime<Utc>,
}

#[derive(Serialize, Deserialize, Debug)]
struct Comment {
    post_id: u64,
    comment_id: u64,
    content: String,
    author: Option<String>, // Some(author) or None for anonymous
    timestamp: DateTime<Utc>,
}

these objects would be managed in different sled trees (which I think is compatible with the existing freedit db_utils)

client side, these objects in serialized format (without author ofc) would be the semaphore signal used to generate the proofs backend side: we would deserialize them, storing them no matter what (author is something or none)

[sripwoud]

compliance: adhere to data protection regulations? I think this is outside the scope for the time being

I agree. let’s ignore this for the moment

[sripwoud]

If I respond to someone’s comment on my Anon post, how would I be able to respond so they know it is from the original poster?

See https://discord.com/channels/943612659163602974/944173742219735080/1316038414688063509

From @cedoor

You can do that with the nullifier, if you use the same scope they'll share the same nullifier. And since the nullifier is the hash of priv key and scope, you can be sure the two messages have been sent by the same user.

[sripwoud]

I would stick with Sled as the DB. Appears to have the needed feature set and refactoring to another DB adds time & complexity that could be better spent elsewhere

👍 Ok let’s do it like this

[cedoor]

Implement a single, global Semaphore group dedicated to handling all anonymous actions across the platform.

I think this is the best solution. Not sure what you mean by "granular control".

creating a post
comment an existing post
voting on a post
voting on a comment

Consider you need to use the nullifier in different ways depending on the action.

Creating a post or comments anonymously requires a nullifier to prevent attackers from spamming essentially. The only reason why an attacker may want to re-use the same proof with the same message is to spam. And in this case, since you need a way to prove multiple comments have been sent by the same user anonymously, you can use the nullifier (hash of scope + priv key) to do that, and the actual nullifier would be hash of nullifier + message.

Voting requires nullifiers to prevent double-voting.

eventually I’d like us to implement a no password auth workflow

Is this app supposed to be used by PSE folks only? If so, another option is to use Metamask to sign a message and use it as a secret to generate a priv key deterministically + SIWE.

Also, if you're going to save the user identity commitments what's the point in using Bandada? Couldn't you use your db directly?