aridder / pengekrukka Goto Github PK

Goal

Implement a website representing a doctors office. While this interaction is digital in our demo, it could be physical in a real world implementation. The original design file is available on figma.

Todo

• #70
• #42
• #43
• #44

Goal

Implement an imagined government organization akin to NAV where the user can upload certificats from (for instance) their doctor in exchange for voucher-VCs from the government. Original design files are available in Figma

Todo

• #45
• #46
• #47
• #48
• #49
• #50
• #80

• #38
• #39
• #40
• #41

https://docs.login.xyz/integrations/nextauth.js

I do use that setup here https://github.com/aridder/openai-t3 (for reference)

• should explain ideas
• room for demos
• use illustrations and thoughts from https://www.figma.com/file/rlraezDx5mZpizzC4GEWBe/Pengekrukka?node-id=0%3A1&t=tTEfWYbixXIP0z8T-0

Our editors do linting slightly differently. This creates needlessly hard to read diffs. I thnk we should do linting on commit to avoid this, e.g. using husky

Looks good. Next natural step would be to add a add one route with input validation. Im familiar with Zod, but I'm open for any other option.
This show an good example of one route with input validation
https://trpc.io/docs/procedures#input-validation

Originally posted by @aridder in #12 (comment)

Goal

A GUI that demonstrates our solution. It should show 1) relevant subsidies 2) login through wallet 3) relevant credentials for user

Todo

• #34
• #35
• #36

    We should probably configure `.eslintrc.json` and `tsconfig.json` globally. But that is out of scope for this issue IMO :) 

Do you agree? If so, I can create an issue for it :)

Originally posted by @olaven in #14 (comment)

When the project is nearing completion, I propose that we dedicate a large portion README.md to explain the project, and the use-case we attempt to show. This is useful for 1) us, preparing for a hackathon presentation, 2) anyone else checking out the project for the hackathon, and 3) others in the future, finding this project.

Depends on #22

We should have tests for the functionality added in #59.

Goal

Endpoints issuing VC's for our use-cases.
For instance, one endpoint for Eidsiva and one for Tibber (if we are working with the energy case)

I propose that each VC provider (energy company) should have it's own package/endpoint/implementation. The ide ais to make it completely clear that these are different (hypothetical) services. To avoid making it too time consuming, however, I think we should share common interfaces between them.

flowchart TB

    subgraph shared
    CI["Common Interface"]
    end
    subgraph endpoints
    CI-->Tibber 
    CI-->Fjordkraft
    CI-->Fortum
    end
    subgraph webapp
    user-- Avhengig av strømselskap som blir oppgitt e.l. -->Fortum
    Fortum -- Forbruk-VC --> user
    end

Todo

• #22
• #23
• #24

Song et al 2022 describes a system for identity verification using VCs and blockchain. Our solution to identity verification should probably be similar.

From my notes (Norwegian):

I deres system lagres ikke [[Verifiable Credential]] i [[plain-text]] paa [[blockchain]]; Kun en hash av [[Verifiable Credential]], [[Zero Knowledge Proofs]] og den digitale signaturen til ID-provider lagres der.

paper.

(thanks to @aridder for pointing me to this)

Goal

The goal is to implement a fictional optician's store where the user can use the government-issued voucher VC they got from #39. As with both #39 and #38, this interaction could be physical in a real world implementation of our solution. It's digital for demo purposes only.

TODO

• #51
• #52
• #53
• #54
• #55

Makes it possible to verify the identity of VC's on the blockchain.
registration could run as a startup script before the web server starts.

Goal

Use T3. The goal here is to get going quickly.

Todo

• #6
• #7
• #8
• #9
• #10
• #11

This graph describes roughly what we want to achieve and is thus great for our presentation at the hackathon.
Source: p. 4 in this article

Discovered in #56

I think we should add a tool to manage the packages in a way that allows for 1: dependency sharing and 2: running commands from root level. I suggest Yarn Workspaces since 1: it's easy to add, 2: it's fairly low level and only adds a few things on top of yarn, 3: we already use yarn and 4: I've had good experiences with it working on https://github.com/olaven/paperpod :)

@tordjon @aridder if you want to add your thoughts below, feel free :) I can add whatever we agree on.

Goal

Implement a wallet that stores verifiable credentials fo a use, and provides a super-simple GUI with VC-cards
See Figma for GUI sketch.

TODO

• #9
• #56

Goal

After the user has gone through #38, #39 and #40, a transaction should have occurred (#55). We want to show this to our audience.

TODO

• Figure out how we can show this
• Implement whatever we figure out

Goal

Use VC Contracts as contracts for verifying VC's and sending NOK funds.

Todo

• Add TODOs like this and create issues out of them

Description

Failing to sign message when Metamask switches to Goerli.

Steps

1. open app
2. click "connect wallet"
3. accept switching network in Metamask
4. a window in the app says that I need to sign a message
5. upon clicking "send message", metamask pops up with a dialogue to be confirmed
6. sign through metamask
7. app GUI says "Error verifying signature, please retry!"

TODO

• Accepts color
• Accepts VC object
• Accepts icons
• Renders color
• Renders expiration
• Renders icons
• Renders title
• Proportions like a credit card
• matching design in figma
• component is used by different pages