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:
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
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
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):
- 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.
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:
- 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
- module is re-used by a course from another DNA. In this case we're making a deep copy of the module
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe