trintler's weblog

Verifying Humans Without Surrendering Identity: A Case Against Government-Issued Online Verification

2026-04-27T22:00:00.000Z

Introduction

The rapid proliferation of artificially generated content has fundamentally altered the digital landscape. Recent research demonstrates that large language models can pass the Turing test^[1], that LLM-generated content is now widespread across society^[2], and that foundational barriers such as CAPTCHAs can be reliably solved by artificial intelligence^[3]. In response, many platforms have turned to government-issued identity verification as a definitive solution. Although government-issued identity verification addresses the genuine challenge of distinguishing humans from automated systems, its widespread implementation commoditises personal identity data and exposes users to inconsistent privacy protections. Privacy-preserving alternatives, particularly open-source methodologies that allow individuals to identify themselves, should therefore be adopted as the primary verification mechanism. This essay first examines the rationale behind identity verification, then analyses the privacy risks inherent in current government-issued approaches, and argues that decentralised alternatives offer a superior balance between platform security and individual privacy.

Current Systems

Conventional behavioural verification methods are no longer adequate to distinguish human users from automated systems, because the same AI capabilities that drive the verification problem also defeat its existing solutions. When Jones and Bergen (2025)^[1] demonstrate that large language models pass the Turing test, and Plesner et al. (2024)^[3] show that AI systems solve reCAPTCHA challenges with high accuracy, any verification method relying purely on behavioural cues becomes increasingly untenable. This obsolescence, compounded by the widespread adoption of LLM-generated content^[2], creates a verification vacuum that platforms understandably seek to fill.

Risks Behind the System

However, government-issued verification is not a proportionate response to this vacuum; rather, it introduces substantial privacy risks through third-party data handling and the commoditisation of personal identity. The inadequacy of passwords and security questions^[4] has driven platforms toward biometric data and government-issued credentials, yet this escalation reveals a perverse dynamic: the mechanism designed to signal trustworthiness simultaneously normalises the surrender of state-issued documents to commercial entities. Verification badges structurally reward credential exposure, as Xiao et al. (2023)^[5] demonstrate through Twitter and LinkedIn, where users voluntarily trade personal data for perceived credibility; although that evidence is drawn from two platforms, the underlying incentive plausibly recurs wherever verified status confers a comparable advantage. Moreover, government-issued digital credentials operate within complex privacy landscapes where data may traverse multiple jurisdictions with varying regulatory standards^[6]. Centralised verification thus incentivises data aggregation, because the verifying authority accumulates a dataset whose commercial value frequently exceeds its original verification purpose, producing unequal access and gaps in accountability across jurisdictions^[7]. Consequently, when identity verification becomes a prerequisite for full platform participation, identity is transformed from an inherent right into a commoditised asset.

Present Alternatives

Although privacy-preserving verification technologies remain at relatively early stages of deployment, their architectural principles demonstrate that security and user privacy need not be mutually exclusive objectives. Satybaldy et al. (2022)^[8] propose a Self-Sovereign Identity framework that enables document verification without centralised storage of sensitive credentials, allowing individuals to maintain control over their personal data while proving their legitimacy. Building on this principle, Muth et al. (2023)^[9] research smart contract-based verification of anonymous credentials, enabling platforms to confirm user authenticity through cryptographic proofs rather than direct access to government identification. The architectural distinction is significant, as under SSI, the verifying platform never possesses the credential itself but only a cryptographic proof of its validity, which eliminates the centralised data aggregation problem identified in the preceding analysis. Critics may contend that SSI’s limited adoption renders government-issued verification the only scalable option today; although that concession is genuine in the short term, it does not justify entrenching centralised verification, since each new deployment that moves toward decentralised systems reduces the future cost of migration away from commoditised identity infrastructure. These alternatives demonstrate that platforms could adopt privacy-preserving approaches that address the legitimate need for human verification while structurally preventing the privacy compromises that government-issued identification demands.

Conclusion

Government-issued identity verification, while addressing a genuine challenge posed by AI-generated content and automated systems, should not become the default mechanism for online platforms. The evidence presented demonstrates that the need for human verification is well established, given the capabilities of modern language models and the obsolescence of traditional barriers. However, current implementations create unacceptable privacy trade-offs by commoditising personal identity data and exposing users to inconsistent jurisdictional protections. Decentralised technologies such as Self-Sovereign Identity and anonymous credential verification offer viable pathways that reconcile platform security with individual privacy. Thus, the distinction is ultimately architectural. Systems that never possess a user’s credentials cannot commoditise them, regardless of jurisdictional pressures.

