Arqora logoA R Q O R A
Open SourceDeveloper toolsPublic releases

Build in public, only when it matters.

Arqora open source is not a dumping ground for experiments. It is a small, deliberate collection of tools, packages, and references that are stable enough to be useful outside our own systems.

quick-start.sh
$ npm install talkshitgetdared
$ npx talkshitgetdared random
→ truth / dare prompt returned

01

Public package

02

Planned tools

03

Internal first

Registry

Public and candidate repositories

talkshitgetdared

Arqora repository

Public

A lightweight truth-or-dare package built for developers, Discord bots, games, and custom party flows.

TypeScriptNPMCLI

arqora-cdn

Arqora repository

Planned

A small upload, storage, and delivery layer for developer tools, bots, and internal Arqora systems.

Next.jsPostgreSQLStorage

arqora-labs

Arqora repository

Internal

Experimental utilities, infrastructure notes, prototypes, and proof-of-concepts before selective release.

SystemsInfraDocs

Principles

What makes something Arqora-open-source

Useful before public

Projects are used internally first. Public release happens only when the tool has proven value beyond Arqora.

Safe by default

We avoid shipping tools that create abuse, privacy, or security risk without clear guardrails and documentation.

Readable over clever

Open-source code should be easy to inspect, fork, maintain, and understand without hidden context.

Small surface area

We prefer focused packages and clean APIs over oversized platforms that try to solve everything at once.

Contribution is welcome, not forced.

Arqora projects should be understandable without needing access to private systems. Contributions are reviewed for stability, maintainability, and whether they keep the project focused.

Contribution flow

01. Fork

Start with a focused change instead of a wide rewrite.

02. Document

Explain behavior, tradeoffs, and breaking changes clearly.

03. Test

Keep public packages stable before asking users to rely on them.

04. Review

Changes are accepted when they improve the project without expanding it unnecessarily.

Licensing & trust

Clear licenses, clear boundaries.

Public repositories should include a license, README, usage notes, and responsible boundaries. If a tool depends on private infrastructure or internal assumptions, it stays private until it can stand alone.

License

Boundaries

Readable API

Contributors

Open-source surface is intentionally small.
Visit GitHub