genjutsu is a fast-paced, developer-focused social network where everything vanishes every 24 hours. share code, connect with fellow builders, and ...
For further actions, you may consider blocking this person and/or reporting abuse
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 tbh. the whole ephemeral thing changes how people post β you stop overthinking every word when you know it's gonna disappear anyway. kinda like how snapchat changed messaging culture back in the day.
curious about the tech stack tho. are you using cron jobs to clean up expired posts or is it more of a soft delete with frontend filtering? i've seen both approaches and they each have tradeoffs when you start scaling.
thanks! using both actually β frontend filters out 24h+ posts instantly on every query, and a pg_cron job hard deletes them every hour on the backend. best of both worlds, clean UX and the DB stays lean.
If you keep developing it, I would focus on two things: spam control and real-time performance. Ephemeral platforms attract bots fast, and even small spikes in traffic can break feeds or message delivery. Solve those early and the project becomes a much stronger technical demo.
spam control is already partially handled β there's a server-side cooldown (30s for posts, 15s for comments) enforced via postgres advisory locks so it can't be bypassed from the client. realtime is on supabase channels which handles the heavy lifting. but yeah, bot accounts are on my radar as the next thing to tackle.
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 π
This is pretty cool! :D
I love this, after 24 hours everything gets forgotten anyways
Nice idea
i send you pull request for performance you can check it in github repo
Best regards
IMAD ABOULHOUDA
great contribution, merged it!
its cool!!
This is a great idea! I really like the concept, it opens up for interesting social dynamics.
The UI is massive dude. Also a great idea with this project :D
Really interesting concept
Will definitely be checking out the source code. Well done! π
peak
Snapchat for the nerds
Letβs delete the user as well after 24 hours
haha tempting, but imagine having to create a new account every 24 hours just to post π the posts vanish, the people stay - someone has to feel the void when their content disappears
"A platform where everyting disappears after 24 hours" sounds like the ultimate bug dressed up as a feature :)
honestly the best bugs are the ones you ship on purpose :)
Cool, you should host it on your own hw
That's fun