# LeaP features

## Dev process

### global stuff to do

- document best dev practices
- for example, avoid using `unwrap` because holochain wouldn't handle it well
- branch naming pattern
- repo access: allow participants to push into feature specific branches? more details in git workflow

### git workflow

- feature specific branch in Leap that all participants can push to
- PRs for every feature part are made from participant's repo to Leap repo and proposed for code review
- code review is done by all other participants working on the feature
- merge into feature specific branch in Leap repo happens after feature developers reach consensus
- merge into Leap master happens after review by Guillem & Hedayat

### things to do for each feature

- define user stories
- define test cases
- make a design scheme: what are the new components? how do they interact?
- split work between participants

---

## Features

### Provide ability for a course to have multiple teachers

This would be a vector of teacher addresses where every teacher has the same rights.

#### use case

- developing a course with other teachers
- substitute teachers

#### challenges

Implementing this would require change of the validation rules because currently they're working under the assumption that course author == course teacher. With multiple teachers, that assumption would no longer be true.

- list of techers isn't enough because one teacher would be able to remove others

### implementors

Nastasia: implementation
Hedayat: architecture
Greg Kerr: interested

### user stories

- Alice creates a course "Holochain basics" and invites Bob to help her teach it. Once Bob joins, they both have equal access to manage the course
- Alice & Bob start teaching a course together and they are both registered as teachers from the beginning. At any point in time since the course creation they both have equal access to manage the course
- Bob is teaching a course alone. He asks one of the best performing students to become a substitute teacher on the course and this student now has teacher-level access to manage the course. Their student role isn't applicable now
- Alice wants to join a paid course and Bob is the only teacher. If he's the only teacher, she has to wait for him to become online, and if there are multiple teachers, she could send request to them without waiting fro Bob

### test cases

