oops

git clone https://github.com/OpenQDev/OpenQ-DRM-Frontend && cd OpenQ-DRM-Frontend

cp .env.sample .env && yarn && yarn dev

The app should be running now but you still need to fill in the blanks in the .env file.

GITHUB_CLIENT_ID="..."
GITHUB_CLIENT_SECRET="..."

OPENAI_API_KEY="sk-..."

TWITTER_API_KEY="..."
TWITTER_API_SECRET="..."
TWITTER_API_BEARER_TOKEN="..."

A GitHub OAuth app is required. OpenAI and Twitter credentials are used for the experimental GPT-based features.

T3 App

This is a T3 Stack project bootstrapped with create-t3-app. To learn more about the T3 Stack, take a look at the following resources:

• Documentation
• Learn the T3 Stack — Check out these awesome tutorials

GitHub Data Scanner

One motivation so far was to leverage the client (and the user's GitHub access token) as much as possible, before introducing any heavy backend components. As a result, two packages were created to handle the more demanding GitHub API queries smoothly.

The term "Scan" in the @mktcodelib/github-scanner package refers to a GraphQL query with one or more paginated properties, where all data / all pages are automatically fetched and the progress can be observed.

It uses @mktcodelib/graphql-fetch-all to handle paginated queries and adds IndexedDB for storage and Web Workers, ensuring a good UX, on top of it. From IndexedDB results can be evaluated and presented in the UI.

After running the app for the first time, you'll find a database named @mktcodelib/github-scanner-<version> with a single table called scans.

Data Evaluations

The stored "raw" data is then digested by functions that extract the desired essence from it.

Find the related utilities in src/lib/evaluation.

Charts in the UI are handled by Chart.js.

Database (IndexedDB)

In addition to the database that contains the scans and is provided by the GitHub Scanner package, the DRM uses another, local database for managing other app data, like campaigns, repositories and users.

import { store, scansDb } from "~/store";

// get all campaigns
const campaigns = await store.campaigns.toArray();

// get all scans
const scans = await scansDb.scans.toArray();

In both cases Dexie.js is used as an abstraction layer around IndexedDB. Get yourself familiar with it, if you want to work with the DRM's local databases directly. Common helpers are/should be provided by the db exports.

import { getCampaigns } from "~/db";

const liveCampaigns = useLiveQuery(getCampaigns);

See: Live Queries

Other OpenQ Services

Currently the DRM is completely independent from the other OpenQ services. Authentication via OpenQ account or providing additional data (like email addresses) is yet to be implemented.

ChatGPT

⚠️ EXPERIMENTAL ⚠️

You'll need an OpenAI API key to use the GPT features.

OPENAI_API_KEY="sk-..."

Chat Completions

/api/chat-completion is a ChatGPT endpoint that can be used to complete a given chat context.

import { completeChat } from "~/server/gpt";

const context: ChatCompletionRequestMessage[] = [
  {
    role: "system",
    content:
      "You are OpenQ-GPT: You know everything about OpenQ and currently ongoing hackathons.\n\nOpenQ is...\n\nHackathons: ...",
  },
  {
    role: "user",
    content: "I have problems claiming my hackathon prize.",
  },
  {
    role: "assistant",
    content:
      "Don't worry, we'll figure it out. What hackathon did you participate in?",
  },
  {
    role: "user",
    content: "ETH Denver, 2023",
  },
];

await completeChat(context);

The maximum response length is 64 tokens (aprrox. 80 words) by default.

You can use the ChatGPT Tokenizer to get a sense of how many tokens are in a given text.

The temperature is set to 0 by default, meaning that the responses are deterministic. Same input in, same output out. A temperature of 1 means unpredictable but more "creative" responses.

// increase response length and let it be "semi-creative"
await completeChat(context, 256, 0.5);

Repo/User Commit Summary

This is an excellent use case for this technology. If you have an OpenAI API key configured in your .env file, you can use the /api/commit-summary endpoint to get a summary of a given GitHub repository or user. You can try this in the repository card UI.

Issues / Discussions

Another handy feature could be to know, with the press of a button, what's going on in a repository's issues and discussions. GPT could be instructed to "write a report to get a sense of the community and the project's health", if provided with the relevant contents. You could of course include the commit summary in the report, too.

All in all lots of potential for generating high quality texts based on carefully tailored data, to get valuable insights into a project in a matter of momments.

Email Finder

The /api/find-email endpoint is an AutoGPT-like experiment, letting it browse the web on its own to find email addresses for a given GitHub user. You provide it with scraped website data and it replies with commands like:

url:https://google.com?q=Christopher Stevers Email
email:christopher.stevers1@gmail.com | High | Email for job opportunities

⚠️ This can get very expensive when using GPT-4. Preparing and reducing information before feeding it to a GPT is key to keeping costs low. Although there might be some hidden use cases that justify any cost.

TODO

• Email functionality
• Import (text/csv)
• OpenQ account integration
• Payments (What product? Price? Modalities?)
  • Stripe
  • Crypto?
• Overall UI/UX
  • Timeperiod for data (currently hardcoded to 30 days)
  • Scores in repo cards
  • User cards
  • Confirm modals when deleting stuff
  • Better error handling
  • Page transitions / reduce UI flickering
  • Drag & drop cards
  • Smooth GitHub API rate limit handling
  • etc.