Crypto Signal Message Revision Diff Analyzer

What this comparison can decide

This analyzer answers a narrow document question: when two valid snapshots identify the same Telegram source scope, which exact message identifiers occur in both documents, which occur in only one document, and which supported fields differ for identifiers present in both? The answer is about the two files supplied in this browser session. It is not a reconstruction of Telegram history and it is not a judgment about a person, channel, group, trading result or commercial service.

The comparison can establish literal membership in each parsed JSON document. It can say that record R0003 is represented only in the earlier document or that the supplied text field for an exact shared identifier differs. It can also say that the available evidence is not comparable because the files use different source scopes, reverse the capture direction, contain duplicate identifiers, violate the schema or exceed a safety limit. Suppression is a result, not a prompt to guess.

Every successful run separates four states instead of manufacturing one warning score. The counts show unchanged records, changed records, records present only in the later snapshot, and records not present in the later snapshot. A changed record names its changed fields. Field annotations can call attention to line endings, canonically equivalent Unicode, timestamp formatting, zero-width characters, bidirectional controls or entity order. Those annotations preserve the exact difference; they never silently convert one supplied value into another.

The tool can calculate exact-byte SHA-256 values for the two inputs, semantic snapshot SHA-256 values after the documented normalization, semantic message-set SHA-256 values, and a deterministic report-payload SHA-256. Those values support repeatable local work. A hash does not authenticate a source. Matching hashes do not establish completeness, authorship, capture time, truth or platform origin, while different hashes do not explain why bytes differ.

The decision boundary is deliberately conservative. This page does not inspect Telegram servers, recover content, identify an editor, calculate a win rate, validate entries or fills, determine profitability, rank a provider or recommend a trade. Coverage is not endorsement. There is No provider score. Use the output as a document-comparison aid inside a larger evidence review.

Compare two local snapshots

Prepare an earlier snapshot and a later snapshot in the closed csr.message-snapshot.v1 adapter format. Paste each document into its labeled input or select a local JSON file. A selected file takes precedence over text in that side until the textarea is edited again. Choose Compare snapshots only after checking that the directional labels are correct: the before capture timestamp must be strictly earlier than the after capture timestamp.

The first validation pass happens before record matching. The page checks byte size, strict UTF-8 decoding, BOM and NUL boundaries, duplicate JSON object members, nesting, string limits and JSON syntax. It then checks every required object member and value rule. Either invalid input suppresses the union table and report download. Snapshot-specific issue codes remain visible so the document can be repaired without inventing a partial match.

Load synthetic example places a complete four-state example in both text areas. It is safe training data, not a real signal or real channel. The example changes one BTC/USDT text value and adds a supplied edit marker, leaves one ETH/USDT record unchanged, has one SOL/USDT record only in the earlier snapshot, and has one XRP/USDT record only in the later snapshot. The expected counts are 1 unchanged, 1 changed, 1 not present later and 1 present only later.

Copy summary copies a short count-and-hash summary without raw values or message IDs. Download JSON creates a privacy-minimized report by default. Turn on Include full supplied values only when a complete local export is genuinely needed. That choice adds scope, identifiers and values to the downloadable report. It is off by default. Review before sharing because clipboard history, downloads, screenshots and later handling are controlled by the reader and operating system.

Clear all removes the current text, selected-file references, result and report from the page. One in-memory Undo clear action remains available until another input action replaces it. The undo state is not written to persistent browser storage. Reloading or closing the page discards it.

How exact ID matching works

Exact message IDs only is the central identity rule. A comparison identity is the exact tuple of source.platform, source.scope_id and canonical decimal message_id. Both documents must say telegram and carry the same scope identifier. Telegram TDLib documents message identity in a chat context; this adapter keeps that scope explicit so equal number strings from two different chats are never paired.

No fuzzy matching means the analyzer does not pair records by similar text, nearby timestamps, matching permalinks, author labels, capitalization or punctuation. It does not guess that one message replaced another. Similarity can be useful during a separate human investigation, but using it silently inside a deterministic diff can hide ambiguity and create a confident-looking false pair.

