17 pages across 3 parts. Click a title to jump straight to it.
Page 1 / 17
A blocksthor is a blockchain of testimonies created and managed directly by its users on the Aristhor platform. Unlike decentralized public blockchains (Bitcoin, Ethereum), a blocksthor is a private, named chain of blocks, where each block represents an act, event, or testimony that is timestamped and cryptographically signed.
Each block of a blocksthor contains a SHA-256d fingerprint calculated from its content and the fingerprint of the previous block, guaranteeing the immutability and traceability of the entire chain from the first block (zero-genesis block) to the last.
The principle relies on cryptographic block chaining: each new block incorporates the fingerprint of the previous block into its own fingerprint calculation. Modifying a past block would invalidate the entire chain from that block onward, making any tampering detectable.
Each block is signed using a private PGP/OpenPGP key, whose corresponding public key is deposited on Aristhor. Anyone with this public key can verify the authenticity of the signature, and therefore the identity of the signer of each block.
The blocksthor is built and managed offline using the Blocksthor Maker, a tool available on Aristhor.com. The resulting fingerprints can then be published on Aristhor for public consultation.
| Player | Role |
|---|---|
| Blocksthor owner | Owner of the blocksthor. They create it, manage it, add blocks, and define publication settings. |
| Users | Users invited by the administrator to access the blocksthor. Depending on their rights, they can add blocks or view the content. |
| Warrantors | Selected users who place a warranty on a specific block of the blocksthor, attesting to the accuracy or reality of its content. |
Page 2 / 17
Imagine a register of real estate sales.
| Real world | PoA blockchain |
|---|---|
| Land registry | Blockchain |
| Real estate sale | Transaction |
| Licensed notaries | Validators |
| Professional reputation | Authority |
| Entry in the register | Creating a block |
Imagine a town: residents propose projects, official decisions are recorded in a public register, but only elected members of the town council can vote on and sign decisions. Once approved, a decision is added to the register.
| Real world | PoA blockchain |
|---|---|
| Residents | Users |
| Town councillors | Validators |
| Town register | Blockchain |
This analogy clearly shows that not everyone needs to take part in validation.
In a port, every ship's arrival or departure is logged. Several harbor masters are authorized to sign entries. The signatures are public and identifiable. If one of them cheats, their career is at stake. This is very close to the PoA logic: a few trusted players, known identity, strong accountability, permanent history.
In a championship, results must be recorded. Only official referees can validate scores. Referees are known to everyone, and a referee who cheats risks suspension. Referees represent PoA validators — this analogy is particularly simple for a non-technical audience.
Every intervention on an aircraft is recorded in a logbook, signed by a certified mechanic, dated, and cannot be discreetly deleted. The logbook is trustworthy not because everyone watches it, but because the people who write in it are identified and accountable.
Imagine choosing who has the right to write the next line in a register:
| Mechanism | Physical analogy |
|---|---|
| Proof of Work (Bitcoin) | Whoever wins an extremely difficult race — like a contest where the first person to solve a puzzle earns the right to write. |
| Proof of Stake | Whoever has put up the most collateral — like co-owners who have tied up money and risk losing it if they cheat. |
| Proof of Authority | Whoever holds an official mandate — like a notary, a court clerk, or an authorized official. |
Two concepts need to be distinguished: who has the right to write? (PoA) and why are past entries hard to change? (chaining). Here are the physical analogies that explain chaining.
Imagine a large paper register. Each page contains new transactions, its page number, and a unique fingerprint of the previous page. If someone modifies a line on page 1, the fingerprint of page 1 changes, the reference recorded on page 2 becomes invalid, page 3 becomes inconsistent... All the following pages would then have to be redone. This is very close to how a real blockchain works.
Imagine a novel written by several authors. Each new chapter begins with: "I confirm that the previous chapter is exactly the one whose fingerprint is XYZ." Each chapter therefore implicitly validates all the ones before it. Modifying an old chapter forces all the following ones to be rewritten — this is the "domino" effect.
Imagine a stack of envelopes. Each envelope contains documents and is closed with a seal. The fingerprint of the previous seal is reproduced on the next one. If someone opens envelope 1 and modifies its contents, seal A changes, envelope 2 no longer matches, then envelope 3, then all the following ones.
Imagine a notebook where each page is signed by a notary. Each page states the exact fingerprint of the previous page, and its signature is calculated from its own content plus that fingerprint. This way, each new page reinforces all the ones before it: the bigger the notebook gets, the harder it becomes to tamper with an old page without it being noticed.
Anchoring consists of using an external register (a public blockchain or a trusted third party) to certify and timestamp the existence of information stored elsewhere: it proves not only that it exists, but also on what date.
A company keeps an internal register of all its operations. Each evening, it calculates a unique fingerprint of its register for the day and hands over only this fingerprint to a notary, who records it in their official register. Later, the register's fingerprint is recalculated: if it matches the one recorded with the notary, the register has not been altered. The notary plays the role of the anchoring blockchain here.
A classic method for proving that a document existed on a given date was to publish its fingerprint in a national newspaper. Once printed in thousands of copies, it becomes very difficult to claim that this proof did not exist on that day. Blockchain anchoring works in a similar way: a small proof is published in a register that is very difficult to alter.
Imagine several municipal departments, each with its own register. Every week, they produce a fingerprint of their register and deposit it in a public safe at the town hall. The safe contains only the fingerprints. If a department alters its register afterward, its fingerprint will no longer match the one deposited. The safe represents the anchoring blockchain.
Instead of having the 500 pages of a book validated, a single summary (the fingerprint) is produced and an official seal is affixed to that summary. Any change to the book changes the summary. The seal does not directly protect the book: it protects the proof of its state at a given moment. This is exactly the idea behind anchoring.
Page 3 / 17
To access Aristhor's features, you need an account. Account creation is available from the home page via the "Create an account" link.
| Space | Description |
|---|---|
| Discovery | Free discovery space for new users. Access to the essential features to get started. |
| Solo | Full personal space. Manage your blocksthor, public keys, warranties, and settings. |
| Team | Collaborative space. Share blocksthor and resources within a team or organization. |
Page 4 / 17
Every blockchain relies on two main technologies: the cryptographic fingerprint (or digital fingerprint) and the electronic signature (or digital signature)
Aristhor uses the OpenPGP standard. Each public key is identified by its key fingerprint (40 hexadecimal characters).
The SHA-256d fingerprint is a cryptographic hash function that transforms any data into a string of 64 hexadecimal characters (256 bits). In Aristhor, each block has its own SHA-256d fingerprint, calculated from all of its fields.
937da0210898846c to make it easier to search for and reduce the length of the string to be shared.| Level | Description |
|---|---|
| Normal | The private key is generated and used on a computer connected to the Internet. |
| High (AIR GAP) | The private key is generated and used on equipment never connected to the Internet. Maximum security level. |
The Blocksthor Maker is an online tool that runs entirely in your browser. It lets you: generate PGP keys, create and manage blocksthor, verify integrity, calculate SHA-256d fingerprints, sign and verify signatures, and create Merkle trees. A "standalone" version of the Blocksthor Maker will soon be available for MacOS, Linux, and Windows.
The Blocksthor Reader is a reading and verification tool, separate from the Blocksthor Maker. It is accessible without being logged in to an Aristhor account, via a link in the public site's menu. It lets anyone explore a blocksthor, a block, a signature, or a public key, and verify its integrity, entirely within the browser.
Page 5 / 17
The zero-genesis block is the first block of a blocksthor. Its SHA-256d fingerprint constitutes the permanent reference of the blocksthor (blockchain UUID). This reference never changes, regardless of how the chain evolves in the future.
The fingerprint of the last block represents the current state of the blocksthor. It changes with each new block added. This is the fingerprint you publish on Aristhor and, optionally, on your Mastodon account, and of course anywhere else you like, such as in your email signature. The more widely this fingerprint is shared, the better.
| Format | Example | Interpretation |
|---|---|---|
| Full (64 char.) | f7a3b1[...]2c4d | Exact search |
Short with - | f7-4d | Starts with f7, ends with 4d |
Page 6 / 17
| Term | Definition |
|---|---|
| Blocksthor | Private blockchain of testimonies, managed by an administrator on Aristhor. |
| Block | Basic unit of a blocksthor. Contains an index, a timestamp, metadata, a signature, and a SHA-256d fingerprint. |
| The zero-genesis block | First block of the chain. Its fingerprint constitutes the permanent reference (UUID) of the blocksthor. |
| The SHA-256d fingerprint | Cryptographic digest of 64 hexadecimal characters uniquely identifying a block or file. |
| Warranty | Cryptographic attestation deposited by a third party (warrantor) regarding a specific block of a blocksthor. |
| Warrantors | User who deposits a warranty signed with their private key. |
| Merkle tree | Cryptographic structure that groups several elements into a single, verifiable root fingerprint. |
| Merkle root | Root fingerprint of a Merkle tree or of a single file. |
| Term | Definition |
|---|---|
| Public key | Freely shareable cryptographic key used to verify a signature. |
| The private key | Secret cryptographic key used to sign blocks or messages. |
| Public key fingerprint | Unique identifier of a public key (40 hexadecimal characters, OpenPGP standard). |
| Public key | Cryptographic value produced by the private key on a message. Proves the signer's identity. |
| Revoke | Action of declaring a public key invalid (its "sibling" private key lost or compromised, etc.). |
| Web of trust | Network of trust formed by cross-signatures between public keys. |
| Term | Definition |
|---|---|
| Space | Work environment determined by the user's role (Discovery, Solo, Team...). |
| User quota | Maximum number of users that can be associated with a blocksthor. |
| Term | Definition |
|---|---|
| Mastodon access token | Authentication token (write:statuses scope) enabling automatic publishing to Mastodon. |
| Mastodon instance | Mastodon server hosting your account (e.g. mastodon.social). |
Page 7 / 17
The "Fingerprints & blocks" page lets you search for any blocksthor whose fingerprint has been made public. You can search by full fingerprint (64 characters) or by short format (f7-4d). The search is performed simultaneously on the last block fingerprint and the permanent reference.
f7a3b1[...]2c4d (full fingerprint) |
f7-4d (short format with - as separator)
A second form lets you find a user's blocksthor from their email address. This search is only possible if the blocksthor's administrator has enabled the "Allow search by email" option.
| Column | Description |
|---|---|
| Name | The blocksthor's name, clickable to access its detail page. |
| Permanent ref. | The first 16 characters of the zero-genesis block fingerprint. |
| SHA-256d fingerprint of the last block | The first 16 characters of the last block fingerprint. |
From a blocksthor's detail page, you can view the full content of the chain if and only if the "Public visibility of blocks" option is enabled. You can then copy or export the blocksthor to a .txt file.
Page 8 / 17
The "Public keys" section lets you search for keys deposited on Aristhor by key fingerprint (partial or full, 40 characters, OpenPGP format) or by the owner's email. Only keys with the "Searchable by fingerprint" or "Searchable by email" option enabled appear in public results.
| Information | Description |
|---|---|
| Status | Valid or Revoked Valid or Revoked, with the revocation date. |
| Public key fingerprint | Unique identifier of the key (40 characters, OpenPGP format). |
| Security level: | Normal or high (AIR GAP). |
| Full key | Armored PGP content of the public key, copyable and exportable. |
| Signatures | List of public keys that have signed this key (web of trust). |
The web of trust is a mechanism by which users mutually certify the authenticity of their public keys. On Aristhor, a user can sign another user's public key to attest to their identity. The more a key is signed by well-known users who also have a strong connection to its holder, the more trustworthy it becomes.
Aristhor publishes its own public key, accessible from the menu and the footer. It lets you verify that a signature genuinely comes from Aristhor.
Page 9 / 17
A warranty is an attestation deposited by a third party (the warrantor) regarding a specific block of a blocksthor. It is itself cryptographically signed by the warrantor with their private key and contains: the fingerprint of the warranted block, a "merkle root" fingerprint, the warrantor's signature, the fingerprint of their public key, and the date.
The "Warrantors of a block" page lets you find all the warranties deposited on a given block by selecting a blocksthor and specifying the block number including the warranties.
| Field | Description |
|---|---|
| Content | Text description of what the warrantor is attesting to. |
| Fingerprint of the warranted block | Fingerprint of the block covered by the warranty. |
| Merkle root | Root fingerprint of the Merkle tree of the grouped warranty or warranties. |
| Warrantor's public key fingerprint | OpenPGP identifier of the sibling key of the private key used to sign the warranty. |
The Merkle tree makes it possible to prove that a set of elements is referenced and intact, based on a single root fingerprint. Verification is performed in the Blocksthor Maker, "Merkle tree" tab.
Page 10 / 17
The "Information" section gathers notes and news published on Aristhor (articles, announcements, tutorials). Each note is presented as a card with a title, date, associated image, content excerpt, and possibly a Pinned.
Each note can have associated documents. For images (jpg, jpeg, png), a thumbnail preview is shown in the table. Clicking the preview or "View" opens the image in a lightbox. For other file types, the "View" button opens the file in a new tab.
Notes and documents can be filtered by category using a search form. The "Documents by category" page lists all documents in a given category with their previews.
Lists come with a column-sorting system. Contextual filters (category, date, system) are available to refine the results.
Page 11 / 17
The Blocksthor Maker runs entirely in your browser, without sending sensitive data to a server. Available sections: New blocksthor, New block, Explore, Fingerprint - Hash, Digital signature, Merkle tree, PGP keys.
.txt file to keep it.The "Explore" section lets you load a blocksthor file and view its details or verify its integrity by recalculating the fingerprint of each block.
Calculating fingerprints: the "Fingerprint - Hash" section calculates SHA-512 | SHA-256 | SHA-256d | SHA-1, Blake, etc. fingerprints for any text or file.
Signature verification: provide the original message, the signature, and the signer's public key to verify the validity of a signature.
Page 12 / 17
Go to "My blocksthor" > "Add a blocksthor". Two approaches:
A. Manual creation: enter the name, permanent reference, last block fingerprint, and publication settings.
.txt file exported from the Blocksthor Maker.unnomdefichier_39-9B_4C-E5.jpgIf you choose not to group all your "blockchained" files into a single folder and to leave them in your usual storage:
unnomdefichier_39-9B_4C-E5.jpg..txt extension) in the blocksthor folder, whose only content is the full file name: unnomdefichier_39-9B_4C-E5.jpg.This way you will know that this file should be searched for on your equipment rather than in your blocksthor's main folder, which avoids duplicates and doubling your storage needs.
Placing a file's fingerprint several times in different blocks is not a problem, even though it is best avoided. If it is necessary for consistency reasons (to recall that this file belongs with a certain group of files), place a text file acting as a shortcut in the files folder, indicating the block where the file "actually" is for the first time. This avoids unnecessarily growing the overall folder due to duplicates.
| State | Meaning |
|---|---|
| Accessible | The blocksthor is up to date. Users can view or download it normally. |
| Locked | Blocks are being added. The content is not accessible. An estimated unlock date may be indicated. |
If you have configured a Mastodon access token, the "Publish to Mastodon" button appears on your blocksthor's page. Aristhor then automatically publishes the name, a link to aristhor.com, the permanent reference, the last block fingerprint, and the hashtags #blocksthor #blockchain #aristhor.
write:statuses scope on your Mastodon instance.If you have configured a Telegram Chat ID, the "Publish to Telegram" button appears on your blocksthor's page. Aristhor automatically sends a message containing the same information as a Mastodon post.
If you have configured a Bluesky handle and an App Password, the "Publish to Bluesky" button appears on your blocksthor's page. Aristhor then automatically publishes the name, a link to aristhor.com, the permanent reference, the last block fingerprint, and the hashtags #blocksthor #blockchain #aristhor.
Page 13 / 17
Only the administrator can invite users. From the "My blocksthor" menu, go to your blocksthor's page, then the "Users" section, enter the new user's email, and click "Add". The user must already have an Aristhor account.
| Right | Description |
|---|---|
| Favorite blocksthor | Marks this blocksthor as a favorite for the user. |
| Pseudonym | The user's displayed name within this blocksthor. |
The quota defines the maximum number of users. This quota depends on the plan subscribed to for blocksthor created from the "My blocksthor" space, and outside of any special agreement.
Page 14 / 17
From the "Add signature" tab of a key's page: the signer generates, via the Blocksthor Maker, a signed attestation ("clearsign" format) declaring that they have personally verified the link between the key's fingerprint and its identifiers (name, email), then pastes or imports this attestation — the signature code (signer's fingerprint) is then automatically detected from its content. It is automatically verified before being added.
If your private key is compromised or lost, revoke your public key from its edit page. You can indicate the date, the fingerprint of the replacement key, and the reason for revocation. The revocation process takes place in the Blocksthor Maker.
The Export button downloads the public key to a .asc file. This file can be shared, loaded into the Blocksthor Maker, or imported into any third-party OpenPGP-compatible software.
Page 15 / 17
Using the Export-Group, button, group several warranties covering the same block into a common Merkle tree. The warranted block is indicated in the call for warrantors.
Warranties can be archived to keep them without showing them in the active list. Archiving is reversible: find archived warranties under "Archived warranties".
Page 16 / 17
The <em>"My account"</em> page lets you edit: personal contact details (title, first name, last name, email, phone, address), profile photo (jpg, jpeg, png — 2 MB max. — 800×800 px minimum, rendered as a circle), and pseudonym per blocksthor (from rights management).
After selecting a photo file, an instant preview is shown. Click "Save" to confirm the change.
The icon lets you show or hide what you type.
write:statuses scope and copy the generated token.The token is displayed masked (dots) and can be revealed via the icon.
-1001234564890) into "My account" > "Telegram - Chat ID".-100 followed by digits. A personal Chat ID is a positive integer.aristhor.bsky.social) in "My account" > "Bluesky - Handle".The App Password is displayed masked (dots) and can be revealed via the icon.
Account deletion: immediate and permanent action from "My account" > "My settings".
Page 17 / 17
Anchoring is a mechanism for cross-existence proof between blocksthor. It allows one blocksthor (the host blocksthor) to incorporate the current state of its users' blocksthor into a timestamped Merkle tree, thereby creating a tamper-proof collective fingerprint that certifies and timestamps the existence of each blocksthor at that date.
In practice: if you are a user of a blocksthor that accepts anchoring, you can indicate which blocksthor belonging to you you wish to anchor there. On each configured anchoring day, the system collects the latest block fingerprint of each declared blocksthor and automatically calculates a SHA-256d Merkle tree that groups them all together.
In your blocksthor's settings (My blocksthor > Edit), the administrator can enable the "Accepted anchors" section and set:
| Setting | Description |
|---|---|
| Accepted anchors | Enables the anchoring feature for this blocksthor. Users will be able to declare a blocksthor to anchor. |
| Anchoring day | Day of the week on which the Merkle tree calculation is triggered (e.g. Monday). |
| Frequency | Anchoring pace within the month (e.g. every full week, the first week, etc.). |
As a user of a blocksthor that accepts anchoring, go to My blocksthor > View > Users of this blocksthor > You > Information. A "My blocksthor to anchor" field appears: select the blocksthor belonging to you that you want to anchor in this host blocksthor.
Once declared, a reminder appears on the host blocksthor's page:
From the host blocksthor's page, the button, reserved for the host blocksthor's owner, gives you access to the list of anchored users and their latest fingerprints, as well as archived Merkle trees. Anchor,
The Merkle tree is calculated from the latest block fingerprints of each anchored blocksthor. Each leaf of the tree identifies its source blocksthor:
| Field | Description |
|---|---|
blockchain_short_uuid | Short identifier of the blocksthor (first 2 + last 2 characters of the permanent ref., e.g.: f8-cf)) |
hash | SHA-256d fingerprint of this blocksthor's last block [ my-son ] at the time of anchoring |
The Merkle root (merkle_root) summarizes the whole set into a single fingerprint of 64 hexadecimal characters. This value constitutes the synthetic proof of the collective anchoring.
| What the tree attests to | Detail |
|---|---|
| Existence | The last block fingerprint of each blocksthor was known on the anchoring date |
| Collective integrity | The Merkle root covers all users anchored that day |
| Non-repudiation | The tree is archived server-side; any change to a hash would invalidate the root |
Each archived tree is exportable as .txt via the Export button. This file constitutes your proof of inclusion in the collective anchoring.
.txt file after each anchoring. It is your only local proof that your blocksthor was anchored.To easily keep and find anchoring proofs, the recommended convention is as follows. Each anchoring corresponds to a named folder:
NNNN_block-file_anchor_XX-XXNNNN — number of the inserted block, zero-padded to 4 digits (e.g.: 0876)XX-XX — short identifier of the host blocksthor (first 2 + last 2 characters of the permanent ref., e.g.: fd-7d)This folder contains:
| File | Description |
|---|---|
NNNN_merkle_tree_XX-XX.txt | The Merkle tree exported from Aristhor — proof of collective anchoring |
NNNN_nom-du-fichier.ext | The file(s) inserted in this block (with the same block-number prefix) |
Concrete example for block no. 876 of a blocksthor whose short identifier is f8-cf . The fingerprint of this block is inserted into the host blocksthor fd-7d :
.txt file after export. Its content includes the merkle_root (root fingerprint), which must remain intact for any future verification.Aristhor Manual — 17 pages — aristhor.com Back to top