1.Jones, C. R., & Bergen, B. K. (2025). https://arxiv.org/abs/2503.23674 Large language models pass the Turing test. arXiv. ↩
2.Liang, W., Zhang, Y., Codreanu, M., Wang, J., Cao, H., & Zou, J. (2025). arxiv.org/abs/2502.09747 The widespread adoption of large language model-assisted writing across society. arXiv. ↩
3.Plesner, A., Vontobel, T., & Wattenhofer, R. (2024). Breaking reCAPTCHAv2. In 2024 IEEE 48th Annual COMPSAC (pp. 1047–1056). IEEE. doi:10.1109/compsac61105.2024.00142 ↩
4.Berozashvili, T. (2024). Securing digital identities in the era of remote identity verification. doi:10.13140/RG.2.2.11839.11688 ↩
5.Xiao, M., Wang, M., Kulshrestha, A., & Mayer, J. (2023). arxiv.org/abs/2304.14939 Account verification on social media: User perceptions and paid enrollment. arXiv. ↩
6.Flanagan, H. (2023). openid.net/Government-issued-Digital-Credentials-and-the-Privacy-Landscape-Final Government-issued digital credentials and the privacy landscape. OpenID Foundation. ↩
7.McGrath, K. (2016). Identity verification and societal challenges: Explaining the gap between service provision and development outcomes. MIS Quarterly, 40(2), 485–500. JSTOR ↩
8.Satybaldy, A., Subedi, A., & Nowostawski, M. (2022). A framework for online document verification using self-sovereign identity technology. Sensors, 22(21), 8408. doi: 10.3390/s2221840 ↩
9.Muth, R., Galal, T., Heiss, J., & Tschorsch, F. (2023). Towards smart contract-based verification of anonymous credentials. In Financial Cryptography and Data Security: FC 2022 International Workshops (pp. 481–498). Springer. ↩

hexo-sam-reader: Building a SAM Text-to-Speech Plugin for Hexo

2026-04-02T18:00:00.000Z

Intro

Motivation

I wanted to use a Text to speech to read these blog posts aloud, the only condition being that, it would have low-latency and locally compute all tokens. The reasoning behind this? because of the fact that I do not own a server! They are extremely expensive.

A very wise person once said, when resources for modern solutions become infeasibly expensive to you, rely on old solutions. Who said that? I did, but that part does not matter.

Thus, SAM came to mind: the Software Automatic Mouth^[1] is a speech synthesiser originally written in 1982 by Mark Barton of Don’t Ask Software for the Commodore 64. Christian Schiffler (@discordier) ported SAM to JavaScript as SamJs^[2], preserving the original’s distinctive robotic phoneme engine in a looooong ca. 3000-line browser-compatible library. SAM does not stream audio from a server! It runs entirely in the browser, synthesising speech from raw text via the Web Audio API^[3]. Therefore there exist no latency beyond local computation. Helpful considering the new state of my internet after moving in! (It is awful)

The product is hexo-sam-reader, which is a Hexo plugin that adds a SAM-powered TTS reader widget to any blog post, made for Hexo. This document traces the full development from a hardcoded prototype to a published npm package. In the future I plan to have a smoother sounding voice, but I would like to talk about SAM first!

Scope of This Document

This post covers the evolution of hexo-sam-reader across two distinct phases: the sam-v1 prototype (a looong Hexo helper script) and the published hexo-sam-reader package (a npm plugin for any hexo user to use). It examines the text processing pipeline, the playback engine, the configuration refactor that removed all hardcoding, and the documentation process.

I: The sam-v1 Prototype

The Helper

The project began as a single file: sam-reader.js, ca. 600 lines, dropped directly into the Hexo blog’s scripts/ directory. It registered itself as a Hexo EJS helper using hexo.extend.helper.register() and returned an HTML string containing the widget markup, inline CSS, and the entire client-side JavaScript.

The registration was:

hexo.extend.helper.register("sam_reader", function () {
  var page = this.page;
  if (!page || !page.sam) return "";

  var safeTitle = (page.title || "")
    .replace(/"/g, """)
    .replace(/, "<");

  return `
${safeTitle}">
  
`;
});

