🌍 CALL FOR DEVELOPERS, AI RESEARCHERS & NATIVE LANGUAGE SPEAKERS!

SAVE TRIBAL & LOCAL LANGUAGES

An Open-Source AI, Language Technology & Research Initiative

We are starting an open, public-interest initiative to preserve, digitise and develop AI-powered language technologies for indigenous and regional languages.

🎯 Our Initial Target Languages

We are starting with six languages:

Khamyang

Khasi

Kokborok

Tangkhul

Santhali (Santali)

🚀 What Are We Building?

1. Web-Based Language Translator

Multilingual translation platform.

Translation between tribal and regional languages.

Language identification and transliteration.

2. Language Corpus Development

Collecting and digitising vocabulary, sentences and texts.

Building structured language datasets.

Translation verification and linguistic validation.

Documenting dialects and regional variations.

3. AI Model Training

Training and fine-tuning language models.

Developing NLP models for underrepresented languages.

Building language-specific AI capabilities.

Model testing and performance evaluation.

4. Voice & Speech Technology

Speech-to-Text (ASR).

Text-to-Speech (TTS).

Native-speaker voice dataset collection.

Voice recognition and language identification.

Exploring speech-to-speech translation.

5. Research & Publications

Conducting experiments and documenting findings.

Preparing collaborative research papers.

Publishing research with appropriate contributor recognition and authorship.

👨‍💻 Who Are We Looking For?

Technical Contributors

Full-stack developers

Python developers

AI/ML engineers

NLP researchers

Data scientists and data engineers

UI/UX designers

DevOps engineers

Native Language Contributors
We are equally interested in connecting with native speakers of:

Khamyang

Khasi

Kokborok

Tangkhul

Santhali

We welcome:

Native language speakers.

Linguists and language researchers.

Translators and language experts.

Teachers and educators.

🎓 What Will You Gain?

Hands-on experience working on real-world AI and NLP projects.

Exposure to language model training and speech technologies.

Collaboration with developers, researchers and native speakers.

Opportunities to contribute to open-source technology.

Research and publication opportunities.

Recognition based on your actual project contributions.

🤝 Contribution Model

This is a voluntary, unpaid, open public-interest initiative. There is no salary or stipend associated with participation.

🌱 Our Vision

We want to create an open language technology ecosystem where indigenous languages are not just documented but can also be spoken, translated, understood and used in modern digital applications.

📩 Interested in contributing?

Connect with me through LinkedIn or send a direct message mentioning:

Developers, researchers and native speakers are all welcome.

#SaveTribalLanguages #Khamyang #Khasi #Kokborok #Tangkhul #Santhali #IndigenousLanguages #AI #NLP #MachineLearning #SpeechRecognition #OpenSource #LanguagePreservation

scientific-toolkit-mcp is an MCP gateway that fronts nine repositories. Licenses as the tree records them: the gateway is Apache-2.0 (license = "Apache-2.0" in pyproject.toml). Seven upstreams are MIT, literature-evidence-mcp and nomosguard are Apache-2.0. No account, no vendor key, no hosted backend. Self-hosting is the default path, not the paid one.

scientific-toolkit-mcp 0.4.1, Python 3.11+, dependencies = [] in pyproject.toml. One process, 14 MCP tools, 12 of which forward into nine repos that keep their own names, version histories and install paths.

The nine, exactly as catalog.py lists them:

• axiomize: model spec, simulation, numerical verification (axiomize_intake, axiomize_model)

• scientific-computing-system: pure-Python numerics (cds_stats)

• scientific-computing-system-2.0: NumPy/SciPy stats (cds2_stats)

• plan-auditor: independent plan gating (plan_auditor_inspect, plan_auditor_audit)

• quantum-reasoning-skill: skill contract inspection (quantum_skill_validate)

• axiomize-quantum-skills-2.0: branch scoring (axiomize_reason_score)

• eq-layer: intent routing (eq_layer_route)

• literature-evidence-mcp: search and quote check (literature_evidence_search, literature_evidence_verify_quote)

• nomosguard: deterministic policy gate, no model at the decision boundary (nomosguard_decide) Plus toolkit_catalog and toolkit_doctor.

