subhadipmitra

Hi HN - we built an API that takes a satellite ID and a workload and returns a physically-accurate execution plan for splitting compute between space and ground.

The motivation: satellites generate ~1 TB/day but can only downlink ~7.5 GB per pass. As on-board compute improves, you need a planner that decides what runs where, schedules transfers across real ground station passes, and handles FEC/encryption overhead.

The planner runs full SGP4 propagation (same algorithm NORAD uses), computes eclipse windows, predicts passes for 12 ground stations with elevation-dependent link budgets, and produces deterministic plans.

You can try it live — our tracker lets you run plans against any satellite: https://rotastellar.com/tracker/ (select a satellite → Schedule tab → pick a preset → Plan Execution)

Happy to discuss the orbital mechanics, the placement heuristics, or anything else.

I built this for testing payment integrations. ISO 8583 is the binary protocol behind most card transactions (ATMs, POS terminals, payment switches) - notoriously painful to debug.

Features: - Parse/build/validate messages (1987, 1993, 2003 versions) - VISA, Mastercard, AMEX, Discover, JCB, UnionPay - 180k+ msg/sec with optional Cython - CLI + Python SDK + Jupyter notebooks

The LLM integration lets you explain raw messages in plain English or generate messages from natural language ("$50 refund to Mastercard at ACME Store"). Works with OpenAI, Claude, Gemini, or Ollama (fully offline).

Docs: https://iso8583.subhadipmitra.com

PyPI: pip install iso8583sim

Happy to answer questions about ISO 8583 or the implementation.

Hey HN, I built this because most LLM eval tools assume single-machine execution. When you need to evaluate against millions of examples (customer tickets, documents, etc.), they don't scale without significant duct-taping.

  spark-llm-eval runs natively on Spark - not "Spark as an afterthought" but distributed evaluation as the primary design goal.

  Key features:
  - Distributed inference via Pandas UDFs, scales linearly with executors
  - Statistical rigor by default: bootstrap CIs, paired t-tests, effect sizes
  - Multi-provider: OpenAI, Anthropic, Gemini, vLLM
  - Delta Lake integration for versioned results with lineage

  pip install spark-llm-eval

  The main gap I'm filling: "I have 2M labeled examples and need to know if Model A is statistically significantly better than Model B." Most frameworks give you point estimates; this gives you confidence intervals and significance tests.

  Blog post with architecture details: https://subhadipmitra.com/blog/2025/building-spark-llm-eval/

  Happy to answer questions about the implementation - rate limiting in distributed contexts was surprisingly tricky.

Author here. This is an RFC for open AI consent standards, not a product announcement.

The thesis: Training data lawsuits, agent security vulnerabilities, and user lock-in are architectural problems. We're trying to regulate AI without infrastructure to regulate.

I documented four standards:

- LCS-001: Consent tokens for training data (with attribution + compensation)

- LCS-002: Digital twins (user-owned, portable AI profiles)

- LCS-003: Agent permissions (capability-based security to prevent prompt injection exploits)

- LCS-004: Cross-agent memory (shared context with privacy controls)

The specs are on GitHub: https://github.com/LLMConsent/llmconsent-standards

Hardest unsolved problems I'm wrestling with:

1. Attribution in neural networks (influence functions are expensive/imperfect)

2. Enforcement without regulatory pressure

3. Whether L2s are really cheap enough for this use case

I'd especially value criticism on:

- Does LCS-003 actually prevent the "confused deputy" agent exploits?

- Is the digital twin evolution protocol (LCS-002) realistic?

- Better alternatives to blockchain for decentralized verification?

Happy to answer questions. Looking for serious technical feedback, not validation.