About Saroir

W3C Decentralized Identifiers (DIDs)

Self-owned identity not controlled by any platform, employer, or institution.

W3C Verifiable Credentials (VCs)

Tamper-proof, independently verifiable attribution that cannot be altered after signing.

GPG / SSH signed commits

Every commit is signed with the contributor's key, proving authorship at the cryptographic level.

Per-user keypair at onboarding

Generated at account creation. Signs content hash at submission, invisible to the user, permanent in the record.

SHA-256 content hashing

Any change to the content produces a completely different hash. Tampering is mathematically detectable.

Transparency Log (RFC 6962)

The same standard used in SSL certificate transparency. Deletions are visible, nothing disappears silently.

Layer-2 blockchain timestamping (OpenTimestamps)

Proof of existence written to a public chain. Survives independently of Saroir's infrastructure.

Merkle tree structure

Each version references the hash of its parent. The chain of changes is permanent and unbreakable.

GitHub Apps API / GitLab App

Per-installation rate limits, scoped permissions, and webhook events. Saroir never owns the repo.

Webhook pipeline on merge

Moderator acceptance fires a webhook. Saroir receives the payload and records attribution without any manual step.

VC payload includes repo URL + commit SHA

The commit hash is included in the contribution VC payload. Independent proof the code existed at that moment, regardless of whether the external repo survives.

Platform-managed commits

Saroir writes structured commits on the contributor's behalf. The user sees a form. Git runs underneath.

JSON Schema

Structured fields per domain. Clinical, legal, research, and creative submissions are reviewable and comparable.

Lightweight checksum + SaaS native version IDs

For Figma, Google Drive, Frame.io and others. Saroir reads the version metadata, it never stores the 2GB file.

Event log pattern

What changed, why it changed, who approved the direction. The intellectual record, not the binary asset.

Pull request review model

Moderator acceptance is a signed event. The reviewer's domain credentials are part of the attribution record.

Contribution-weighted voting

A vote from a practitioner with 50 verified contributions in a subdomain carries more weight than one from a new joiner.

Semantic similarity + graph analysis + velocity detection

Flags duplicate submissions, effort-to-claim mismatches, and Sybil patterns before a human moderator sees them.

Reputation escrow pattern

Every approval links back to the moderator's own record. Patterns of poor moderation are visible and accountable.

Immutable versioning

Old versions are marked superseded, never deleted. The contributor retains full attribution for every stage of their thinking.

Structured archival schema

The idea layer: concept, learnings, failure modes, published permanently and independently of the codebase.

Explicit parent reference

Every revival declares its origin. The attribution chain from original idea to rebuilt product is permanent and auditable.

Archived state pattern

Unanswered questions are not deleted as noise. They are preserved as structured signal about where a domain has gaps.

Cryptographic verification

Any third party can verify credentials using the contributor's public key and the OTS proof. No Saroir server needed.

W3C Verifiable Credentials export

The profile is a signed document the contributor owns and can present to any employer, institution, or platform.

OAuth-linked git identity

One verified link maps all future commits from that handle automatically to the contributor's Saroir profile.

Read-only API integration

Figma, Google Drive, and similar tools. Saroir reads metadata as supporting evidence, never stores the content.

LiteLLM proxy

A single interface across OpenAI, Anthropic, Azure OpenAI, Mistral, Cohere, and self-hosted models. Swap providers without changing application logic.

Org-scoped encrypted key injection

API keys are stored encrypted at rest, never logged, and injected at request time. Saroir never sees the key value after initial submission.

LiteLLM sidecar deployment

Model traffic never transits Saroir's core application layer. For air-gapped deployments, the proxy runs entirely within the organisation's own infrastructure.

Cost-based and latency-based routing

Lighter models handle spam triage and velocity detection. Stronger models handle semantic similarity scoring and contribution analysis. Routing is configurable per feature.