elearningdao / pocre Goto Github PK

This publication is for testing purposes only.
Someone in the community will be invited to use and give feedback about the look & feel and user experience.
It will be temporarily published on Heroku and fully centralised with no connection to the blockchain yet.

Take the wireframe "UI - Layout - Collection - Overview.jpg" as a guideline and define a design of the overall platform.
Try to make it nice-looking and usable for the final user.
Provide a couple of proposals and store them in a defined directory.

The current implementation is more a demo than anything else, the users are selected from a list of fake accounts.
However, now the frontend start to be much more close to what is the desired workflow and it is time to manage properly the user session process.

We need to protect the APIs by applying a JWT session (for every call).

An evolution of this ticket could be a full registration process for the users, maybe using some already available framework (because at the moment it is completely skipped) like https://next-auth.js.org

We need a professional logo for POCRE, that gives the idea of co-creation activity from users.
In this task, we also manage the redesign of e-Learning DAO and BOUNDER logo.

In this scenario (3), Charlie is alerted by friends (or anybody) that the paternity of his opera (or portion of) is wrongly assigned to someone else.

• Charlie doesn't have yet a wallet and he creates a new one
• he searches for his opera by the name and finds it
• he recognizes Alice as the co-creator of something new but also realizes that Bob wrongly took the paternity of Charlie's opera
• Charlie starts litigation with Bob
  

There is some flaw in the design compared with the wireframe.
This is the refactoring of the "inbox" section, some labelling is already changed and a couple of new requirements have been added.

We need to have the main branch used as an updated version of the active development, where users who download it can launch the project following easy README instructions.
Currently, Heroku automatically builds + deploys the backend from the branch api and Netlify automatically builds + deploys the frontend from the branch web-frontend. We can keep it as it is and manually converges it into the "main" when satisfied with the released branches (backend & frontend).
By doing that, we can finally use the git tag feature, for marking stable versions.

create the templates for all wireframes involved in scenario #1

Having already clarified the workflow and wireframes, it is possible now to define all the entities and the system, creating an entity-relationship data structure for the overall project.
It is worth mentioning that at this stage we are not taking into account any blockchain peculiarity (nor layer1 and 2).

The ER diagram has to be designed as a typical cloud (centralised) application. In the second stage, we will decide what data (and components) have to be stored in the blocks and only in the final stage (when hydra is stable and released) we will build the layer 2 engine.

create the templates for all wireframes involved in scenario #4

