mariuskimmina.com
+109
rfc/initial-design.md
+109
rfc/initial-design.md
···
1
+
## Why?
2
+
There is no flash card system built atop ATproto.
3
+
There are many language learners active on BlueSky and other languages are becoming more frequently used on the platform, especially Japanese.
4
+
Building a flashcard system for language learners on top of atproto can lead to integrations with *sky/yoten/sidetrail and other atproto based applications.
5
+
The increasingly international community and number of language learners on BlueSky can serve as a motivation to keep each other going.
6
+
7
+
## Context
8
+
A tenet of ATproto is the data ownership. Hence deck-makers should own their deck, i.e. it is stored on their pds.
9
+
Successes/failures related info belongs to the deck-users, and goes to their PDS.
10
+
The service owns the service data. This includes statistics
11
+
Especially to get started all data should rely on PDS for storage, therefore all data needs to be public.
12
+
13
+
14
+
## Design goals
15
+
### Key decision 1: universality
16
+
17
+
We have decided to build a language learning focused flashcard application rather than a general one. While this narrows down use-cases it allows
18
+
us to consider more specialised features around e.g. Text-to-speech or transliteration.
19
+
20
+
### Key decision 2: LTR and RTL languages?
21
+
22
+
At the time being I am unaware how much of challenge it would be to support RTL languages.
23
+
For now the aim will be to support them.
24
+
25
+
## Key features
26
+
### Deck making
27
+
28
+
- Bulk upload csv/json/xlxs/ggl sheets
29
+
- UI for creating/editing individual cards
30
+
- Merge/split decks
31
+
- Copy decks (deep copy)
32
+
33
+
### PVP
34
+
Contest between users.
35
+
Scoreboards (w. opt-out), global, per language, also see 'stats'
36
+
37
+
38
+
## Card Creation
39
+
The core: two texts, with say max 300c visible max 600c total. Author can decide whether the cards are reversible or not.
40
+
For languages, 2 text fields are not really enough for a quality deck.
41
+
Any ldeck for latin-script-langs speakers in a non-latin tlang needs at least pronunciation, usually with two-levels:
42
+
* IPA phonetics
43
+
* transcription (approximate, but more aboardable).
44
+
45
+
If there is an IPA field, a full-IPA keyboard such [this ](https://ipa.typeit.org/full/)should be provided.
46
+
Another poss. field: hlink to a dictionary definition in native tlang.
47
+
Self-labelling: at leasty the possibility of using #nsfw. Some might want to create or learn swearwords and detailed slang for alt genitalia, but other might get offended, or in trouble for using audio at the lunch canteen.
48
+
49
+
We can also have multiple "levels" of cards, like [mochi.cards](https://mochi.cards) does where after "revealing the back of the card" there is another reveal option.
50
+
51
+
### Deck using
52
+
53
+
- Play
54
+
- SRS play
55
+
- Choose which face and/or which facets to display
56
+
- Publish success (deck completed, 100 cards known, etc. TBD in 'stats') to [yoten.app](https://yoten.app) and/or [sidetrail.app](https://sidetrail.app/) and of course \*sky as a post.
57
+
58
+
Note: e.g. [Dan learns Hiragana](https://sidetrail.app/@danabra.mov/trail/3m75zw7qiqe2z)
59
+
60
+
## Key algorithms
61
+
62
+
### SRS
63
+
64
+
Required whatever Key decision 1 ends up being
65
+
66
+
1\. none (just create/play)
67
+
68
+
2\. anki SM-2
69
+
70
+
3\. 3-bucket Leitner
71
+
72
+
The 3-bucket Leitner lends itself well to the data split-ownership, and minimise the load on the service. Most SRS algo would require at least computation and potentially storage in the service. The 3BL replace that by simple updates to the buckets stored in the deck-user PDS.
73
+
74
+
### UI layout LTR/RTL
75
+
76
+
Depends on KD2
77
+
78
+
### Language-specific phonetization and/or transcription
79
+
80
+
Applies only within one branch of KD1, but isn't even required, i.e. even a LL system might just let deck-makers add manually phonetics/transcriptions. Now I see that! I advocate a separate field, or better 2, as cmt in 'card creation.'
81
+
82
+
### Statistics
83
+
84
+
Decks: Summary of likes/dislikes, deck copies, actual card use!
85
+
User: deck completed, how many words in a session?
86
+
87
+
## Security
88
+
89
+
### Rate limiting
90
+
91
+
Why is this required? Nowadays, even mini-niche-services are attacked and abused. Prob not a day-1 requirement, but design should provide the hooks.
92
+
93
+
### Moderation
94
+
95
+
A minimum support for self-labelling, e.g. suggested #nsfw, should be enough. Reliance of standard moderation layers and labellers otherwise?
96
+
97
+
## Naming
98
+
99
+
What should it be called?
100
+
101
+
- [recard.blue](https://recard.blue)
102
+
- [recard.social](https://recard.social)
103
+
104
+
### IMPLEMENTATION NOTES
105
+
106
+
Support of audio
107
+
108
+
- what are the built-in limitations for blob size?
109
+
- if the service doesn't do caching, the performance for deck-users retrieve audio blobs from deck-makers pds might not be OK.