Message identifiers are canonical non-negative decimal strings. Zero is represented as 0. Other values begin with digits 1 through 9 and may continue with decimal digits. Leading zeros are rejected. Ordering does not pass through JavaScript Number, so an identifier larger than 9,007,199,254,740,991 remains exact. The comparator sorts by digit count and then by code-unit order, which is equivalent to arbitrary-precision numeric order for canonical non-negative decimal strings.

Duplicate identifiers inside either snapshot are fatal. First-wins and last-wins behavior would make results depend on array order, so the tool refuses both. Message array order itself is not semantic: valid unique records are sorted by arbitrary-precision identifier for semantic serialization and union output. This makes a reordered export reproducible without suppressing any supplied field difference.

Entity arrays have a separate normalization rule. Their semantic order is offset, length, type and value. Two arrays containing the same valid entities in different raw order produce an entity_order_only annotation and do not turn an otherwise identical record into a changed record. Entity targets and ranges remain exact; a changed target is still a substantive field difference.

Why not present is not deleted

The only label for an earlier-only record is Not present in later snapshot. Absence is not proof of deletion. The label states one observable fact about two supplied documents and stops there. It does not identify a platform action, an author action, a moderation event, an intent or a hidden record.

Many preparation differences can change membership. A later export may cover a shorter date window, use a different export filter, omit a message type, be captured with different permissions, end early, contain partial data or pass through a transformation that dropped records. Platform behavior can also change without being represented by these adapter files. The analyzer has no independent observation that would choose among those explanations.

Coverage fields make part of this uncertainty visible. Each snapshot supplies a start time, end time and completeness state of complete, partial or unknown. Different windows add COVERAGE_DIFFERENT. Any partial or unknown declaration adds COVERAGE_INCOMPLETE. These are warnings rather than schema failures, so literal membership can still be reported, but every presence interpretation becomes coverage-limited.

A supplied availability value of tombstone is also neutral capture data. The adapter permits present, tombstone and unknown. A transition between those values is a changed field, not an explanation. The source transformation must document what its tombstone value means and how it was produced. This analyzer does not turn that local label into a conclusion about Telegram or a provider.

When evidence stakes are high, retain the original export, the adapter output, transformation notes, exact-byte hashes, capture settings and coverage statement. Compare additional independent captures where lawful and appropriate. Keep unknowns visible. A narrow report with an explicit gap is more useful than a complete-sounding narrative assembled from missing evidence.

How the four states differ

For a shared identifier, the comparator walks the fixed field order: availability, posted time, edited time, message kind, text, caption, entities, media digest, native-payload digest, reply identifier, author identifier, author label, permalink and reply-markup digest. Every schema property is required, even when its value is null. Omission is therefore a schema error. A required nullable property changing from null to a value is field_added; a value changing to null is field_missing; two different non-null values are field_changed.

Timestamp subtypes add neutral precision. A posted time can be changed or format-only. An edited time can carry an edit marker added, edit marker removed, time advanced, time regressed or format-only label. A marker is only a supplied field. The page does not infer that the platform performed an edit. A regressed time is reported for source review without assigning motive.

Unchanged means all normalized supported message fields match for that exact identity. It does not mean that either snapshot is complete or authentic. Changed means one or more supplied fields differ. It does not mean that the later value is better, worse, accurate or inaccurate. Present only in later snapshot describes later-only membership and does not establish when or by whom the record was created.

Versioned JSON schema and limits

The accepted media type is UTF-8 JSON using the closed csr.message-snapshot.v1 adapter. The top level requires schema_version, snapshot_id, captured_at_utc, coverage, capture, source and messages. Unknown members are rejected. Version 1 therefore cannot silently absorb a new property with unclear meaning; a future expansion needs a new explicit schema version and method review.

