Establish Congress voucher replication and incoming-email evidence #2

New issue

Closed

opened 2026-10-20 21:29:12 +00:00 by phg · 1 comment

phg commented

2026-10-20 21:29:12 +00:00

Owner

Part of #1

Question

What can official Congress/pretix documentation and the supplied email establish about voucher replication and the evidence prevouch can rely on?

Investigate the purchase/order/payment trigger, successor delay and quantity, expiry and inventory conditions, supported recipient field, and whether one voucher permits multiple tickets. Distinguish generic pretix capabilities from Congress-specific configuration. Inspect MIME/header and body structure, stable event/voucher identifiers, transport recipient information, and whether any predecessor reference exists. Assess whether distinct application-controlled return addresses can provide correlation without assuming the email body does.

Use primary sources and a redacted analysis of the private attachment. Do not redeem the sample voucher or contact the issuer. Explicitly state what cannot be established and what evidence would settle it. The supplied email alone states only presale access subject to remaining inventory.

Resolution: a sourced research note on a throwaway research branch, linked from a resolution comment with a concise statement of facts, uncertainties, and downstream implications. Research alone must not decide product policies.

Part of #1 ## Question What can official Congress/pretix documentation and the supplied email establish about voucher replication and the evidence prevouch can rely on? Investigate the purchase/order/payment trigger, successor delay and quantity, expiry and inventory conditions, supported recipient field, and whether one voucher permits multiple tickets. Distinguish generic pretix capabilities from Congress-specific configuration. Inspect MIME/header and body structure, stable event/voucher identifiers, transport recipient information, and whether any predecessor reference exists. Assess whether distinct application-controlled return addresses can provide correlation without assuming the email body does. Use primary sources and a redacted analysis of the private attachment. Do not redeem the sample voucher or contact the issuer. Explicitly state what cannot be established and what evidence would settle it. The supplied email alone states only presale access subject to remaining inventory. Resolution: a sourced research note on a throwaway research branch, linked from a resolution comment with a concise statement of facts, uncertainties, and downstream implications. Research alone must not decide product policies.

phg added the

wayfinder:research

ready-for-agent

labels

2026-10-20 21:29:31 +00:00

phg added a new dependency

2026-10-20 21:29:43 +00:00

#5 Define ticket-request allocation and fulfillment

phg added a new dependency

2026-10-20 21:29:43 +00:00

#6 Choose successor routing and incoming-voucher trust rules

phg referenced this issue

2026-10-20 21:29:45 +00:00

Plan prevouch: specification and four-design prototype #1

phg self-assigned this

2026-10-20 21:29:46 +00:00

phg commented

2026-10-20 21:37:30 +00:00

Author

Owner

Research resolution for Establish Congress voucher replication and incoming-email evidence.

Official Congress documentation establishes single-use, one-ticket vouchers; payment-gated group successors; evening bank-day processing with a 24-hour order-age gate; and inventory/phase limits. Angel successors do not replicate. The Friends Ticket exception means successor arrival is not universal proof of completed payment. The note separates 39C3 evidence from the current 40C3 announcement and generic pretix capabilities.

Local MIME inspection found one code repeated across language/MIME alternatives, matching recipient trace fields, and no predecessor reference. No private codes, addresses, message identifiers, or redeem links are published.

Per-assignment return aliases could correlate mail through trusted SMTP envelope-recipient metadata, conditional on seller routing and preservation before rewriting. That does not itself authenticate the voucher or prove lineage.

Unresolved evidence is explicit: the exact Congress successor field/default/edit behavior needs a redacted checkout or seller-configuration capture; alias preservation and lineage need a known successor paired with trusted ingress metadata; per-code expiry and lifecycle edge cases need issuer evidence. This completes the research inventory, not live integration validation or product-policy decisions. No map edits or production changes were made.

Research resolution for **Establish Congress voucher replication and incoming-email evidence**. - [Research branch](https://git.s1q.dev/MISChaufen/prevouch/src/branch/research/voucher-replication) - [Sourced research note at commit 2ba0ec6](https://git.s1q.dev/MISChaufen/prevouch/src/commit/2ba0ec6ff7709f53c6f64cc17ba113be198da1ad/docs/research/voucher-replication.md) - [Commit](https://git.s1q.dev/MISChaufen/prevouch/commit/2ba0ec6ff7709f53c6f64cc17ba113be198da1ad) Official Congress documentation establishes single-use, one-ticket vouchers; payment-gated group successors; evening bank-day processing with a 24-hour **order-age** gate; and inventory/phase limits. Angel successors do not replicate. The Friends Ticket exception means successor arrival is not universal proof of completed payment. The note separates 39C3 evidence from the current 40C3 announcement and generic pretix capabilities. Local MIME inspection found one code repeated across language/MIME alternatives, matching recipient trace fields, and no predecessor reference. No private codes, addresses, message identifiers, or redeem links are published. Per-assignment return aliases could correlate mail through trusted **SMTP envelope-recipient** metadata, conditional on seller routing and preservation before rewriting. That does not itself authenticate the voucher or prove lineage. Unresolved evidence is explicit: the exact Congress successor field/default/edit behavior needs a redacted checkout or seller-configuration capture; alias preservation and lineage need a known successor paired with trusted ingress metadata; per-code expiry and lifecycle edge cases need issuer evidence. This completes the research inventory, not live integration validation or product-policy decisions. No map edits or production changes were made.

phg closed this issue

2026-10-20 21:37:37 +00:00

phg referenced this issue

2026-10-20 21:40:25 +00:00

Obtain redacted evidence of successor-address routing #13

phg added a new dependency

2026-10-20 21:40:54 +00:00

#13 Obtain redacted evidence of successor-address routing

phg referenced this issue

2026-10-22 18:46:51 +00:00

Define ticket-request allocation and fulfillment #5