todo

-- this is just me rambling to myself about possible future features so i dont forget it


# collections

a collection is a set of card references. cards may be chosen dynamically (e.g. dependencies of a card), and cards added manually.
for dynamically added cards, they may only use properties of cards that are not specific to a user when cards later can be shared. So nothing about the recall/review state of the card, or if it's suspended or not.

multiple collections may reference the same card.

a collection may reference another collection as long as there's no cycles. 

# review sort

like the algorithm use to determine the review priority. so for example recall rate, min recall etc..
it should return something like an Option<f32>, meaning, whether it should be reviewed at all, and if it should, its priority


# review 

reviewing will be done by choosing two items

one is the collection of cards that will be reviewed.

the other is the predicate which may contain things like recall rate, stability, suspended status etc..

for simplicity sake there should be a collection which contains all cards.

hmm maybe we should allow metadata stuff like suspended since we can tie it to the user, i guess we'll have both user-level metadata and global one for cards?


# shared cards

users should be able to share cards so that others can download it and use it and share references

would make sense they submit an entire collection at a time. it'll also push all the dependencies of the collection.

maybe have a github repo that has all the shared cards, and when user press share it creates a PR there that me or others will approve or make suggestions for?
at least for the "global map". 

or maybe no global map and instea deverybody just share collections and can search for each other's collections and reference each other and hopefully organically 
people will converge to one big map since they can reference each other

a challenge here though is how to deal with referencing other collections if the original card is updated or something?
hmm.. i think easiest just let people handle these dependencies themselves, so if you're not happy with how the original guy remade it then you just gotta change your reference

maybe i'll also have a global map that's like more static or smth ? like when people converge on certain collections and they have a high standard i can move them into a global map that's more static
and then i'll have the responsibility for them and the original creator cannot change it so it's more "safe" to use it by others?


# recall rate calculation

should move into using ML for determining recall rate, can just feed a lot of the reviews into a model lol

# expected gain 

lets say current stability is 50

if at a given point you succeed in recall it'll become 130
if at that point you fail, the new stability is 20

let's say the recall rate at that point is 0.8

expected gain = (0.8 * 120) + ((1 - 0.8) * 20) - 50 = 58

we can sort cards based on their expected gain so you know which reviews give you most benefit
maybe also multiply with the priority of the card

limitations:
- it's greedy, so, maybe the optimum long term strategy is not to just take the one with highest expected gain 
- maybe it'll be biased to long or short term ? could be fixed by having a time horizon variable where you can bias certain information to near or long term stability

for example if you're learning two languages, maybe one you need to use 6 months from now and another you have no specific plans it'll bias more to near-term stability for first one and long term for 2nd one

# smart watch integration?

maybe can integrate smart watch data into the app so users can see how well their memory affected by things like sleep recovery exercise


# extension vs intension classes

extension classes can have instances where the instance itself is also a class. is the same also true for intension classes?

on whether the answer on an instances should be which class it belongs to or something about its property, is whether it's intensional or extension class matter here?


# sorter


like an item for sorting cards. takes in a card as an input, returns a float value you can use to sort with. mainly used for review but can use the same concept in browse page, either explicitly by selecting a sorter or implicitly when you click one of the columns. 

so a review session basically takes in 3 arguments.

the collection of items, based on static data saved in the RawCard type.
user data, which is basically reviews + metadata
and the sorter, which decides the order you see the items in 

so the sorter should be like a method i guess on the card which takes in an enum which will return a numeric value. example fields of enum: lastmodified, recall_rate, dependenc_qty...

hmm in a way this seems like a superset of both the static and user data things.. i should explore that. maybe those can just wrap this thing? maybe the enum can be on the top level two enum fields, one for static and one for user data.


# github sync

while I stopped working on this, progress with syncing should make it easier. I cna make a github syncer trait, which will before the sync, pull items from upstream, then i can fetch everything from the origin/main, fetch everything from main, sync them, write to both basically, and maybe force override origin/main since i take care of merging?

idk about the github sync from web-app as i thought of earlier.

