developer-dao/dao-job-board

A job board connecting DAOs with talent.

dao-job-board's Issues

Setup Supabase in App

Proposal: Adding user stories for building up the roadmap

As per feedback from @with-heart during the call from last Friday, to build out an MVP we need to setup a clear goal on what we want to achieve, what certain functionalities should be shipped, and know what exactly are we building.

I had a slight conversation with @angeljgomezc and I proposed that we'll use of "User Stories" for defining a set of functionalities that we want to ship for the MVP.

We basically just create a bullet list of single sentences/phrases on what we want to expect or what certain functionalities we want to have in the app

e.g.

• As a developer I want to browse jobs/gigs that I am interested in
• As a developer I want to setup my profile, upload photo, update my description, username
• As a developer I want to send job applications to job postings
• As a developer I want to create gig postings
• As a company recruiter I want to create job postings
• As a company recruiter I want to receive job applications from developers

Personally I think these would helpful for someone that wants to contribute into the project.

But if there would be any other suggestions than this, please share it with us we would be happy to learn more about it :)

Build Application Form for Gigs

Every gig in the website will need a way for devs to apply.

WHAT ARE GIGS?

They are tiny freelance projects for devs to tackle. This could be anything as simple as centering a div to slightly more difficult things like designing a landing page from scratch or connecting a smart contract to a front-end.

WHY AN APPLICATION FORM?

Because gigs will be internal between people/companies starting the gigs and devs themselves, we need to make it easy for devs to show what they can offer.

I suggest a simple form where devs need to write:

• WHY they're ideal for the job (like Gitcoin Bounties pages) - this should be a simple 100-word input form where devs can write an appealing proposal.
• PROOF would be extra inputs where devs show they can actually get the job done (or at least make a good try) with links to repos, live sites, figma files, etc.
• WORK PLAN where the devs explain a step-by-step plan of how they will get the job done. This will be optional, but could make it easier for gig creators to know who has a better of how to get the job done.

All these inputs should make it easier for those starting the gigs to find their ideal candidate.

There are many examples to follow about application forms for gigs, I'll recommend these:

Upwork = the biggest freelance site out there, makes it easy for people to apply on both tiny and large projects by letting them set up different pieces of info before sending the application. We should focus on only a tiny description of the dev and a proof of their competence (a link, for example)

Gitcoin Bounties = Some Gitcoin bounties let hackers apply by sending a tiny message. This is a very straightforward form but gets the job done.

P.S. We also need an application list. But this will a separate issue we will start later.

Setup Prettier!

To avoid unnecessary time time spent in PRs for things like this

Broken / incorrect 🔗 in the README

At the bottom of the README, there are two links ( See screenshot below )

1. ISSUES
2. CONTRIBUTING GUIDELINES

Link 1 - ISSUES

• The link points here 👉 https://github.com/angeljgomezc/DAO-job-board/issues
• It should point here 👉 https://github.com/Developer-DAO/DAO-job-board/issues/

Link 2 - CONTRIBUTING GUIDELINES

• The link returns a 404
• It should point here - Maybe 🤷‍♂️? 👉 https://github.com/Developer-DAO/DAO-job-board#how-to-contribute
• It should not 404 at least

Develop + Design Gig Page

To minimize the number of tasks per issue, I'm separating #18 into two parts:

1. Job Page
2. Gig Page

This one will be the gig page as mentioned in the issue.

• Gig (will be left for later)

The gig page should include information about the gig for people to understand what the creator is looking for (title, description, keywords, timeframe, reward, and amount). We should also develop a form for devs to apply for each gig. The application should allow devs to write at least 50-100 words about why/how they can handle the job (take Gitcoin bounties as an example).

NOTE: Every gig page should be on the link = devdaojobboard.com/gigs/company-or-devname/gig-title-with-dashes

Current mockup for the gig page is located here (image on the left).

Create hooks relevant to fetching data from DB

Develop + design Job Page

• Job

Every job page should hold basic info about the job (title, description, job type, position, keywords, company's link with logo, location, compensation, etc.). Plus, it should have a final button people can click to apply (either via email/ or company's website).

NOTE: Every job post page should be on the link = devdaojobboard.com/jobs/companyname/job-title-with-dashes

Use supabase

It would be a great idea to use Supabase for off-chain data store, I can help with designing or coming up with a database schema.

Application List

As of now, we have a mockup for each Job Page
(right component)