Coverage requires start, end and completeness. Capture requires method, tool, tool version, nullable archive SHA-256 and a redactions array. Source requires platform, scope ID and nullable locator. Every message requires all fourteen compared fields plus its message ID. Every entity requires type, UTF-16 offset, UTF-16 length and nullable value. Null is accepted only where the ledger lists it. A missing property and a present property whose value is null are different states.

Timestamps use a deliberately narrow profile: four-digit year, real calendar date, 24-hour time, seconds, optional exactly three millisecond digits and uppercase Z. Other offsets are rejected rather than converted silently. Coverage start cannot follow coverage end. The earlier capture timestamp must be strictly before the later capture timestamp. A message time after its supplied capture or an edit time before its supplied post time is retained as a warning because the record still has inspectable input.

The parser reads at most 524,288 bytes per snapshot, 2,000 messages, depth 12, 20,000 object members and 20,000 array items. Text is capped at 16,384 Unicode code points, captions at 8,192 and entities at 256 per message. Comparison output is capped at 4,000 rows and the page displays at most 500 rows.

Strict UTF-8, no BOM, no NUL byte, no unpaired surrogate and no duplicate object member are enforced before schema use. Native JSON.parse alone is not enough because duplicate names are otherwise overwritten. The bounded recursive parser detects the duplicate before any first-wins or last-wins interpretation can occur.

Issue reference

Privacy and local processing

Your files stay in this browser under the page design: paste, file reading, validation, comparison and hashing use browser APIs in the current page. The analyzer interaction script makes no intentional fetch, XMLHttpRequest, WebSocket, EventSource, beacon, analytics, service-worker, cache, cookie or persistent-storage call. There is no form submission. The V3 stylesheet is a normal first-party page asset loaded separately from analyzer interactions.

Browser-local is a processing boundary, not an anonymity promise. The operating system can retain downloads, clipboard history or temporary data. Browser extensions, screenshots, screen sharing, backups and later file transfer are outside this script. Work on a trusted device, minimize input before use, and follow applicable privacy, employment, platform and legal requirements.

The default report is privacy-minimized. It contains sequential references such as R0001, four-state labels, counts, issue codes, changed field names, annotations, method version and hashes. It omits raw text, captions, author labels, permalinks, source scope and message IDs. This is useful for discussing a comparison pattern without automatically reproducing the underlying messages.

The optional full-value mode adds exact scope, identifiers and before-and-after message objects to the local report. It is intentionally explicit and off by default. Enabling it does not upload anything, but it creates a more sensitive file. Review before sharing, choose an appropriate recipient and channel, and consider whether the minimized report already answers the decision question.

Clear all removes page references and offers one in-memory undo. No localStorage, sessionStorage or IndexedDB entry preserves the input. A page reload discards the application state. The source files remain wherever the reader originally stored them; clearing this page does not erase those originals or any report already downloaded.

Hashes and provenance limits

Exact-byte SHA-256 applies directly to the selected or pasted UTF-8 byte sequence. Whitespace, member order, escape spelling and line endings can change that value even when parsed content is equivalent. Preserve it when the exact file matters. The NIST Secure Hash Standard defines SHA-256; this page uses the browser Web Crypto implementation for interactive hashing and Node crypto during deterministic generation and fixture replay.

The semantic snapshot representation contains every supported schema value. Message arrays are sorted by arbitrary-precision decimal ID and entities by their documented semantic order. Object members are serialized recursively in lexicographic order with no insignificant whitespace, following the deterministic principles used by RFC 8785 for the supported I-JSON value subset. Supplied strings are preserved exactly.

Unicode UAX 15 explains why different code-point sequences can be canonically equivalent. This analyzer may annotate NFC equivalence, but exact values remain different. It never uses compatibility normalization to collapse circled digits, ligatures, full-width forms or other distinctions. NFKC is not an equality rule here. Line-ending equivalence is likewise an annotation, not a replacement.

The semantic message-set hash excludes capture metadata and snapshot identifier while retaining source platform, source scope and normalized messages. It helps show that message order alone did not change the compared set. The semantic snapshot hash includes snapshot metadata, so two captures can have equal message sets and different semantic snapshots. The exact-byte, semantic snapshot and semantic message-set labels are therefore not interchangeable.

