# __fastdata

The protocol is intended to simply store any raw data using Near blockchain as a ledger. The data is not stored in a smart contract, just in a transaction ledger.

To store data blob you have to send a transaction with function call method starting with `__fastdata_`. The suffix is the extension of the fastdata indicating the purpose and format that it should use. For example `__fastdata_raw` will store raw data without keys.

The owner of the data will be considered the predecessor account. And the namespace for the data will be the current (execution) account. More about data and namespace later.
Note, executing this on your own account is cheaper, since it doesn’t require cross-shard receipt.

The execution will most likely fail and this is expected. The execution account might not have a contract or the contract does not implement the method with such name. But since we don’t care about getting this data into a contract state, the failed transaction will still be included into a chunk, so it can be indexed.

FastNear will index the raw data and provide a simple retrieval API for lookups. E.g. an api for a lookup by tx hash and action index (0 by default). But we'll work to support more structured data.

There are couple of use-cases that can be built on top of this protocol:

1. Raw data or blob storage. `__fastdata_raw(blob)`. Store a binary blob of data. Easily accessible using TX id and an action index.
2. Key value store. E.g `__fastdata_kv({key, value})`. The full key will be `(predecessor_account_id, current_account_id, key)`. The value can be overwritten, you may access value history as well as the latest value.
3. File hosting. `__fastdata_fastfs(data)`. The data is borsh serialized binary that includes relative path, mime type and the content. More information will be shared later
4. SocialDB. More complicated KV store that implements tree structure, or takes array of KV. It's a scalable and cheaper alternative to an existing socialdb contracts.
5. Messaging system. `__fastdata_chat({channel_id, message})`. In this case messages from multiple accounts will be aggregated into the same channel_id and served in order of block height, shard_id and tx index. It’s up to the provider to decide how to serve results from the channel, e.g. filter by namespace or not.