This is what every developer/job seeker will see as they open a job posting. However, what does every recruiter's job page look like?

We should add an applicationList component that shows every developer that's applied so far. It should a tiny application letter + links the developer wants to send.

This feature would be available for Recruiters who decide to receive applications directly on the site (the default will be their email/website posting).

What do you guys think? @carlomigueldy @JoviDeCroock @frankTurtle @Miral @Dhaiwat10 @kasthor @swetshaw

If we're doing this, feel free to propose a mockup for how every recruiter will see these applications :)

User Stories

// TODO:

Create a Doppler workspace

As per suggestion/recommendation from @JoviDeCrook this will be a great tool for distributing environmental variables :)

I am going to set it up soon and allow it to easily distribute to other devs that'll join into the project

Doppler

Roadmap + MVP Features

Hey everyone!

The job board is already shaping up, things are looking neat so far and there's a thing or two to finish before we launch the MVP.

But there's a tiny issue - even though it already has a shape, we still should make it CLEAR what we want the website to be like before we launch it.

After talking to @with-heart about this, it makes sense to DEFINE what the ideal MVP should look and be like.

For that, it would be great if we develop a roadmap for the job board, starting with WHAT the MVP should have at first and HOW we can achieve that (a step-by-step list).

With that in mind, let's get into a few points I had in mind:

ACCESS TO THE JOB BOARD

The job board MVP should be only for DAO members first. This way we can iterate faster without having so many people using the site (and get feedback directly on the Discord). Of course, we may need to develop a way to authenticate those who own an NFT.

Later, if we decide to open the job board for everyone, this authentication feature could help us identify who belongs to the DAO via tags or icons, for example.

NOW, how should people authenticate? According to what we first had in mind, authenticating via Metamask using Supabase to store data would be a decent approach. This way we aren't entirely web2 and we have a way to authenticate only members from the DAO if we want.

What do you guys think?

JOBS

With the previous point in mind - we should decide whether we want the MVP to have both Gigs and Jobs, or only Jobs. So far, I've seen people asking for help in personal projects (gigs) and others posting job opportunities on companies they're working on (jobs) on the #jobs channel in Discord. Of course, having both Gigs and Jobs will be a bit more of work, but it also makes the site more complete.

What are your thoughts on this?

P.S. We already have both pages almost completely done.

GIGS

For Gigs, we also need to figure out how the application form/website flow looks like. Gigs should have their internal application through the site.

Now, how can we ensure devs get paid for their work? Or at least they get a reward for their efforts?

Most bounty systems I've seen so far have their internal payment systems (with their coin). We should probably develop something like that.

Because of this, there are two paths (IMO) we can take:

1. A reward/payment system is a lot of extra work, and we still don't have a coin to work with, so we should probably delay the Gigs part of the website for now and focus on the Jobs board instead.

2. Otherwise, we could use the Gigs page to help people looking for help to connect with those who want to help (without a payment/reward system... yet).

APPLICATIONS

How does the application feature look like for Jobs and Gigs?

For Jobs, my first idea was to let companies and people opening job posts add their email/webpage posts so devs can apply to jobs DIRECTLY and leave the job board only for posting. Now... should we also develop an internal tool for these applications? This will let companies see who applies through the job-board site - separating DAO members from everyone else who applies directly on their page/email.

For Gigs, I explained a quick approach on Issue #26
. In short, add a simple application form with a proposal input (where devs write what they offer), proof they can handle the job (with links to repos/websites/etc), and a plan form where they explain how they will tackle the gig.

DESIGN

The first few pages in what we already have for the job board were designed taking into consideration the main developerdao.com site as an example.

The colors, boxes, shadows, and fonts were all taken from there. However, it probably doesn't look perfect for the job board. We should probably strive for something simpler (especially now the main DevDAO website is getting a re-design).

I'd suggest proceeding with a simple black-and-white theme instead of the current bluish/grayish tones in the site.

HAVING SAID THAT, we should probably develop a design system. This would be the job of the #design-guild back at the Discord. Once we have the MVP rolling, that re-design may come helpful to make everything clearer. (Or maybe even before the MVP rolls out?).

Anyway, we're taking feedback + recommendations for this. If you belong to the DAO and want to give your two cents, feel free to comment on this issue.

DEADLINES

Also, we should probably come up with a deadline for the MVP. Not to put pressure on ourselves, but developing stuff without a clear date and/or idea of what we want to do could make it impossible to finally ship. However, it shouldn't be something too close either (most of us have either full-time jobs or other responsibilities).