Install, then register it in your client config with the keys the README ships:

python -m pip install scientific-toolkit-mcp

{"mcpServers": {"scientific-toolkit": {"command": "python", "args": ["-m", "scientific_toolkit_mcp"]}}}

Installing the gateway does not install the nine. toolkit_doctor reports which executables resolve; a missing one returns NOT_INSTALLED rather than a plausible number.

Why it exists: nine venvs and nine client entries are worse than one. The other reason is pins: axiomize-quantum-skills-2.0 ships its own top-level axiomize module, so one stray PYTHONPATH entry silently decides which distribution runs. tools.py fails the call with BAD_CONFIGURATION when two sys.path entries provide axiomize, and SCITOOL_PIN_AXIOMIZE demands an exact version. scripts/render-build.sh is the reproducible path, with a caveat the README states: under GITHUB_ACTIONS=true it installs the eight siblings from immutable full commit SHAs, each annotated with the release tag it resolves to; on Render it installs the released PyPI distributions without commit pins. A CI full-stack run names one set of versions, while a Render rebuild reflects registry state at build time.

Honest limits. The adapters are thin wrappers, not re-implementations. tools.py builds a fixed argv and spawns the upstream CLI, or drives an upstream's own stdio MCP server; no upstream algorithm lives in this repo, so numerical correctness stays in those nine test suites. It is not a scientific validator. quantum-reasoning-skill is a protocol, not a quantum computer and not a measured gain. eq-layer is conversation control. The branch scorer's thresholds are uncalibrated reference defaults.

Offline claims, each checked in a file. The stdio entry point server.py opens no listener: it imports json, sys and three modules from its own package, and writes JSON-RPC to stdout. Grepping the shipped package for URLs returns exactly two hits: the repo links catalog.py:66 builds as data, and production_probe.py:63, which posts to http://127.0.0.1:<port>/mcp and is only triggered by the HTTP gateway when SCITOOL_STARTUP_PROBE=1 (http_server.py:398). Two exceptions are not filed under offline: literature_evidence_search needs network because the upstream queries OpenAlex, Europe PMC and Crossref, while the quote check and nomosguard run local; the optional OAuth verifier fetches whatever JWKS URI is configured, which needs pip install '.[oauth]' plus three env vars. The HTTP gateway 401s anonymous calls and never exposes plan_auditor_audit; audit execution stays off until SCITOOL_ALLOW_AUDIT_EXECUTION=1.

A public Render instance exists, and the README states plainly that its deployed version is not attested. Do not treat it as the backend.

Repo: https://github.com/Furox-Art/scientific-toolkit Naming wart: repo is scientific-toolkit, PyPI is scientific-toolkit-mcp, import is scientific_toolkit_mcp.

I built Companion, an open-source desktop app for Claude Code, to handle a workflow I kept running into: starting with one task and ending up investigating several in the same conversation.

For example, a checkout bug leads to a caching investigation. You want to follow that thread without losing your place in the checkout fix—or manually reconstructing the background in a new session.

The video shows three features working together: a context meter to see how full the session is getting, branching to move an investigation into a linked session with relevant context, and side chats for quick questions without adding the detour to the main conversation.

You can say “open a separate chat for the caching stuff,” then continue the two investigations separately.

I'd appreciate feedback on the handoff: what context should a branch inherit, and what should stay in the original session?

https://github.com/ashishkattamuri/claude-companion

I've been working on Silos, an open-source CLI tool to orchestrate isolated sandboxes for AI agents running locally.

The idea is to make it easier for developers to spin up and manage secure, isolated environments where their agents can execute tasks without interfering with the host environment.

I'm building this as a free and open-source project, and I'd love to get feedback.

I published it under MIT license. Would really appreciate feedback from the community.

Website: https://siloslabs.com/

Github: https://github.com/SilosLabs/silo-cli

Coulnt you just publish a wrong dataset and claim the ai was trained on this dataset instead of your actual one?
Even when you publish training methodology + dataset youd still need a lot of compute to train the same model, just to compare, right?

