Summary

• Private groups
  • invite-only group
  • has private markets that only members of the group can view/create/bet on

Context

• multiple companies have asked for a private instance of manifold
  • ex. Alvea, CEA, Rethink Priorities
• private instances are difficult to spin up/maintain, we should just make them private groups!
• this is a good path forward to monetization

Considerations

• how secure do we want to make this?
• bets?
  • what to do with bets?
• how to do permissions? do we need both?
  • we’re keeping firebase auth even after move to supabase?
  • firebase
    • not great for long term because moving to supabase
  • supabase RLS
    • good for long term but is hard 😟
      • has to be done eventually though
    • will likely need to do something like this
  • thinking about having private markets be a separate table that only exists in supabase so we don’t have to deal with double permissions

PUBLIC CAN VIEW

• group name
• the fact that group is private
• gains/losses from private market bets (in profile graph n stuff)

PUBLIC CAN’T VIEW

• group markets
• group members
• group posts
• private market bets
• group comments

Inspo

• github private repos

• facebook private groups

• google docs

  

Proposals

P1: have a separate table for private markets

• private groups remain in group table
  • are groups replicated anywhere? Is that a security concern?

PROS

• LONG TERM - probably more secure
• LONG TERM - don’t have to deal with managing permissions where regular markets are replicated (ex. algolia, db backups)
• SHORT TERM - doing it this way, we could potentially only have private markets in supabase, meaning we don’t have to deal with permissions twice (supabase and firebase)

CONS

• LONG TERM - market database type is now duplicated in 2 tables
  • more to keep track of as changes are made to market types
• probably have to recreate a lot of things
• [A] how do we deal with search?