--- title: Clapper Clone Script: Building the Comment and Moderation Layer description: "What a Clapper clone script ships for comments: one-level replies, server-side daily caps, owner pins, a banned-word list, report streams and role limits." url: https://miracuves.com/blog/clapper-clone-script-comment-moderation-stack date_modified: 2026-10-23 author: miracuves language: en_US --- ### Key Takeaways - A **Clapper clone script** ships a comment layer already wired end to end: add, reply, like, owner pin and delete, each as its own authenticated endpoint. - Abuse control here is deterministic, not predictive. Daily caps, a pin ceiling, an admin word list and a per-post comment switch do the work founders assume a model is doing. - Automated media screening is optional and runs on your own vendor keys. It inspects uploaded images and video, not comment text. - The Moderator role can freeze a user and delete a post or story. It cannot delete a comment. That one detail decides how you staff a rota. - Communities, groups and clubs do not ship in this build. A shared-space product is custom scope. - Every comment interaction can raise a push notification, so conversation volume and notification volume are the same number. ## What does a Clapper clone script actually ship for comments? Most short-video founders budget carefully for the feed, the camera and the payout rails, then treat comments as a text box someone will add later. That is the wrong order. The feed decides whether a video gets watched. The comment layer decides whether anybody comes back tomorrow, and it is where your support cost, your legal exposure and your app-store review risk converge. This post covers what a documented conversation and moderation layer looks like in practice, field by field and endpoint by endpoint. For the product, pricing and demo view, start at the [Clapper clone](https://miracuves.com/clapper-clone/) page and come back here for the plumbing underneath it. The foundation we work from is a Flutter client against a single Laravel API and one MySQL database. Comments are not a bolt-on module. They are first-class tables with their own endpoints, their own limit settings in the global configuration row, and their own line in the admin panel. So the questions founders spend weeks specifying are already answered: what a reply is, how deep threading goes, who can pin, and what happens when someone posts a hundred comments in a minute. Your job is deciding whether you agree. ![Desktop short-video platform messaging screen with a conversation thread, message input, and contact list](https://miracuves.com/wp-content/uploads/2026/05/Chat-1024x502.webp "Clapper Clone Script: Building the Comment and Moderation Layer 1")Image Source: Miracuves product screenshot. ## How is the comment layer modeled, and why does that shape matter? Three tables carry the whole surface. A comments table holds the post reference, the author, the body and a pinned flag. A comment-likes table holds one row per user per comment. A third holds replies, each row pointing at a parent comment and carrying its own body and its own list of mentioned user IDs. Read that third table carefully, because it is the most consequential decision in the layer. Replies point at a comment, not at another reply. Threading is exactly one level deep, and there is no documented path to a reply-to-a-reply chain. Founders read that as a limitation. In a vertical video product it is closer to a feature. Deep nesting is expensive to moderate, because context lives six levels up and a moderator has to reconstruct an argument before judging one line. A one-level model keeps every decision local. Two other fields matter. The pinned flag lives on the comment row, so pinning is cheap to query. And the mentioned-user-ID column means mentions are structured data, not strings parsed at read time, which matters for notification delivery and for abuse: a mention is something you can count and cap. ## Which comment actions exist, and who is allowed to call each one? The endpoints are documented individually, and the permission model is encoded in which endpoint exists rather than in a matrix you configure later: - Add a comment, taking the post ID, the body and a list of mentioned user IDs. - List comments on a post with pagination, and list the replies of a single comment separately. - Fetch a single comment by ID, and fetch a single reply by ID. - Like and unlike a comment. - Reply to a comment, and delete a reply. - Delete your own comment. - Pin and unpin a comment, restricted to the owner of the post. - Report a comment, which writes to a dedicated comment-reports table. Notice what the delete endpoint says: delete your own comment. Not delete a comment. That is the correct default and the source of the enforcement gap covered below. Pinning is owner-scoped and capped. The post owner pins, and a global setting for the maximum number of comment pins decides how many a single post can carry. Small lever, outsized effect: one pin makes a creator’s top comment feel like an answer, five make it a curated page. Set it deliberately rather than discovering later that creators use it to stack promotional links. A per-post switch on the post record controls whether the post accepts comments at all. That is a creator-side control, and the cheapest de-escalation tool in the build: a creator being brigaded can close one post without you freezing anybody. One optional addition sits in the same surface: GIFs in chat and comments run through a Giphy API key the operator supplies, behind a GIF-support flag. No key means no GIFs, and you carry the vendor cost only if you switch it on. ## How do you cap comment spam without a machine learning model? Here is the part that surprises people, so it is worth stating without hedging: there is no machine learning in this moderation layer. The product requirements and feature documentation contain no model, no classifier, no scoring pipeline and no toxicity signal. Nothing in the shipped build reads a comment and forms a judgment about it. What it has instead is counters, and counters are better than founders expect. The global settings row carries per-user daily maximums: one for uploads, one for stories, one for comments and a separate one for comment replies. These are enforced in the backend, which is the detail that matters. A cap enforced in the client is a suggestion, because anybody with a proxy can ignore it. A cap enforced server-side is a wall. The same row carries the comment pin ceiling, so the whole family of volume limits is configured in one place. Consider what a daily cap defeats. The dominant abuse pattern in a young short-video app is not a cleverly worded insult a classifier would catch. It is volume: one account posting the same link under two hundred videos, or a few accounts flooding a trending post. A server-side counter stops that with no false positives on the content itself. A model that misreads a joke as harassment creates a support ticket. A counter creates nothing. The honest limitation is the other half. Counters are blind to meaning. One well-aimed comment from an account that posted nothing else passes every limit in the system, and the only things between it and your user are the word list, the report flow and a human. ## What does the word filter catch, and what does automated screening not cover? There is a banned-word check on the comment path, backed by an admin-managed table with a uniqueness constraint on the word, and the documented seed list ships with fifteen terms. Submit a comment containing a listed term and the add-comment call rejects it with a message saying the comment contains a banned word. The comment is never written, and admins edit the list from the panel without a deploy. Fifteen seed terms is a starting point, not a policy. Grow the list weekly from your own reports queue. The terms that matter in a regional audience are rarely on a generic English list: they are slurs in the local language, the scam schemes currently circulating, and the handles your spammers funnel people toward. Be equally clear about the ceiling. Exact-match filtering loses to deliberate evasion within a day of a spammer noticing it; spacing, substituted characters and transliteration all walk straight through. It is a floor, not a content-safety system, and it is worth having because every comment it blocks is a report nobody files. The automated screening most founders picture when they say moderation is a different thing entirely. Sight Engine is a documented integration for automated image and video screening, configured with workflow IDs behind a content-moderation flag, and it can block an upload. Three qualifications you need in writing: it is optional, it runs on your own vendor keys and account, and it is not bundled with the codebase. It inspects media, not comment text, so it does nothing for the conversation layer. The compliance notes are also explicit that the policy around flagged content is yours to define, from whether a flag blocks outright or lands in a review queue to how appeals get a human look. Switching on a vendor key is not a policy. For the wider view, we covered that separately in [AI moderation for short-video apps](https://miracuves.com/blog/ai-moderation-for-short-video-apps/). ## Who can actually remove a comment once it is posted? This is the detail most often discovered after a trust and safety hire has already started. The build has seven documented roles, and one is a Moderator: a platform-appointed user, flagged on the user record, assigned and unassigned by an admin. Their powers are four documented endpoints. They can freeze a user, which prevents that account logging in or acting. They can unfreeze a user. They can delete any post. They can delete any story. There is no moderator endpoint for deleting a comment. Comment removal is documented in exactly two places: the author deleting their own comment, and an admin-level delete-comment action in the admin panel’s post, story and comment management. The admin surface is complete. The moderator surface is not. Work through a Saturday night. A moderator sees a harassing comment on a popular video. Their moves are to delete the entire post, punishing the creator for something a stranger wrote, or to freeze the commenting account, the heaviest sanction in the system. The proportionate move, removing one comment, requires an admin login. Three sane responses, and you should pick one before launch rather than during an incident. Keep an admin on call and accept the latency. Give moderators admin accounts and accept that they then hold settings and payout access too. Or scope a moderator-level comment delete as custom work, which is the cleanest answer and a small one, since the admin action and the role check both exist and only need joining. Live streams are the one place where mid-conversation moderation is already delegated. Mute, unmute and kick actions exist for a live room, authorized for the host or a moderator, and each is written to a moderation-actions ledger rather than applied silently. That is the shape the comment layer lacks: a scoped action, a delegated role, and an audit trail. ## How does a report travel from a tap to your admin panel? Reporting connects your users’ judgment to your staff, and here it is structured rather than freeform. Users do not type a complaint; they pick from a list of report reasons that admins define and edit from the panel. That constraint is worth more than it looks. Freeform reports arrive as paragraphs somebody has to read before triaging, and they cannot be counted. Reason-coded reports sort themselves: you can see that spam reports tripled this week while harassment held flat, and route the two differently. Five or six reasons that map to actions you will actually take beat twenty that produce a queue nobody can act on. Three streams are documented, each with its own table: post reports carrying the reporter, post and reason; user reports carrying the reporter, reported user and reason; and comment reports, which have their own table and their own admin listing with search. That last one matters here, because comment complaints are not folded into the post report queue and do not get buried under video complaints. Resolution is an admin action: accept or reject, where accepting means taking the implied action, typically deleting the post or freezing the user. This is a two-outcome workflow, not a status pipeline. No in-review state, no assignment to a specific moderator, no ticket history. A queue with ownership and SLAs is reporting you build on the data rather than inherit. Users also have a self-serve lever that costs you nothing. Block and unblock exist as endpoints with a blocked-list view in settings, and blocked users cannot interact. Every block is a report you never receive, so make the control easy to find: the cheapest moderation in any social product is the moderation your users do for themselves. ![Administrator analytics dashboard with user and post trends, registered-user totals, content totals, reports, withdrawals, and moderation status](https://miracuves.com/wp-content/uploads/2026/05/AdminDashboard-1024x506.webp "Clapper Clone Script: Building the Comment and Moderation Layer 2")Image Source: Miracuves product screenshot. ## Which moderation lever fits which abuse pattern? Every lever above is already in the build. The mistake is reaching for the wrong one, usually the heaviest. Give this table to whoever is on the rota. | Abuse pattern | The right lever | Where it lives | Who can act | What it will not do | | --- | --- | --- | --- | --- | | One account posting the same link under many videos | Daily comment and reply caps | Global settings, enforced in the backend | Admin sets it once; the API enforces it | Nothing about the first comment of the day | | Known slurs, scam words, competitor handles | Banned-word list on the add-comment path | Admin word table, no deploy needed | Admin edits the list; the API rejects the comment | Spaced, substituted or transliterated evasions | | A creator being brigaded on one video | The per-post comment switch | Flag on the post record | The creator, without contacting you | Anything about the accounts doing the brigading | | Promotional noise drowning a good thread | Owner comment pinning, capped | Pin endpoint plus the pin ceiling setting | The post owner only | Remove anything; it only reorders | | A single harassing comment | Admin comment delete, raised by a comment report | Admin panel comment management | Admin, or the author deleting their own | Reach a Moderator; there is no moderator comment delete | | An account that will not stop | Freeze the user | Moderator and admin endpoints, freeze flag | Moderator or admin | Anything proportionate; it ends all app access | | Two users who simply cannot coexist | User block | Block endpoints and the blocked list in settings | Either user, with no staff involvement | Produce any record you can review later | | Harmful uploaded media | Optional automated screening on your own keys | Content-moderation flag and workflow IDs | Admin configures; the vendor screens the upload | Read comment text, or arrive bundled | | Disruption inside a live room | Mute, unmute, kick, written to a ledger | Live moderation actions | The host or a moderator | Apply to comments on ordinary posts | Two readings fall out. The lightest levers, caps and the word list, are configuration you set once and never touch during an incident, which is where defenses belong. And the ladder has a missing rung between delete-one-comment and freeze-the-account. ## What happens the moment a comment lands? A comment is not a quiet database write. Activity notifications fire on like, comment, follow and gift, stored in a table recording the actor, the recipient, a type and the ID of the related post or comment, and pushed over Firebase Cloud Messaging using a device token on the user record. This is the number founders model last and should model first. Your conversation volume is your notification volume. A video attracting four hundred comments generates four hundred stored rows and up to four hundred pushes to one creator’s phone. There is no documented batching or digest layer, so the tray becomes unusable at exactly the moment that creator is having their best day on your app. You have two levers. Per-user notification preferences carry independent toggles for post likes, comments, follows, mentions, gifts and chat, letting a creator switch off the noisiest channel without going silent. And the structured mention IDs let mentions be treated as a higher-value class than a generic comment ping. A creator who can mute comment notifications but keep mentions stays reachable. The constraint is the processing model. There are no queue workers in this build. Background work runs on cron and scheduled commands, with documented jobs for deleting expired stories, deleting old notifications and counting daily active users. That is fine for housekeeping, and it is why old notification rows do not accumulate. It also means you should not design a moderation feature that assumes asynchronous job processing. Admins can also create broadcast notifications with a title, description and image, and resend one to the device topics. That is your incident channel: when you change a comment policy, announce it the same day, because policy nobody was told about reads as arbitrary enforcement. ## Why there is no community, group or club layer in this build Communities, groups and clubs do not ship. Searching the full documentation set for those words returns a handful of hits and not one describes a feature: they appear in marketing prose about building a brand community, and in a line describing the Moderator role as enforcing community rules. There is no group table, no membership model, no group-scoped feed, no group role and no group moderation path. Any proposal that quietly assumes that shared-space framing is either describing custom scope or describing something that does not exist. What you have instead is a set of adjacent primitives. Hashtag feeds give topic-scoped browsing. Location and nearby feeds give geography-scoped browsing, backed by place fields on the post record. Following feeds give person-scoped browsing. Creator subscription plans and subscription-only posts give a paid audience boundary. Together those cover much of what founders mean by community. What they do not give you is a persistent space with its own membership list, rules and appointed moderators. If that space is the core of your thesis, you are commissioning a build and should price it as one from the start. If it is a phase-two ambition, the primitives above carry a real product a long way first. ## Founder Decision Signals Use these to decide whether a documented comment and moderation layer fits what you are building, before you compare quotes. - **You want to launch in weeks, not quarters.** A wired comment layer with endpoints, limits and an admin surface removes a whole design and build phase. - **One-level threading is acceptable.** If your product needs branching discussion trees, you are specifying a forum and should say so out loud. - **You can name who removes a comment at 11pm.** If the answer is an admin, proceed. If it is a moderator, budget the custom work now. - **You accept that screening is yours to arrange.** Automated media screening runs on your own vendor account, and comment text is not covered by it. - **Shared spaces are phase two.** No groups, no clubs. If that is a deal-breaker, you are in custom territory. - **You have someone to own the word list and the reason list.** Both are editable from the panel and both decay if nobody tends them. - **You are planning notification volume alongside comment volume.** They are the same number. ## Common Comment Moderation Mistakes to Avoid Each of these is avoidable with a decision made before launch rather than during an incident. - **Assuming a model is reading your comments.** Nothing in this build judges comment content. Caps, a word list and human review are your defenses. - **Leaving the caps and pin ceiling at their defaults.** They are enforced server-side, which makes them your cheapest controls, and worthless if nobody chose the numbers. - **Treating fifteen seeded banned words as a finished list.** It is a floor. Grow it weekly from your own reports queue, in the languages your audience uses. - **Promising moderators a tool that does not exist.** The Moderator role deletes posts and stories, not comments. Say that in week one, not week six. - **Writing twenty report reasons.** Keep the list to the outcomes you will act on, so the queue stays triagable and the counts stay meaningful. - **Buying a vendor key and calling it a safety policy.** Flagged-content handling, appeals and reason mapping are all yours to define. - **Designing features that assume background workers.** There are none. Scheduled work is cron-only, so anything expected to react in seconds belongs in the request path. - **Shipping without the hardening pass.** Rate limiting on sensitive routes, two-factor authentication for admin logins and audit logging of admin actions are recommendations in the security documentation, not features in the build. Your admin panel can freeze accounts and delete content. - **Hiding the block control.** User blocking is already built and costs nothing per use. Surfacing it well is the highest-leverage moderation work your design team can do. ## How a Ready-Made Foundation Fits a Conversation-Led Build The argument for a documented foundation is not that it is cheaper. It is that the parts of a conversation layer that take longest to get right are the parts nobody demos. Nobody asks to see your daily comment cap. Everybody notices when your comment section fills with scam links in week two. At [Miracuves](https://miracuves.com/solutions/entertainment/video-content-platform/) we work from a documented video platform codebase where the comment tables, the endpoint list, the limit settings, the report streams and the role model are already specified and already in the admin panel. That is what a Clapper clone script is in practice: not a visual copy of somebody’s app, but a foundation where the unglamorous decisions have been made, written down, and are open to inspection before you commit. It also means we can tell you where it stops. The moderator comment-delete gap is real and we would rather you heard it here than found it in production. Groups and clubs are not in the build. Automated screening is optional and runs on your keys. None of those are reasons not to launch; they are the inputs to a launch plan that survives contact with real users. A foundation pays off most when your differentiation sits upstream of the plumbing. If your bet is a specific audience, tone or creator relationship, rebuilding comment pagination and a report queue is pure cost. Our wider work across [media and entertainment](https://miracuves.com/industries/media-entertainment/) products follows the same shape: inherit the documented layer, spend your budget on what makes the product yours, and add the custom pieces when a real need names them. ## Final Thoughts The comment layer is where a short-video product stops being a content feed and becomes a place. That is also where it becomes your liability, and a documented foundation gives you a specific, verifiable starting position rather than a promise. It also hands you four honest absences: no model reading your comments, no moderator-level comment delete, no groups or clubs, and no background workers. Each is workable in planning and expensive in production. Decide all four before you write a launch date, pick your numbers for the caps and the pin ceiling on day one, name the person who owns the word list, and schedule the hardening pass as part of launch. ## FAQs ### Does the comment layer include AI or machine learning moderation? No. The product requirements and feature documentation contain no model, classifier or toxicity score. Comment abuse control is deterministic: per-user daily caps enforced in the backend, an admin-managed banned-word list that rejects a comment before it is written, a per-post switch to close comments, and human review of reports. The optional Sight Engine integration screens uploaded images and video, not comment text, and it runs on your own vendor keys. ### How deep does comment threading go? Exactly one level. Replies are stored in their own table and point at a parent comment, not at another reply, so you get a comment with a flat list of replies beneath it. There is no documented reply-to-a-reply chain. For a vertical video product this is usually the right trade: it keeps every moderation decision local, because the comment and its replies are the whole unit of judgment. ### Can a moderator delete a comment? No, and this is the most important operational detail to plan around. The documented Moderator role can freeze and unfreeze a user and delete any post or story. Comment removal appears in only two places: the author deleting their own comment, and an admin-level delete-comment action in the admin panel. A moderator-scoped comment delete is a small piece of custom work, since the admin action and the role check both already exist. ### What stops one account from spamming hundreds of comments? Per-user daily maximums in the global settings row, with separate limits for uploads, stories, comments and comment replies, enforced in the backend rather than in the client. That is what makes them meaningful: a client-side cap is a suggestion, a server-side cap is a wall. Volume is the dominant abuse pattern in a young short-video app, and a counter defeats it with no false positives on content. ### Does this build include communities, groups or clubs? No. There is no group table, membership model, group-scoped feed, group role or group moderation path anywhere in the documentation. What you do get are adjacent primitives: hashtag feeds for topic-scoped browsing, location and nearby feeds for geography, following feeds for person-scoped browsing, and creator subscription plans for a paid audience boundary. A persistent shared space with its own membership and moderators is custom scope. ### How do user reports reach the admin panel? Users pick from a list of report reasons that admins define and edit from the panel, so reports arrive coded rather than freeform and can be counted and routed. Three streams are documented, each with its own table: post reports, user reports, and comment reports with their own searchable admin listing. Resolution is a two-outcome admin action, accept or reject, with no in-review state, assignment or ticket history. ### Can users post GIFs in comments, and what does that cost? Yes, with a condition. GIFs in chat and comments run through a Giphy API key that you supply as the operator, behind a GIF-support flag in settings. It is optional and not bundled, so no key means no GIFs and the rest of the comment layer is unaffected. You carry the vendor cost only when you switch it on, which makes it a later engagement lever rather than a launch dependency. ### What should we harden before opening comments to the public? Three things the security documentation raises as recommendations rather than shipped features: rate limiting on sensitive routes, two-factor authentication for admin logins, and audit logging of admin actions. Your admin panel can freeze accounts and delete content, so treat that pass as part of launch. Also note there are no queue workers in this build, only cron and scheduled commands. ## Disclaimer **Miracuves is an independent software development company.** We are not affiliated with, connected to, sponsored by, or endorsed by any of the brands or platforms named on this page. Names of the form “Brand Clone” are used descriptively: it is how the software industry refers to building a platform with functionality comparable to a known service, and how clients search for it. The entire design and codebase of our products is built by our own team and contains no code, design, graphics, or content originating from any third-party website or application. All third-party names and marks are the property of their respective owners. [Full Legal Notice & Disclaimer](https://miracuves.com/disclaimer/)