Why? What? Who? How?

# Why?

Having an append-only log is _incredibly_ useful in _way_ more situations than most people _realise_.
Anywhere you would need **_accountability_ in data** is an _excellent_ candidate for ***immutability***.

+ **CRM** - where customer data is updated and can be _incorrectly_ altered, having the _complete_ history of a record and being able to "time travel" through the change log is a _really_ good idea.
+ **CMS/Blog** - being able to "roll back" content means you can _invite_ your _trusted_ readers / stakeholders to edit/improve your content without "fear" of it decaying.
+ **E-Commerce** - both for journey/story tracking and transaction reliability. Also, same applies for the Product catalog (_which is a specific type of CMS_); having version history dramatically increase _confidence_ in the site both from an internal/vendor perspective and from end-users.
+ This is _especially_ useful for the ***Reviews*** on e-commerce sites/apps where we want to be able to detect/see where people have _updated_ their review following extended usage. e.g: was did the product disintegrate after a short period of time? did the user give an initially _unfaforable_ e.g 3/5 stars review and with time come to realise that the product is actually exceptionally durable, well-designed and great value-for-money because it has lasted twice a long as any previous product they purchased to perform the same "job to be done".
+ **Chat** - a Chat system should allow editing of previously sent messages for typos/inaccuracies.
but that edit/revision history should be transparent not "message edited" (_with no visibility of what changed_) and if a person _deletes_ the a message they should have to provide a comment indicating _why_ they are "breaking" the chain. (_more on this later_).
+ _Most_ other **Consumer Web/Mobile Applications** - you name the app, I can illustrate _exactly_ how an append-only log is applicable/useful/essential to the reliability/confidence in that app.
+ Forums - any sort of user-generate content where
+ Social Networking - not allowing people to delete a message without leaving a clarifying comment promote accountability for what people write and in many cases avoids most hate speech.

When a system/db does _not_ have (_field/record level_) "version control" each update _over-writes_ the state of the record so it's impossible to retrieve it without having to go digging through a backup which is often a multi-day process, cost/time prohibitive or simply _unavailable_.

We _propose_ that _all_ apps should be built with an Append Only Log at the _core_ by _default_.
This is not a "_new_" idea. Several _large_ companies have used the "Lambda" or "Kappa" architecture in production with _superb_ results for reliability and scalability.
see: http://milinda.pathirage.org/kappa-architecture.com

# _What_?

Instead of using **`Ecto`**'s standard "CRUD" which allows overwriting and deleting data without "_rollback_" or "_recoverability_", we propose writing a _thin_ "proxy" layer between the application code and the PostgreSQL database

# _Who_?

_All_ developers who have _basic_ understanding of web development where data is stored in a DB
and want to "level up" their knowledge/skills and the reliability of the product they are building
with a _view_ to understanding more ("advanced") "distributed" application architecture
including the ability to (_optionally/incrementally_) use IPFS and Blockchain.

# How?

The purpose of this tutorial is to:

+ [ ] Make it _easy_ for _anyone_ to build a Phoenix/Ecto based app with an append-only log at it it's core.
+ [ ] Write a step-by-step guide that shows how to:
+ [ ] create a content type using _standard_ Phoenix generators
+ [ ] Take your pick of what you think is the simplest/most beginner friendly content type. e.g:
+ [ ] **Address Book** is easy to show value of tracking updates.
+ [x] no additional DB plugins/"add-ons" should be required to make this work,
just "stock" PostgreSQL as downloaded or available through a DB-as-a-service provider. e.g. Heroku.

> + [ ] Add our tutorial to _this_ thread once it's "ready": https://elixirforum.com/t/append-only-db/13355
> + [ ] Add link to tutorial to: https://stackoverflow.com/questions/35405671/append-only-data-in-phoenix-ecto-and-postgres

## Open Questions:

+ [ ] How to _reference_ the previous version of a record from the latest one. (_keen to hear feedback on this_) Happy to explore using hash of data as "parent id" thus we would have a "merkle tree" structure for all data. i.e. "Blockchain" but without the "proof of work" (factor), just a chain with the _history_ of a record for accountability/rollback purposes no need to _waste_ CPU cycles.
+ [ ] How to **`delete`** data (_mark an item as deleted_) without "_destroying_" the data.
+ [ ] Note: we would still have to have a "batch process" that is able to "**_really_ delete**" data to comply with GDPR/"Right to be forgotten". But from the User's perspective we only need to "unlink" the data in the UI and then the _batch_ process will delete it after a specified expiry. Similar to the _recycling bin_ on a Desktop OS.

Similar to: (_please use these a **reference** when writing the doc(s)_)
+ https://github.com/dwyl/phoenix-ecto-encryption-example [Quite Technical]
+ https://github.com/dwyl/phoenix-chat-example [more Beginner Friendly]