Why?

At present we are using a UUID in our Append-only Log see: https://github.com/dwyl/alog/issues/15
This is a good "stop gap" to get the `alog` project to "alpha" so it could be _used_ in the Client Project. :shipit:
But I feel that we should **_carefully_ consider** the use of UUIDs as IDs in the "_long term_".

If an ID is meant to be "machine readable" and "guaranteed" unique, then UUIDs are _perfect_.
If there are **_additional_ requirements** then we need to _capture_ them.

For example: are we going to **display** the UUID in the **URL** for a given content type e.g:
```
location-app.com/venues/123e4567-e89b-12d3-a456-426655440000
```

Is this the most _user-friendly_ ID we could display? (_is it distinctive or memorable ...?_)

Could we _instantly_ improve UX by shortening the URL and making it Base64 instead of Base16? e.g:
```
location-app.com/sw1x
```
Where the app would automatically `301` re-direct the request to:
```
location-app.com/venues/the-islington-roof-garden-sw1x
```
Can we "re-think" content/record IDs for _both_ Uniqueness and _Usability_?

# Basic Example: Address Book

The append-only log example: https://github.com/dwyl/phoenix-ecto-append-only-log-example
demonstrated the benefits of using an append-only log for an address book.
But we _also_ explained that _any_ app can benefit from having an _immutable_ log as its' data store!
see: https://github.com/dwyl/phoenix-ecto-append-only-log-example#examples-where-an-append-only-log-is-useful

What the example did _not_ cover is how to _mitigate_ against saving the _same_ data multiple times.
For example, consider the form:

| Field | Value |
|-----|-----|
|Name|Bruce Wane|
|Address|1007 Mountain Drive, Gotham|

if Bruce clicks/taps to **`edit`** his address,
and we have an _auto-save_ function to prevent loss of changes.
We need a way of checking on the _client_ that the address has _not_ changed
***`while`*** he is viewing the edit screen.

Yes, this function should only be triggered by the "onChange" DOM event, but for argument's sake, we assume that Bruce clicks the "save" button (_which we have discovered through UX-testing people still expect to have despite the "autosave"_),
should the server attempt to "re-save" the data that has _not_ changed?

I suggest that by using a hash of the content as the Primary Key, Ecto (_or PostgreSQL_) would "reject" the insert request as a "duplicate" and we would not _waste_ space in the database/table with dupe data.

If the data has not changed then the **ContentID** (**`cid`**) would be the _same_ so no data insert.

# Use Case: Distributed Learning Platform

Learning systems _universally_ have "vendor" or "platform" Lock-in.
Do a lesson on
Ask a question on StackOverflow? If your account gets banned for any reason, you lose "ownership" of any questions you had asked.
Want to _export_ your data and take it with you? Tough!

In our "product roadmap" we have begun to detail the creation of an Open Source Distributed Collaborative Learning platform:
https://github.com/dwyl/product-roadmap/blob/master/collaborative-learning-community.md

By using a **`cid`** where each item of learning has a unique "fingerprint",
_everyone learning on the platform can _clearly_ see what each of their fellow learners has "covered".
If anyone wants to either _import_ or _export_ their learning, they can do it _easily_.

This is _game-changing_ for making your "learning log" portable from kindergarten to the grave!
No longer will your new school, university or employer/team have to rely on a "report card" or (_incomplete_) "transcript", everyone will be able to see that Alex
+ "learned **quadratic equations** on 2017-01-14 10:09 at Hyde Park Middle School."
cid: sha2-256-6e6ff7950a36187a801613426e858dce686cd7d7e3c0fc42ee0330072d245c95

When Alex moves from Middle School to High School, all his teachers and classmates can easily see _exactly_ what he has learned.

The teacher can be _far_ more effective because they know what each student has _already_ covered vs. what they still don't grasp. And instead of teaching more advanced topics that _half_ the class will be confused by, they can attempt to cover the areas that still require work.

This is _highly_ relevant in the workplace too!
As a "hiring manager" or "team lead", I want to know _exactly_ what my (_potential_) team members _already_ know and what they are still trying to learn. I will delegate tasks to them that stretch their current abilities enough to encourage learning but not too much that would "_overwhelm_" them!

### Closing the Gender/Class/Minority Divide in STEM/Tech

I feel that having a _complete_ "learning log" will help to _eliminate_ the gulf that exists in STEM/Tech because it will _always_ be _immediately obvious_ who has the knowledge/skill and it wont be a matter of which person has the loudest voice and most over-confidence.