ViaSanto

  1. Chapter IIApps

  2. ViaSanto

    ViaSanto is a prayer app that grew out of a simple observation from everyday life: today, smartphones constantly pull us away from what matters. Instead of fighting that, I decided to turn the phone into an ally of prayer. Many people want to pray regularly but lose out to the rush of the day: a rosary started on the tram is easy to interrupt and lose track of, and a nine-day novena is easy to abandon after one missed day. Many others – because of illness, age, emigration or work – pray alone and have no one to share their intentions with. ViaSanto lets you pray discreetly on the go, keeps track of your progress and of each day of a novena, and brings people who pray on their own into a community that prays for their intentions.

    ViaSanto

  3. The app is built around a virtual, interactive rosary on the phone's screen. ViaSanto guides you step by step through the chosen devotions, tracks your progress and reminds you of your intentions. Gentle gamification supports the habit: perseverance unlocks new, carefully designed bead patterns. The social space matters just as much – groups where you can share intentions and support one another in prayer.

  4. See how it works

    The phone beside this text runs the real app. Click its screen to take control.

    • Find the first bead that hasn’t been prayed yet (just above the ones with a golden glow) — press and hold it: the text of the prayer starts running in the box at the top of the screen, and a bar shows your progress.
    • To change the look of the rosary, open the collection (the book icon in the bottom bar): choose “Różańce” (Rosaries) and another design — the app takes on its colours, and so does the frame around this text.
    • In the box, click “Czytanie na dziś” (Today’s reading) to open the readings of the day.
  5. The app is written in Flutter: one code base runs natively on iOS and Android and in the browser. The logic, the data and its security are handled by a self-hosted Supabase (PostgreSQL) backend on European servers. I designed the whole thing for reliability: ViaSanto also works offline – it stores progress on the device and syncs it with the server as soon as the connection is back.

  6. OrsonAI

    OrsonAI is an editorial text editor with a built-in AI assistant, which I built for journalists — freelancers as much as newsrooms, to which it is meant to offer comprehensive support. It grew out of my own work: writing, research and verification now happen at the same time, and in practice that means constantly jumping between documents, the browser and notes. Here everything happens in one window. You can consult a selected passage with the chat without pasting in the whole context, transcripts of recorded interviews land in the editor, and separate modes help you write from notes, look things up, check a text before publication — from the facts to the legal risks — and analyse documents and recordings. Before a query goes to an AI model on external servers, the text can be anonymised, so that interviewees’ names and other personal data never leave the newsroom. The assistant helps the journalist but doesn’t do the work for them. The app is not currently on sale, but it works and you can try it in guest mode. If newsrooms show interest, I don’t rule out continuing work on it.

    OrsonAI

  7. Most of my work went into the layer of trust. Every interaction with the AI is hashed — the whole path from the project, through the document and the conversation, to the query and the answer — and a background process checks the collected hashes every minute and anchors them in the Hedera Consensus Service every 1,000 events. On that basis the system can award a text a certificate of human authorship: it assesses the human contribution and the quality of the text, and if the text passes the thresholds, it writes its hash to the public Hedera Hashgraph ledger. Any later edit invalidates the certificate, and authenticity is checked by comparing the document’s SHA-256 hash with the record in the ledger. I spun the audit mechanism off as a separate, open library, HDK, under the CC BY-NC 4.0 licence from version 0.1.3 (a free library, alpha, with optional Hedera anchoring; earlier versions Apache 2.0). The backend is Python and FastAPI on Google Cloud in a European region; the text is handled mainly by Gemini models, Mistral is the fallback provider, and OpenAI models work on transcription.

    HDK on Hugging Face

  8. Orson Rec

    Orson Rec is a web app for recording interviews that you can install on your phone’s home screen. I made it for reporters working in the field, to save them hours of listening back to recordings and typing them up. At an important moment in the conversation you press CUT — the recorded fragment goes straight to speech-to-text, so the transcript, with timecodes, appears on screen fragment by fragment while the interview is still going on. You can mark key moments with IN and OUT markers and keep your prepared questions at hand in the prompter. VO mode lets you record a voice-over from a script prepared in the OrsonAI editor, and the built-in audio editor lets you trim the recording. The file exports to WAV, MP3 or AAC, and the transcript goes to the editor with one click. The recording itself happens on the phone, but transcription needs an internet connection.

    Orson Rec

  9. NextAI

