EPIC: Record All Actions App for Transparency + Replayability

One of the things that has always **_deeply_ frustrated** me when using tools like [**`JIRA`**](https://techcrunch.com/2018/12/09/jira-is-an-antipattern/)
is the rudimentary notifications and inability to "replay" actions performed by colleagues.
You can see comments on issues and basic status updates. But only the _current_ point-in-time.
Unless you're an "admin", you cannot see **history** of what has happened in an issue much less in the whole project.
So ... for **someone `new` _joining_** a **project** with **100+ members** and **1000's** of **issues** it's **_totally_ overwhelming**.

What we _want_ with our product/project is:
**_complete_ traceability** of every _character_ typed, mouse movement made and action permed
so that it can _all_ be ***replayed*** by anyone so that **_complete_ context** is preserved.

Yes, this transforms a basic "todo list" into the **_complete_ history** of every action performed in the company/organisation. That's _exactly_ what we _want_ from a ["single source of truth"](https://en.wikipedia.org/wiki/Single_source_of_truth). It will naturally imply _considerably_ more data will be collected & stored for each `person`, `item`, `list` etc. But I encourage you to think about it this way: most Apps _already_ capture/store this data as "Analytics". e.g. using a tools like **`Data.ai`**, **`Mixpanel`**, **`Segment`**, **`Firebase`**, etc.

The _problemz_ with using **3^rd** party ***external*** analytics tool -
and I've used most of them over the years - is that:

a. Only what you _deliberately_ send to the analytics/tracking service is recorded/tracked. 👩‍💻
So devs either _forget_ to track something and then later cannot see the historical data ... 🤦‍♂️
***or*** devs track _everything_ and the company ends up paying a _fortune_ in storage costs for the "Data Lake". 💸
b. Using a **3^rd** party tool usually means there are per-user costs
both from the perspective of what you track and then who can _view_ the data so it creates silos.
c. The people _using_ your app almost always don't have _any_ visibility of what is being recorded,
i.e. they the analytics are totally hidden from them. IMO: this is a _huge_ mistake & missed opportunity.

> Ask friend-of-dwyl & data science extraordinaire @pratik-IDWT, he can back me up on this. 😉
> Trying to apply analytics retrospectively to an **`App`** is always more costly [expensive consultants].
> Thinking about how to capture actions/events in an **`App`** up-front will be one of our [**USPs**](https://en.wikipedia.org/wiki/Unique_selling_proposition) longer-term.
> Instead of collecting a bunch of data on usage behaviour and keeping it to ourselves,
> We will collect the data from the "_user's_ perspective" and make it a ***feature*** of our App.
> i.e. they can _see_ exactly how they themselves use the **`App`**, i.e. personal dashboard/metrics
> and in "Team Mode" they can see all the actions performed by their teammates as a **_replayable_ log**.
> I haven't seen this done before in a team collaboration/communication **`App`**, have you? 💭

So, to summarise, we want to capture _everything_:

+ [ ] "Pages" viewed - this will be both the URL they viewed and given the timestamp, we can derive the _contents_ of what was viewed by querying the data at that time.
+ [ ] Login/logout events - so people know when they logged-in/out
+ [ ] Browser/devices used
+ [ ] Location data so that people know _where_ they are using the App
> **Note**: the **`App`** will request access to location services and explain _why_ it's useful/relevant
> both from a security and personal analytics perspective. They have the **`option`** to _not_ grant permissions.
> We will keep this data very safe and _never_ share/sell it to anyone _ever_!
+ [ ] Characters typed into every field - so that anything can be undone/re-done and replayed later
+ [ ] `tags` applied
+ [ ] `items` added to a `list`
+ [ ] `people` added/removed to/from a `group`
+ [ ] Mouse Movement on the page (desktop): see: https://github.com/dwyl/phoenix-liveview-realtime-cursor-tracking-tutorial/issues/1
+ [ ] Clicks/Taps
+ [ ] Drags and Drops - see: https://github.com/dwyl/learn-alpine.js/issues/4
+ [ ] _Anything_ `else` that you/we deem is relevant to people _using_ the **`App`**.

# Todo

+ [ ] Confirm you understand _why_ we want to do this;
i.e: we want the `people` _using_ the **`App`** to have **_deep_ insights** into their own usage of the **`App`**.
+ [ ] As engineers we need to "work back" from the goal of total transparency/replayability and build accordingly.