COOPERATIVE DEVELOPMENT
Taransvar does not claim to have all the cybersecurity expertise needed to build TaraSec. Our contribution is the idea, working infrastructure and a governance framework. We need developers, researchers, students, ISPs, hosting providers and network operators who know more than we do in their own fields.
GOOD GOVERNANCE, NOT A CLAIM OF EXPERTISE
A useful TaraSec partner may be an established institution, or a previously unknown developer who understands one part of the problem and is willing to improve it. TaraSec should make both able to contribute.
The aim is a public governance system where anyone can propose a change, support or oppose proposals, explain objections, revise ideas and follow accepted changes through implementation and testing.
Taransvar retains accountable governance responsibility without pretending that governance authority equals technical expertise.
MERIT IS BUILT BY CONTRIBUTING
Deploying and responsibly operating a TaraSec hotspot, node, gateway or participating server is a real contribution. It creates infrastructure, operational experience and evidence about how TaraSec works outside a development machine.
Propose changes, contribute code, tests and documentation, reproduce problems, find vulnerabilities and provide technically useful reviews.
Contributors can build demonstrated merit in different areas: networking, Linux/kernel, DDoS, ISP operations, AI, mobile apps, testing, documentation and governance.
Persistent identity and contribution history allow responsibility to grow from demonstrated work rather than titles alone.
IDENTITY WITHOUT BUYING INFLUENCE
The planned governance system can use Google sign-in for a persistent identity and allow contributors to add optional GitHub, LinkedIn or other relevant public profiles. These provide context; they do not prove expertise.
Financial supporters can also be acknowledged. Donations support TaraSec but must not purchase technical authority or votes. Technical merit should primarily be earned through observable contribution.
AN EXTENSIBLE CONTRIBUTOR PROFILE
TaraSec should not define expertise through one employer, platform or credential. A contributor profile can combine verified identity context, public work, TaraSec operation and evidence of useful outcomes. Contributors should also be able to propose new evidence types.
Google can provide the primary TaraSec identity. Optional links may include GitHub, LinkedIn, Facebook, Upwork, ORCID, institutional affiliations and other relevant public profiles. Verification establishes control or association; it does not establish expertise.
Verified deployment and responsible operation of hotspots, nodes, gateways and participating servers can provide direct operational evidence. Useful signals include ownership confirmation, uptime, healthy configuration, completed tests and incident participation—not raw device count.
Code, research, proposals, reviews, reproduced defects, security findings, documentation, teaching, translation, community organization and other work can build merit in different domains.
A contributor may name an evidence type, explain its relevance, provide a proof link or verification method, select a domain and propose whether it should establish identity, context or merit. New types require review before affecting trust or governance.
Evidence should distinguish self-declared, ownership verified, independently reviewed and outcome verified. Contributors choose whether suitable evidence is public, limited to reviewers or private. Sensitive documents and platform access tokens must not be published.
Use minimal authorization scopes and store stable provider identifiers where available. Do not scrape contact lists or private social data. A public profile URL may provide context even where automated provider verification is unavailable.
Profiles provide evidence; they do not create a social score. Merit remains domain-specific and explainable. Donations, follower counts, popularity, credentials and message volume cannot purchase votes or unilateral authority.
Explore TaraSec ID → Suggest another kind of profile evidence →
VERIFIED GITHUB CONTRIBUTIONS
GitHub discussion activity is not currently credited automatically. The planned integration will attach a verified GitHub account to the contributor's Google-linked TaraSec identity before GitHub work can enter the merit ledger.
The contributor signs into TaraSec with Google and authorizes GitHub. TaraSec stores the stable GitHub user ID, not merely a changeable username, against the TaraSec contributor identity.
Candidate contribution events retain the GitHub discussion, comment, proposal, review, commit or test link, its category, time and author identity.
Messages do not earn merit merely by existing. Merit follows useful outcomes: improving a specification, identifying a real risk, providing evidence, verifying a test or helping an accepted proposal.
Each award records its reason, verifier and later corrections. GitHub work, infrastructure operation, testing and other contributions can appear under one identity while remaining separate merit categories.
Identity is evidence of who contributed, not proof that the contribution was correct. Discussion, merit assessment, voting and authorization remain separate steps.
AI-GUIDED DEVELOPMENT
TaraSec's public source and documentation can already be examined with ChatGPT where repository access is available. A contributor can ask AI to understand existing code, challenge assumptions, trace the consequences of an idea, find affected components, propose tests and develop a candidate implementation.
In the planned governance system, AI can analyze every proposal and summarize benefits, risks, affected components and unresolved objections. Other contributors must be able to challenge the AI's reasoning.
AI analysis is a contribution, not an authorization. AI-generated changes remain proposals subject to accountable review, testing and repository permissions.
CONSENSUS, NOT JUST UPVOTES
The goal is not “50% + 1 deploys code.” The system should expose support, opposition, relevant demonstrated expertise, unresolved objections, evidence, tests and the consequences of the change. Consensus can move a proposal toward implementation while consequential changes still pass technical and security safeguards.
A security-sensitive discovery also needs a private disclosure route so contributors are never required to publish an exploitable vulnerability in order to participate or receive credit.
TWO FORMS OF COOPERATION
AI-guided cooperative development helps people improve TaraSec itself through proposals, evidence, merit, consensus and reviewed implementation.
Automatic Request for Assistance is different: it is an operational protection mechanism where a constrained server can ask cooperating infrastructure to preserve presumed-clean traffic and suppress traffic already tagged through TaraSec's normal evidence process.
PLANNED GOVERNANCE PLATFORM
The next step is an online governance system with authenticated contributor profiles, proposals and revisions, support/opposition with reasons, AI analysis, unresolved-objection tracking, domain-specific merit, infrastructure contribution history, links to GitHub implementation and a permanent audit trail.
Automatic deployment is not the starting point. First we build a trustworthy process that can show why a change has consensus and how it was verified.