I'd propose getting the MVP rolling within 2 weeks. This way everyone has enough time to contribute while also giving us enough space to test stuff out before releasing it.

The website is pretty simple still, but 2 weeks seems like a fair timeframe - right? What does everyone think?

ROADMAP

The points above are mostly my concerns + ideas so far. Once we figure them out (preferably within a few days), we can proceed with the writing of the roadmap so we're all in the same page when it comes to designing and developing the website.

Now, how should we write the roadmap? I propose creating a ROADMAP.md in the repo. Whatever we end up having a consensus on, we'll write on that roadmap.

To speed up the roadmap process, I'd propose the following step-by-step list for the MVP roadmap:

1. • Develop the MVP with a simple design (black and white as said above) + only the Job posting page. Only DevDAO members will be able to apply to jobs for now (via the company's emails or their website posts). We should have this by the 30th of November.
2. • Iterate and make changes on feedback from members using the site. This would be ideal to perfect the job posting + application system as we go.
3. • In the meantime, we should figure out how we want the Gigs page to look and work. So far, my idea was to make a smart contract (once we have our own DAO coin or using an ETH L2) so people creating gigs can deposit rewards and developers working on those gigs can receive them directly. Once we have that ready, release the Gigs MVP to the public (likely before the year ends)?
4. • Re-design the page with help from the #design-guild. This would be the last step into the MVP roadmap. Once we have everything working, a re-design that makes the site more usable and easier to work with would be ideal. Most likely will be the design guild who tackles the job.

After that, maybe we can come up with newer features over time - but that's probably enough for now. The re-design will take the site to a new place, so we may still have a lot of stuff to play around with + develop.

Anyway, this is my initial approach to a roadmap + concerns + ideas I think could help us develop the site further.

What do you guys think? @with-heart @carlomigueldy @Dhaiwat10 @miralsuthar @JoviDeCroock @swetshaw

Feel free to comment on every/any subject I went over. Also, it'd be great to come up with your roadmap so we can brainstorm as we go.

Consider Carlo's approach: Issue #33

Proposal: Integrate I18n

Well as the job board might grow but it's still small, i believe it's probably the best time to integrate Internationalization to the project

Also from my experience I believe that getting I18n early in the project also helps to keep the code clean as the Interface level strings are always represented as a 'label'

Later on I can help to provide a translation to spanish :)

Vercel Integration

Web3 auth w/ supabase instead of email/pass

User Profile Form - User Profile

This is how every dev's profile looks like: Dev Profile

I think it looks simple but has pretty much everything we need every developer to have... Apart from experience/education/projects (which I discuss about the form below)

And this is the form for creating such profile: Form

I'm proposing adding either of these two sections:

1. A "Projects" section where you add projects you've worked on before. This could be anything from repos to running websites you've worked by yourself or others

2. An "Education" and "Experience" tab where you add your road as a developer + qualifications (this could also include personal projects, etc.)

My bias is towards (1) given it's a lot more encouraging, as beginners won't feel left out by their lack of experience in companies nor their lack of qualifications. Instead, they can make themselves seen with their projects (personal or not).

