--- title: MYM Clone Script: A Private Vault and Segmented Mass Sends description: "What a MYM clone script's vault and mass sends really do: the tables behind them, signed-URL behavior, the missing access log, and how segmentation works." url: https://miracuves.com/blog/mym-clone-script-vault-and-mass-sends date_modified: 2026-10-23 author: miracuves language: en_US --- ### Key Takeaways - A **MYM clone script** gives you two surfaces founders underestimate: a creator-side media vault and a one-to-many send. Both are thinner in the data model than in any feature grid. - Vault protection depends on which storage disk you configure. One helper returns a permanent public link for a public disk and a one-hour signed link for a private one, so the control is your deployment choice. - The requirements document promises vault access logging, but no table in the 118-table catalog records who opened a vault item. - Segmentation is a hand-filled list. A list and its members are two plain tables with no rule or criteria column, so every segment is curated by a human and goes stale by itself. - A creator broadcast writes ordinary message rows carrying no link back to the broadcast that produced them. Per-send attribution is a migration, not a setting. - Folder organization, vault search and bulk download appear in the feature catalog with no table, column or endpoint behind them. Every creator platform ends up with a room where the unreleased work lives. Creators call it the vault. The other surface that matters as much is the send, which puts one message in front of several thousand people without opening several thousand conversations. Both appear on every comparison grid in this category, usually in one line. “Private encrypted content storage, bulk download.” “Admin and creator broadcasts, scheduled, email.” Those describe intent, not a data model. If you are evaluating a [MYM clone](https://miracuves.com/mym-clone/) build, or any platform in the [creator economy](https://miracuves.com/industries/creator-economy/), what decides your first six months is not whether the vault exists but what it is made of. What follows walks both surfaces down to their tables and routes, from the platform’s own engineering documentation, and names the gaps: a gap you know on day one is a sprint, a gap you find in month four is an incident. ## What does a creator vault actually store, column by column? In the schema reference the vault is one table, `vaults`, in the content domain as table 30 of 118. Seven columns: a primary key, the owner’s `user_id`, a `name`, a `description`, an `is_locked` flag defaulting to on, a nullable `access_price`, and a `media_count` integer. No file path, no MIME type, no size, no thumbnail. The `vaults` table does not hold media at all. It is a named container with a lock flag and a counter. The media lives in the polymorphic `media` table, table 15, which attaches to any owner through a `model_type` and `model_id` pair and carries the asset columns: `file`, `thumbnail`, a `type` enum of image, video or audio, `size`, `duration`, dimensions and a display `order`. A vault item is a `media` row whose owner is a vault. That is sound design: it is the same table serving posts, so an asset moves into a post or message without being copied. Two consequences. `media_count` is a denormalized cache, so any import or bulk delete that skips the application layer leaves the counter lying to the creator. And the `media` enum is image, video and audio only, while the feature catalog says the vault holds “images, videos, files.” The message attachment table carries a file type; the polymorphic media table does not. Parking PDFs or archives in the vault is a column change before launch, not a toggle. ![Creator vault displaying uploaded photos and videos with search, upload controls, and storage management](https://miracuves.com/wp-content/uploads/2026/06/5-Vault-MxFans-Support-Creators-Content-06-27-2026_01_27_PM-1024x573.webp "MYM Clone Script: A Private Vault and Segmented Mass Sends 1")Image Source: Miracuves product screenshot. ## Is vault media genuinely access-controlled, or just unlisted? This is the most important question on this page, and the honest answer has two halves. The application route is gated: of the four documented vault endpoints, upload, list and the composer’s media picker require authentication, and the per-item download route carries a purchase and access check. The stored object is a different matter. In the security assurance review, the shipped upload control protecting a stored path is “randomized filenames,” whose stated objective is to “prevent path guessing and overwrite attacks,” and the API collection adds that each media record captures a unique token. So the default protection for the object behind the record is that the path is long and unguessable. That is obscurity. It is useful, and it is not an expiring credential. Signed URLs do exist, and the mechanism shows where responsibility sits. The storage abstraction exposes one URL helper with a default expiry of 3,600 seconds, and inside it branches: for a public provider it returns a plain permanent URL, otherwise a temporary URL that expires. The architecture document’s bucket table makes the same split explicit, marking the upload and processed buckets private with signed URLs and the CDN and avatar buckets public. The control is conditional on configuration. Point vault media at a private disk and that line returns a link that dies in an hour. Point it at the public CDN disk because the CDN made your feed faster, and the same line returns a link that never dies and that any fan can paste into a group chat. The security review treats this as live risk rather than settled design: “public object storage exposure” sits in the residual risk register at high severity, mitigated by private buckets, signed URLs and entitlement checks, and its upload test checklist asks the tester to “attempt direct access to restricted media object paths.” A control still on the test list is one you verify. ## Does the vault keep an access log, and what would it record? The requirements document is unambiguous about intent. Functional requirement 13 reads: store private content in the vault with access logging. That is the right promise, because the first question after a leak is who opened it. There is no table for it. The schema reference closes with a complete catalog of 118 tables across identity, content, commerce, messaging, live, AI, analytics, reference, advertising and system domains, and nothing in it records a vault access event: no `vault_views`, no `vault_access_logs`, no `media_access_logs`. What exists nearby shows a pattern the platform writes well already. `story_views` records a user and a story, `video_views` a user and a video, `pay_per_views` a buyer with a polymorphic content reference, and `login_sessions` and `user_devices` track sessions and devices. The engine for per-event access rows is present; it has never been pointed at the vault. The entity relationship document adds a line under every entity saying least privilege, audit logging and a retention policy are recommended. That is boilerplate repeated across the catalog, not evidence of a shipped audit trail, and reading it as the latter is the easiest mistake in that document. The feature catalog does list a login activity log, a per-user activity audit and an immutable financial audit log. None covers a vault read. Scope a small table in sprint one: viewer id, media id, vault id, timestamp, IP, user agent, and the entitlement that allowed the read. ## Where does the feature list run ahead of the data model? The vault section of the feature catalog lists twelve capabilities, most marked “Included.” Set each against the schema, the API collection and the job catalog and they separate into three groups: backed by a table or route, backed by a job or setting, and backed by nothing. The third group is where budget goes. | Vault capability as listed | What backs it in the engineering docs | Verdict | What you own | | --- | --- | --- | --- | | Private storage | `vaults` table with `user_id` and `is_locked` | Backed | Nothing | | Access control | Authenticated routes; download route carries a purchase and access check | Backed at the route | Verify the storage disk is private | | All media types | `media` enum is image, video, audio only | Partial | Add a file type for documents and archives | | Bulk upload | One vault upload endpoint; no batch route documented | UI affordance | Client-side queue, or a real batch endpoint | | Bulk download | Download route takes a single id | UI affordance | Archive job plus a collection route | | Folder organization | No folder table; no parent or folder column on `vaults` or `media` | Unbacked | The whole feature | | Content search | No search column or index on vault media | Unbacked | Metadata fields plus an index | | File encryption at rest | No encryption column; PII and field-level encryption are operator-configured | Operator responsibility | Storage-layer or field-level encryption | | Watermarking | `GenerateWatermark` job on the media queue; image uploads “may be watermarked” | Backed as a job | Confirm it runs on the vault path | | Auto-archive | `CleanupExpiredVault` job exists; `vaults` has no expiry column | Job without a field | An expiry or retention column | | Share from vault | Composer media picker endpoint | Backed | Nothing | | Storage tiers | Upload tiers from 50MB per file up to 5GB per file | Backed as config | Pick and enforce a tier | Two rows deserve a second look. `CleanupExpiredVault` is a real job, hourly on the maintenance queue with one retry and no dead-letter queue, and the `vaults` table has no timestamp for it to read, so it either does nothing or runs on a rule living in code rather than data. And folder organization appears exactly once across the entire documentation set, in that one feature row: no folders table, no self-referencing parent column, no tag table, no join. Creators managing a few hundred assets will ask for folders in week two, and the answer is a schema change, a migration, a picker rewrite and a backfill. Price it now. ## How does a mass send actually reach many fans? The broadcast surface is a single endpoint, a POST to send a massive message, scoped to creators and managers. Behind it sit a mass message controller and a `SendMassMessage` job class, which the job catalog records as `ProcessMassMessage` on the messaging queue with a ten-minute service target, two retries and a dead-letter queue. The row it writes is `mass_messages`: an owning `user_id`, the `message` body, a `type`, an optional `price`, a `sent_count`, a `status`, a `scheduled_at` and a `sent_at`. The documented workflow is a fan-out. The creator composes a broadcast, selects custom lists or all subscribers, and a queue job iterates the recipients, writing for each a personalized `messages` row, a transaction if priced, and a notification. One broadcast row as the campaign, N message rows as the deliveries, so each fan sees a normal conversation rather than a visible blast. Here is the part that catches teams out. The `messages` table has ten documented columns and none is a broadcast reference: conversation id, sender id, body, type, price, paid flag, reply-to id, status and a soft-delete timestamp. There is no `mass_message_id`. That column name appears exactly once in the schema, on the `mass_message_custom_list` join table, where it points at the lists a broadcast targeted, not the messages it produced. So a delivered message is structurally indistinguishable from one the creator typed by hand. You can read `sent_count` and learn how many the job thought it sent. You cannot ask which fans received broadcast 412, which replied, or which broadcast earned Thursday’s tip. Per-campaign attribution is the first analytics request every operator makes, and here it is a migration: add the broadcast key to the message row, or add a delivery table, before the missing history starts to hurt. Worth contrasting, the admin broadcast table stores a `recipients` JSON column, so the operator’s own announcement records who it was aimed at while the creator’s broadcast does not. ## Is a mass send queued, or does it run inside the request? Queued by design. Whether it is queued in practice is a line in your environment file. The architecture documents describe mass messaging as processed asynchronously so the sender gets an immediate acknowledgment. The scalability table in the schema reference, though, lists the current queue state as “sync processing” against a recommended Redis queue manager, and the environment examples make the split concrete: the development profile sets the queue connection to sync, staging and production set it to Redis. On a sync connection a dispatched job is not deferred. It executes inline, in the request that dispatched it. A creator with twelve thousand subscribers presses send and the request sits there writing twelve thousand message rows, twelve thousand notifications and a transaction per priced delivery until the web server’s timeout ends it mid-way. There is no partial-completion marker to tell you where it stopped: `status` is scheduled, sent or failed, and `sent_count` is one integer. This is a deployment requirement masquerading as a feature, and the documents are consistent about it: the uptime target is annotated as environment-dependent with production-grade queue workers recommended, and the security guidance says workers should be supervised and isolated from the web process. Treat a running, supervised worker as part of launch-ready, alongside a scheduler for `scheduled_mass_messages`, which the data model marks as requiring a deployment-specific scheduler. No cron, no scheduled broadcasts, and the row stays pending. ## Is segmentation a documented query, or a list you fill by hand? By hand, and this is the most consequential thing to understand before promising a creator “segmented campaigns.” A segment is two tables. `custom_lists` holds an id, the owning `user_id`, a `name` and a `description`. `custom_list_members` holds an id, a `list_id` and a `user_id`, with a unique key on the pair. A third table, `mass_message_custom_list`, joins a broadcast to the lists it targets. Look for a criteria column and there is not one: no rule JSON, no filter expression, no dynamic flag, no last-evaluated timestamp. A list is an explicit set of membership rows, which means someone put every fan in it and nothing re-evaluates it. “Fans who spent over fifty dollars last month” is not a list this platform can hold; it is a list a human assembled in March and that is wrong by April. The one computed audience is “all subscribers,” offered alongside list selection and derivable from the subscriptions table at send time. So you get one dynamic audience and any number of static ones. Predictive segmentation is named in the documentation, and it is named in the roadmap chapter: fan segmentation AI for lifetime-value scoring and churn-risk identification sits under future capabilities. It is a direction, not a shipped module. If dynamic segments matter to your pitch, the build is well-shaped: add a criteria column to the list, add a job that re-evaluates membership on a schedule, and keep the member table as the materialized result so the send path never changes. It is the highest-leverage addition here. ![Creator customization screen for name, username, display choice, email, occupation, language, gender, and birth-date details](https://miracuves.com/wp-content/uploads/2026/06/5-Customize-MxFans-Support-Creators-Content-06-27-2026_01_25_PM-1024x573.webp "MYM Clone Script: A Private Vault and Segmented Mass Sends 2")Image Source: Miracuves product screenshot. ## Who is allowed to fire a broadcast, and what stops a runaway? The send endpoint is scoped to creators and managers. The role matrix is more specific: sending mass messages is unavailable to fans, available to creators when permitted, and available outright at the higher creator tier. Managers come through `manager_access`, which carries a `permissions` JSON column, so delegated sending is a permission inside a blob rather than a named column and your authorization tests must cover the blob’s contents, not just the presence of a row. On abuse control the risk register names the mitigations as throttle middleware, creator-level limits and admin settings. The feature catalog lists message rate limiting as supported rather than included, meaning a control you turn on, and the API guidance gives throttle postures by endpoint class rather than a number for broadcasts. Login does ship brute-force throttling at five attempts per five minutes, so the middleware pattern is proven; there is no documented per-creator broadcast ceiling. Set one yourself, because a scripted client can empty a creator’s goodwill in an afternoon and the only record will be a `sent_count`. ## Does bulk download exist as an endpoint, or only as a button? Only as a button, as far as the documented contract goes. The feature catalog lists bulk download as included with a one-click description, and the headline feature table repeats it as a vault highlight. The API collection documents one download route, taking a single item id. You can build a one-click experience on that route by looping in the client, and plenty of products do. It works until the collection is large, at which point you are issuing hundreds of parallel authorized requests from a browser, each re-running the access check. The honest version for a four-gigabyte archive is a queued job that assembles a package and returns one expiring link, a short build on a stack that already has a media queue and a temporary-URL helper. Bulk upload sits in the same position: one documented upload endpoint, no batch route. Say that in your own documentation so nobody budgets zero days for a resumable uploader. ## Can a vault be sold, or only emptied into something that can? The `vaults` table carries an `access_price`, which reads as “a creator prices a vault and a fan unlocks it.” The entitlement table does not support that. `pay_per_views` is the unlock record: a buyer, a polymorphic `payable_id` and `payable_type`, a price and a status, and the documented values for `payable_type` are updates, media and reels. Vaults are not among them, so no documented entitlement row points at a vault and `access_price` has no documented purchase path behind it. Three documents also disagree about what the vault is for. The schema reference files `vaults` under content as private storage for creators. The entity relationship document files `Vault` under commerce and calls it locked or escrowed value associated with messages or premium content, an entitlement or escrow-style record. The whitepaper glossary defines a vault as private content accessible only to specific fans or tiers. A creator’s drawer, a monetization record, and a fan-facing access tier. The reading that reconciles all three with the actual columns is that the vault is a creator-side organizer and monetization happens to the media after it leaves. That is what the composer media picker is for: pull an asset into a post or message, and that object becomes the priceable one with a real entitlement row. The vault is the staging area, not the storefront. Decide which reading you are building, and make the columns match. ## Founder Decision Signals **Ask for the storage disk, not the storage feature.** “Is content secure” gets a yes from every vendor. “Which disk serves vault media, and is it public or private” gets a configuration file. Then open a vault object’s raw URL with no session. **Ask which table records a vault read.** If the answer is a document reference rather than a table name, the log is a build item, and retrofitting it gives you no history for the period you most want to investigate. **Ask which catalog features have no table.** Folders, vault search and bulk download are the three to name first here. **Ask whether a segment re-evaluates, and ask to see a queue worker running.** If a list is membership rows with no criteria column, every segment is a snapshot. And ask for a supervised process, not a configuration: broadcast to a thousand seeded accounts and watch whether the request returns or hangs. ## Common Vault and Mass-Send Mistakes to Avoid **Treating an unguessable path as access control.** A randomized filename stops enumeration. It does nothing once the link is shared or logged by an intermediary. The fix is a private disk and an expiring URL. **Reading boilerplate guidance as a shipped control.** A line saying audit logging is recommended, repeated under every entity in a data model document, is advice. Treating it as evidence is how a platform ends up telling a creator it can see who opened a file when it cannot. **Launching on a sync queue.** The failure is not slow, it is silent and partial: some fans messaged, some not, one integer counter, no way to resume. **Promising dynamic segments on static lists.** Creators build a list once and assume it keeps up. Six weeks later the “top spenders” list is full of lapsed fans and the campaign underperforms invisibly. Build re-evaluation, or label lists as snapshots. **Assuming compliance obligations travel with the software.** Identity and age verification, consent records, takedown handling and processor rules are integrations and operator policies here, not bundled guarantees. Verification requests have tables and a job; the policy, the retention and the legal duties are yours. ## How a Ready-Made Foundation Fits a Vault-First Build Nothing here argues against starting from an existing codebase. The opposite: a 118-table schema with a polymorphic media layer, a job catalog, a queue architecture, a composer picker and a broadcast fan-out is work you do not have to do, and building it from zero is a year of plumbing nobody will compliment you on. The argument is that you should know which rows of the feature grid are tables and which are intentions before you commit a launch date. The gaps here are not structural failures. They are small builds on a foundation whose joints are already in place: an access log table on a route that already checks access, a criteria column on a list that already has a member table, a broadcast key on a message row a job already writes, an expiry column for a cleanup job that already runs hourly. Each is days, not months, precisely because the surrounding architecture is there. That is where [our influencer platform solution](https://miracuves.com/solutions/entertainment/influencer-platform/) sits. We work from a documented foundation, say which capabilities are backed by a table and which need building, and scope the difference as named work with a date. For a vault-and-broadcast build that means four decisions settled on day one: the storage disk and its URL policy, the access log schema, the segment evaluation model, and the queue and scheduler topology. For the commercial shape of the product rather than its data model, the [MYM clone](https://miracuves.com/mym-clone/) page covers packaging, pricing and timelines; if your question is protecting creator media across every surface, our write-up on [creator platform content security](https://miracuves.com/blog/creator-platform-content-security/) takes that wider view. ## Final Thoughts A vault and a broadcast look like two features. They are two sets of columns, and the columns are where your promises either hold or quietly do not. The vault is a named container with a lock flag, a counter and a price nothing can buy, pointing at a polymorphic media table that does the real work. The broadcast is one row, one job and a fan-out that writes messages carrying no memory of where they came from. Both are solid starting points; neither is finished. Bring us the four decisions above and we will tell you what the foundation covers, what it does not, and what it costs to close the gap: no readiness badges, no implied certifications, and no capability described as shipped when it is a setting you have to turn on yourself. ## FAQs ### Is vault media protected by a signed URL or just an unlisted path? Both are possible, and your storage configuration decides which. The shipped upload control protecting a stored object is a randomized filename, documented as preventing path guessing. Signed URLs exist through a storage helper that returns a temporary URL with a default one-hour expiry for private providers and a plain permanent URL for public ones. Public object storage exposure sits in the residual risk register at high severity, so this is a control you configure and verify. ### Does the platform log who viewed a vault item? Not in the shipped data model. The requirements document states that private content should be stored in the vault with access logging, but no table in the 118-table catalog records a vault access event. Comparable per-event tables exist for story views, video views, pay-per-view unlocks and login sessions, so the pattern is established but has not been applied to the vault. ### Can creators organize vault content into folders? Not with the documented schema. Folder organization appears once, in the vault feature table, and there is no folders table, no parent or folder column on the vault or media tables, and no tag join. It is a modest build: a parent column or folder table, a migration and a picker update. ### Is a mass message sent in the background or during the request? It is designed as a queued job on a messaging queue with a ten-minute service target, two retries and a dead-letter queue, fanning out to one message row per recipient. Whether it defers depends on the queue connection: the development profile uses the sync driver, which executes jobs inline in the HTTP request, while staging and production use Redis. The scalability table lists the current state as sync processing, so a supervised worker is a launch requirement, not an optimization. ### How does audience segmentation work for broadcasts? Through hand-curated lists. A list table holds a name and owner, a member table holds explicit list and user pairs, and a join table links a broadcast to the lists it targets. There is no criteria, rule or dynamic flag column in any of them, so nothing re-evaluates membership; the only computed audience is all subscribers. Predictive fan segmentation is in the roadmap chapter, not the shipped model. ### Can I see which fans received a particular broadcast? Not from the documented schema. The broadcast row carries a sent count, a status and timestamps, and the fan-out writes ordinary message rows with no broadcast foreign key; that column name appears only on the join table recording which lists a broadcast targeted. Attribution needs a broadcast key on the message row or a delivery table. The admin broadcast table does store a recipients JSON column, so operator announcements are attributed while creator broadcasts are not. ### Does bulk download of a vault exist as an API endpoint? No. The API collection documents a single download route taking one item id, while the feature catalog describes bulk download as one-click. A client-side loop produces the experience at small scale; for large archives the sound version is a queued packaging job returning one expiring link. Bulk upload is the same: one upload endpoint, no documented batch route. ### What does a vault-and-broadcast build cost to get right? The expensive part is already built: the polymorphic media layer, the queue and job architecture, the composer picker, the broadcast fan-out and the list join tables. The gaps are days each rather than months. For a quote we scope four items: the storage disk and URL policy, the vault access log, the segment evaluation model, and the queue and scheduler topology. Talk to Miracuves and we will price those as named work with dates. ## 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/)