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.

product footprint

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 and data boundaries

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.

accounts and community

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 and delivery

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.

deployment direction

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.

project footprint