A request to collect links, reject duplicates, let an administrator remove entries, and count contributions sounds straightforward. It still leaves important decisions open: does a changed query parameter create a new submission? Who gets credit when two people submit together? Can a removed link be submitted again?
A historical Freelancer client brief asks for these features alongside Google Sheets storage and automatic monthly summaries. Checked on November 2, 2026, the project is marked Closed and shows only a relative posting date; its exact publication date is unknown. It supplies a problem to examine, rather than an available job or a BitBear delivery case. The policies and tests below are proposed examples.
Decide where a link must be unique
Personal bookmarks may allow everyone to save the same address. A shared submission collection may need one entry across all contributors. Separate campaigns may need independent collections.
For a collection owned by one campaign, specify one registration slot for each campaign and comparison key. Keep the contributor ID as attribution rather than part of the uniqueness rule. Otherwise, two people can register the same link successfully.
This addresses a different problem from webhook delivery deduplication. Two genuinely different messages can identify the same business item. Neither message has to be a redelivery for the collection to contain a duplicate.
Compare conservatively and preserve the submitted address
Section 6 of RFC 3986 describes levels of URI comparison and normalization. Scheme and host names are case insensitive; that does not justify lowercasing the entire address. Other components need their own semantics.
For an initial collection, choose a conservative policy. The following rules are a proposed submission policy, rather than a universal content-equivalence algorithm:
| Difference | Suggested first-version policy |
|---|---|
| Case in the HTTPS scheme or host | Normalize for the comparison key; preserve the original URL |
| Path case or a trailing slash | Preserve the difference |
| Query values or parameter order | Preserve them; do not delete or sort them globally |
Fragments such as #section-a and #section-b | Preserve by default; add an explicit site-specific rule if the collection should merge whole articles |
| A shortened, redirected, or expanded link | Require review instead of assuming equivalence |
For example, https://EXAMPLE.com/Guide and https://example.com/Guide can share a key. Do not automatically merge /Guide with /guide. Similar-looking addresses do not establish identical content.
Accept complete HTTPS addresses only, reject URLs containing account information, and tell contributors to avoid private links containing access credentials. Keep the first version to registration without fetching links or following redirects. If you later remove tracking parameters, define the relevant sites and parameter names first, then rerun acceptance checks. A more aggressive matching policy should not rewrite the address someone actually submitted.
Keep registrations, attempts, and removal status separate
Each registration should identify its campaign, original URL, comparison key and policy version, first successful contributor, submission time, current status, and any removal reason.
A duplicate attempt should return the existing record ID without replacing its contributor or increasing the accepted count. If later recommendations deserve recognition, track attempts separately from accepted registrations. A public duplicate response does not need to reveal another person's private information.
For administrator removals, preserve the record ID, attribution, and reason while marking the entry removed. One simple policy keeps its registration slot reserved: ordinary contributors cannot bypass moderation by submitting it again, and only an administrator can restore it. A service that permits resubmission needs a separate review and attribution policy.
Simultaneous submissions must still produce one successful registration. Ask the builder to establish whether the available storage supports an appropriate uniqueness constraint or atomic write. A sequential demonstration does not establish this. If the guarantee is unavailable, route submissions through review instead of promising automatic correctness under concurrency.
Define the monthly metric before automating delivery
Attempts, successful registrations, and successful registrations that remain active are different counts.
One workable definition selects the first successful submission time within a calendar month in an agreed time zone, counts only records active when the report runs, and credits the original successful contributor. Display the time zone, period boundaries, generation time, and metric definition. Removing a record later changes a rerun of that report; preserving a historical result requires a separate snapshot.
Start with an administrator command that generates the report on demand. The client brief requests automatic monthly delivery, but scheduling, reliable execution, and failure notifications need separate verification. Persistent storage alone does not establish an automatic reporting feature.
Choose between a bot builder, custom development, and review
| Approach | Appropriate scope and next check |
|---|---|
| Try a small registration tool with BotFatherV2 | Describe inputs, persistent records, isolation, and query commands; verify SDK support for the matching rules before generating and testing |
| Build or commission the full integration | If Google Sheets must be authoritative or scheduled delivery is mandatory, separately verify authorization, sync direction, conflicts, and maintenance responsibilities |
| Keep an approval step | When matching, concurrent writes, or removal policy is unresolved, review submissions rather than reporting uncertain outcomes as successful |
As checked on November 2, 2026, BotFatherV2 documents AI-assisted creation and modification of Telegram bots, import of existing Telegram Serverless bots, version publishing, and code rollback that retains current business data. These are development and maintenance capabilities, rather than a ready-made link collection or a documented Google Sheets connector. The requested /en-US product entry could not be retrieved during this check; the English homepage was accessible.
Its Build with AI documentation limits the initial scope to menus, simple community helpers, polls, and persistent tools with per-user isolation. The fixed SDK does not support arbitrary npm packages or Node/Bun runtime APIs, and the initial release does not add paid-AI-dependent bot runtime features. This proposal therefore matches only part of the product scope: a small registry is something to explore, while shared campaign access, storage uniqueness, Sheets synchronization, and scheduling each need verification. BotFatherV2 operates independently of Telegram's official BotFather.
A brief for an AI builder or a contractor
Design a campaign link registry for Telegram. Each submission contains a complete HTTPS URL and a description. Use a conservative comparison policy within each campaign, preserving the original address, comparison key, and policy version. Do not fetch URLs, strip parameters, or follow redirects automatically. A duplicate returns the existing ID without replacing the first successful contributor or increasing the active contribution count. An administrator can remove an entry with a reason; retain it and prevent ordinary users from registering it again. Allow administrator restoration. Start with an on-demand administrator report based on the agreed time zone, first successful submission time, and current active status. Before implementation, explain whether the current SDK supports shared campaign access control, uniqueness writes, and the required commands. List unsupported parts. Exclude Google Sheets, scheduled delivery, and runtime AI from this first version.
If the original Sheets integration and automatic report delivery remain mandatory, specify them as separate deliverables. Do not assume this smaller version covers them or commit to an unverified price or completion time.
Acceptance checks for the collection
- A receives a stable ID after submitting. B submitting the same link to the same campaign gets no second registration and cannot replace A's attribution.
- Host-name case changes still match. Path case and query differences follow the declared conservative policy.
- Submitting the same link to different campaigns respects the chosen isolation boundary.
- Simultaneous submissions produce one accepted registration, or enter the agreed review flow when storage cannot guarantee it.
- Removing an entry preserves its reason and ID; resubmission cannot bypass moderation, and restoration retains the original record.
- Monthly counts exclude duplicate attempts and handle month boundaries, time zones, and removed records consistently.
- Publishing a new version does not silently recalculate existing comparison keys. A policy change requires checking potential merge conflicts first.
These checks establish collection behavior. Spreadsheet synchronization, scheduled delivery, and recognizing identical content are additional scopes with their own evidence and tests.
Sources and verification
- Freelancer client project, Telegram Notification Bot Development, English, project ID 39734983. Checked November 2, 2026: Closed; exact publication date unknown. Only the client brief informs this article, not bidders' claims or prices.
- T. Berners-Lee, R. Fielding, and L. Masinter, RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, January 2005, English. Section 6 checked November 2, 2026. It supports comparison semantics, not the proposed ownership or reporting policy.
- BitBear Studio, Build with AI and English homepage, no separate publication dates shown; capabilities checked November 2, 2026.