Ideas for diff-ref-struct, each on its own page with its own log: the day it was said, the discussion held on it, the decisions taken, and its status on the way from a conversation to the app, the core, a module or an extension. An idea waits here until it gets the green light; then it becomes a requirement of the brief and a step of a stream, and this page records where it went. An idea can also be parked or discarded, with the reason kept. Nothing here is decided until a decision entry in the log says so. 10 ideas. Generated from data/ideas.yml; do not edit by hand.
I012026-10-15, Josudiscussed→ app
The option to choose a theme, a skin, for the app's appearance, as the forks of VS Code offer: not only light and dark, but named looks a user picks, shares and installs.
2026-10-15discussion Assessed: the app's 46 colour tokens, light and dark, and the Appearance settings already carry it; the cost is the three rules (two columns, the plot's meaning and colour-blind safety, Publish never follows the screen). A theme as a code-less extension once I02 exists.
I022026-10-15, Josudiscussed→ app
The option to add extensions, as the TRAE IDE does: a button to search and import them, and a place for each in the left vertical bar. This asks the core to be opened so that extensions connect to it; or extensions could be small cores of their own, written in Rust, that do their calculations and connect to the app to show the results.
2026-10-15discussion Assessed: the module interface and the shell's services are the extension interface in embryo; two kinds (view, engine) follow from L139; the cost is the frozen interface and the versioned core; five steps proposed, drs-infer as the first engine.
I032026-10-15, Josuworkshop→ site
A place in the website for ideas as they are said, each with the date it was added, the discussion held on it, the decisions taken, a status and its migration to the app, the core or an extension: a log per idea, since an idea gets modified, renewed or discarded later. Built like the rest of the site but in another palette, since the ideas are the innovative part. Perhaps a dedicated website, the seed-place, created in parallel with each project's site, where every idea has a workshop until it gets the green light to migrate from the incubator into the project.
2026-10-15discussion A section of each project's site rather than a separate site, bound to the log, the brief and the streams; the generator to move into the kit so that every project starts with it; the family's own incubator parked until an idea without a project appears.
I042026-10-16, Josudiscussed→ core
A derivative of the Bayesian inference before refinement (L286): extend the approach to the analysis of magnetic structures, with their symmetry treated thoroughly in the superspace formalism. The Bilbao Crystallographic Server's magnetic structures database could be a massive source of data for it.
2026-10-16discussion Assessed with MAGNDATA's pages and the literature: the database holds models, not patterns, so it is the measured prior and the test bed, not data to refine; 91 % single-irrep in a 2026 analysis; no program compares magnetic candidates by evidence; the core has no magnetic scattering yet, which is the real cost.
I052026-10-16, Josuworkshop→ core
Some twenty-five years ago the maximum entropy method was a promising approach to solving and refining crystal structures. Did it succeed, how far was it adopted or abandoned, was it really for refinement; could it be resurrected, or derived into something like the Bayesian inference and the exploration of configuration space?
2026-10-21discussion Audited with I06 (its workshop note of 21 October, §4): nothing found contradicts it; the entropic refinement still has no precedent for powders; WPEM (2026) is the nearest different estimator to compare with. Its references, until now only in the log's sources, are on this page with how each was checked. Josu proposes a project of its own for the topic (I07); this page keeps the record and points there.
I062026-10-19, Josuworkshop→ core
Beyond reproducing FullProf and GSAS-II, innovate in the minimisation, not only in the information it uses (as mode crystallography does). The Rietveld method is fixed; is its least-squares minimisation the best one can do, in reliability and in speed? Molecular dynamics and DFT codes (SIESTA, for one) relax structures into energy minima with algorithms of their own; Monte Carlo might approach the minimum of a many-parameter problem faster. The application differs, but think about what could be borrowed, and propose another possible way of refining that still lands on the very same results. And, asked straight after: machine learning, neural networks, physically informed models?
2026-10-21discussion Audited with I05 at Josu's request, with the Bayesian-optimisation primer he sent: Bayesian optimisation belongs where a whole refinement is the black box (BBO-Rietveld 2020, the Agada–Biswas papers of 2025–26, Spotlight 2025), never as the minimiser; twelve precedents the first assessment missed, by section (Antoniadis 1990, David 2004 twice, Gagin–Levin 2015, Coelho 2005, Toby 2024, Kerman 2012, Segal 2025, AiMat-DRX, the agents, WPEM, HMC in scattering, optimal transport in diffraction); three more path methods (an optimal-transport misfit for capture, the Poisson likelihood, a parameter released by its derivative); the references on the page; a project of its own proposed as I07. Second workshop note.
I072026-10-21, Josudiscussed→ project
Perhaps it is time to move the content of this topic, the ideas I05 and I06, the sessions they came out of and the audit of 21 October, to another website dedicated to it, to go deeper: all the references, what each of them claims, and how all of them could be taken into account, in a separate, independent project, first for deepening and only after for implementing, if possible and if it makes sense, in the app we are working on.
2026-10-21discussion Assessed and designed: a project worked as the inverse-problems one, with a library of every reference and its claims, a method catalogue, the sessions curated, the bench, a bridge page to the app, the brief as questions; prototypes in Python on the core's bindings, Rust only for what wins. The scaffold made locally the same day, not published; the name, the repositories and the first readings are Josu's to decide.
I082026-10-23, Josumigrated→ module
While reading the maps of the ESRF ID22 series of sample 400_4 (the esrf-datuak-irene project, 23 October 2026): a kind of map, but interactive, so that the exploration of the map is made easier for finding the phase transitions. It should have the option to select in the height, done on the colour-map legend at the right: the idea is to be able, so to say, to get rid of the big-height peaks and "go down" to the details.
2026-10-24migration Migrated: app 0.53.0 on core 0.77.0 and drs-publish 0.36.0 built from main e73e5b89, self-checked under PL36 (151 OK, 0 FAIL; relaunch 146 OK, 0 FAIL; Josu's files unchanged) and installed on Josu's Mac, 0.52.1 to the Trash. The interactive map is in his app from the colour bar to the paper and the browser. P65 (a region's range per view) follows as a correction of the core and the module.
I092026-10-23, Josuseed→ module
Seen on the maps of the ESRF ID22 series (esrf-datuak-irene, 23 October 2026): the tick marks of the axes are drawn inside the frame, over the map; they should go outside. Not to be applied in that project for now; a reminder for the Plots module (and Publish, whose figures showed it).
2026-10-23said Said by Josu on the maps of the ESRF ID22 series: the tick marks are generated inside, they should go outside; not to be applied there now, a reminder for the Plots module.
I102026-10-25, Josumigrated→ extension
Said on 25 October 2026, after the ESRF series was worked with the interactive map (L421; esrf-datuak-irene L021): a standalone, full HTML app, public on Josu's repositories, so that anyone with the URL has a UI for this kind of analysis: access to the user's local file structure to load the files, and then the app offers the possible map plots from the files. And for the present page: the project's navigation on the left as in the apps, an inspector, with a < to shrink it and a draggable separator; a toggle for the y axis between the interval adapted to the file shown and one fixed to the whole set's maximum, to see how things change; a toggle between the √ values and the raw values of the files, since the differences between peaks are often not so large that √ is needed; the map's vertical axis shows hours, should it be temperatures; a richer file inspector in every sense: icons, selecting files one by one or all at once. "Innovate, propose, be wise: a powerful tool that should be in the instruments at the ESRF so that the users do not have to do all this."
2026-10-25migration Migrated, the same day: diff-ref-struct Web is public at jmigartua.github.io/diff-ref-struct-web, built and pushed by the Action from main (web 24d8619, core 0.81.0). The five steps built in two rounds of three parallel orders (L424–L428): the core in WebAssembly, the browser host with the inspector, the files read in the browser and never uploaded, the series detector finding the ESRF run's three sets as they were built by hand, live mode, offline, the address in the hash, the public repository. Checked on the public page with the 101 ESRF files (L429).