(2) is more traditional and could be helpful, but we would be making it another LinkedIn (it's still helpful, tho)

LASTLY, comment on the "Content Visibility" section. I added that because some people may decide to hide some of their data from time to time (for whatever reason) and not have to add those later if they decide to make them visible again.

What do you guys think? @with-heart @Dhaiwat10 @JoviDeCroock @carlomigueldy @kasthor @frankTurtle

Build Hamburger Menu for Mobile (Navbar Responsiveness)

Add guide to `README.me` for how to start discussions etc

https://discord.com/channels/883478451850473483/908922214345211954/914039928055283722

Refactor `LinksSection.tsx`

Is your feature request related to a problem? Please describe.

The structure of the LinksSection.tsx file is a bit dirty and needs some refactoring.

Describe the solution you'd like
It would be great to write a loop/map that reduces the amount of code + makes the whole component a lot easier to read

Just remember to keep the FontAwesome icons as they are. The component should work as it does right now.

Describe alternatives you've considered
No alternatives, but feel free to ask your own suggestions

Proposal: using prisma for database query.

Some of the advantages using prisma with supabase other than @supabase/supabase-js

• type safety - prisma generates types for every model based on the schema.
• schema migrations - ability to version control schema migrations
• awesome DX - provides auto completion out of the box.
• supports connection pooling for pgbouncer.
• easy database setup for local development .
• has an API for seeding database locally .

We can start from here https://dev.to/prisma/set-up-a-free-postgresql-database-on-supabase-to-use-with-prisma-3pk6

Implementation of path aliases

Problem

• Importing from a path such as import {updateUser} from '../../../../../library/database/lameAssDbLib'; is clearly a bad idea
• As soon as this particular component is refactored or moved, it's going to break a lot
• With how dynamic this project is, this will almost certainly cause issues down the road

Solution

• Enter in Next.js 👉 Absolute Imports and Module path aliases🚀🚀
• Now all we need to do is import {updateUser} from '@db/coolAssDbLib' - It's magic 🧙‍♂️!

Add automatic database migrations

Overview

I haven't read abour this in context of supabase but the idea is setting up a CI step that will update the database schema when we roll out updates to production. This so we don't have the pressure of manually running a script to keep the schema in sync. When I look for supabase migrations I ended up at their cli https://supabase.com/blog/2021/03/31/supabase-cli

From @JoviDeCroock

---

Migrations are like version control for your database, allowing your team to define and share the application's database schema definition. If you have ever had to tell a teammate to manually add a column to their local database schema after pulling in your changes from source control, you've faced the problem that database migrations solve. (Read more here)

I have worked with Laravel projects in the past and it's where I got introduced to database migrations, it was fairly easy to use it with just a few artisan commands to run e.g. php artisan make:migration update_users_table, php artisan migrate

PS: Thought I'd create an issue for this after you sent me a DM about it @JoviDeCroock

How it works

The current process of updating database tables, modifying columns, adding attributes to columns, etc is to manually run SQL statements inside Supabase or PostgreSQL client (e.g. PGAdmin). With that process we can't really keep track of when the attributes were modified into the tables or forget to run the SQL statements.

Typically how database migrations would work:

• Create a migration file with the current timestamp as its filename at the time it was created
• Inside the migration file, have a SQL statement that modifies the database (e.g. ALTER COLUMN ...)
• Run a terminal command to finally execute these migrations into the database (e.g. php artisan migrate)

Migrations are usually be generated from CLI tools.

References

There is an active pull request by @G3root here where it uses Prisma

• Prisma Migrations, it has support and a few resources with integrating to Supabase: https://www.prisma.io/docs/concepts/components/prisma-migrate
• An example from Laravel, this won't likely be used here in the project but just a reference: https://laravel.com/docs/8.x/migrations

Small Database Change

@carlomigueldy Hey mate! I've been thinking of changing the wording in database from category and instead use keyword.

This way it's easier to map users, jobs, and gigs.

What do you think?

Add hardcoded fake/placeholder data to DB

Move `client` directory into `packages` and rename `client` to `website`

🔍 Overview

I notice most monorepos that's using Yarn Workspace have all the projects into packages directory. So thought we would follow that convention where I think that keeps things clean while on the root directory we have all the configurations for CI, lints, Husky, etc. And for renaming the client to website would make more sense. Since we "might" want a React Native project in the future?

📄 Steps

1. Move the client directory into packages
2. Rename client directory into website
3. Rename the package name from package.json inside website directory to "website" (Which previously was "client")
4. On the root directory, change all references from "client" workspace to "website" (e.g. "yarn workspace website dev")

⚠️ Note

Only take action on this ticket when most of the outstanding pull requests have been merged in, that way we can avoid unnecessary merge conflicts.

• #70
• #64
• #63
• #41

The other pull requests were inactive so I'll mention them here separately:

• #38
• #50

Migrate Components to Chakra UI

Chakra saves time and effort as it comes with tons of functionality + a11y that I may otherwise come up with myself

Will try to migrate everything within 2 days

Update database attributes to match UI forms

Overview

There were lots of additions since so the database attributes got outdated overtime. We need to update the attributes that is inline to the current UI that we have in the website. My recommended approach to figure out what attributes to add, change or removed is to go over the website, check out the existing implemented forms and try to come up which attributes that are need to be added.

Add Forms for Jobs, Gigs, and Profile Creation

Proposal: Add ability to add POAP/Completion NFTs for user profile

Allow user to display POAPs and NFTs from completed courses/tutorials etc.

Advantages: User to be able to show efforts and involvement in the open source and web3 communities to prospective employers.

Add form for Company profile creation

This form is required to onboard the companies who want to post job openings on Developer DAO.
A few points that are in my mind right now are:

• Name of company
• Brief detail
• Year of founding
• Industry (finance, games, healthcare, NFT, etc)
• Company Size
• Website
• Twitter
• LinkedIn

Setup Hardhat Project

Overview

Since we're looking at putting funds for Gigs into a smart contract, then we need to setup the Hardhat project into the repo. It will be using TypeScript and all them goodies, i.e. it will use the Advanced TypeScript setup from Hardhat template.

Dockerize

I want to learn more about it and how to use docker-compose on this project :)

