u/Jazzlike_Wash6755

I'm a software developer from way before AI, from before this flood of badly made SaaS projects and half-baked platforms. I've been building and refining this for more than a year now.

The platform is the following: login is Web3, wallet-based, with EIP-712 typed signatures, no custody of user keys ever. Payment is crypto, and the payment plus the license record settle in one atomic on-chain transaction. Licenses get dual blockchain anchoring: batches go to a public chain as Merkle roots, so any license can prove inclusion without exposing anyone's data, and the full records are mirrored on a private permissioned ledger for enterprise setups.

Under all of it sits the cryptography: AES-256-GCM envelope per content item, the content key encapsulated with hybrid X25519 + ML-KEM-1024, both shared secrets fed into HKDF-SHA384, Ed25519 platform signatures with kid-based key rotation. Delivery is per-buyer proxy re-encryption: the content key gets re-wrapped for each buyer inside an isolated WASM enclave, the content itself is never re-encrypted. Oh, and all of this happens client-side, the server never touches decrypted data. There was a performance problem with that, which I solved by compiling the SDK from the native Rust crypto (standard RustCrypto crates) to WASM.

In the beginning I was thinking DRM. But during the build I accepted that nothing stops someone from recording or sharing content once it's decrypted on a screen. The analog hole doesn't care about ML-KEM. I realized this could still be something, proof of who licensed what and when instead of "nobody can copy this", but honestly I don't know how to move forward. So I ended up building a web3 marketplace hub on top with the dual anchoring above.

One more thing, and it's the uncomfortable part. The marketplace is built, but I never launched it, and the reason is partly ethical. If you've read this far you probably spotted it already: a marketplace where the operator can never inspect content, and where buyers are pseudonymous wallets, is also a perfect channel for material I want no part of. I don't have a real answer for moderation in a system deliberately designed so nobody can look inside, and I'm not willing to operate one without that answer. So take the marketplace off the table, and what's left in my hands is the cryptographic model and the SDK.

And honestly, after a year on this, I think that's the strongest piece anyway: a drop-in Rust/WASM core that encrypts, delivers and licenses content with hybrid post-quantum crypto, and it works independently of everything else.

Anyway, I'd honestly like your opinion. Should I give up and forget this thing, or is there something here worth pursuing, maybe the SDK and the crypto core on their own? And if you spot mistakes in the composition, say it bluntly, that's why I'm posting.

https://drive.google.com/file/d/1Qi\_\_\_E9\_yI83Ylfo1djYTA3zswRBP8hD/view?usp=drivesdk

I deleted my last post here two days ago. Short version: I found errors in the PDF, and a question in the comments deserved a better answer than the one I had at the time. Rather than leave a broken paper up, I took it down to fix both. This is the repost.

For anyone who missed the original: it's a phenomenological model where gravitational decoherence gets both its length scale and its rate from the cosmological constant, λ_Λ = √(ℓ_P · L_dS) ≈ 52 µm and Γ = (m/m_P)² c/λ_Λ, zero free parameters, linear and compltely positive.

The errors first, since that's the embarrassing part. The worst one: the constraints table in section 3 was running off the right edge of the page so part of the "experimental bound" column was just... not there. No idea how I missed it before posting. Fixed now, plus smaller cleanup throughout.

Now the part that actually matters. The question was, fairly, whether any of this can be derived or if it's just numerology. Honest answer: I still can't derive it from first principles, and the paper now says so explicitly. But sitting with that question forced a result I didn't have before, and it became section 2.4.

It's a reconstruction theorem. The dephasing channel turns out to be exactly (not approximately, no Born-Markov step) the noise average of ordinary unitary evolution under a classical stochastic field that jitters local clock rates, with correlation length λ_Λ. Once the kernel and the rate are fixed, the noise amplitude isforced: S0 = 4ħG/(c⁴λ_Λ). Write it as S0 = σ²(λ_Λ/c) and you get σ = 2√(ℓ_P/L_dS) ≈ 6×10⁻³¹, with σ·λ_Λ = 2ℓ_P exactly. That is the Planckian modular fluctuation Verlinde and Zurek assign to the de Sitter causal diamond.