This is the Hexo helper pattern: a function that receives the current page context via this.page and returns raw HTML. The conditional if (!page.sam) return '' ensures the widget only renders on posts with sam: true in their front matter.

Hardcoded Values

Every configurable value was baked into the source. The colour scheme was embedded in CSS literal strings:

.sam-reader-widget {
  background: #000;
  border: 1px dashed #924a41;
  font-family: DOS, SimHei, Monaco, Menlo, Consolas, "Courier New", monospace;
}
.sam-reader-widget .sam-title {
  color: #c08179;
}
.sam-reader-widget .sam-controls button {
  background: #352b42;
  color: #c08179;
  border: 1px dashed #924a41;
}

The voice parameters were fixed in the HTML markup:

<label
  >Speed <input type="range" id="sam-speed" min="20" max="200" value="72"
/>label>
<label
  >Pitch <input type="range" id="sam-pitch" min="0" max="255" value="64"
/>label>
<label
  >Mouth <input type="range" id="sam-mouth" min="0" max="255" value="128"
/>label>
<label
  >Throat <input type="range" id="sam-throat" min="0" max="255" value="128"
/>label>

The abbreviation list was hardcoded inside the cleanForSam() function as a sequence of individual regex replacements:

text = text.replace(/\bNL\b/g, "Netherlands");
text = text.replace(/\bKIT\b/g, "K I T");
text = text.replace(/\bTUD\b/g, "T U D");
text = text.replace(/\bICPC\b/g, "I C P C");
text = text.replace(/\bTAPC\b/g, "T A P C");
text = text.replace(/\bBAPC\b/g, "B A P C");
text = text.replace(/\bNWERC\b/g, "N W E R C");
text = text.replace(/\bSSH\b/g, "S S H");
text = text.replace(/\bJOSS\b/g, "J O S S");
text = text.replace(/\bCLI\b/g, "C L I");
text = text.replace(/\bAPI\b/g, "A P I");
text = text.replace(/\bLaTeX\b/gi, "lay-tech");
text = text.replace(/\bCMake\b/gi, "see-make");
text = text.replace(/\be\.g\./g, "for example");
text = text.replace(/\bi\.e\./g, "that is");

Eighteen abbreviations, each a separate text.replace() call. Adding a new one meant editing the helper source. The content selector was hardcoded as .mypage. The SAM library path was hardcoded as /js/sam.js. The pause duration was var PAUSE_MS = 400. The chunk length limit was 200.

This worked for my blog specifically. However, could it could work for anyone else’s? No.

How the Prototype Functioned

Despite the hardcoding, the prototype established the complete processing pipeline that survived into the published package:

Conditional rendering: Check page.sam in front matter.
Widget injection: Return inline HTML with controls (Play, Pause, Stop), a progress bar, voice setting sliders, and a status indicator.

Async SAM loading: Dynamically create a

Bouncing Ball — Newton Impact Law
initializing...
Other examples:
A relay circuit where a diode switches on at a threshold voltage
A sliding-mode controller that changes sign when the error crosses past zero
A dry-friction joint where stick and slip have entirely different dynamics
Financial models with hard constraints (prices must be non-negative, quantities cannot be fractional)
All of these belong to the family of nonsmooth dynamical systems. Specifically, solve_nivp targets systems expressible as differential inclusions:
where  is a set-valued map, at smooth points,  is a singleton and you recover the classical ODE. At discontinuities however,  returns a set of feasible velocities (the Filippov convex hull at a switching surface, or a single value constrained by an inequality).
Why Classical Solvers Fail
Stiffness at a given Discontinuity
If you take a smooth solver (Runge-Kutta, Adams-Bashforth) and naively apply it to a nonsmooth system, two unfortunate results occur:
Event detection is now brittle! The solver doesn’t know when an impact occurs, this leads it to overshoot the constraint surface, finds itself on the wrong side, and then attempts to integrate backwards toward the event. This requires rootfinding at every step near a contact surface and gets extremely expensive.
Regularisation makes everything stiff. One of the most prevalent workarounds is to replace the hard constraint with a smooth approximation, which is a steep sigmoid instead of a step (This can be thought of as taxing the use of an illegal item, instead of banning it.) This introduces a large Lipschitz constant, which forces explicit solvers to use tiny timesteps or blow up in terms of memory, time, etc. You end up taking thousands of steps to resolve what is fundamentally a single instance.
It is worse for a Filippov system (switching at a surface): classical solvers exhibit chattering near the sliding surface, flipping between modes at each step, which leads to never having proper convergence.
Solver Chattering at a Switching Surface
Solver Chattering at Switching Surface
initializing...
Interesting Approach: Encode the Nonsmoothness
The cleaner solution, which solve_nivp implements, is to build the nonsmooth rules directly into the time-stepping scheme from the initial, rather than trying to smooth them away or detect them as events opposed to the ideal system.
The Time-Stepping Scheme
Implicit Euler as the Foundation
The implicit Euler method updates state via:
Unlike its explicit counterpart , this requires solving a (possibly nonlinear) system at each step. However the stability desired is derived fundamentally from it’s unconditional stableness for stiff problems.
Augmenting
Now, suppose the system has a contact constraint: state  must satisfy  (e.g., position above floor), and there exists a contact force  that only acts when the constraint is active.
The complementarity condition encodes this:
The last conditions says that either the constraint is inactive i.e.  and the force is zero, or the constraint is active i.e.  and the force is whatever is needed to prevent penetration of system. These 3 conditions altogether form a Linear Complementarity Problem (LCP) when the dynamics are linear, or a Nonlinear Complementarity Problem (NCP) otherwise.
Complementarity Condition
Complementarity Condition — Position vs Contact Force
initializing...
The augmented implicit step at each time  is to find any given  satisfying

