* Add temporal graph evolution & RuVector integration research GOAP Agent 8 output: 1,528-line SOTA research document covering temporal graph models (TGN, JODIE, DyRep), RuVector graph memory design, mincut trajectory tracking with Kalman filtering, event detection pipelines, compressed temporal storage, cross-room transition graphs, and a 5-phase integration roadmap. Part of RF Topological Sensing research swarm (10 agents). https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add transformer architectures for graph sensing research GOAP Agent 4 output: 896-line SOTA document covering Graph Transformers (Graphormer, SAN, GPS, TokenGT), Temporal Graph Transformers (TGN, TGAT, DyRep), ViT for RF spectrograms, transformer-based mincut prediction, positional encoding for RF graphs, foundation models for RF sensing, and efficient edge deployment with INT8 quantization. Part of RF Topological Sensing research swarm (10 agents). https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add attention mechanisms for RF sensing research GOAP Agent 3 output: 1,110-line document covering GAT for RF graphs, self-attention for CSI sequences, cross-attention multi-link fusion, attention-weighted differentiable mincut, spatial node attention, antenna-level subcarrier attention, and efficient attention variants (linear, sparse, LSH, S4/Mamba). 8 ASCII architecture diagrams. Part of RF Topological Sensing research swarm (10 agents). https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add sublinear mincut algorithms research GOAP Agent 5 output: 698-line document covering classical mincut complexity, sublinear approximation (sampling, sparsifiers), dynamic mincut with lazy recomputation hybrid, streaming sketch algorithms, Benczur-Karger sparsification, local partitioning (PageRank-guided cuts), randomized methods reliability analysis, and Rust implementation with const-generic RfGraph, zero-alloc Stoer-Wagner, SIMD batch updates. Part of RF Topological Sensing research swarm (10 agents). https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add CSI edge weight computation research GOAP Agent 2 output: ~700-line document covering CSI feature extraction, coherence metrics (cross-correlation, mutual information, phasor coherence), multipath stability scoring (MUSIC, ESPRIT, ISTA), temporal windowing (EMA, Welford, Kalman), noise robustness (phase noise, AGC, clock drift), edge weight normalization, and implementation architecture showing 32KB memory for 120 edges within ESP32-S3 capability. Part of RF Topological Sensing research swarm (10 agents). https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add contrastive learning for RF coherence research GOAP Agent 7 output: 1,226-line document covering SimCLR/MoCo/BYOL for CSI, AETHER-Topo dual-head extension, coherence boundary detection with multi-scale analysis, delta-driven updates (2-12x efficiency), self-supervised pre-training protocol, triplet networks for 5-state edge classification, and MERIDIAN cross-environment transfer with EWC continual learning. Part of RF Topological Sensing research swarm (12 agents). https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add resolution and spatial granularity analysis research GOAP Agent 9 output: 1,383-line document covering Fresnel zone analysis, node density vs resolution (16-node/5m room → 30-60cm), Cramer-Rao lower bounds with Fisher Information Matrix, graph cut resolution theory, multi-frequency enhancement (6cm coherent dual-band limit), RF tomography comparison, experimental validation protocols, and resolution scaling laws (8.8cm theoretical limit). Part of RF Topological Sensing research swarm (12 agents). https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add RF graph theory and minimum cut foundations research GOAP Agent 1 output: Graph-theoretic foundations covering max-flow/min-cut for RF (Ford-Fulkerson, Stoer-Wagner, Karger), RF as dynamic graph with CSI coherence weights, topological change detection via Fiedler vector and Cheeger inequality, dynamic graph algorithms, comparison to classical RF sensing, formal mathematical framework, and 9 open research questions. Part of RF Topological Sensing research swarm (12 agents). https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add ESP32 mesh hardware constraints research GOAP Agent 6 output: ESP32 CSI capabilities (52/114 subcarriers), 16-node mesh topology with 120 edges, TDM synchronized sensing (3ms slots), computational budget (Stoer-Wagner uses 0.07% of one core), channel hopping, power analysis (0.44W/node), dual-core firmware architecture, and edge vs server computing with 100x data reduction on-device. Part of RF Topological Sensing research swarm (12 agents). https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add system architecture and prototype design research GOAP Agent 10 output: End-to-end architecture with pipeline diagrams, existing crate integration mapping, new rf_topology module design (DDD aggregate roots), 100ms latency budget breakdown, 3-phase prototype plan (4-node POC → 16-node room → 72-node multi-room), benchmark design with 8 metrics, ADR-044 draft, and Rust trait definitions (EdgeWeightComputer, TopologyGraph, MinCutSolver, BoundaryInterpolator). Part of RF Topological Sensing research swarm (12 agents). https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add quantum sensing and quantum biomedical research documents Agent 11: Quantum-level sensors (729 lines) — NV centers, SQUIDs, Rydberg atoms, quantum illumination, quantum graph theory (walks, spectral, QAOA), hybrid classical-quantum architecture, quantum ML (VQC, kernels, reservoir computing), NISQ applications (D-Wave, VQE), hardware roadmap. Agent 12: Quantum biomedical sensing (827 lines) — whole body biomagnetic mapping, neural field imaging without electrodes, circulation sensing, cellular EM signaling, non-contact diagnostics, coherence-based diagnostics (disease as coherence breakdown), neural interfaces, multimodal observatory, room-scale ambient health monitoring, graph-based biomedical analysis. Part of RF Topological Sensing research swarm (12 agents). https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add research index synthesizing all 12 documents (14,322 lines) Master index for RF Topological Sensing research compendium covering: graph theory foundations, CSI edge weights, attention mechanisms, transformers, sublinear algorithms, ESP32 hardware, contrastive learning, temporal graphs, resolution analysis, system architecture, quantum sensors, and quantum biomedical sensing. Includes key findings, proposed ADRs (044, 045), and 5-phase implementation roadmap. https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add SOTA neural decoding landscape and 10 application domains research - Doc 21: Comprehensive SOTA map (2023-2026) of brain sensors, decoders, and visualization systems with RuVector/mincut positioning analysis - Doc 22: Ten application domains for brain state observatory including disease detection, BCI, cognitive monitoring, mental health diagnostics, neurofeedback, dream reconstruction, cognitive research, HCI, wearables, and brain network digital twins with strategic roadmap https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add NV diamond neural magnetometry research document (13/22) Comprehensive 600+ line document covering NV center physics, neural magnetic field sources, sensor architecture, SQUID comparison, signal processing pipeline, RuVector integration, and development roadmap. https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add ruv-neural workspace Cargo.toml with 12 crate definitions Workspace structure for the rUv Neural brain topology analysis system. 12 mix-and-match crates with shared dependencies including RuVector integration, petgraph, rustfft, and WASM/ESP32 support. https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add ruv-neural crate ecosystem — 12 mix-and-match crates (WIP) Initial implementation of the rUv Neural brain topology analysis system: - ruv-neural-core: Core types, traits, errors, RVF format (compiles) - ruv-neural-sensor: NV diamond, OPM, EEG sensor interfaces (in progress) - ruv-neural-signal: DSP, filtering, spectral, connectivity (in progress) - ruv-neural-graph: Brain connectivity graph construction (in progress) - ruv-neural-mincut: Dynamic minimum cut topology analysis (in progress) - ruv-neural-embed: RuVector graph embeddings (in progress) - ruv-neural-memory: Persistent neural state memory + HNSW (compiles) - ruv-neural-decoder: Cognitive state classification + BCI (in progress) - ruv-neural-esp32: ESP32 edge sensor integration (compiles) - ruv-neural-wasm: WebAssembly browser bindings (in progress) - ruv-neural-viz: Visualization + ASCII rendering (in progress) - ruv-neural-cli: CLI tool (in progress) Agents still writing remaining modules. Next: fix compilation, tests, push. https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Fix ruv-neural crate compilation: all 12 crates build and 1200+ tests pass - Fix node2vec.rs type inference error (Vec<_> → Vec<Vec<f64>>) - Fix artifact.rs with full filter-based detection implementations - Fix signal crate ConnectivityMetric re-export and trait method names - Fix embed crate EmbeddingGenerator trait implementations - Complete spectral, topology, and node2vec embedders with tests - Complete preprocessing pipeline with sequential stage processing - All workspace crates compile cleanly, 0 test failures https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * Add ruv-neural-cli README https://claude.ai/code/session_01DGUAowNScGVp88bK2eiuRv * fix: convert desktop icons from RGB to RGBA for Tauri build Tauri's generate_context!() macro requires RGBA PNG icons. All 5 icon files (32x32.png, 128x128.png, 128x128@2x.png, icon.icns, icon.ico) were RGB-only, causing a proc macro panic on Linux builds. Fixes #200 Co-Authored-By: claude-flow <ruv@ruv.net> * Add Subcarrier Manifold and Vitals Oracle modules for 3D visualizations - Implemented Subcarrier Manifold to visualize amplitude data as a 3D surface with height and age attributes. - Created Vitals Oracle to represent vital signs using toroidal rings and particle trails, incorporating breathing and heart rate dynamics. - Both modules utilize Three.js for rendering and include custom shaders for visual effects. * feat: complete ruv-neural implementation — physics models, security, witness verification Replace all stubs/mocks with production physics-based signal models: - NV Diamond: ODMR Lorentzian dip, 1/f pink noise (Voss-McCartney), brain oscillations - OPM: SERF-mode, 50/60Hz powerline harmonics, full cross-talk compensation via Gaussian elimination with partial pivoting - EEG: 5 frequency bands, eye blink artifacts (Fp1/Fp2), muscle artifacts, impedance-based thermal noise floor - ESP32 ADC: ring-buffer reader with calibration signal generator, i16 clamp Security hardening (SEC-001 through SEC-005): - RVF bounded allocation (16MB metadata, 256MB payload) - sample_rate validation (>0, finite) - Signal NaN/Inf rejection - ADC resolution_bits overflow clamp - HNSW HashSet visited tracking + bounds checks Performance optimizations (PERF-001 through PERF-005): - 67x fewer FFTs via pre-computed analytic signals - VecDeque O(1) eviction in memory store - Thread-local FFT planner caching - BrainGraph::validate() for edge/weight integrity - Eigenvalue convergence early termination Ed25519 witness verification system: - 41 capability attestations across all 12 crates - SHA-256 digest + Ed25519 signature - CLI commands: `witness --output` and `witness --verify` README: ethics warning, hardware parts list (AliExpress), assembly instructions Co-Authored-By: claude-flow <ruv@ruv.net> * docs: add crates.io badges and install instructions to ruv-neural README Add version badges linking to each published crate on crates.io, cargo add instructions, and crate search link in the Crate Map table. Co-Authored-By: claude-flow <ruv@ruv.net> --------- Co-authored-by: Claude <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| LICENSE.txt | ||
| README.md | ||
| package.json | ||
README.md
baseline-browser-mapping
By the W3C WebDX Community Group and contributors.
baseline-browser-mapping provides:
- An
Arrayof browsers compatible with Baseline Widely available and Baseline year feature sets via thegetCompatibleVersions()function. - An
Array,ObjectorCSVas a string describing the Baseline feature set support of all browser versions included in the module's data set via thegetAllVersions()function.
You can use baseline-browser-mapping to help you determine minimum browser version support for your chosen Baseline feature set; or to analyse the level of support for different Baseline feature sets in your site's traffic by joining the data with your analytics data.
Install for local development
To install the package, run:
npm install --save-dev baseline-browser-mapping
The minimum supported NodeJS version for baseline-browser-mapping is v8 in alignment with browserslist. For NodeJS versions earlier than v13.2, the require('baseline-browser-mapping') syntax should be used to import the module.
Keeping baseline-browser-mapping up to date
baseline-browser-mapping depends on web-features and @mdn/browser-compat-data for core browser version selection, but the data is pre-packaged and minified. This package checks for updates to those modules and the supported downstream browsers on a daily basis and is updated frequently.
If you are only using this module to generate minimum browser versions for Baseline Widely available or Baseline year feature sets, you don't need to update this module frequently, as the backward looking data is reasonably stable.
However, if you are targeting Newly available, using the getAllVersions() function or heavily relying on the data for downstream browsers, you should update this module more frequently. If you target a feature cut off date within the last two months and your installed version of baseline-browser-mapping has data that is more than 2 months old, you will receive a console warning advising you to update to the latest version when you call getCompatibleVersions() or getAllVersions().
If you want to suppress the console warnings mentioned above you can use the suppressWarnings: true option in the configuration object passed to getCompatibleVersions() or getAllVersions(). Alternatively, you can use the BASELINE_BROWSER_MAPPING_IGNORE_OLD_DATA=true environment variable when running your build process. This module also respects the BROWSERSLIST_IGNORE_OLD_DATA=true environment variable. Environment variables can also be provided in a .env file from Node 20 onwards; however, this module does not load .env files automatically to avoid conflicts with other libraries with different requirements. You will need to use process.loadEnvFile() or a library like dotenv to load .env files before baseline-browser-mapping is called.
If you're building a tool that uses this module, consider suppressing the warnings but building a process into your tool that automatically updates this module. See, for example, browserslist and its update-browserslist-db package.
If you're implementing baseline-browser-mapping directly, you should add a script to your package.json to update baseline-browser-mapping and use it as part of your build process to ensure your data is as up to date as possible. For example, if you are using NPM for package management:
"scripts": [
"refresh-baseline-browser-mapping": "npm i baseline-browser-mapping@latest -D"
]
If you want to ensure reproducible builds, we strongly recommend using the widelyAvailableOnDate option to fix the Widely available date on a per build basis to ensure dependent tools provide the same output and you do not produce data staleness warnings. If you are using browserslist to target Baseline Widely available, consider automatically updating your browserslist configuration in package.json or .browserslistrc to baseline widely available on {YYYY-MM-DD} as part of your build process to ensure the same or sufficiently similar list of minimum browsers is reproduced for historical builds.
Importing baseline-browser-mapping
This module exposes two functions: getCompatibleVersions() and getAllVersions(), both which can be imported directly from baseline-browser-mapping:
import {
getCompatibleVersions,
getAllVersions,
} from "baseline-browser-mapping";
If you want to load the script and data directly in a web page without hosting it yourself, consider using a CDN:
<script type="module">
import {
getCompatibleVersions,
getAllVersions,
} from "https://cdn.jsdelivr.net/npm/baseline-browser-mapping";
</script>
Get Baseline Widely available browser versions or Baseline year browser versions
To get the current list of minimum browser versions compatible with Baseline Widely available features from the core browser set, call the getCompatibleVersions() function:
getCompatibleVersions();
Executed on 7th March 2025, the above code returns the following browser versions:
[
{ browser: "chrome", version: "105", release_date: "2022-09-02" },
{
browser: "chrome_android",
version: "105",
release_date: "2022-09-02",
},
{ browser: "edge", version: "105", release_date: "2022-09-02" },
{ browser: "firefox", version: "104", release_date: "2022-08-23" },
{
browser: "firefox_android",
version: "104",
release_date: "2022-08-23",
},
{ browser: "safari", version: "15.6", release_date: "2022-09-02" },
{
browser: "safari_ios",
version: "15.6",
release_date: "2022-09-02",
},
];
[!NOTE] The minimum versions of each browser are not necessarily the final release before the Widely available cutoff date of
TODAY - 30 MONTHS. Some earlier versions will have supported the full Widely available feature set.
getCompatibleVersions() configuration options
getCompatibleVersions() accepts an Object as an argument with configuration options. The defaults are as follows:
{
targetYear: undefined,
widelyAvailableOnDate: undefined,
includeDownstreamBrowsers: false,
listAllCompatibleVersions: false,
suppressWarnings: false
}
targetYear
The targetYear option returns the minimum browser versions compatible with all Baseline Newly available features at the end of the specified calendar year. For example, calling:
getCompatibleVersions({
targetYear: 2020,
});
Returns the following versions:
[
{ browser: "chrome", version: "87", release_date: "2020-11-19" },
{
browser: "chrome_android",
version: "87",
release_date: "2020-11-19",
},
{ browser: "edge", version: "87", release_date: "2020-11-19" },
{ browser: "firefox", version: "83", release_date: "2020-11-17" },
{
browser: "firefox_android",
version: "83",
release_date: "2020-11-17",
},
{ browser: "safari", version: "14", release_date: "2020-09-16" },
{ browser: "safari_ios", version: "14", release_date: "2020-09-16" },
];
[!NOTE] The minimum version of each browser is not necessarily the final version released in that calendar year. In the above example, Firefox 84 was the final version released in 2020; however Firefox 83 supported all of the features that were interoperable at the end of 2020. [!WARNING] You cannot use
targetYearandwidelyAavailableDatetogether. Please only use one of these options at a time.
widelyAvailableOnDate
The widelyAvailableOnDate option returns the minimum versions compatible with Baseline Widely available on a specified date in the format YYYY-MM-DD:
getCompatibleVersions({
widelyAvailableOnDate: `2023-04-05`,
});
[!TIP] This option is useful if you provide a versioned library that targets Baseline Widely available on each version's release date and you need to provide a statement on minimum supported browser versions in your documentation.
includeDownstreamBrowsers
Setting includeDownstreamBrowsers to true will include browsers outside of the Baseline core browser set where it is possible to map those browsers to an upstream Chromium or Gecko version:
getCompatibleVersions({
includeDownstreamBrowsers: true,
});
For more information on downstream browsers, see the section on downstream browsers below.
includeKaiOS
KaiOS is an operating system and app framework based on the Gecko engine from Firefox. KaiOS is based on the Gecko engine and feature support can be derived from the upstream Gecko version that each KaiOS version implements. However KaiOS requires other considerations beyond feature compatibility to ensure a good user experience as it runs on device types that do not have either mouse and keyboard or touch screen input in the way that all the other browsers supported by this module do.
getCompatibleVersions({
includeDownstreamBrowsers: true,
includeKaiOS: true,
});
[!NOTE] Including KaiOS requires you to include all downstream browsers using the
includeDownstreamBrowsersoption.
listAllCompatibleVersions
Setting listAllCompatibleVersions to true will include the minimum versions of each compatible browser, and all the subsequent versions:
getCompatibleVersions({
listAllCompatibleVersions: true,
});
suppressWarnings
Setting suppressWarnings to true will suppress the console warning about old data:
getCompatibleVersions({
suppressWarnings: true,
});
Get data for all browser versions
You may want to obtain data on all the browser versions available in this module for use in an analytics solution or dashboard. To get details of each browser version's level of Baseline support, call the getAllVersions() function:
import { getAllVersions } from "baseline-browser-mapping";
getAllVersions();
By default, this function returns an Array of Objects and excludes downstream browsers:
[
...
{
browser: "firefox_android", // Browser name
version: "125", // Browser version
release_date: "2024-04-16", // Release date
year: 2023, // Baseline year feature set the version supports
wa_compatible: true // Whether the browser version supports Widely available
},
...
]
For browser versions in @mdn/browser-compat-data that were released before Baseline can be defined, i.e. Baseline 2015, the year property is always the string: "pre_baseline".
Understanding which browsers support Newly available features
You may want to understand which recent browser versions support all Newly available features. You can replace the wa_compatible property with a supports property using the useSupport option:
getAllVersions({
useSupports: true,
});
The supports property is optional and has two possible values:
widelyfor browser versions that support all Widely available features.newlyfor browser versions that support all Newly available features.
Browser versions that do not support Widely or Newly available will not include the support property in the array or object outputs, and in the CSV output, the support column will contain an empty string. Browser versions that support all Newly available features also support all Widely available features.
getAllVersions() Configuration options
getAllVersions() accepts an Object as an argument with configuration options. The defaults are as follows:
{
includeDownstreamBrowsers: false,
outputFormat: "array",
suppressWarnings: false
}
includeDownstreamBrowsers (in getAllVersions() output)
As with getCompatibleVersions(), you can set includeDownstreamBrowsers to true to include the Chromium and Gecko downstream browsers listed below.
getAllVersions({
includeDownstreamBrowsers: true,
});
Downstream browsers include the same properties as core browsers, as well as the enginethey use and engine_version, for example:
[
...
{
browser: "samsunginternet_android",
version: "27.0",
release_date: "2024-11-06",
engine: "Blink",
engine_version: "125",
year: 2023,
supports: "widely"
},
...
]
includeKaiOS (in getAllVersions() output)
As with getCompatibleVersions() you can include KaiOS in your output. The same requirement to have includeDownstreamBrowsers: true applies.
getAllVersions({
includeDownstreamBrowsers: true,
includeKaiOS: true,
});
suppressWarnings (in getAllVersions() output)
As with getCompatibleVersions(), you can set suppressWarnings to true to suppress the console warning about old data:
getAllVersions({
suppressWarnings: true,
});
outputFormat
By default, this function returns an Array of Objects which can be manipulated in Javascript or output to JSON.
To return an Object that nests keys , set outputFormat to object:
getAllVersions({
outputFormat: "object",
});
In thise case, getAllVersions() returns a nested object with the browser IDs listed below as keys, and versions as keys within them:
{
"chrome": {
"53": {
"year": 2016,
"release_date": "2016-09-07"
},
...
}
Downstream browsers will include extra fields for engine and engine_versions
{
...
"webview_android": {
"53": {
"year": 2016,
"release_date": "2016-09-07",
"engine": "Blink",
"engine_version": "53"
},
...
}
To return a String in CSV format, set outputFormat to csv:
getAllVersions({
outputFormat: "csv",
});
getAllVersions returns a String with a header row and comma-separated values for each browser version that you can write to a file or pass to another service. Core browsers will have "NULL" as the value for their engine and engine_version:
"browser","version","year","supports","release_date","engine","engine_version"
...
"chrome","24","pre_baseline","","2013-01-10","NULL","NULL"
...
"chrome","53","2016","","2016-09-07","NULL","NULL"
...
"firefox","135","2024","widely","2025-02-04","NULL","NULL"
"firefox","136","2024","newly","2025-03-04","NULL","NULL"
...
"ya_android","20.12","2020","year_only","2020-12-20","Blink","87"
...
[!NOTE] The above example uses
"includeDownstreamBrowsers": true
Static resources
The outputs of getAllVersions() are available as JSON or CSV files generated on a daily basis and hosted on GitHub pages:
- Core browsers only
- Core browsers only, with
supportsproperty - Including downstream browsers
- Including downstream browsers with
supportsproperty
These files are updated on a daily basis.
CLI
baseline-browser-mapping includes a command line interface that exposes the same data and options as the getCompatibleVersions() function. To learn more about using the CLI, run:
npx baseline-browser-mapping --help
Downstream browsers
Limitations
The browser versions in this module come from two different sources:
- MDN's
browser-compat-datamodule. - Parsed user agent strings provided by useragents.io
MDN browser-compat-data is an authoritative source of information for the browsers it contains. The release dates for the Baseline core browser set and the mapping of downstream browsers to Chromium versions should be considered accurate.
Browser mappings from useragents.io are provided on a best effort basis. They assume that browser vendors are accurately stating the Chromium version they have implemented. The initial set of version mappings was derived from a bulk export in November 2024. This version was iterated over with a Regex match looking for a major Chrome version and a corresponding version of the browser in question, e.g.:
Mozilla/5.0 (Linux; U; Android 10; en-US; STK-L21 Build/HUAWEISTK-L21) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/100.0.4896.58 UCBrowser/13.8.2.1324 Mobile Safari/537.36
Shows UC Browser Mobile 13.8 implementing Chromium 100, and:
Mozilla/5.0 (Linux; arm_64; Android 11; Redmi Note 8 Pro) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.6613.123 YaBrowser/24.10.2.123.00 SA/3 Mobile Safari/537.36
Shows Yandex Browser Mobile 24.10 implementing Chromium 128. The Chromium version from this string is mapped to the corresponding Chrome version from MDN browser-compat-data.
[!NOTE] Where possible, approximate release dates have been included based on useragents.io "first seen" data. useragents.io does not have "first seen" dates prior to June 2020. However, these browsers' Baseline compatibility is determined by their Chromium or Gecko version, so their release dates are more informative than critical.
This data is updated on a daily basis using a script triggered by a GitHub action. Useragents.io provides a private API for this module which exposes the last 7 days of newly seen user agents for the currently tracked browsers. If a new major version of one of the tracked browsers is encountered with a Chromium version that meets or exceeds the previous latest version of that browser, it is added to the src/data/downstream-browsers.json file with the date it was first seen by useragents.io as its release date.
KaiOS is an exception - its upstream version mappings are handled separately from the other browsers because they happen very infrequently.
List of downstream browsers
| Browser | ID | Core | Source |
|---|---|---|---|
| Chrome | chrome |
true |
MDN browser-compat-data |
| Chrome for Android | chrome_android |
true |
MDN browser-compat-data |
| Edge | edge |
true |
MDN browser-compat-data |
| Firefox | firefox |
true |
MDN browser-compat-data |
| Firefox for Android | firefox_android |
true |
MDN browser-compat-data |
| Safari | safari |
true |
MDN browser-compat-data |
| Safari on iOS | safari_ios |
true |
MDN browser-compat-data |
| Opera | opera |
false |
MDN browser-compat-data |
| Opera Android | opera_android |
false |
MDN browser-compat-data |
| Samsung Internet | samsunginternet_android |
false |
MDN browser-compat-data |
| WebView Android | webview_android |
false |
MDN browser-compat-data |
| QQ Browser Mobile | qq_android |
false |
useragents.io |
| UC Browser Mobile | uc_android |
false |
useragents.io |
| Yandex Browser Mobile | ya_android |
false |
useragents.io |
| KaiOS | kai_os |
false |
Manual |
| Facebook for Android | facebook_android |
false |
useragents.io |
| Instagram for Android | instagram_android |
false |
useragents.io |
[!NOTE] All the non-core browsers currently included implement Chromium or Gecko. Their inclusion in any of the above methods is based on the Baseline feature set supported by the Chromium or Gecko version they implement, not their release date.