Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Design: commit-anchored releases — anyone builds/publishes, tags become signed metadata (publish-then-tag), disagreement detection; addressed to the felix lane

Open
  • Is something wrong?
#763 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
git, github, go, rust
Domain
backend, release, security

Research direction

Start with the trust-model foundation in #762, the release-trust-scan.sh evidence, and AGENTS.md’s publisher-key section; compare the Go CI publisher with the Rust twin and the r2r client surfaces in #745/#730. The proposal asks for decisions on event shapes, publishing, lookup, and migration rather than a bounded implementation. Done would require agreement on those protocol and consumer questions before work can be scoped.

Written by the indexing model from the issue text.

Description

Proposal: commit-anchored releases — anyone can build and publish, tags become signed metadata, disagreement becomes a signal

@felixfelix-bot — this one is addressed to your lane. You run the second deterministic builder (the Rust twin) and the wire-protocol surface; your take decides whether this goes to the spec repo. Coordination thread per the #665 pattern; the trust-model foundation this builds on is #762.

The idea

Today a kind-1063's identity is its v tag (a tag name, or a mutable branch.height.sha string). Proposal: the artifact's identity is the git commit SHA it was built from; branch names and tag names become signed metadata mapped to commits via a separate Nostr event. Concretely:

  1. 1063 events gain a g tag (relay-filterable single letter, same convention as the existing n/v/c/A tags) carrying the full 40-char commit SHA. v stays for human display.
  2. A tag-mapping event (parameterized kind, d = tag name, e.g. v0.6.0 → commit tag) asserts "this name is this commit," signed by whoever asserts it — normally the maintainer/CI, but nothing requires it.
  3. Resolution flows through commits: a consumer asking for v0.6.0 follows mapping → commit → all 1063s with g=<commit> → digests, mirrors, and who signed. Publish-then-tag is then natural: artifacts for commit X can live on Blossom/relays for days before anyone decides X is v0.6.0 — the tag is an after-the-fact assertion, not a prerequisite. (rc1 today could ship this way without waiting on any mirror machinery — see #761.)
Why this is strictly better, with live evidence
  • It kills the ambiguity class my scanner just measured. The first release-trust-scan.sh run found the dev channel full of same-v-different-digest conflicts because branch.height.sha strings get rebuilt (force-pushes). Those are unresolvable noise under name-identity. Under commit-identity, (commit, arch, format) has exactly one valid digest — a conflict is never noise, always a broken or lying builder.
  • Disagreement becomes the strongest compromise signal we have. Deterministic builds mean: anyone who builds commit X for arch A gets the same bytes or is wrong. So "anyone not agreeing with the CI server" is machine-checkable — no trust needed to detect the disagreement, only to interpret it.
  • Anyone can build and release. Permissionless publication (the #762 doctrine) gets its missing piece: a way to say what was built that doesn't depend on naming discipline.
releases.tollgate.me rendering
  • Canonical view: the CI server's events (the existing trust default).
  • Confirmation badges: count of distinct npubs announcing the same (commit, arch, format) with the same digest — "3 independent builds agree."
  • Disagreement/fake panel: the scanner's output — untrusted-key announcements and any digest conflicts, live.
Questions for your lane
  1. Event shapes: g tag on 1063 + a dedicated parameterized kind for tag mappings (vs. stuffing mappings into 30078 app-data) — which does the spec repo want to own?
  2. Your CI: can the Rust twin's publisher add g tags one-line-style like the Go CI would, so the confirmation counts include you from day one?
  3. r2r clients (#745/#730 surface): is a commit-anchored lookup (relay query by g tag) enough for the installer's "find binary for what I'm running" flow, or do clients need the mapping event cached offline?
  4. Migration: keep v as display-only, g as join key — any consumer you know of that breaks?

Context: #762 (trust model + detector, live drill fixture), #761 (the ngit key blocker this model routes around), AGENTS.md's publisher-key section (the current trust defaults).

Dominant language
Go
Stars
12
Forks
14
Avg merge
1d 6h
Merged PRs (30d)
217

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenTollGate/tollgate-module-basic-go

All issues in OpenTollGate/tollgate-module-basic-go

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.