The total amount of Arweave-transactions retrieved by this session so far.

A transaction is an action to interact with Arweave's blockchain (or 'blockweave' as the blocks also point to an effectively random block in the past in addition to the previous block) - an event that may contain a currency (AR) transfer, data storage or both.

While it is possible to store data in just a single transaction, in the currently prevalent practice, a file might take up to three transactions: one for the ArFS-metadata (file name, directory and so), one for the actual data in the file, and a transaction bundle to group the two virtual transactions into one real transaction.

(The bundling-tech was created to combat the heavy network congestion that caused some posted transactions to not get mined into the chain, effectively acting as an archive-format that allows one Arweave-transaction to contain multiple virtual data-transactions, this system also utilized by so-called 'bundlers' that offer a service to upload your transactions for you. However, these 'layer 2' transactions cannot contain monetary transfers)

The site only shows the transactions I deem relevant (ie. files and webpages), this constituting the vast majority of them. The first transaction that should be shown after a full fetch ('fetch all') should be 7Xhk5LXBkXVavih4RxFY5la-tKCVuodPq313B1V-OSI, being part of block with height of 707176 (Block ID: zcK4dIi74xtHp0335dDk0WFE_wrIDe03tN62tkzgMettJxKNv1Zsmu0LSwf1R_Rq), containing the index.html of silanael.com, dating back to 2024-06-14 16:47:14 (Finland time).

Multiple transactions (file data, file metadata and the bundle) may result in one list-item (mouseover 'Transactions' for more info on this).

ArFS, or Arweave File System, is a poorly-designed attempt to build a filesystem on top of Arweave, one that discards the most sacred principle of filesystem development: fault-tolerance.

An ARFS-file consists of two transactions: one for the file data, another for the metadata, the latter containing the typical things such as the file name and location (Folder-Id).

Upon designing this system, none of the people at ar.io stopped to think what would happen if, for some reason, one of the two transactions failed to get stored into the blockweave. And this is exactly what happened in 2021 when the Arweave-network was experiencing high congestion.

If the metadata succeeded but the data failed, the file entry would be broken, the data not stored. And if the data succeeded but the metadata failed, the file data would still exist in the chain yet not visible in ArFS-using software until a new metadata-entry was constructed.

These outcomes are not the end of the world when it comes to public drives; the data-transaction could be reuploaded, and a missing metadata-transaction be reconstructed. However, things fall into pieces when it comes to private files; in order to generate the key to decrypt them, 'File-Id' of the file is required - a randomly generated UUIDv4 present only in the metadata-transaction that would by now be gone for good.

Many people were effectively losing their data in this period; even while the data was technically in the chain, it would do little good without the encryption key. The caching of app.ardrive.io gave users the impression that the data was still there, until they would eventually clean the browser cache, resulting in missing files, folders and even drives. Even while aware of all this, instead of taking action to mitigate the issue (by storing the File-Id into the data transactions and build a system to reconstruct missing metadata that they these days have) or at the very least warning their users of potential data loss, the ArDrive-team opted to prioritize working on on their upcoming improved ArDrive-CLI, leading me to abandon my position of an advocate to voice out this warning myself, this further souring our relations.

Another poor design-choice is having all the file metadata in the data-portion of the metadata-transaction instead of having some it in the transaction header tags; due to this, one can't get the dataTxId by a GraphQL-query, requiring one additional HTTP-fetch per file. Furthermore, it is not possible to query transactions based on filename, as it would need to be stored in the transaction-tags (unless someone builds an ArFS-indexing service or something). This point is, however, debatable as the transaction tags can only hold a fixed amount of data, and with a lot of services stacked into one transaction, they might well come to bloat out of proportions, though one might carry the notion that the current tag size limit, 2KB, ought to be enough for everybody. Then again, we all know how well those saying age. I'd likely opt for a hybrid system; use the dataTxId from tags if it's present, fetch if not.

If I'm going to say something good about ArFS, it's the usage of UUIDv4 for the unique IDs for drives, folders and files; this allows for an immutable reference to a file even when its name, location and even content changes. I'd add a file hash on top of this for public files in order to easily check if a file has already been uploaded to the weave.

The earliest block containing transactions of my addresses that this session has retrieved.

After a successful 'fetch all' operation, the first block number should always be H:707176 (2021-06-14) - if it isn't, it may indicate either a fault in the gateway, a fault in the code of this site, or an attempt to censor my data; recommend using a different gateway if this happens.