The overall idea is to have a user profile linked to his wallet, where the wallet has a reputation (from 0 to 5 stars) based on user profile information (eventually verified).
Having a 0 stars wallet or 4 stars wallet doesn't change anything in the use of the application, the only difference is the time required for a user to have authorship acknowledgement of his/her material in the case of a dispute.
At this stage, the formula for the assigned stars is quite basic/silly (we also don't have yet any real verification process). More data verified more stars if the user has more than 10 operas (creations/materials) registered, the user receives an extra star.
The maximum amount of stars is 4. The fifth star is only temporary and for the jury members (never displayed in the user profile)..

The user profile page has to change allowing the user to input the data and display the reputation

Some components of the wireframe were missing but in general, this is a re-thinking of the functionalities desired

There are a couple of documents, but it is not enough to give a proper picture of the project, to help people to contribute and to help people to understand what we are talking about.
A wiki where everybody can contribute was created here, with already a few articles written, but many more are still necessary.

Scenario 2 (as you can see in README) is where Bob receives the notification of contribution acknowledgement and now he:

• enter in his wallet,
• recognize the piece of the opera as one's own
• confirm the acknowledgement
  

We created all the designs, now we want to build a real browsable web interface, but without yet the backend implementation.
Adopt a CSS frameworks like material UI.

The previous developer @mrron313 forget to implement a few things:

1- this page is fully missing
https://www.figma.com/file/CqtC9u2rLf0WcpFv44VoQc/Web3-e-learning-(Copy)?node-id=194%3A655

2- missing the preview component in the white box and the carousel
https://www.figma.com/file/CqtC9u2rLf0WcpFv44VoQc/Web3-e-learning-(Copy)?node-id=194%3A2387

3- I can't find where this page is implemented (probably missing)
https://www.figma.com/file/CqtC9u2rLf0WcpFv44VoQc/Web3-e-learning-(Copy)?node-id=176%3A3859
however, the design can be simplified by removing the fancy "author info"

4- missing icons and rounded boxes
https://www.figma.com/file/CqtC9u2rLf0WcpFv44VoQc/Web3-e-learning-(Copy)?node-id=166%3A1182

5- missing "add files" and preview boxes
https://www.figma.com/file/CqtC9u2rLf0WcpFv44VoQc/Web3-e-learning-(Copy)?node-id=168%3A2858

6- missing "save draft" and "finish" button
https://www.figma.com/file/CqtC9u2rLf0WcpFv44VoQc/Web3-e-learning-(Copy)?node-id=173%3A4076

We have done the frontend UI part in ticket #73, now we need to integrate this part with backend.

Backend API :
https://pocre-api.herokuapp.com/v1/users/{USER_ID}

Frontend:
https://pocre.netlify.app/wallet

The notification part is tricky. Partially it can be implemented at this stage, but mainly is for later (in a more "web 3" fashion).
Anyway, for this first beta release, we want to search inside the user's DB (they could have done other creations or just authorship of materials). If the user is not present we need to "popup" a quick add-to button (in this case would be nice to add an email field for async sending).

THIS PART IS IMPLEMENTED

Scenario 1 (as you can see in README) is where Alice already created the opera (mashing materials) and now she:

• enter in her wallet,
• decides to record a new opera,
• fill a form with the fields in relation to the components of this opera,
• identify other co-authors,
• complete the registration and generate the QR code.
  When (with other tools) she put the QR code of the opera (for example a video), she:
• open again the wallet and select the previous opera
• finalize the record storing the link where the opera is hosted (for example youtube, IPFS, etc).
  

There is an urgency to publish the contributor list but the page is not designed for easy manual editing.
Follow the instructions on the screenshot.

The old home page was partially implemented (there were just problems with responsiveness) and it is still in the source, code but commented on. It refers to this design
https://www.figma.com/file/CqtC9u2rLf0WcpFv44VoQc/Web3-e-learning-(Copy)?node-id=154%3A53
however in these weeks, we updated some components like the logo and background, so make sure you don't overwrite the new things.
We need a new icon home, linked to this homepage

The home will be accessible to everybody (logged and not logged users).
These are the interacting components

We don't have any system yet to define the concept of "trending", temporary it can be just the first 5 creations in the "progress" of the assignment.

We want to give the users the opportunity to share (on social media) the proof of their creations.
The "sharing button" will open a little popup where the user can select these social services: Twitter, Facebook, LinkedIn
On page creations, by clicking the social link, the user will share the selected creation. For example this link:
https://pocre.netlify.app/creations/eba2d853-83c8-437a-a076-69581132c4d8

On page recognitions, by clicking the social link, the user will share the selected recognition. For example this link:
https://pocre.netlify.app/recognitions/23e928a7-e7dc-4ced-8fe0-69da4d4d9eb8

I found 2 good "share button" solutions, easy to integrate:
https://github.com/assisfery/SocialShareJS
https://github.com/kytta/shareon
pick the one you prefer, but also feel free to choose other solutions (but they have to be light).

As you can see from the screenshots I'm also asking to use the icon "proof of creation" instead of the others
https://www.clipartmax.com/middle/m2i8A0K9b1m2H7Z5_lawyer-clipart-legal-requirement-legal-document-png/

We have to improve the footer by adding the GitHub icon/link and the link to the main website (pocre.net)

Let's reacap the basic scenario:
Alice did a new creation and identified Bruno as a material author. Bruno receives the notification of acknowledgement and confirms his authorship. Charlie recognises the material as his property and claims it. Bruno has 2 options: withdraw or start the litigation.
Jury components vote to correctly assign the authorship to Bruno or Charlie based on their information.

On this litigation dashboard page, If you are logged as:
Alice -> you see the box "Waiting authorship recognition"
Bruno -> you see the box "Opened against me", where you can withdraw or start the litigation process (it is only one shot option)
Charlie -> you see the box "Waiting authorship recognition"

You could be a user with all of these scenarios active, with all the boxes available.

This bug is probably related to the documented issue with the ER model.
What is missing here is the option to add multiple files (representing multiple materials) to a single author, in relation to a single creation (alias opera).
It was present in the workflow but sadly missed in the design implementation.

For all four scenarios already designed, the mobile version must also be created.

We want to show random avatars of the authors of the materials (used in the "creation" displayed on this page).
It is mainly to give evidence that there is co-creation. All of these users are contributors to the new opera.
Avatars are not clickable. In the future, we could display a new section with materials related to authors.

At the moment the jury member, during the litigation phase, can change his mind a few times in the voting preference.
However, this elasticity should not be allowed. The vote has to be a one-shot preference, there is no room for changing it.
The reason is that this info is currently stored on DB but (in future) it has to be stored on-chain (in the blockchain) and the back and forward don't fit the tech (because unreasonably expensive).

1. I feel the creation date display can be improved in frontend. Currently it shows in iso format something like this 2022-09-25T11:10:00.000Z, How about we add it like 25 September 2022 @ 11:10 AM?
2. There is a reCaptcha on creations step 3, should we add google reCaptcha there?
3. I think this should be 'All Creations' (on the creations home page). When the user is redirected from his wallet we show him 'My Creations'.
4. Should we show the most recent creation first on the creations home page?
5. Currently we are not checking a link if it is a valid link for image, video, audio, document. A webpage link (example https://pocre.netlify.app/) is also allowed for a creation link which is not always correct, a correct url should only have an image, video, audio, or a document (no webpages). Should we add logic to handle these checks in the api?
6. Do we need an edit-creations page (we have an edit icon in the creations card but not the UI for editing a creation, we can use existing ui from create-creation flow to make the new edit creation page)?
7. There is a share button on the creation card. Which platforms will we allow for sharing a creation (like facebook, twitter, instagram, whatsapp or copy-creation-link-to-clipboard etc), This is also directly related to point 8.
8. Do we need a details page for a single creation, like a detail page for creation id = 12345 that has all the details of materials used (and its author), and the creation. This could then be a shareable link like https://pocre.netlify.app/creations/12345 where 12345 is the creation id. External users can then share this creation and visit this specific creation by the url
9. we have a save draft button on creation step 3, but no such logic to handle drafts on the api. Should we add logic to handle creation drafts on the api?

The user logged in (currently using pre-built users) has to be able to see his data on every page.
At the moment this is only possible on the "creation" feature. You can see an example of how to do that for other pages here
https://github.com/e-Learning-DAO/POCRE/blob/web-frontend/src/components/Layout/Header/useHeader.js#L6
Users not logged in cannot access any page other than "credits".
At this stage, this check is only required for the front-end side. A proper authentication backend at the API level is planned for later.

The "preview" function generates a JSON representing the "Proof Of co-CREation" (with the status).
This JSON is the info we want to store on-chain (because it has to be global and immutable) but only when the authorship is acknowledged and the process is complete (status completed and NOT pending).
The status is complete when there are no claiming processes and the CAW (Creation Authorship Window) time window is ended.

Further clarifications:

We don't generate an on-chain transaction every time the creation change status (from creation to pending to closed) because it's too expensive. For these middle statuses, we continue to store off-chain (DB) data, even the final status is always in DB but also stored on-chain
During the litigation process, we don't store on-chain all the voting transactions, it is an off-chain process (in the future we could change it).
The best scenario is having hydra that manages all of these "middle" transactions, but at the moment the tech doesn't fit 100% of our requirements.

Potential issues:

The JSON output of the "preview" could be too long to be fully stored on-chain, maybe compressing and splitting is an option but probably the best option is storing (again) in IPFS.

How to store the JSON on Cardano:

Every transaction (send token) in Cardano associates metadata (a few bytes of available space to describe what we are sending). The idea is to store the JSON (or the link to IPFS representing the JSON) during a transaction.
To do technically this is straightforward using https://meshjs.dev toolkit. The only thing you need is https://meshjs.dev/apis/transaction "Send ADA to addresses".

Transaction between actors:

POCRE will have its Cardano wallet
The user will have his Cardano wallet
POCRE transact a minimum amount of ADA to the user and inside the metadata it will store the representing JSON (or IPFS link) that is the output of the "preview" feature which is the "Proof Of co-CREation" (with status completed).

Where do the tokens come from?

The user will pay POCRE in advance, for the service. POCRE returns part of the tokens with the transaction on the JSON.
Anyway, this is a detail for another ticket.

Action Items

• 1. Display a button to publish/store the creation on chain on every non-draft creation after the user makes it. The transaction amount is 9 ADA + Transfer Fee. All transactions are from User's to POCRE's wallet
• 2. Store creation IPFS and metadata in every crypto (ADA) transaction
• 3. Mark the creation stored on chain as 'stored' in the db.

We want to give the user the opportunity to connect his browser wallet (like with metamask) to POCRE.
Cardano has a few wallets, but at this stage, even a connection with Nami (https://namiwallet.io/) is good enough.
It should be straightforward to use the demo documented here
https://developers.cardano.org/docs/get-started/cardano-serialization-lib/create-react-app
deployed here
https://dynamicstrategies.io/wconnector
with the source code here
https://github.com/dynamicstrategies/cardano-wallet-connector
The feature will be available in the "wallet" section. There is no need to do any transaction at this stage, only wallet recognition.

After receiving complaints about the design's originality, we decided to change the colour background gradient.
Other minor improvements could be made later.
Substitute with this

Even if it doesn't seem important naming is extremely valuable to clarify the purpose of the things and so what to do and how.
Because of this topic, we need a bit of refactoring of naming for labels, routes and source functions

There are hundreds of wrong entries called "invitation" to rename into "recognition"

This is even worse, instead of credits there is credit card (obviously to rename)

I assume the DB tables/fileds are affected as well.

If you found something else don't hesitate to fix it.

We tried to implement the wallet reputation without a clear redesign of the page but it was a mess. So, let's start again.
This ticket is about creating a design (for desktop and mobile as usual) for the user wallet, where is possible to update the user profile.
The current (not completed) ugly implementation is this

here https://pocre.netlify.app/wallet
The explanation of what every component does is well described here #35
Let's clarify what is needed:

1- The user can have many wallets (they are linked to browser extensions), currently they are just displayed one by side with another and it's not good. We need a section/tool where there is a list of the available wallets and where the user can select the one he prefers. When selected (means connected) the list disappears showing only the connected wallet. The user can disconnect the wallet, enabling again the list of the available wallets.

2- The user can edit:

• email
• phone
• verify the ID (at the moment only a toggle on/off)
• name
• bio
  We need a button to edit and save (unless there is some other clever solution)

3- the stars rating are generated automatically (not imputed)

4- the time window available for creation approvement is generated automatically (not imputed) based on the stars rating

5- I would suggest adding some sort of (i) or "?" icon, to help the user understand the meaning of every component

As mentioned in our wiki the user wallet address will never be publicly displayed.
However, to avoid any leak or malicious actors we want to avoid storing it in plain, but hashing it (one-way encryption) in our DB.

In the scenario when a user saw online creations belonging to him/her, instead of filling the form to search it (because he could not know the name of the creator or the creation) the user could quickly add the unique id found in the preview feature (that it is also the QR code).
We implemented already this "preview" button

that generate a link pointing to the details of the creation.

We should expose this preview also in other parts of the application like in the "creation"

So the user can search by any creation or point on it directly by having the URL (or QRcode)

This first release must be as clean and simple as possible.
There is no need for things like the search tool, multi-languages and material carousel. They are unnecessary at this stage, they will be implemented later on.

I clicked to "start litigation" here and this error message was displayed

related to this litigation https://pocre.netlify.app/litigations/e779edd8-2288-4163-8ffc-48fadab6b706
Anyway, after refreshing the page, the content was right

However, the voting process from the jury was started already, but it is wrong because the voting has to start ONLY when the user starts the litigation. This is because the user can also withdraw and the voting process is skipped.

create the templates for all wireframes involved in scenario #3

Currently, the QRcode displayed is just a fake, it is just to give an idea of what the user should see, but now it is time for proper implementation.
The QR code is generated ONLY after the user saves the draft. It is a simple representation of the unique link representing the "preview" (rename in "Proof Of co-CREation - Status pending"), where users can see details about the creation, materials used, authors, claiming process (if any), assignation date-time, etc.

(not "Creation Authorship Acknowledgement" but "Proof Of co-CREation - Status pending")

Add also the ID in the doc, to facilitate the user who wants to print it.

At some point, in the near future, the "Proof Of co-CREation" info (or just the ID) will be stored also in the blockchain, but it's a ticket for later.

create the templates for all wireframes involved in scenario #2

Design, describe and document the APIs via swagger, mocking every response from the backend.

We found a few issues with the ER model, some are fixed already but others are not yet.
Here some:
1- Missing creation_date field in the 'creations table'
2- A tag can belong to 1 or many creations (1 to many relations from 'tags' to 'creation' table)

Please comment on this ticket to update on other bugs discovered.

In scenario 4, three of the most trustable people are randomly selected to be anonymous litigators.

• They receive in the wallet the notification
• where the information about the Alice opera is detailed
• and where Bob and Charlie are in the litigation process.
• All of them vote (who is right and who is not) based on the info they have
  

In order to simplify the litigation feature, the explore section has been refactored, however, we can further improve by completely removing the landing section as well

and adding the "new claim" feature on the top of the dashboard

We want to give external (not logged) users "access" to view registered users info.

The user profile (linked to the wallet) has to be publicly accessible for everybody, together with the co-creations he/she did.

To recap, the overall idea is to have some sort of "open linkedin" where everybody can see the Alice operas.
The Alice's open information will be:
-bio with wallet reputation
-list and details of creations
-list and details of materials recognised as author

We need a basic website with info about the overall project, an explanation of the solution, the work-in-progress status, etc. that works as an entry point to the Dapp we are building.

Create a database (based on the ERD already defined) and populate it with dummy data.
Substitute the mock implementation of the APIs with the real ones.

The wallet template is changed and now the list of available wallets are in a dropdown menu.
On selecting the preferred wallet extension, the wallet address is displayed.
When the user saves the profile, the wallet address is saved (temporarily as clear info without encryption, the encryption is for this other ticket #91).
When the user clicks to edit the list of available wallets extension is displayed again.

Make sure in this wallet integration the following previous bugs are not available anymore:

The integration is done but there are things to tune and fix:
1- The logout button doesn't work anymore.

2- Automatic wallets disconnection in case of:

• Logout
• User switch (via dropdown menu)
• On click on the "switch wallet" button
  

3- Wrong wallet address association

4- When a wallet is connected, remove the others available from the view. When disconnected shows all the available wallets again.

5- Every user can have only ONE wallet ID associated. After the connection, the address has to be stored in the user profile.
If the user disconnects from the wallet, remove the address from the user profile.