docs

infiniware docs

this is the structural reference for the website, privacy posture, deployment path, and the broader open-source identity around infiniware.

overview

what infiniware is and what the site is expected to communicate.

infiniware hand-crafts open-source tools that respect privacy and keep digital life simple.
the public site should explain that the work is human-made, independent, and technically intentional.
the design should feel calm and structured, but not empty or vague.

the site should reflect the real project surface, not only one product card.

current public work includes al-muslim, al-muslim for linux, infinifix, conflictcraft, infinityos, and arabtech at the organization level.
the website should make it clear that infiniware is an open-source studio, not a one-page brand shell.
products should be described through utility, privacy posture, and technical direction rather than hype.

privacy is not marketing copy here. it is part of the operating model.

infiniware should clearly state that it does not sell user data.
data collection should stay minimal and tied to explicit site functions such as accounts, verification, discussions, comments, and contact messages.
privacy language should be readable, specific, and realistic about what is stored and why.

the community layer now belongs to the site itself.

django now owns local accounts, sign-up, sign-in, email verification codes, profiles, discussions, and comments.
postgresql is now the source of truth for community data instead of github issues, utterances, or firestore.
the same urls can stay in place while the backend underneath them becomes simpler and easier to maintain.

email should work as a first-class part of the backend, not as a best-effort extra.

verification uses a six-digit code valid for 10 minutes.
email is intended to be sent from noreply@infiniware.bid using smtp configured by environment variables.
contact submissions should still be stored by the backend even if delivery fails, so messages are not lost.

the live target is a python deployment, not the old static/runtime mix.

render is now a good fit for the live deployment because the backend has a single python entry point.
postgresql should hold owned application data so the site can grow without depending on scattered third-party surfaces.
the migration should reduce complexity and increase trust, not turn into a rewrite for its own sake.

al-muslim

mobile companion built around prayer times, reading, and a quieter daily surface.

al-muslim for linux

native linux branch for desktop prayer times, quran playback, and hijri date work.

infinifix

python-based open-source work under the infiniware umbrella.

conflictcraft

c++ merge workstation work focused on determinism and control.

infinityos

a broader systems idea that shows the studio is thinking beyond a single product.

arabtech

an independent arabic platform for reviews, programming, linux, and open-source projects with privacy first and no data sales.