The HDK technology

HDK (Hedera Detection Key) is a small, free Python library that I spun off from OrsonAI as a separate, open tool. From version 0.1.3 it is under the CC BY-NC 4.0 licence (earlier versions, released under Apache 2.0, remain under it). The download is a free library (alpha 0.1.3) with optional Hedera anchoring (install from the downloaded file: pip install ./hdk-audit-0.1.3.zip). It ran for a while in a demo application, anchoring its records on Hedera; the application did not go to production, so HDK is not used in production today. It sits between an application and a language model’s API and records every interaction in a way that makes later tampering detectable. It does not change the prompts or the answers: it adds cryptographic proof of what was asked, what came back, when, and from which model.

The problem

Companies and newsrooms rely more and more on AI-generated text, yet they have no verifiable proof of what a model actually produced. Application logs sit in databases controlled by the operator: they can be changed or deleted, and nobody outside can check that this has not happened. Even where hash chains exist, a change is found only by comparing records by hand – nothing makes unauthorised access reveal itself at the moment it happens.

Hierarchical hash genealogy

HDK computes a SHA-256 hash of every event together with the hashes of all its ancestors: project, document, conversation, query and response. The hash of an answer therefore contains the whole path back to the project. Change anything at any level – one word of a prompt, one document – and the hashes of all its descendants change too. For each project HDK computes a Merkle root: a single hash that stands for the state of the whole project at a given moment.

The canary

The second layer is a “canary”: a secret 256-bit value and a counter that goes up with every read. Their hash (the commitment) is woven into every record and checkpointed regularly. If someone reads data through the middleware without updating the counter, the counter no longer matches; if they update it without knowing the secret, the commitment no longer matches. Either way, verification fails. The idea carries over to ordinary infrastructure a principle from my earlier, conceptual work on detecting breaches in AI containment.

Anchoring on Hedera

From time to time – by default after every 1,000 new events – HDK publishes the Merkle root on the Hedera Consensus Service, a public ledger that adds a consensus timestamp and a sequence number. Only hashes leave the user’s system; content, identities and prompts stay private (“data private, proof public”). Anyone can then check the record independently, for example on hashscan.io (OrsonAI’s anchors from February–May 2026: topic 0.0.10278996 on the Hedera mainnet). Because the ancestor chains of new events reach into the range of the previous anchor, every anchor implicitly confirms all the earlier ones: the longer the system runs, the harder it is to rewrite history unnoticed.

Overhead and cost

In the measurements described in the paper, on standard x86 cloud infrastructure, HDK adds less than a millisecond per event. One anchor costs $0.0001, so at the default interval of 1,000 events anchoring costs $0.0000001 per interaction – about 0.0001% of the price of a typical model call ($0.01–$0.10). Anchoring every single event, for the highest security, costs $0.0001 per event.

Why it matters: the EU AI Act

The EU AI Act requires high-risk AI systems to keep records (Article 12) and to be transparent (Article 13). HDK provides an audit trail that a third party can verify without seeing any private content. In OrsonAI, this mechanism was the basis of the certificate of human authorship of a text.

Limitations

HDK’s guarantees are computational – they rest on the strength of SHA-256 and on external anchoring – not absolute. The canary works at the application level: it detects access through the HDK middleware, but not passive copying of data at the operating-system or infrastructure level, because copied bits leave no trace. A copy does not make it possible to falsify history, though: changing any past event breaks the genealogy, and the anchors on Hedera keep the original state. Random integrity checks catch mass changes, but not a single, surgical modification – against that, the protection comes from the genealogy and the anchoring. Security assumes that at least one of three layers stays uncompromised: the user-side data, the anchored record on Hedera, or the secret material. Next steps: formal verification of the hash-chain properties (Coq/Lean), federation of systems on shared HCS topics, and content-provenance certificates with selective disclosure.

Read the paper on ResearchGateHDK on Hugging Face