Being upfront about what this is and isn't: the amplitude follows by algebra, so these are not independent coincidences. What the theorem buys is compression, the model's two postulates (scale and rate) collapse into a single hypothesis about a single object. Two side effects I like: the preferred frame becomes a property of the noise configuration, like the CMB frame, instead of a proaperty of the dynamical law, and the GIE sector survives untouched, unlike in Tilloy-Diósi type constructions. The missing step for a real derivation is exactly the contested √N enhancement from the holographic noise program ...

PDF: https://drive.google.com/file/d/17UMI6eTIJWnXiJYUSu0AGwrSkgAZ1wSE/view?usp=drivesdk

https://preview.redd.it/mzc8tsjndxah1.png?width=2559&format=png&auto=webp&s=d84fb4912b6e065b8e8e747ccb726ba24e5dd967

For anyone who hasn't seen it before: AstroBurst is an open-source desktop app for processing space telescope data, fully offline. You drop in FITS or ASDF files from the public archives (JWST, Hubble, Roman), compose RGB from narrowband channels, stack, stretch, and export. Rust does the heavy lifting, React handles the UI, and the live preview runs on WebGPU. It opens a 2 GB datacube in about 300 ms and renders STF adjustments in 8 ms on the GPU.

The typical use case: grab three public Hubble frames from MAST, get a finished Pillars of Creation in about five minutes. The README now has a full ten-step walkthrough of exactly that, using the sample data that ships with the repo.

What's new in v0.5.6(Session generated by AI):

Star removal. Classic detection plus a soft mask and multi-scale push-pull inpainting. It produces a starless image and a separate stars layer (starless + stars reconstructs the original), so you can process nebulosity and stars independently and recombine. RGB uses a shared luminance mask to avoid color fringing. Known limit: diffraction spikes survive it, ML is on the roadmap.

LRGB combination in the compose wizard. Fun correctness detail: the first implementation normalized channels with a shared min-max, which zeroed the weakest channel. Color ratios only survive pure scaling, not offsets. The property tests caught it before release.

New background modes. Linked gradient removal (one surface fitted on the channel mean, subtracted from every channel, so per-channel fits stop silently shifting color balance), pedestal neutralization, and row/column de-banding for JWST 1/f striping with automatic axis detection.

Stretch UX. The Auto STF midtone slider is log-scale now with an inline histogram. The old linear slider had min=0.01 with the useful range sitting at 0.0001 to 0.01, so the right values were literally unreachable. GHS defaults were also retuned for linear data.

Alignment robustness. Phase correlation gained a rejection gate that falls back to identity instead of "correcting" an already-registered set. The threshold sits at the statistical noise floor of the correlation surface (the max of ~262k samples is ~5 sigma even for pure noise, so anything below that is meaningless).

The bits Rust folks might enjoy: it still has (as far as I know) the first non-Python ASDF reader (zlib/bzip2/lz4, Roman gWCS), memory-mapped FITS I/O, and an STF stretch that is bit-for-bit identical across the WGSL shader, a CPU worker, and the Rust backend. New lesson from this cycle: ndarray's .to_owned() on an f-order view preserves the f-order layout, so a downstream as_slice().expect("contiguous") can panic on an array that looks obviously contiguous. as_standard_layout().into_owned() is the actual spell. Regression test added.

If you want to try it, the fastest path is the Pillars tutorial in the README (three public WFPC2 frames, included in the repo). Feedback very welcome, especially from anyone who has fought FITS/WCS, FFT registration, or ndarray memory layouts before.

Repo: https://github.com/samuelkriegerbonini-dev/AstroBurst

https://preview.redd.it/tz7uzxep1p5h1.png?width=2559&format=png&auto=webp&s=5035e9bdf7b502057326fa5696a2f882182bcc5b

