FAQ

  1. Question 1

    What is Decoding-Us.com?

    Decoding-Us.com is a collaborative platform designed for the genetic genealogy and population research community. It serves two main purposes:

    • Public Resource: We analyze and visualize publicly available Whole Genome Sequencing (WGS) data from academic sources, providing alternative Y-DNA and Mitochondrial DNA trees, coverage benchmarks, and reference data.
    • Federated Collaboration: We are building a decentralized application using the AT Protocol (the same technology behind Bluesky) that allows researchers to securely share and compare genetic data without relying on a central server to hold their files.

    Our goal is to empower citizen scientists with tools to explore human history while maintaining complete ownership and control over their sensitive genetic data.

  2. Question 2

    How does the "Federated" model work?

    In a traditional model (like AncestryDNA or 23andMe), you provide a biological sample (such as buccal swab or blood) for sequencing. The service then processes your sample, sequences your genetic data, and often maintains ownership or significant control over that data on their servers. Decoding-Us.com offers a unique alternative: our platform is designed to bridge data from any genetic service—be it 23&Me, Ancestry, FTDNA, YSEQ, or direct-to-consumer Whole Genome Sequencing (WGS) providers. As long as you maintain ownership and access to your sequencing data, our system empowers you to bring it into our federated network, uniting insights from across different providers.

    In our Federated Model (Phase 3 of our roadmap), you don't upload your raw data to us. Instead:

    1. You run a "Personal Data Server" (PDS) application—software that lives on your own computer or private cloud.
    2. This software analyzes your WGS data locally to extract non-sensitive summaries (like your haplogroup or anonymous matching tokens).
    3. You choose to publish these summaries to the "Atmosphere"—our secure network.
    4. Decoding-Us.com acts as an "AppView," indexing this public information so you can find matches and collaborate with other researchers.

    This approach, known as a "Decentralized AppView," ensures that your massive and sensitive raw data files (BAM/CRAM) never leave your control, while still allowing you to participate in community discoveries.

  3. Question 3

    Can I upload my Big Y, WGS, or other DNA files?

    No, we do not accept direct file uploads. To protect your privacy and reduce infrastructure costs, we do not host user data files.

    Instead, we provide tools that allow you to process your data on your own machine. Currently, we offer an Alpha version of the Decoding-Us Navigator (also known as the Navigator Workbench). This edge-computing application runs locally on your PC (Windows/Linux/Mac) and empowers you to:

    • Analyze Locally: Process BAM/CRAM files directly on your machine to generate coverage metrics and haplogroup determinations without uploading massive files.
    • Integrate with Atmosphere: Future versions will allow you to publish anonymized summaries to your Personal Data Server, enabling you to share insights with the federated network while keeping your raw data private.

    The Navigator is built on the JVM (Java/Scala) for performance and cross-platform compatibility. It represents the core of our privacy-first philosophy: bring the analysis to the data, not the data to the analysis.

  4. Question 4

    What is the "Atmosphere" and the AT Protocol?

    The AT Protocol is a new technology for decentralized social networking. It allows users to own their identity and data, moving freely between different services without losing their connections.

    We call our implementation the Atmosphere. Just as the air connects us all, the Atmosphere connects individual researchers' Personal Data Servers. It uses "Lexicons"—standard dictionaries for genetic data—to ensure that a researcher in the UK can automatically compare notes with a researcher in the US, even if they use different software, provided they both speak the "Atmosphere" language.

  5. Question 5

    Why the .com domain? Is this a commercial service?

    Decoding-Us.com is currently a free resource. However, hosting high-performance databases and indexing the global federation costs money. We chose a .com domain to keep our options open for long-term sustainability.

    Future sustainability models might include:

    • Patronage Donation System: A voluntary tiered donation model where community members can become "Patrons" to support hardware and hosting costs. Contributions are optional, but help ensure the platform remains free and open for everyone.
    • Managed PDS Hosting: For users who don't want to run their own server, we could offer a paid, secure hosting service for their Personal Data Server.
    • Sponsorships: Partnerships with sequencing labs or academic institutions, provided they align with our strict privacy and anti-tracking values.

    Regardless of the model, our commitment to open-source code and user data sovereignty will remain unchanged.

  6. Question 6

    How can I submit my haplogroup tree research for merging into DecodingUs?

    DecodingUs welcomes contributions from researchers to help build a more comprehensive and accurate haplogroup tree. You can submit your data via our automated Tree Merge API.

    For a detailed guide on how to format your tree data, the rules for provenance (how your research gets credited), and how conflicts are resolved, please refer to our API documentation: Learn more about Submitting Tree Data

  7. Question 7

    Which reference genome are your trees built on, and why don't the coordinates match FTDNA / YFull / ISOGG?

    Our Y-DNA and mitochondrial trees are built natively on T2T-CHM13v2.0 (the UCSC name is hs1), the first complete, gapless "telomere-to-telomere" human reference assembly. Most consumer and academic services still report positions on GRCh38 (also called build 38, b38, or hg38), an older assembly that contains thousands of gaps. Because the two assemblies number their bases differently, a variant's position on CHM13 is not the same number as its position on GRCh38, and haplogroup-defining SNP addresses will not line up one-to-one with a GRCh38-based catalog. This is a difference of coordinates, not of biology — the same underlying mutations and branches are simply addressed on a more complete map.

    Why this matters most on the Y chromosome: GRCh38's Y is heavily gapped — the ampliconic and palindromic segments (P1–P8), the DAZ/ampliconic arrays, and the enormous Yq12 heterochromatin were unresolved or misassembled. T2T-CHM13v2.0 incorporates a complete Y (from the HG002 genome, since the CHM13 cell line itself is 46,XX), giving the first end-to-end Y sequence. That lets us confidently place variants — and therefore branches — in regions GRCh38 could not even represent. We still mask the most repetitive regions (palindromes, ampliconic arrays, and heterochromatin) when computing branch placement and ages, because short-read data remains error-prone there. Legacy SNP names originally defined on hg19 or GRCh38 are preserved as aliases, so you can still search for a familiar SNP even though its canonical coordinate here is CHM13-based.

    Why this matters on mtDNA: Standard mitochondrial nomenclature — PhyloTree, and tools like HaploGrep that follow it — is defined against the rCRS (the revised Cambridge Reference Sequence, GenBank NC_012920, 16,569 bp). T2T-CHM13v2.0's mitochondrial genome is a different sequence (GenBank CP068254.1), so our de-novo mitochondrial tree's defining variants and positions are expressed in CHM13 coordinates and will not match rCRS-based mutation names or the classic PhyloTree labels. If you know your mtDNA haplogroup from another service, the clade relationships are comparable, but the position numbers and the specific defining mutations shown here are on the CHM13 frame.

    On our roadmap: an rCRS "liftover" for mtDNA (and clearer cross-referencing of GRCh38/hg19 SNP positions for Y-DNA) so you can translate between our CHM13-native coordinates and the references you may already be using.