The deterministic report hash identifies the canonical report payload before its own hash field is attached. Repeating the same valid comparison, mode and method produces the same payload. None of these hashes can authenticate a Telegram source, an author, a timestamp, a capture process, a provider or a claim. Provenance requires custody records, original material, documented transformations and independent corroboration appropriate to the decision.

How to prepare a Telegram export

Telegram documents JSON and HTML export availability in Telegram Desktop. The browser-local adapter on this page accepts the bounded official JSON structure pinned to Telegram Desktop exporter commit a898b079c940b16f3e4de6faa7c85926b6f362e5: a single-chat object, chats.list or left_chats.list. It does not accept HTML, scrape Telegram, sign in to an account or send the export to CryptoSignalsReview.

Select the exact chat when a full export contains more than one. The adapter never chooses by name, audience, row position or message count. Enter a snapshot ID, capture timestamp, coverage start, coverage end and completeness for each conversion. Those are user-supplied provenance assertions because result.json does not establish the export-completion time or the reviewer's intended coverage. The adapter does not derive them from the file timestamp or latest message.

Preserve the untouched original export beside the converted csr.message-snapshot.v1 output. The adapter retains the original file SHA-256, exact chat type and chat ID, supported message IDs and Unix timestamps, flattened ordered text parts, direct sender fields, channel signatures and safe same-scope reply identifiers. Every remaining native message property is deterministically represented by native_payload_sha256, so a poll, todo list, giveaway, rich message, reaction or inline-button change cannot be labeled unchanged merely because it lacks a direct field mapping. That digest is a change detector, not a media hash or authenticity proof.

The adapter deliberately does not infer native entity offsets, media-file hashes, reply markup, permalinks or cross-scope reply targets. Full exports use two stages: the published root schema checks the inspection envelope, then the selected chat must satisfy the stricter 2,000-message definition and the runtime's aggregate limits. Passing the root schema alone is not an importability or provenance conclusion.

1. Define the exact chat or channel scope. Assign one stable ASCII scope_id and use it unchanged in both adapter documents. Do not combine multiple chats into one scope.
2. Record captured_at_utc when each source capture completed. Keep the earlier and later roles directional. Do not rewrite times merely to pass validation.
3. Describe the intended coverage start, end and completeness. Use partial or unknown honestly when filters, permissions, interrupted exports or transformation limits prevent a complete claim.
4. Map message identifiers as canonical decimal strings. Reject or investigate duplicates rather than renumbering. Preserve nullable fields explicitly and include every required property.
5. Preserve message text, captions and labels exactly. Do not trim, case-fold, normalize Unicode, rewrite line endings or repair invisible controls silently. Document deliberate redactions separately.
6. Represent entities with UTF-16 offsets and lengths because the schema names those units. Keep a nullable entity value. Do not infer targets that the export did not supply.
7. Use lowercase 64-character SHA-256 strings for non-null archive, media, native-payload and reply-markup digests. A missing digest is null, not an empty string or a fabricated placeholder.
8. Validate each document independently before comparison. Retain failures and repair notes when they are material to an audit trail.

A transformation can introduce its own errors. Compare adapter counts with the source export, spot-check exact IDs and values, and have another person review the mapping when the result could affect a complaint, payment dispute, moderation decision or public statement. Passing the closed schema establishes only that the converted document meets this method contract.

Worked synthetic example

The starter before snapshot contains IDs 1001, 1002 and 1003. The starter after snapshot contains IDs 1001, 1002 and 1004. Both identify the same synthetic Telegram scope and the before capture precedes the after capture. Exact union order is 1001, 1002, 1003, 1004 regardless of the order in either message array.

ID 1001 is changed. Its supplied text changes the synthetic stop value from 64000 to 64200, and its nullable edited_at_utc gains a timestamp. The field states are field_changed for text and field_added for the edit marker. This demonstrates document difference only; the values are not a trade instruction and the edit marker is not platform-history evidence.