# desktop version

should be able to choose between sqlite and filesystem.

and also when you click sync you should be able to choose target to sync with. and you can for example use sqlite as your main backend for speed but then also every time you press sync it'll sync with your filesystem (as well as firestore if configured).

# healthcheck

integrity is kinda crucial, hard to ensure integrity when all cards depend on each other and stuff

i should write out a list of invariants basically
it's too expensive to run proper healthcheck all the time
maybe i should write a separate script to run the healthcheck? or maybe not
not sure how i can reasonably integrate more with type system. for example i could re-introduce the types of instances vs classes as diff types but i think it's more annoying than not. 


# log based state

log based meaning each change in the state of the program is based on a log of actions, like, create new card, suspend, do review, etc...

advantages is, would make it easier to debug when an incorrect state happened, can easily roll back stuff, if i wanna make a schema change to something i can simply change how the events create the items, then remove the state and re-run the actions to re-create it.

also fits well with syncing i guess? easy to just pick up logs from a given timestamp

disadvantage, well, it's more cumbersome, potentially slower but i dont think that's a big problem. 


# properties

sometimes a card depends on another because it describes the card in more detail, while other times it just references it. I'd like to be able to properly distinguish that, so that you can see how well you know a certain card not just by its own recall rate but also how well you know the properties, while ignoring the cards that just reference it.

for example, where was shakespeare born is like a property of him
but a card that's like, whats churchill favorite author and if it's shakespeare would just be a reference, knowing this wouldn't teach you more about shakespeare.

could be used to determine which cards should be reviewed first to understand something. like if A has a dependency on B, you need to learn B first, but maybe you could also learn all the properties of B, even tho not strictly necessary. hmm... or i guess A should depend on the correct properties of A but i still feel it's better to know all the properties yaknow?

also would make it easier to learn about a given subject, like if you do wanna learn about shakespeaere, first it'll teach you to learn the depencies (here just "male" i guess), then you'll learn the concept itself of shakespeare which is just a person (dumb example lol), and then it can start drilling you on its properties, so all the dependents that are considered properties. 

and it can just skip all the references to it cause that's not important, or at least put that last lol.

can all cards have properties of itself? i guess instances can, classes can too right? can properties have properties? i dont think so.. 

attributes would automatically be considered properties tho but i guess we can't fit everything into the attributes thing. or maybe we can rename attributes to properties and not only have the auto-generated ones be that?

should propertyness be defined in the card itself or in the dependency?


# other sync options?


dropbox? google drive?


# main graph


maybe that main global graph thing can simply be a collection i make where i incorporate all the collections i think are good


# release goals

## todo

- make certain cards trivial, like instances of certain classes
- make dependency removal more intuitive, not accidentally clicking it away
- fix dependency removal
- custom question format for instances
- add filter cards thing to browsepage
- sort on browsepage
- move x to left
- firebaseprovider use online timestamp for current_time
- fix bug where card reference dont show up sometimes in cardviewer
- if too many dependencies of a card in graphview, instead of render, just show like e.g. "100+" on a node and if you press it, it'll open a browse page with all the dependencies listed there.
- make collections pretty

## done

- suspend cards
- fix deleted bugs?
- suspend from review
- collections 
- remove all dependencies and dependents of a card in the cache on persist() call

# post-release goals

- see previous reviews on card
- attributes
- links embedded in text
- desktop version
- priorities
- audio
- firestore backups
- symlink, if you wanna merge a card to another one, turn one card into a symlink to the other card lol. 
- add sorter stuff (mentioned above)
- extract provider trait to separate crate, not mentioning speki there
- proper healthcheck stuff
- timeseries for syncing upstream, so we don't need to read entire user dir to find out which stuff are modified after given timestamp
- graphview edges should be diff based on relationship (subclass, instance..)
- make provider into stream, so no need to wait until all is loaded before you get items
- natively support composite items in the provider trait (like how card is RawCard, Metadata, and Reviews)
- tag for a card having all its dependencies in order and stuff (so like, even more finished than finished)