- student -> teacher role conversion only leaves user with teacher privileges removing any student ones (even though teacher continues to learn as they teach the course, their primary role isn't a student anymore so none of this context should be applicable)
- when teacher is removed from the course, they can no longer manage it
-

### design scheme

requirements:
- allow for update & delete validation based on whether or not agent is a teacher
-

#### option 1

separate entry for teacher list.

pros:
- teacher changes are contained separately from the course entry

cons:
- (DEAL BREAKER) course validation would rely on a teacher-list-entry retrieval
- additional complexity in having yet another entry

#### option 2

store teacher list inside the course entry

pros:
- validation for "only teacher can manage the course" doesn't require fetching any other entries

cons:
- not sure there are any

---

### Reputation Modules: review and ratings implemented through mixin zomes.

Develop this functionality as a reusable zome that could be mixed into any project. Modules will be [along these lines](https://sacred-capital.gitbook.io/sacred-capital/documentation/technical/reputation-data-types)

asia hackalong: speaking about modularity, can use that

current work that Jakub is doing with Eric could overlap with this and would be helpful

todo:
- Sid: define questions
- chat with Sid about his questions

#### use case

- Students offering reviews to a course/teachers. Zomes can be swapped out for different Reputation data types i.e. likes/upvotes/stars/emojis etc.

#### challenges

Ensuring the modules are generic enough to be reused by other projects.

### implementors

Sid, Jakub

- start development this week (11th May)

### questions

- how to plug this in?
- Philipp Beadle work with Asia-pacific hackalong would implement something similar as a separate DNA
- we can do it as a mixin zome

### user stories

### test cases

### design scheme

---

### User profile in the app

Give users ability to create a profile in the app so that they can define some human readable handle.

#### use case

- make it easy to recognize a user when performing publicly visible activity (publishing courses, leaving reviews)

#### challenges

### implementors
Josh Fairhead
Greg Kerr
?

### user stories
Q: As a user, how do I add my profile?
S: I want to interact with other users the leap app and for them to be able to identify me
A: Upon first interaction with the application, it requests me to fill in a username. This data is then stored on my source chain, in the personas app.

Q: As a user, how will I log in?
S: I'm returning to the Leap app and have already registered - I'd just like to log in
A: Upon interaction with the app post registration, the app will request my consent to read the previously stored fields from my source chain, provided that I've not already whitelisted it within my settings. If I have it will just log me in automatically

Q: As a user whats stored in my profile?
S: I'm interacting with the site, and so data is exchanged between my sourcechain and the hApp - living on a public DHT
A: The profile stores all user information thats required by Leap. In the most basic form, this will be my user name, courses, reviews & private messages.

### test cases

### design scheme
- New user prompt
-

---

### Separation of courses into different DNAs

Let every course to be a separate DNA and maintain it's separate DHT.

#### use case

- data separation: if you're not participating in the course, you're not participating in storing it's DHT
- improved data privacy

#### challenges

- running multiple DNAs of a single app is only permitted with admin permissions set on the conductor, so this would need to be handled

### implementors
Greg Kerr
(Nastasia): I would like to participate in this too

### user stories

### test cases

### design scheme

- lobby DNA (basically the same as for [mutual-credit app](https://github.com/holochain-open-dev/community-mutual-credit)):
- profiles zome
- allow users to set a profile name
- remote_bridge zome
- allow for communication between different DNAs
- courses_index zome
- store index data about all public courses (Nastasia: as of 16th May, all courses are public by design, but I'm writing this here to plan for the future)
- courses DNA:
- course zome
- course content
- module content
- reputation zome

---

### Indexing Course Title + Search

Enabling discovery of courses by running a search query for a string, or for tags associated with a course.. May be implemented along the lines of [Holodex.](https://github.com/holochain/holodex)

#### use case

Users can search for courses by name, or by category (indicated by tags)

#### blockers

anchor pattern
DNA per course (it would severely impact design of this feature)

#### challenges

May involve bridging to specific DNA with indexing nodes?
DHT already stores data sorted by it's content (but doesn't allow to seach by parts of this data). How can we take advantage of that?

### implementors

Sid, Hedayat?

Greg Kerr

### user stories

### test cases

### design scheme

do indexing on two levels:
- lobby DNA level:
- course category index
- course name index
- module names index
- teacher name index (Nastasia: seems like a reasonable option since people often look for courses based on who's teaching them)
- course DNA level:
- terms index (Nastasia: more like index we see in books where you can look up a term and find all it's occurences in all chapters). Would make sense to require module definition to provide list of terms to allow building of this index
---

### Payments with mutual-credit (*)

A double entry accounting system that keeps track of who's made payments for courses.

#### use case

A credit currency that represents access to courses on the Leap platform

#### challenges

Integrating and validating with external fiat/crypto systems? Bridging across DNAs to ensure valid people access courses.

### implementors

Guillem, Hedayat? (Sid can help with monetary currency design if needed), Greg Kerr, Josh

### user stories

Josh: add user stories
Q: As a user, how do I make a payment to another agent?
S: I wish to pay another agent, this means debiting my account and crediting their acocunt
A: Select the user, choose an amount, click send

Q: As a user, how do I recieve a payment from another agent?
S: I wish to recieve payment from another agent, meaning my balance should be positive and theirs the corresponding negative
A: Be online when they send it, you should also share the same membrane

Q: As a user, how do I know who I can send payments to?
S: I want to find out who I can send payments to within my network
A: You can click the creditors tab and see whos available

### test cases

### design scheme

---

### Ability to include single module into several courses

Allow modules to be reusable instead of copying the shared modules between the courses.

#### use case

- module "rust basics" could be included into both "Into to holochain" and "Advanced Rust" courses

#### challenges

- how to allow one module to be included in multiple courses if each course has a separate DHT?

### implementors

? Greg Kerr

### user stories

### test cases

### design scheme

There are 2 possible cases:
1) module is re-used between courses in a single DNA. In this case we need to reference this module,because course using it is located in the same DHT and has access to module data
2) module is re-used by a course from another DNA. In this case we're making a deep copy of the module