ID 1002 is unchanged in all normalized supplied fields. ID 1003 receives the exact label Not present in later snapshot. ID 1004 receives Present only in later snapshot. No score combines these categories.

The generator replays 66 synthetic fixtures before writing any artifact. They cover message and member ordering, arbitrary-precision identifiers, leading zeros, scope and capture errors, coverage warnings, duplicate IDs, null transitions, line endings, NFC equivalence, forbidden compatibility collapse, invisible controls, timestamp subtypes, entity order, digest changes, missing and unknown properties, duplicate JSON members, lone surrogates, byte and depth limits, temporal warnings and tombstone state changes.

Inspect the machine-readable method summary, Telegram Desktop import schema and calculation fixtures. They are method artifacts and synthetic examples, not reports about a real provider or Telegram account. Their expected values are checked against the same production core embedded in this page; any drift stops generation.

What to check next

Start with validity and coverage, not the changed count. Confirm that both source scopes are the intended same chat, capture direction is correct, coverage windows are comparable and completeness declarations are credible. Resolve duplicate IDs or schema errors before reading record states. A large table produced from poorly scoped inputs is not a stronger result.

For changed records, review field names before raw values. A timestamp format-only annotation has a different consequence from a text change. An entity-order-only annotation means normalized entities match. A zero-width or bidirectional-control annotation calls for careful rendering and source review but does not by itself establish harmful intent.

For earlier-only and later-only records, inspect export settings, permissions, date ranges, message-type filters, transformation logs and completeness. Seek another capture when appropriate. Avoid public allegations based solely on membership differences. Keep the phrase Not present in later snapshot when that is all the evidence can support.

For signal due diligence, move separately to the evidence needed for the actual decision: original alert chronology, entry and exit definitions, order and fill records, fees, slippage, funding, denominator completeness, cancellations, risk exposure and custody of source material. A message revision diff cannot substitute for a result-sheet audit or alert-to-order attribution.

Use the message red-flag analyzer when the question concerns one supplied message, the result-sheet structure validator when the question concerns reviewable trading-result rows, the alert-to-order attribution library when an alert must be connected to an order or fill, the moderation evidence library when the task is to preserve and assess a broader before-and-after moderation record, and the accuracy and performance evaluation method when the decision concerns evidence populations and result methodology. Each route answers a separate decision and none converts this diff into platform-history proof.

Save the minimized report and source hashes with a short method note. If full values are necessary, control access and document the reason. Re-run after any adapter repair and compare report hashes. When results matter outside a private review, have a qualified human assess the original evidence, local law, platform rules and the limits written on this page.

Method sources

The reader-facing sources below have bounded roles. Telegram export documentation establishes that desktop export can provide JSON or HTML. The immutable Telegram Desktop JSON writer defines the accepted envelope and field subset, not export authenticity. Telegram TDLib supports chat-scoped identity, not provenance. RFC 8785 informs deterministic JSON serialization. Unicode UAX 15 informs representation annotations. RFC 3339 supplies timestamp context while this schema intentionally accepts a narrower UTC-Z profile. NIST supplies SHA-256 context. The CFTC source provides general messaging-app caution rather than a finding about any supplied record.

Google, Bing, OpenAI crawler and IndexNow materials in the research ledger are release-operation evidence only. They are not rendered as financial-method citations and do not predict indexing, rank, traffic, citation or inclusion in an answer. This canonical exists for a distinct reader task and information gain, not a page-per-query expansion strategy.

Generator provenance for this build records source ledger SHA-256 31404bf0725e7bf6b89473320ae61bbec9a9a75c68600db57f5983c014fd9c33, generator SHA-256 db60e4a707c8a15791a30327d617f62a6d6b886026cab3293f79f2e6710e84a5 and checker SHA-256 fde5a258c668fa0579d08105b57004bfa718ed6bb4b1188f04fe30cf6dfff6fc. Those hashes identify the three source-freeze bytes used for generation under repository source 74bed2b023064a6ffe82bfba5705ceffc44d1b19.