Serein
Rust로 만든 가볍고 성능 좋은 Discord 전용 네이티브 클라이언트
프로필 한 링크로 팔로워를 커뮤니티로 모아 최고의 아이디어와 사람을 보여주고 팬에게 스포트라이트를 제공합니다
One link in your bio that gathers your followers into communities, surfaces the best ideas and people, and lets you give fans your spotlight.
소셜TypeScript · CSSGitHub @neilkumar93600온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
Startupathon challenge: Operating System for Fanbases (Persist Ventures).
Goal: move a creator's audience from Followers -> Organized communities -> Ideas -> Collaboration -> Action.
One link in a creator's bio that gathers followers into communities, surfaces the best ideas and people, and lets the creator put their reach behind what the community builds.
Needs Node 24, pnpm (version from package.json) and Docker.README 전문 보기 ↗Startupathon challenge: Operating System for Fanbases (Persist Ventures). Goal: move a creator's audience from Followers -> Organized communities -> Ideas -> Collaboration -> Action.
One link in a creator's bio that gathers followers into communities, surfaces the best ideas and people, and lets the creator put their reach behind what the community builds.
| Part | What | Runs on |
|---|---|---|
web/ | Next.js 16 app: bio pages, fan pages, creator dashboard | Vercel |
api/ | Express 5 API: business logic, auth (Better Auth), AI, Drizzle + Postgres | Railway |
shared/ | zod schemas, enums and limits used by both | built into both |
docs/ | The build docs (below) |
Needs Node 24, pnpm (version from package.json) and Docker.
pnpm install
docker compose up db # Postgres with pgvector on :5432
cp api/.env.example api/.env # defaults work for development
pnpm db:migrate # apply the SQL migrations
pnpm dev # web and api through Turborepo; api on :4000
The web app rewrites /api/* and /r/* to the API (API_URL, http://localhost:4000 in development). Without OPENROUTER_API_KEY a deterministic fake AI answers, so every screen works with no keys. docker compose up --build runs the database and the API in containers instead.
Scripts (root package.json): pnpm dev, build, typecheck, lint (Biome), test:unit, test:integration (needs the Postgres from Docker), test:e2e (Playwright smoke test), db:generate, db:migrate, db:embed (backfill embeddings, needs an AI key), db:studio.
Production is one Railway project plus one Vercel project. Details and every variable are in docs/02-trd.md, sections 2 and 3.
| Service | Setup |
|---|---|
api | Build from api/Dockerfile (context: repo root; .railwayignore trims the upload). Pre-deploy command: node dist/db/migrate.js, so migrations run before traffic moves. Health check: GET /api/health (503 when the database is down). Set RAILWAY_DEPLOYMENT_DRAINING_SECONDS so open requests finish on a deploy. Per-IP limits use Railway's X-Real-IP, or the visitor IP that web/proxy.ts sends as x-edge-client-ip when the request also carries x-edge-key = INTERNAL_API_KEY, so set the same INTERNAL_API_KEY on both services |
pgvector | Postgres with the vector extension. DATABASE_URL on api points at it |
| Redis | REDIS_URL on api: rate-limit counters, daily caps, code throttle and live notifications across replicas. Optional |
cron | Schedule 0 * * * *. Its start command calls POST /api/cron/tick on api with Authorization: Bearer $CRON_SECRET. The tick runs the hourly jobs (sweep, question grouping, challenge closing, email digests) and the daily and weekly ones (follower refresh 06:00 UTC, retention purge 09:00 UTC, community digests Mondays 13:00 UTC). A missed hour catches up on the next tick. GET /api/cron/status shows recent runs; POST /api/cron/tick?job=<name> runs one job now |
media bucket | S3-compatible bucket for image uploads. Give api its BUCKET_ENDPOINT, BUCKET_NAME, BUCKET_ACCESS_KEY_ID and BUCKET_SECRET_ACCESS_KEY (all four, or uploads stay off). Set the bucket's CORS once so browsers can PUT and GET from the web origins (production, previews, localhost) |
Rows written while AI was off have no embeddings: run pnpm db:embed against the database with an AI key to backfill them.
Project fellow-owners-web (the Next.js app in web/). Environment variables:
| Variable | What |
|---|---|
API_URL | Origin of the Railway api service. The rewrites and server-side reads use it |
NEXT_PUBLIC_APP_URL | The public web origin, for links people copy or scan. Optional |
INTERNAL_API_KEY | Server-only, 32+ characters, the same value as on api; lets the web server's reads skip the API's per-IP rate limits, and proxy.ts (which rewrites /api/* to API_URL) sends it as x-edge-key with the visitor's IP as x-edge-client-ip, so the API counts the visitor's IP, not Vercel's |
NEXT_PUBLIC_GA_ID | Google Analytics 4 measurement id (G-…). Optional; loads only after a visitor accepts analytics cookies. Set before building |
GOOGLE_SITE_VERIFICATION | Google Search Console HTML-tag token (the content value only). Optional |
BING_SITE_VERIFICATION | Bing Webmaster Tools msvalidate.01 token. Optional; Bing's index also feeds ChatGPT search and Copilot |
On api, set WEB_ORIGIN and BETTER_AUTH_URL to the web origin (auth is reached through the web rewrite), and TRUSTED_ORIGINS for preview deployments.
Only in the Railway and Vercel environment variables. api/.env.example lists names, never values; api/src/config/env.ts checks them on boot and stops the process with the full list of problems. In production the API requires DATABASE_URL, BETTER_AUTH_SECRET (32+ characters), RESEND_API_KEY with EMAIL_FROM, CRON_SECRET and CLICK_SALT. Optional keys switch features on: OPENROUTER_API_KEY (live AI), GOOGLE_*, APPLE_*, FACEBOOK_* (sign-in), APIFY_TOKEN (profile lookups), YOUTUBE_API_KEY (comment import), FAL_KEY (media generation), ADMIN_EMAILS (admin allowlist).
These docs follow the "Six Documents Before Vibe Coding" template. Give them to the coding agent together.
| # | Document | Answers |
|---|---|---|
| 01 | PRD | What we build, for whom, how we know it worked, what is built |
| 02 | TRD | Stack, hosting, environment, API, jobs, AI design, security, decisions |
| 03 | App Flow | Every screen, journey, action, empty state |
| 04 | UI and UX Design Brief | Visual language, tokens, components |
| 05 | Backend Schema | Tables, relationships, authorization, validation, retention, seed |
| 07 | File Structure | The repo tree and naming rules |
If two documents disagree, do not guess. Flag it, and resolve in this order: PRD (what) > App Flow (behavior) > Backend Schema (data rules) > TRD (how) > UI brief (look). Then update the losing document. The glossary is in docs/README.md.