filipesmedeiros / zep Goto Github PK

this will much more easily allow offline use that then gets flushed once you get online

onesignal.com seems like a good idea to do this!

right now it's super slow, don't know why...

also, should i always refill work when a new block is confirmed? i believe so

we can store rejected hashes on idb and hide them completely from the user.

i believe any normal use case will be able to handle this solution, but if the list gets too big, maybe this won't be performant enough

it's gonna be used 2 or 3 times in the whole app, might as well use native hooks for it, it's probably easy

this should also receive all incoming transactions when the user comes in if they have zep unlocked

idb is much smaller, i really need to cut down my chunk size

this includes only updating the list itself when a new confirmation comes through

this will probably store a different encrypted seed on idb, and unlock it separately

probably just switch to nanocurrency from nanocurrency-web?

• move stuff into components

basically that's it, but maybe there's some more stuff that i will find in the meantime

i made changes and need to fix light mode

• seed onboarding
• passphrase onboarding

when you leave the qr code read page before before the video stream loads, it keeps loading in the background and never shuts off, even if swapping to the page and leaving again (we probably lose the ref to that video)

that way we can also remove qrcode from the client bundle

this should just store a bunch of (address. name) pairs on idb

i should also load this into memory on startup because it will be bad if i have to cycle through all blocks always checking idb

offline, i have drawn a diagram with what i picture would be a good way to structure this.

basically it goes like this:

• there's 2 "apis"
  • the nano price
  • the nano node
• there're the permanent storage aka idb
• there's react state aka context

data should flow nicely between all of them, in the following way:

• idb only gets updated when:
  1. an action takes place (new block is confirmed by me, new preference is set)
  2. on startup, if there's any difference with the old state
• on startup, we feed the react context immediately from idb (it should have basically the same state) and go to the node to check for differences (which will update both context and idb)
• every time an action is successful (e.g. failed sends have no effect on state) we should reflect that both in context and idb
• websockets flow data from node to context directly

some of this is for performance reasons, because it would be simpler to have a linear model: context <-> idb <-> node, but that's probably not fast enough