genjutsu is a fast-paced, developer-focused social network where everything vanishes every 24 hours. share code, connect with fellow builders, and stay in the loop without the clutter of a permanent history.
live link: genjutsu-social.vercel.app
source code: github.com/iamovi/genjutsu
screenshots
in a world of digital permanence, genjutsu offers a temporary space for ephemeral thoughts. whether it's a quick code snippet, a late-night epiphany, or a daily progress update, it lives for 24 hours and then disappears—leaving no trace.
key features
- 24-hour lifespan: every post, comment, and interaction has a strictly enforced 24-hour timer.
- developer first: optimized for sharing code and technical insights.
- real-time connection: built for instant engagement with a community of builders.
- manga aesthetic: a clean, high-contrast visual style inspired by japanese manga.
- zero clutter: start every day with a fresh feed and a clean slate.
why genjutsu?
most social platforms are designed for the long term, which often leads to performance anxiety or a fear of being "on the record" forever. i designed genjutsu to remove that pressure. it's a place to be experimental, raw, and authentically you, knowing that your mistakes or half-baked ideas won't follow you around for years.
the tech stack
- frontend: react with vite
- styling: tailwind css for that crisp manga look
- animations: framer motion for smooth transitions
- backend: supabase for real-time magic
- deployment: vercel
roadmap
i am just getting started. some things on the horizon include:
- ephemeral messaging (whispers) that also vanish after 24 hours.
- social mini-games to play together within the platform.
- dynamic open graph images for better social sharing.
- progressive web app (pwa) support for a native feel.
join the loop
genjutsu is open source. i built this for the developer community, and i would love for you to be a part of it. whether you want to fix a bug, suggest a feature, or help with the manga-inspired design, your input is welcome.
if you are interested in helping out, please check the CONTRIBUTING.md file on github. let's build something ephemeral together.
no archives, no legacy, just what's happening now.
Top comments (35)
fun :)
coming from you, that hits different 😄 thanks ben!
ops
This is a genuinely interesting product idea. The performance anxiety point is real. A feed that resets every day changes how people write, and it probably makes experimentation feel safer.
The hard part with anything ephemeral is trust and safety. People want it to disappear, but you still need moderation, abuse handling, and some kind of honest answer about what deletion actually means on the backend.
When a post expires, is it a true delete from the database, or just hidden from the UI. And how do you handle reports that come in after something has vanished
really glad you brought this up — these are the exact questions every ephemeral platform should have clear answers to.
hard delete — pg_cron hits postgres every hour with DELETE FROM posts WHERE created_at < now() - INTERVAL '24 hours'. comments cascade with the post, dms have their own cleanup job. nothing is hidden from ui, nothing is archived.
post-expiry reports is a genuine gap right now. since the content is gone by the time a late report comes in, the plan is a minimal reports table — just reporter, reported user, reason, timestamp. no content stored, just enough to catch repeat offenders.
and honestly the strongest trust signal i can offer — it's fully open source. every migration, every rls policy, every cron job is sitting right there in the repo. you don't have to take my word for how deletion works, go read it. prs welcome too. 🙌
That is a solid answer and I respect how direct it is. Hard delete on a schedule with nothing hidden is the cleanest way to honor the promise, and using open source as the trust surface is the right move.
The minimal reports table idea makes sense too. It keeps the platform honest about not storing content while still letting you detect patterns. The only thing I would watch for is abuse that depends on context. Sometimes the reason text alone is not enough to distinguish nuisance reports from real harm.
If you want a middle ground that still respects the ethos, you could store a tiny amount of non content metadata tied to the post at creation time. For example a post id, author id, and a salted hash of the content, plus maybe the client timestamp. That way you are not keeping the post, but you can correlate repeated incidents and block obvious evasion without reintroducing a shadow archive.
Also curious how you are thinking about rate limiting and friction. On ephemeral platforms, spam can burn trust fast because the cleanup job does not stop the harm in the moment.
that salted hash idea is genuinely smart, store just enough to correlate incidents without ever being able to reconstruct the content. going to steal that for the reports table design, clean middle ground.
rate limiting is an honest gap right now. supabase rls handles access control but there's no aggressive cooldown on post creation yet. spam on an ephemeral feed is extra dangerous because there's no history to bury it in, it just floods the only feed people have. per-user cooldowns on the api side is next on the list before this scales. this thread is basically the architecture review i needed.
honestly this is just the beginning, a lot more to build and a lot of room to grow. contributions from anyone who cares about building it right are always welcome, hope to see you in the repo.
Love that you are willing to steal the hash idea. That is exactly the kind of compromise that keeps the promise intact while still giving you a way to see patterns.
On rate limiting, you are thinking about it the right way. For an ephemeral feed, you almost want friction to be a feature, not a bug. A little delay protects the vibe more than any cleanup job ever will.
If you want a simple starting set that works without getting fancy, I would do per user cooldowns plus a couple hard caps. Something like a minimum time between posts, a daily post limit, and a separate limit for comments or replies. Then add a gentle ramp where new accounts are stricter and accounts that behave well earn more throughput over time.
Also worth thinking about how you surface the friction. If someone hits a limit, a calm message that explains why tends to reduce churn and reduces the urge to game it.
If you drop an issue in the repo for rate limiting, I would be happy to review the plan and help you sanity check the edge cases.
opened an issue for the rate limiting plan if you want to take a look — github.com/iamovi/genjutsu/issues/2
Perfect, thanks for opening it. I took a look and dropped a detailed comment on the issue.
Main theme is the same as we talked about in the thread. If posting is still a direct client insert, any limits are bypassable. The moment you move it behind one guarded server or database path, the whole thing becomes real.
Happy to keep reviewing as you implement it. This is the right kind of boring safety work that protects the vibe.
Wow wow this is really impressive and nice the UI in fact is amazing 👏🏼💫
"Please Speed I neeeeed thissssss. I kinda of want to contribute. I am on Dev.to, just looking around" lol.
In all seriousness, great work! I will keep it bookmark for now to come back to this and glad you found a problem and create a solution! Great work again :D
thanks bro, this means a lot,
contributors are always welcome!!! ♥️
This is an interesting experiment in rethinking how social platforms handle permanence and noise. Building a developer-focused network where posts disappear after 24 hours creates a lightweight space for sharing ideas, quick code snippets, and progress updates without the pressure of maintaining a permanent digital record.
The concept of ephemeral content can encourage more authentic and frequent interaction, especially for builders who want to share in-progress thoughts rather than polished posts.
It’s a creative approach to reducing long-term clutter while still fostering connection within the developer community.
this is exactly the vision — no pressure, no permanent record, just builders sharing raw thoughts. glad it came across that way.
This is such a cool concept! A social network for devs where everything vanishes after 24 hours feels like a mix of Snapchat and GitHub.
I love the idea of sharing code without the pressure of permanence. Quick question: how do you handle moderation if content disappears so fast? And what's the tech stack behind it?
Will definitely check out the live link. Great work
snapchat meets github, i love that framing honestly.
moderation runs within the 24-hour window. posts are hard deleted via pg_cron every hour, comments cascade delete with the post, and dms have their own separate cleanup job. planning a minimal reports table to track abuse patterns without storing actual content.
stack is react 18 + typescript + vite, tailwind + shadcn/ui + radix-ui for the ui, framer motion for animations, supabase for database, auth, storage and realtime, tanstack react query for data management, react router for navigation, deployed on vercel. fully open source, every migration, rls policy and cron job is readable in the repo. hope you enjoy the live link!
Great work! Really impressive 🔥
thanks bro 🙌
I love this, after 24 hours everything gets forgotten anyways
its cool!!
Nice idea
i send you pull request for performance you can check it in github repo
Best regards
IMAD ABOULHOUDA
great contribution, merged it!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.