Version: 3.4dev-20260819_084452
Commit: cfe90cf
Mediabot has gradually accumulated more features that need to understand one deceptively simple question:
Who is this IRC user, really?
A visible nickname is not always the durable identity.
With MB669, that answer finally gets a public, read-only API instead of being reimplemented by each consumer.
MB669 adds two public methods to Mediabot::Achievements:
resolve_registered_user(channel, nick)
known_aliases(channel, nick [, limit])
The first resolves a visible nickname to the registered Mediabot user.
The second exposes bounded durable alias evidence for that resolved identity.
The resolver follows a conservative rule:
exact registered USER nickname
↓
authoritative
If there is no direct registered nickname match, Mediabot may use durable alias evidence.
But only when that evidence points unambiguously to one registered user.
If identity is ambiguous:
Mediabot does not guess.
That is deliberate.
Identity infrastructure should prefer a clean “unknown/ambiguous” result over attaching somebody’s history to the wrong person.
The new public API does not:
create profiles
observe identities
touch identities
merge profiles
repair ambiguity
run migrations
rewrite identity state
It only reads existing identity information.
This makes it safe for features such as:
profiles
community statistics
awards
quotes/factoids
future social/history aggregation
to ask for identity without accidentally mutating it.
Before MB669, the Community Footprint work from MB665 needed to know directly about:
ACHIEVEMENT_PROFILE
ACHIEVEMENT_IDENTITY
That worked, but it crossed an architectural boundary.
MB669 migrates that consumer to the new public API.
A structural guard now confirms:
IDENTITY_SCHEMA_BOUNDARY=OK
Runtime modules outside Mediabot::Achievements no longer need to know how durable identity is physically stored.
That storage can evolve later without every social feature becoming coupled to it.
The first consumer moved to the new API is deliberately small:
MB665 Community Footprint
This is not a massive refactor.
MB669 proves the API with one real consumer first.
That keeps the round reviewable and avoids turning identity cleanup into a big-bang migration.
The API was tested read-only against the real development database.
Direct registered nickname:
DIRECT
status=ok
source=registered_nick
id_user=1
registered=teuk
channel=#radiocapsule
Durable alias:
ALIAS
status=ok
source=durable_alias
id_user=1
registered=teuk
channel=#radiocapsule
Both resolved to the same registered user:
SAME_REGISTERED_USER=OK id_user=1
The alias API also returned the stored durable evidence:
nick=Te[u]K
userhost=teuk@teuk.org
Final runtime result:
MB669_RUNTIME_READ_ONLY=OK
RC=0
The first runtime probe failed while reading mediabot.conf.
That failure was not caused by MB669 or by the configuration file.
The diagnostic script temporarily used:
local $/;
to slurp Achievements.pm, but the scope was too wide.
That left Perl’s input record separator undefined when Config::Simple later parsed the configuration file.
The probe was corrected by limiting that local $/ to a lexical block.
The second run succeeded without any application-code change.
The identity/profile regression covered:
MB646 durable Achievement identity
MB654 identity diagnostics
MB659 profile
MB665 Community Footprint
MB668 Community Achievements
MB669 Durable Identity API
Result:
PASSED : 182/182
RC=0
The complete fast lane also passed:
PASSED : 5191/5191
RC=0
Runtime: 180s
The latest full-suite checkpoint remains:
PASSED : 13837/13837
RC=0
Runtime: 955s
MB669 introduces:
no database schema change
no migration
no configuration key
no identity-data rewrite
no service change
no systemd change
The round is architectural, not migratory.
cfe90cf
🗺️ Let the Marauder's Map Resolve Every Durable Identity
Version:
3.4dev-20260819_084452
The visible result of MB669 is small.
That is intentional.
The important change is that future features no longer need to reinvent the question:
"Who does this nickname belong to?"
There is now one conservative answer.
One place owns the persistence details.
One API exposes the evidence.
And when the Marauder’s Map cannot prove who someone is, it simply refuses to invent footsteps. 🗺️✨
You must be logged in to reply.