The number presented is the block height, with the first block (aka. the genesis-block) in the entire chain being H:0. The date is derived from the block time (that is denoted in UNIX-time, seconds after epoch) and displayed at the timezone of the user (my timezone during summer is GMT+3 / Finland).

Arweave-blocks are groups of transactions that get mined into the chain together, the block time reflecting the time the block was mined (added to the chain) - or is it the creation time? I'm not entirely sure. Regardless, this means that one can consider the block time as a time during which the data was quaranteed to exist; yet the data may have existed prior to this date.

An Arweave-address can be thought of as an account or an identity in the blockweave, being able to own AR (its native cryptocurrency) along with posting transactions. (Transactions refer to the source address as the 'Owner')

Under the hood, the address is a truncated public key; in the employed asymmetric key cryptography, a transaction signed with the address' private key can be verified with the public one, so one can be certain that a transaction from an address has been created by someone that has its private, secret key. (It is possible for the key to be compromised; I'm thinking of a protocol to announce such an unfortunate event if it was to happen, but this has yet to leave the drawing board)

I'm using multiple addresses in order to separate concerns (though not doing a very good job at it) and to combat the conceived possibility of gateways starting to refuse serving entire addresses (perhaps with a commonly-accepted blacklist).

The current most prominent ones include:

• zPZe0p1Or5Kc0d7YhpT5kBC-JUPcDzUPJeMz2FdFiy4
• SILAqW41DykO7DGa2I9pEcqi0ApkydA-5nUZWw6yfjQ
• SilaP1T6g4vqzkZa-LJTmNmd06v5tNLB7AAR3di3SzM
• SilaMZ6WJ2wL6itp3IeyqsFLmj_yP2qN22b21w1J2LQ
• 5ESsfIgEIb461LmSR0MJ0OIDoSXaCEBiwNiamXZn2sA
• S1m1xFNauSZqxs3lG0mWqa4EYsO7jL29qNHljTADcFE
• SARTcYwRzJ6rJNNM7OfNu6g58MSX-fCFTIr72PacKcc
• ERPnR7nmSwiX5_NC5dKVbK1K3kh_1goRGfyACEY-sJE

The total amount of data stored in the retrieved transactions.

This is a mere sum of the reported transaction sizes; the data isn't actually downloaded (except for ArFS-metadata JSONs). The amount is presented in binary; a KiB is 1024 bytes. This is the only right way.

Storing data to Arweave costs its native currency - this is the sum of the transaction fees on the TXs retrieved during this session.

Additional fees such as the ArDrive-tip are not currently included in this calculation.

(Some of the transaction fee goes to the miners, while the rest goes to the 'endowement pool' that is designed to work as a long-term mining incentive; miners are the ones that add new blocks (data) to the chain, and the more of the existing blocks they store, the better their efficiency - this is the core mechanic behind Arweave's premise of long-term data storage)

Gateways are special nodes that index and serve the content of Arweave. The data can be either retrieved directly with a transaction ID (TXID) or queried via GraphQL (GQL), the latter most commonly used to find transactions belonging to a certain application, protocol and/or address.

It is possible for a gateway to be a malicious actor by serving incorrect or tampered data via the HTTP API; this site does NOT currently verify the integrity of the data retrieved.

The most widely used Arweave-gateway at this point in time is arweave.net - if it ever goes out of operation resulting in some Arweave-links breaking, the situation can be mitigated by replacing constant GATEWAY in silacom-arweave.js with another gateway, or by editing the hosts-file (/etc/hosts in Unix-like operating systems) and mapping arweave.net to a different gateway. The base64url-encoded part that comes after the hostname is the important part - the immutable transaction ID - that can be used to access the content.

Gateways often redirect to a subdomain upon accessing a content, ie. a link https://arweave.net/3mlqZeERCttMTaZj8bk4mqim_971CssUmgkcIQcuXd4 might redirect to something like 'https://3zuwuzpbcefnwtcnuzr7dojytkukn7666ufmwfe2beoccbzolxpa.arweave.net/3mlqZeERCttMTaZj8bk4mqim_971CssUmgkcIQcuXd4'; the first part isn't necessary for accessing the content, but it plays an important role in preventing other JavaScript-code from accessing the site's saved variables (localStorage) as the validity of the access is dependent on the 'origin'.