IGNATIJ TASEVSKISoftware engineering student & builder

RaNdm.net

Still curious. Still making.

THE PERSON IN THIS WORLD

Ignatij Tasevski.

Software engineering student & builder

SKOPJE
NORTH MACEDONIA
SCROLL
TO EXPLORE
A WORLD STILL UNFOLDINGTHE NEXT LAYER
02 / SELECTED WORKFour things. Different worlds.

Projects
in context.

Systems, everyday tools,
and a little room for play.

Keep exploring
02 / MY CITY

A bus app for Skopje.
Made for the everyday.

03 / JUST BECAUSE

A bit of Club Penguin,
back on my desktop.

Unofficial fan project
04 / HACKATHON · CO-CREATOR

A parking app.
Built together at a hackathon.

A SMALL OUTSIDE. MORE WITHIN.Choose an object to look closer
A LITTLE OFF THE PATH

Still curious?

You found another door.
You’ll need the password on the other side.

Step inside
01 / NEXARIS Copy link ↗
NEXARIS / SYSTEM ARCHITECTURE

A system
taking shape.

In progress

Nexaris is a capability-oriented system for connecting identities, services, data, and actions.

The aim is to give software a controlled way to use external services: make authority explicit, separate access from execution, and keep a trustworthy account of what happened.

Architecture and working local prototypes · Active development
THE PROJECT

Connections, with boundaries.

The longer-term vision is a shared operating layer for capabilities across services. The work today is building and testing the boundaries that would make that possible: protocols, authentication, authorization, scope, provider adapters, revocation, and audit.

Rather than treating every integration as an unrestricted API call, Nexaris asks who can request an action, which capability they hold, how that maps to a provider, and what evidence comes back.

01 / AUTHORITY

Who may act?

Identity, explicit grants, capability and scope models, and revocation. Pairing a client does not automatically give it execution permission.

02 / CONNECTIONS

Across the boundary.

Provider adapters and service bindings connect a bounded request to an external system while keeping native credentials out of the requesting client.

03 / ACCOUNTABILITY

What can we know?

Operation identifiers, structured audit, isolation review, and automated tests make both successful actions and uncertain outcomes inspectable.

WHAT EXISTS TODAY

A deliberately bounded
working slice.

The current local prototype connects an Android requester to a computer-hosted control plane and a real Radicale calendar service. It supports a scoped event-replacement operation, separate execution grants, local biometric confirmation, and a record of the outcome.

The general platform remains in progress. This prototype is not an Internet-deployed universal operating layer.

OPTIONAL / ONE ENGINEERING DECISIONWhat if an action happens, but its result is uncertain?Open the recorded case and supporting evidence

Unknown. But it happened.

A calendar event changed, but evidence of the change did not make it into the result. Nexaris kept the outcome Unknown and did not retry automatically. An independent read showed the effect.

P1 · Recorded local test · Controlled evidence loss
01 / FOLLOW THE EVIDENCE

A gap in knowing.

Explore the saved record.
Nothing here executes a live operation.

THE RECORDED RESULT

Uncertainty is an outcome.

The terminal record says application_evidence_lost. The operation may have taken effect, so Nexaris does not turn missing evidence into a claim of failure.

after.json · terminal audit
effect: unknown
reason: application_evidence_lost
receipt: null
observation: null
02 / WHAT CHANGED

A real effect.
An honest limit.

The target event’s summary and content hash changed. The separate Bob test calendar remained unchanged.

One native PUT was observed in this recorded window. That is evidence about this test, not an exactly-once delivery guarantee.

ALICE / BEFOREP1-legitimate-intervening-change
ALICE / AFTER P1-real-effect-lost-evidence
BOB / BEFORE & AFTERInitial — unchanged
Inspect the content hashes

Loading the recorded hashes…

Nexaris on Android displaying Unknown, no automatic retry, and a separate refresh-current-event action.
Original Android capture · P1 local build
Open image to inspect at full size ↗
03 / THE INTERFACE HAS TO TELL THE TRUTH

Read again.
Don’t act again.

The screen separates the historical outcome from a fresh observation. Refreshing reads the current event; it does not resubmit the replacement or rewrite the earlier result.

Here, the phone still shows the prior observation. The independent after-state above comes from the owner’s recorded read, not from this screenshot.

THE DESIGN DECISION

No default retry for an uncertain effect. A repeated action could overwrite a newer change.

This inspection covers one local capability: radicale_event_replace@1.0. It makes no claim about a general execution platform or an Internet deployment of Nexaris.

04 / OPEN THE RECORD

The evidence underneath.

Selected fields from the original before/after records and native log. Synthetic test calendars; no credentials or client identifiers included.

Download the evidence extract

p1/evidence/traces/unknown-real-effect/

before.json · after.json · native-window.log

p1/screenshots/unknown-real-effect.png

p1/docs/P1_ARCHITECTURE.md

The extract includes source-file hashes for provenance. It is a curated projection, not the complete test bundle.