I posted AstroBurst here a while ago: a free, open-source desktop app that loads standard FITS (including the subs and stacks your Seestar saves) and lets you stack, compose, stretch, color-balance and export, all on your own machine. No cloud, no subscription.

It's been quiet in this project for a few months to focos on other projects (and evenings playing HOI4) . But I'm finally back at it, and v0.5 is a huge step forward:

• Drizzle super-resolution when stacking (scale, pixfrac, kernel).
• Quality-weighted stacking: it scores every frame on stars, FWHM and SNR, and automatically leans on your sharpest subs.
• A better masked stretch with a shared star mask, so you stop getting those ugly colored halos around bright stars.
• Alignment that actually works now on real sky-background frames. The old version could drift, and I finally tracked down why.
• Proper FITS export that keeps your WCS and headers and records exactly what was done to the image.
• Color tools: white balance, SCNR green removal, and SHO, HOO, Foraxx and Hubble palettes for narrowband.

It's built for space-telescope data (JWST, Hubble, Roman) but works on any well-formed FITS, so if you like reprocessing your Seestar subs by hand, it's worth a shot.

Repo and downloads: https://github.com/samuelkriegerbonini-dev/AstroBurst

I'd genuinely love feedback from Seestar folks on what would make it fit your workflow better.

https://preview.redd.it/i3mp7mz6oo5h1.png?width=2000&format=png&auto=webp&s=d83188b6665edbefaeb686d7dc6c7aa706ae05e1

A while back I shared AstroBurst here: an open-source desktop app for processing astronomical images (JWST, Hubble and Roman, in FITS and ASDF) fully offline. Compose RGB from narrowband channels, stack, stretch, export. Rust for the heavy lifting, React for the UI, WebGPU for the live preview.

Then it went quiet for a bit. I got pulled into other projects, but I finally circled back, and v0.5 is out. It's mostly the unglamorous but important stuff: getting the math right and not panicking on bad files.

Correctness (the part I actually lost sleep over):

• Phase-correlation alignment was just wrong. The cross-power conjugation order was inverted and I wasn't removing the DC pedestal before windowing, so it returned garbage shifts on anything with a real sky background. It registers properly now.
• Drizzle now accumulates a proper flux-conserving weighted average, so pixfrac and kernel actually do something.
• Sub-pixel peak interpolation had a sign flip. Also fixed.

New features:

• Drizzle in the compose pipeline (per-channel scale, pixfrac, kernel).
• Quality-weighted stacking: a subframe selector scores each frame (stars, FWHM, SNR) and weights the good ones.
• FITS export that's actually valid now. It preserves WCS and metadata and writes PROGRAM/HISTORY provenance cards for every step applied.
• Shared-luminance star mask for the masked stretch, so no more chromatic halos.

Robustness:

• Hardened the FITS and ASDF readers against malformed input, with checked arithmetic on all the untrusted size math, so no more overflow or panics.
• 305 backend tests passing.

The bits I'm quietly proud of, Rust-wise: it has (as far as I know) the first non-Python ASDF reader (zlib/bzip2/lz4, Roman gWCS), memory-mapped I/O, and the STF stretch comes out bit-for-bit identical across the GPU shader, a CPU worker, and the Rust backend.

Repo: https://github.com/samuelkriegerbonini-dev/AstroBurst

Honest feedback welcome, especially from anyone who's fought with FITS/WCS or FFT registration before. I clearly needed a second pair of eyes on that alignment code.

NOTE: I've always been transparent about my use of AI, but things have changed a bit. I still use it for drafting text, docs, and frontend work. However, since its coding quality seems to be degrading lately and it was stressing me out trying to fix the bugs it generated , so i've decided to stop using it for the Rust code.

Because I built the early versions with its help, a good chunk of this specific release was spent fixing some silly mistakes it left behind. The goal from here on out is to rely on it less and less.