where  is the constraint Jacobian. This is a Mixed Complementarity Problem (MCP), and this is what solve_nivp solves at each step instead of tradition.
Handling Impacts
For our previous bouncing ball from earlier, the impact law is applied exactly at the transition step. When the solver detects that the constraint surface is crossed (i.e.  in the unconstrained prediction), it applies the restitution law:
and then continues from the new post-impact state. There is surprisingly no extra-smoothing present here! =D
What solve_nivp Provides
The API
The library’s entry point is solve_ivp_ns. One specifies a given constraint type via a projection argument (e.g. 'unilateral' for a one-sided contact, 'identity' for unconstrained), and choose a nonlinear solver ('VI' for variational-inequality fixed-point, or 'semismooth_newton'). Our lovely bouncing ball now looks like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
import numpy as np
import solve_nivp

t, y, h, fk, info = solve_nivp.solve_ivp_ns(
    fun=rhs,                          # right-hand side f(t, x)
    t_span=(0.0, 5.0),
    y0=np.array([0.0, 1.0]),          # [velocity, height]
    method='trapezoidal',
    projection='unilateral',          # encodes q >= 0 contact constraint
    solver='VI',
    adaptive=True,
    atol=1e-6,
    rtol=1e-3,
)
The function returns a 5-tuple: (t, y, h, fk, info); that being: time array, state trajectory, step sizes, constraint forces, and a solver info dictionary respectively. The solver is then setting up and solving the complementarity system with the given arguments at each step.
Which Systems?
solve_nivp covers three main categories including the ones mentioned earlier to this:
Unilateral constraints with impacts, the bouncing ball, rigid-body contact, granular media
Switching systems (Filippov), sliding-mode controllers, relay circuits, piecewise-linear dynamics
DAEs with inequality constraints, mechanical systems with joints that can separate or lock
For each category there are worked examples in the repository^[2].
Relay Switching — Filippov Dynamics
Relay Circuit — Filippov Switching
initializing...
Documentation and Tests
The solve_nivp package is clearly shipped with the following on their github releases:
A full Sphinx documentation site with mathematical background
Jupyter notebook tutorials for each system class
A test suite covering the main integrator cases and edge conditions (zero-velocity impact, constraint grazing, etc.
Conclusion
Nonsmooth systems are not edge cases in engineering, they are everywhere and they must be responded to and considered for. Any system with contact, switching, or hard constraints is nonsmooth, and the classical ODE toolkit cannot handle them out-of-the-box. solve_nivp brings the complementarity approach to python with a clean API and proper documentation.
What stands out most to me is that most numerical software in this space is written as Fortran-wrapped Matlab, roughly readable by no one (including me!). This was rather refreshing python.
Thank you to David Riley and Ioannis Stefanou for the work on a genuinely useful package, and to Daniel S. Katz for editing the submission and inviting me.
The published article: DOI: 10.21105/joss.09775
1.solve_ivp package ↩
2.solve_nivp available on GitHub ↩



2025/2026 ICPC Regional Performance
2026-03-24T01:37:22.000Z
Intro
ICPC
The International Collegiate Programming Contest is an incredibly renowned competitive programming competition with various stages, in this document I walk through my experience this 2026 ICPC in my three regional contests.
Team Found
Valyn, Anton and I formed the sudden team “(() => {})();” – which indeed is meant to represent the no-ops lambda function in javascript or “arrow-function” – thought of by our one and only Valyn on the first day (the initial orchestrator.)
Contests
TAPC, UTwente, Enschede, NL
Initially, we participated in the Twents Algorithms Programming Contest (TAPC) at my university: University of Twente where we had a lot of fun, with a lax competition unexpectant of the continutation of this.
BAPC, TUD, Delft, NL
Intro
Subsequently, the next month as time passed by almost immediately, we qualified for the Benelux Algorithms Programming Contest (BAPC) being held at Technical University Delft. This was our first ever competition which was at such a scale and our nerves were racked to the computers (though there was only one.) Without a coach, this all was extremely difficult; however we persisted, formed a more unified Team Reference Document (TCR) which was made in the times when my proficiency with LaTeX wasn’t present (seen by the un-printed {} in the team name^[1]), and nor was my knowledge in this field worth much (also, I bought a HUGE QWERTY-US keyboard shown below to practice with (I usually use QWERTZ, but everyone else uses QWERTY-US.)). As you can imagine, our priorities were more present in complaining about our short stay in Rijswijk instead of Delft to cut costs (there was a beautiful arabic restaurant, though) (we almost slept with a 40-year-old in the same dorm as-well =)).
The aforementioned “HUGE” Keyboard:
Result
After the contest, our resolutions were moderate, wishing we could have performed better. However, we all saw we did quite a lot so far and were satisfied with the performance amidst the competiton with good solutions and program code.
NWERC, KIT, Karlsruhe, Germany
Intro
To plan for future competitions far ahead, we decided to string along a Year 2 senior, Adrian in our University to be our coach for the duration of the semester. Although, as it were looking like there was nothing more till next year: We get accepted to Northwestern Europe Regional Contest (NWERC)! This was exciting, finally we get to make another chance.
Concerns
There were a few admistrative, and logistical costs to take us in the Dutch university to Karlsruhe Institute of Technology (KIT); incuring MIN ca. €250 / person, and for this reason we have started works of our own study association described further. Leaving this aside, the trip to germany was fun, tiring and exhausting, sure, but fun.I think that was one of the most enjoyable FlixBus rides I have ever had since we were more focused on flipping a Swapfiets bicycle upside down (contemporary Dutch culture which might be illegal and hence filtered (see below)), speaking till 4:// am when there was work to do the next day and coding our beautiful team website arrowfunc.now made by Valyn on that very day. We then register at the new accomodation, sleep in, and get ready for the next day, where we mostly just take EVERY goodie IMAGINABLE from the sponsors. I think there is a very really stress-release behind this. I recommend everyone to take as many goodies as they can from an event, and goodness did we score, I believe the valuation of the goods were approximately €150. I think that is apt reimbursement. Don’t believe me? Check the picture^[2]. Those little jetbrains pins alone on the bottom right cost ~€4 each (see under reference) (and these were what I got, my teammates got similar returns.)
The aforementioned upside down bike,
Result
After thinking of who to gift these goodies to (families and friends) it quickly took time to do the real contest, we improved the TCR which helped, it was fun, exciting, and most of all tough. We hadn’t solved as many problems as we’d hoped due to ill health. However, we still put in the effort, Anton did an extremely impressive job, we all came up with interesting solutions and above all it was a lovely experience – and I would always do it again. I now do competitive programming problems for fun, and in my spare time, and I recommend you too! to me, it feels like playing chess. I love this stuff. The train back to Enschede while being in Dortmund Station at midnight sucked, but that’s how life is sometimes.
This is us in the hall:
Conclusion
I am incredibly grateful to my team, coach and university, since without them I wouldnt have done nearly as much, and overall this was one of the most thrilling experiences I have had, along with now fostering the ideas of creating my own study assocation for the betterment of the competitive programming in my university and financial/mental compensation, and for the creation of the social groups for it.
I have also in addition am grateful to have visited the beautiful cities Delft and Karlsruhe from these events, and the people I have met here.
A small landscape gallery:


1. ↩
2. ↩
3.View the Disatrous prices of Jetbrains Pins, the price as of 11/2025: ↩