<commit_before># imag

Imag is a CLI PIM suite with a nice API-ish commandline interface, so you can
integrate it in your tools of coice (Editor, MUA, RSS reader, etc etc).

## Modules

All the modules have access to a shared store (which lives in `~/.imag/store/`
by default). Files are named after a schema:

    ~/.imag/store/<module_name>-<hashtype>-<hash>.imag

Where module name is "bookmark" for example. The hashtype is "UUID" by default
and the "hash" is a UUID then. Other types are possible as well:

- SHA1
- SHA512

for example (though it might not be a good idea to use SHA hashes,
see [Linking](#Linking))

Some modules might not want to store content there, for example you don't want
to put your icalendar files in there. So the calendar module just crawls through
your ical files and puts the scanned meta-information into the store. Of course,
if the content of the ical file changes, the store entry does not. It still
points (via its JSON content for example) to the same file. So changes are not
tracked (We can argue here whether we want to copy the contents to the store for
ical and vcard files, but we cannot argue on for example music files).

If a (for example ical-)file gets removed, the store entry gets invalid and has
to be garbage-collected.

>   The current model is not fixed yet. I'm thinking about copying .ical and
>   .vcard, basically all text files, to the store.
>   This is not possible for media files like music or movies, though. Also this
>   is not feasible for documents like .pdf or similar.

Each of the following modules has a short description including a table what
core features are required to get it working.

### Linking

The UUID/SHA hashes in the file names can be used to connect two store entries.
For example, an entry from the wiki could refer to a contact by a UUID, because
the file for the contact has a UUID in its name. These UUIDs are constant and
should not change.

A link chain like this

    Wiki -> Shopping List -> Calendar Entry
            |                       |
            |                       v
            |                       Contact -> Calendar Entry -> Bookmark
            v
            Wiki Entry -> Bookmark

is totally possible. Scenario: You have a Wiki entry of a recipe you like to
cook. The recipe is linked to a shopping list, where you want to buy the
ingredients. Of course, you want to do this on a specific date (calendar entry).
And you want to do this with your Girlfriend, so she (as a contact) is linked to
the calendar entry. Her Birthday is linked to her Contact and for her Birthday,
you saw something on amazon, so you bookmarked it and linked it to the calendar
entry.
On the other hand, the Shopping list has links to some other Wiki entry, because
it contains Kiwi, and you have notes about Kiwi, how to cook them properly. You
saw this on some website, so you linked to the website from your wiki entry, of
course.

### Bookmarks

Bookmarks should be stored in a simple format:

```json
{ "URL": "https://github.com", "tags": ["ducks", "r", "great"]}
```

Each file is one bookmark and the filename is a SHA512.

| Required core feature                 | Purpose       |
| :------------------------------------ | :------------ |
| JSON File backend                     | Data format   |
| Git backend                           | Data sync     |

### Contacts

Contacts are just read and indexed by `imag`, to create an internal index of
them and to be able to refer to.

| Required core feature                 | Purpose       |
| :------------------------------------ | :------------ |
| vcard file format parsing             | Data access   |

### Calendar

Calendar are just read and indexed by `imag`, to create an internal index of
them and to be able to refer to.

| Required core feature                 | Purpose       |
| :------------------------------------ | :------------ |
| ical file format parsing              | Data access   |

### Mail

`imag` should be able to index all your mail and make them accessible through
its interfaces, so you can link contacts, calendar entries, wiki pages, todo
notes, etc etc. to your mail.

Some of these things (like linking contacts, calendar entries) should be
linked automatically.

| Required core feature                 | Purpose       |
| :------------------------------------ | :------------ |<commit_msg>Add module for simple note keeping<commit_after># imag

Imag is a CLI PIM suite with a nice API-ish commandline interface, so you can
integrate it in your tools of coice (Editor, MUA, RSS reader, etc etc).

## Modules

All the modules have access to a shared store (which lives in `~/.imag/store/`
by default). Files are named after a schema:

    ~/.imag/store/<module_name>-<hashtype>-<hash>.imag

Where module name is "bookmark" for example. The hashtype is "UUID" by default
and the "hash" is a UUID then. Other types are possible as well:

- SHA1
- SHA512

for example (though it might not be a good idea to use SHA hashes,
see [Linking](#Linking))

Some modules might not want to store content there, for example you don't want
to put your icalendar files in there. So the calendar module just crawls through
your ical files and puts the scanned meta-information into the store. Of course,
if the content of the ical file changes, the store entry does not. It still
points (via its JSON content for example) to the same file. So changes are not
tracked (We can argue here whether we want to copy the contents to the store for
ical and vcard files, but we cannot argue on for example music files).

If a (for example ical-)file gets removed, the store entry gets invalid and has
to be garbage-collected.

>   The current model is not fixed yet. I'm thinking about copying .ical and
>   .vcard, basically all text files, to the store.
>   This is not possible for media files like music or movies, though. Also this
>   is not feasible for documents like .pdf or similar.

Each of the following modules has a short description including a table what
core features are required to get it working.

### Linking

The UUID/SHA hashes in the file names can be used to connect two store entries.
For example, an entry from the wiki could refer to a contact by a UUID, because
the file for the contact has a UUID in its name. These UUIDs are constant and
should not change.

A link chain like this

    Wiki -> Shopping List -> Calendar Entry
            |                       |
            |                       v
            |                       Contact -> Calendar Entry -> Bookmark
            v
            Wiki Entry -> Bookmark

is totally possible. Scenario: You have a Wiki entry of a recipe you like to
cook. The recipe is linked to a shopping list, where you want to buy the
ingredients. Of course, you want to do this on a specific date (calendar entry).
And you want to do this with your Girlfriend, so she (as a contact) is linked to
the calendar entry. Her Birthday is linked to her Contact and for her Birthday,
you saw something on amazon, so you bookmarked it and linked it to the calendar
entry.
On the other hand, the Shopping list has links to some other Wiki entry, because
it contains Kiwi, and you have notes about Kiwi, how to cook them properly. You
saw this on some website, so you linked to the website from your wiki entry, of
course.

### Bookmarks

Bookmarks should be stored in a simple format:

```json
{ "URL": "https://github.com", "tags": ["ducks", "r", "great"]}
```

Each file is one bookmark and the filename is a SHA512.

| Required core feature                 | Purpose       |
| :------------------------------------ | :------------ |
| JSON File backend                     | Data format   |
| Git backend                           | Data sync     |

### Contacts

Contacts are just read and indexed by `imag`, to create an internal index of
them and to be able to refer to.

| Required core feature                 | Purpose       |
| :------------------------------------ | :------------ |
| vcard file format parsing             | Data access   |

### Calendar

Calendar are just read and indexed by `imag`, to create an internal index of
them and to be able to refer to.

| Required core feature                 | Purpose       |
| :------------------------------------ | :------------ |
| ical file format parsing              | Data access   |

### Notes

Just plain text notes.

| Required core feature                 | Purpose       |
| :------------------------------------ | :------------ |
| Linking to other store entries        | Data Link     |

### Mail

`imag` should be able to index all your mail and make them accessible through
its interfaces, so you can link contacts, calendar entries, wiki pages, todo
notes, etc etc. to your mail.

Some of these things (like linking contacts, calendar entries) should be
linked automatically.

| Required core feature                 | Purpose       |
| :------------------------------------ | :------------ |
{'fraction_non_alphanumeric': 0.10565492723030774, 'fraction_numerical': 0.0015553827352516388, 'mean_word_length': 2.301063439677301, 'pattern_counts': {'":': 4, '<': 9, '<?xml version=': 0, '>': 27, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 7, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4273804', 'n_tokens_mistral': 2299, 'n_tokens_neox': 2187, 'n_words': 1309}