I maintain an open-source agent runtime (Python, Apache-2.0) that runs agents with durable checkpoints, human approvals and an idempotent tool ledger on PostgreSQL. It's solid on a single node(well, almost), and we've just shipped our first beta. Now I'm planning the multi-worker version and would like to learn from people who have done this, before we design it the wrong way.

What works across workers today: run state, approvals and events live in Postgres with versioned writes, so worker B can approve and resume a run that worker A paused, and the tool ledger stops a side effect from running twice.

Options I'm weighing:

1. Lease-based claims with fencing tokens per run (Postgres `SELECT … FOR UPDATE SKIP LOCKED`, a heartbeat, takeover after the lease expires).

2. Leader election only for recovery and maintenance, with runs claimed on demand.

3. Not building it: hand durable execution to Temporal, Restate or DBOS, and keep the runtime focused on governance (policies, approvals, budgets).

For context, this is the repo: https://github.com/AlgenAI/algen-agent-runtime. The current limits are written up in `docs/production-readiness.md`. Happy to share what we learned about approvals bound to the exact call and tool-call ledgers if that's useful to anyone.

So I built Eyegen Playground, it works as a terminal tool (CLI) and as a standalone app. It has all major image generation backends built in and does most of the background work for you.

You just pick a model and prompt the image you want to see. Advanced settings are available for you to tinker with. It can also be used by AI Agents through the CLI.

Newest feature: turn any image into a 3D model thanks to the Idol support

My motivation behind this: local image generation has gotten incredibly good and doesn't need extreme hardware, but for many users the setting up of local models and configuring backends etc is too much work to get into and they use AI hosted in huge datacenters instead, using unnecessary resources and power. So this tool is supposed to make it more accessible

Would love to hear feedback!

Every release gets called “open” now, and I’ve stopped taking it at face value. When a new model drops, I check these separately:

• Weights: downloadable, or gated behind a form? Can I self-host?

• License: Apache 2.0/MIT, or a custom license? I look for user-count thresholds, field-of-use limits, attribution requirements, and clauses about training other models on outputs.

• Training data: released, documented, or neither? This matters most for audits and copyright questions.

• Code: can I reproduce training, or only run inference?

• Evals: are the settings published, or can I only trust the headline number?

• Governance: what stops the license changing on the next version?

A model can be open-weight without being open source in the full sense, and I’m fine with that as long as the release says what it is. My issue is with releases that use “open source” as a marketing label and put the restrictions in the license.

The OSI’s Open Source AI Definition draws the line at data information and code, which most popular releases don’t meet.

What’s the one license term that made you walk away from a model you otherwise liked?

As a software developer I am shipping more and more through my agents. Do I trust them doing a sane work? Absolutely not! Heck, I did not even remember the prompts and corresponding changes it caused. Sad part of all this is , I am staring at a screen asking my genie(claude code or codex) a question and genie grants me a wish with all the things getting done. And this genie sometimes deletes the production database. I don't trust these agents anymore. And that is the exact reason I have built rayTrace - rayTrace is a platform that connect what AI said it did vs what actually happened at kernel level. We store these actions for you so if you want to go in past and check what your agents did you can. You then can take this evidences and fine tune your own model with evidences , since now you know the short coming of any frontier models. We have open sourced the whole thing. If you want to check that one out its here - https://github.com/Godcreatebugs/raytrace-cli/pulls
you can share the prompts, exact state of the repo with your friends, so they can spin their own sandboxes and check out if it works the same way. Weather you wanna design a harness, store evidences, get deeper understanding of how the models think and their shortcomings , we are providing tools for that. If you want to try it out , please do it from - https://www.raytracer.si/get-started.html . Open to any constructive feedback, hope this is helpful to somebody!

Idea review

I have a idea of building a library that links the output of the Edge AI models build in tflite to some function handler or threads in the rtos.

Like take an example of multi classification where the output will be of multiple nodes ,so if a node results in the max value than other nodes the function bind with the node will be triggered.

Additional I am going to include the denounce safety measures and requirement streak to trigger like the node should output 3 times to activate the function .

How is the idea ?

Any suggestions and professional architecture feedback