It's relatively trivial ticket but if someone does it for fun then we'd be happy to dockerize this repo and we can learn from it how it was setup

Document how to appropriately handle internal links, external links, and buttons that act as links

This issue comes from some of my code review feedback in #41. The way we have to handle links in combination with the Link component from Next.js's next.link package can be quite confusing and we should document those patterns in a place that's easy for contributors to access.

—

Created via Raycast

Transfer Vercel environment variables to Doppler

Task for me to do this since Vercel team seats are limited and I'm the only one with access to both Doppler and Vercel rn (I think)

Related to #27

Hook up forms to database

🔍 Overview

While @angeljgomezc is wrapping up the UI for the forms on job posting creation, user profile, gig posting or etc. Thought it'll be good to plan things out here and to give some context on what I can recommend the approach to take to make it easier to contribute into the project. I have already defined types into client/types which y'all can use it however an updated type definitions for it will be created soon, a PR will be ready in a few minutes at the time of writing this.

I suggest that you take 1 form to hook it up to database and that's for a single PR, and let me know if you're working on that so I can mark it in there so we don't duplicate some work

🔱 Hook

I have created a useSupabase hook where it is a wrapper for the Supabase client and it kinda acts like a repository for CRUD operations but feel free to use just the plain Supabase client instead if you prefer it that way or the hook does not allow you to do certain actions.

There's a usage guide written usign jsDoc as per recommendation from @with-heart which you can find here

📃 Forms

Here be list of types that you can use to guide you which attributes are being used.

• For creating the job postings you can use the type called JobForm
• For creating the gig postings you can use GigForm
• For creating job applications you can use JobApplicationForm
• For creating gig applications you can use GigApplicationForm
• For adding/attaching social media links to a User Profile or Organization Profile, you can use LinkForm
• For updating User Profile you can use UserForm (Maybe this needs to have a better type name, feel free to comment it down if you have a suggestion to give it a better name)
• For creating/updating an organization you can use OrganizationForm

The created_by attribute should take a value of the wallet address of the currently authenticated user. Details in this PR #64 regarding how authentication is handled using wallet.

Example usage

const jobRepository = useSupabase<Job>('jobs');

async function submit(payload: JobForm) {
  await jobRepository.create<JobForm>(payload)
}

Note: The types mentioned might not be available yet on main branch until this PR #77 is merged in.

---

💡 Should you have any problems or something is not clear feel free to reach out to me on Discord or comment down below and I'll help clarify things to you or point a direction so it'll be much easier to contribute to this project :)

Supabase generate type definitions

Overview

While maintaining defined types on client/types can easily be forgotten then it's most likely be out-of-date. We need something that can auto-generate on the fly.

More information can be found here from Supabase official docs

GitHub Actions CI/CD Setup

If someone finds it fun setting it up and writing some tests for the website, that would be cool to have it in the repo

Gitpod

Trivial ticket again but it'd be cool to have Gitpod support

Job Board Main Ideas

After having a conversation in Discord about WHERE to take the job board and ship quickly so we can start iterating more concretely - we ended up with a few main points to tackle:

• We need User Stories to brainstorm ideas for the job board like below
• USERS will be allowed to become either Recruiters or Seekers so they can either post Jobs or apply to jobs.
• The job board will start only with Jobs and get the site shipped with as little complexity as possible
• The Gigs section development will be left for later too (we need to figure out how to allow users to deposit/receive rewards).
• Company profiles will be left for later (we need to figure out a way to allow companies to sign up / verify it's actually a company) so we'll start only with Recruiters
• We need to figure out the perfect User Flow for signing up and creating a profile. We're trying to set up a call with the design guild to get help with UI/UX of the job board (to iterate the MVP quickly) Link to the: LettuceMeet

Check our User Stories for a to-do list of these ideas

Security: Validating a job posting

Overview

While having a random chat with @PBillingsby we were talking about how people could potentially flood the job board using bots, they can create a new wallet and flood more with not useful information thus that might not give us a good reputation or perspective for our users that our job board is spammy with scammy postings. Tackling this early on or finding a solution would be great.

Solution

@PBillingsby suggested to have an admin dashboard where we can manage job postings, that we can maybe ban or suspend users however this approach can make the job board a bit more centralized since we're controlling what users would see. But it's for creating a good user experience for our users that we would prevent scammy-spammy postings.

It would be cool that if we can come up with an algorithm that filters or prevents this kind of problems but it might be difficult.

However if you might have a better suggestion on how we go about it please comment down below, we'd love to discuss it with you.

Proposal: Shorten required char length for job title for job post form

Overview

While looking over the code I noticed that with the job post form there is a minLength of 10 for the job title.

Problem

Have not considered jobs like Tech Lead, that have less than 10 characters

Proposal

Shorten required character count to 7 to account for shorter job titles: minLength={7} <Text fontSize="xs">At least 7 characters</Text> Make sure title is at least 7 characters long

Update Database Schema

The schema is somewhat out-of-date since we're moving towards Sign In with Wallet for our authentication, so it shouldn't be referencing to auth schema for the primary key that we currently have on users table.

Consolidate user stories for RFC

Yarn Workspace

To setup the repo utilizing Yarn Workspace

Adding Profile Image/Avatar

Every user will have the chance to change their PFP through the Profile Form

We have the mockup for the profile form, but we should still add the input so users can add the image they prefer and upload it. We need a mockup for this input (feel free to propose something via Figma + push a PR to the repo afterward)

Here's the create-profile file. The add-avatar component should rest on the create-profile folder in components

I think we could use Fleek's file storage to store these pictures then add them to the database only as URLs (this will make them slower to fetch, given IPFS slowness), but makes the website more web3 friendly in the process.

What do you guys think? @carlomigueldy @with-heart @JoviDeCroock @swetshaw @Dhaiwat10 @miralsuthar @frankTurtle

Proposal: Roadmap Page

Overview

A page where the users can see a timeline of a set of features that were implemented on each month. And they will also see upcoming features with a time estimation that we can ship it by a given timeframe? Or maybe only have a date displayed if the features were implemented. By having a roadmap page in the website, that could bring excitement for our users and may also encourage potential contributors to the project.

What are your thoughts on this everyone? :)

Company's Profile

The company profile will hold basic data about a company or startup. This data should also include links to relevant company websites if necessary. It should also have a logo and a brief description.

NOTE: Companies/startups should be on the link = devdaojobboard.com/companies/[companyname]

Proposal: Sort job/gig results by matching tags/skills

Problem
Default search results in no particular order with other job sites. Most job sites do not sort job/gig results in a way that creates a good and sensical experience for job/gig seekers.

Proposed Solution
Sort job/gig results based on matching skills.
Eg -

Dev	Job 1	Job 2	Job 3
Solidity React	Rust Python	Rust React	Solidity React

Default sorting results would look like this based on the below skills matching -

0. Job 3 (2)
1. Job 2 (1)
2. Job 1 (0)

Add Role Level Security (RLS)

Overview

It's pretty much a trivial task for now, but we'll add it later on.

Row level security (RLS for short) is a PostgreSQL security feature provided by the open source PostgreSQL database. It allows database administrators to define policies to control how specific rows of data display and operate for one or more roles. (Read more here)

You can inspect the database design here

Policies

Feel free to list down any particular rules if you can think of anything in the comments.

I'll start with a few in mind:

• Only allow update on users when the row to update matches the wallet address to id attribute
• Only allow adding of user_keyword to users that matches the wallet address to id attribute
• Only allow reads on job_applications to members of an organization that created the job posting
• Only allow reads on gig_applications to members of an organization that created the gig posting
• Only allow updates on jobs to members of an organization with the correct permissions
• Only allow updates on gigs to members of an organization with the correct permissions
• Filter out records where if the deleted_at attribute has a timestamp value

... etc, there are still more policies to be defined.

Challenges

The one thing that's going to be challenging for adding RLS is that we're not gonna be able to make use of the auth() helpers that Supabase provides since we're going to a web3-ish authentication therefore adding policies will need more thought on how we can prevent anyone randomly creating records.