Experimental public-interest open-source privacy and evidence infrastructure, built to stay in public hands.

Proofline is being built for records that should not disappear just because a phone does. The project aims to preserve encrypted evidence as events unfold, while keeping access explicit, bounded, and user-controlled.

Proofline is experimental. It is not an emergency service, emergency dispatch system, emergency-services integration, staffed response center, or guaranteed real-time response workflow.

open-proofline is the GitHub organization for Proofline's public source code, project documentation, and community-service repositories.

The organization currently includes:

• the public website and project framing surface
• the experimental Go server backend
• the experimental React web-client prototype
• best-effort community-service work kept separate from Proofline's safety and evidence system
• source-of-truth documentation for governance, security boundaries, and current implementation status

Proofline should read like public-interest infrastructure with a spine, not a startup pitch deck that discovered the word "community" under a desk.

This organization is not:

• an emergency service
• an emergency dispatch system
• emergency-services integration
• a staffed response center
• a production safety workflow
• a mobile recording app today
• a guarantee that any public deployment is production-ready
• a place to publish secrets, private deployment details, exploit payloads, incident data, request bodies, uploaded bytes, plaintext, raw keys, wrapped-key ciphertext, object-store details, or user safety data

Users and trusted contacts remain responsible for contacting emergency services. Proofline must not be treated as a guaranteed real-time safety system.

The long-term project direction is to support:

• encrypted incident capture
• timed safety checks
• non-emergency interaction records
• evidence notes
• near-live encrypted upload of short audio, video, location, timestamp, and context chunks where clients support it
• evidence preservation if a device is lost, damaged, powered off, destroyed, or taken
• controlled trusted-contact access for authorized review
• end-to-end encryption so Proofline itself is not meant to read sensitive material
• clear separation between capture, escalation, sharing, retention, and export

The goal is not to pretend software can replace emergency services, legal advice, a support network, or human judgment. It cannot.

Proofline is experimental, maintainer-led, and not production-ready emergency infrastructure.

Current core repositories:

Planned future repositories:

Planned repositories should not be described as implemented until they exist and their scope is documented. Prototype optimism is not a safety feature.

Use the right source for the claim:

Repository-specific facts belong in the repository that owns them. Project-wide governance posture belongs in the website repository.

Proofline is intended to grow as public-good open-source infrastructure. The planned long-term direction is a non-distributing cooperative or similar mission-locked public-good structure aligned with cooperative and libertarian socialist principles.

The core posture:

• public-good infrastructure
• workplace democracy and shared accountability
• transparent worker compensation
• pay for labour, not ownership extraction
• surplus reinvestment into Proofline and aligned public-good work
• self-hosting and open source as anti-capture design constraints
• resistance to vendor lock-in, investor capture, and trust-branded SaaS mutation

Proofline does not currently claim to be an incorporated cooperative, registered charity, registered nonprofit, foundation, company, or staffed governance body. If the project reaches that stage, governance should make project capture harder, not merely better branded.

Read the canonical source: website/docs/governance-and-political-alignment.md.

Proofline is currently a maintainer-led open-source project. There is no company, large team, support department, charity, nonprofit status, or emergency response center behind it.

Donations are optional and help with maintainer time, development, documentation, testing, security-conscious review, hosting, monitoring, backups, maintenance, abuse-control, and release work. The boring parts are, unfortunately, load-bearing.

Donations and contributions do not create accounts, unlock features, provide support priority, provide emergency assistance, create ownership, produce investment returns, or imply tax-deductible charity status.

Future official hosted-server cost recovery, subscriptions, or payment-gated account access, if they exist, should recover hosting and maintenance costs. They should not turn Proofline into a profit-maximizing SaaS creature wearing a public-good hat.

Support information lives at proofline.live/support/.

At a high level:

• the public website is live at proofline.live
• the server repository contains the experimental Go backend, authenticated /v1 API, private admin surfaces, encrypted chunk ingest, metadata storage, token-scoped incident viewer, release workflow, and deployment/security docs
• the web-client repository contains an experimental React account and incident-review prototype for authenticated metadata review and future user-facing account flows
• community services are operated separately from Proofline's safety, evidence, account, and emergency boundaries

For implementation details, read the owning repository. This organization profile is a high-level map, not a second source of truth with its own maintenance backlog.

Proofline does not currently provide:

• production mobile recording clients
• production public hosted accounts
• production payment or billing flows
• production account recovery
• push, SMS, Messenger, or trusted-contact notification delivery
• emergency-services integration
• guaranteed real-time trusted-contact review
• backend decryption
• browser decryption
• trusted-contact decryption
• raw server-held media keys
• key escrow
• break-glass key access
• playable media export
• public production admin/operator surfaces
• production deployment hardening

Future concepts must stay future-tense unless the source repositories document them as implemented.

Proofline may operate separate public-interest open-source services, such as the current best-effort Redlib community service listed on the website.

These services may be useful to the public web, but they are not part of Proofline's evidence system. They do not store Proofline evidence records, encrypted chunks, incident records, wrapped keys, account data, or safety-context data. They should not be treated as emergency infrastructure, service-level commitments, or support channels for urgent safety needs.

Read the current service boundaries at proofline.live/services/.

Proofline is planned around native iOS and Android clients for private capture, encrypted staging, upload, safety checks, trusted-contact alerts, and evidence review.

Early mobile interface concepts exist in Figma. They are design concepts only; native mobile clients, account/recovery flows, and production recording behavior are not implemented yet.

• iOS concepts
• Android concepts

Do not report security vulnerabilities through public GitHub issues.

For the current server implementation, follow:

open-proofline/server/SECURITY.md

For the current web-client prototype, follow:

open-proofline/web-client/SECURITY.md

Do not publish raw incident tokens, session tokens, secrets, uploaded bytes, request bodies, Authorization headers, private deployment details, plaintext, raw keys, raw media keys, contact private keys, wrapped-key ciphertext, exploit details, object-store credentials, stored paths, object keys, or user safety data.

Proofline's public voice should be:

• serious about safety, privacy, and public trust
• clear and humane
• principled without becoming foggy
• dryly witty where the humour clarifies values
• openly anti-SaaS and anti-capture when discussing governance, vendors, funding, and community services

Keep safety, security, implementation status, metadata, navigation, encryption, decryption, key-custody, vulnerability-reporting, and cryptocurrency transaction warnings plain. One sharp line per section is usually enough.

Each active code repository owns its own local development and validation commands. Start with the repository README and security policy before changing behavior or public claims.

Useful entry points:

• website/README.md
• server/README.md
• web-client/README.md

Current files override stale assumptions. Reusable prompts and summaries help with review, but they are not audits, certifications, or endorsements.

Active code repositories declare their own licenses. The website and current server implementation are licensed under the GNU Affero General Public License v3.0 only (AGPL-3.0-only).

The web-client repository also contains its own license and third-party license notes. Tailwind Catalyst/Tailwind Plus-derived component source files, if present, remain governed by the Tailwind Plus license and must not be redistributed as a standalone UI kit, template, starter, package, or design asset set.

Future repositories should declare their own license explicitly.