LeaP

Selected Features

See more details on these features implementation here.

• Multi-teacher Course
  • vector of teachers with the same permissions
  • would require change of validation rules
• Reputation Modules: review and ratings implemented through mixin zomes
• Profile
• Each course one DNA: show how to keep separate DHTs inside a single app
• Indexing Course Title + Search
• Payments with mutual-credit (*)
• Implement the same entry hash for different module
  • one module can be used in the multiple courses (like Rust basics are used in both Holochain & advanced Rust course)

Design & architecture principles, refactoring

Principles that we should demonstrate

• best practices in Validation
• best practice of Anchor Pattern
• performance implications of features

New features backlog

• Course to have multiple teachers (have been mentioned during the calls multiple times)

• Using reputation modules for micro-certification, P2P certification
  -certifications computed locally by individual agents/teachers
  -grade curves chosen by teachers through libraries
  -reviews and ratings implemented through mixin zomes
  -reputation staking for entry into certain courses

• Instant (or not so much) messaging (very resource consuming, can use Kizuna for the reference instead)

  • course chat with teacher & all students
  • private messages between teacher / students

• Allow agents to create their profile within LeaP and have a search function for profiles

• Subscriptions to private courses

  • Each course different DNA!!?? I am not sure –>>> Private courses ^^
    • (Nastasia) that might be a good idea since this would allow to separate DHTs between courses and achieve data privacy (only course members would be storing data of the course) +1 +1

• Invitation by admin to private courses

• Payments with mutual-credit

• Courses reviews and ratings :))))

• Mutli device Agent identity.

• Implement reusability of modules in different courses

• (not a feature, it's an architecture concept that should be demonstrated) Implementing unique pattern for Course

• (not a feature, it's an architecture concept that should be demonstrated) Implementing fully validation on all Etnry and Links in best practice (not get_links in validation) +1

• Solve the update loop issue with static anchor and changing entry pattern

• A simple testing module, possibly connected to credentials

  • Perhaps think of Verifiable Credentials standard implementation / wrapper

• Course forum, questions and answers

• Full index Course for search by title | module | content +1111

• Implementing Role management for User|Teacher

• Discoverability: exploring different models

• Performance: different approaches and their impact on performance

User stories

• A user should be able to view 3 tabs: enrolled courses, my courses and all courses
• In enrolled courses, a user should be able to see all the courses in which the user is enrolled
• In my courses, a user should be able to see all the courses in which the user is the teacher, with a "Create course" button and a "Delete course" button, and an Edit button inlined
• In all courses, a user should be able to see all courses with an "Enrol" button if the user is not its teacher
• The teacher for a course should be able to create/edit/delete a module in the course from each course view inside "My courses" tab
• The teacher for a course should be able to create/edit/delete contents for each module from the module's view inside "My courses" tab
• The teacher for a course should be able to see all the students for that course

Entries

Entry "course" {
    Model: struct Course {
        title: String,
        modules: Vec<Address>,
        timestamp: u64,
        teacher_address: Address,
    }
    Links: {
        course->student
        student->course
        teacher->course
    }
}

Entry "module" {
    Model: struct Module {
        title: String,
        course_address: Address,
        timestamp: u64
    }
    Links: {
        module->contents
    }
}

Entry "content" {
    Model: struct Content {
        name: String,
        descritpion: String,
        url: String,
        timestamp: u64,
        module_address: Address
    }
}

Entry relationship diagram

graph LR
  subgraph Courses zome
    
    subgraph agent_id
      bob_id
      alice_id
    end
    subgraph anchors
      all_courses
    end
    subgraph courses
      Course1v0 ==>|replaced_by| Course1v1
      Course1v1 ==>|replaced_by| Course1v2
    end
    subgraph modules
      Module1
    end
    subgraph content
      Content1
    end
    
    all_courses --> Course1v0
    Course1v0 -.->|modules| Module1
    Module1 -.->|course_address| Course1v0
    Course1v0 -.teacher.-> alice_id
    bob_id -->|student->courses| Course1v0
    Course1v0 -->|course->students| bob_id
    alice_id -->|my_courses| Course1v0
      
    Module1 -->|module->contents| Content1
    Content1 -.->|module_address| Module1
            
  end