Oddbean new post about | logout
▲ ▼
EnergerticLaser | 1 years ago (raw) | export | reply | flag +1 
 Wishlist for primal.net (cc @miljan).

1. Store profile metadata in local storage; browser should read from that instantly on refresh then issue a fetch in the background to test for updates. A refresh shouldn't do a full refetch every time: it takes forever and slows the whole experience down.

2. Messages that were marked resurface as unread. It's annoying and makes me want to write a firefox plugin to hide the message button entirely.

3. In Settings>Appearance, allow a minimal mode where the primary nav can be reduced to only icons (no text) and font-size for the entire site can be made larger.
▲ ▼
EnergerticLaser | 1 years ago (raw) | root | parent | reply | flag 
 cc @miljan
▲ ▼
nielliesmons | 1 years ago (raw) | root | parent | reply | flag 
 If you zoom in, you can have (3). It already does that on smaller screens. 
An extra plus is having the notification dots way smaller and less in your face 👌
▲ ▼
EnergerticLaser | 1 years ago (raw) | root | parent | reply | flag 
 cc @miljan
▲ ▼
miljan | 1 years ago (raw) | root | parent | reply | flag 
 Thanks for the feedback. 

1. Yes, we are looking into ways to speed up the initial load, as well as the app in general. Storing more data locally will be a part of the solution. 

2. Are you able to repro this reliably? If so, we'll reach out over DMs to get more info. 

3. Good idea. We are considering something along these lines for our next update.
▲ ▼
EnergerticLaser | 1 years ago (raw) | root | parent | reply | flag 
 Additional primal.net requests:

A. Actions, like liking a post, should immediately be rendered in the frontend and then queud to be persisted in the backend. Today, a like will only activate the like button once it has been persisted. This makes the entire UI feel slow. Queue actions, never block on them.

B. The frontend only renders once it gets a reply from the backend. This causes the UI to take many seconds before rendering. Instead, the UI should be rendered immediately then populated asynchronously as data comes in. Architecturally speaking, this means decoupling the presentation layer from the data layer, which makes sense for #Nostr given it's heavier, complex data stream.

C. The frontend refetches notes it already has seen before; frontend caching can calculate a hash of the note (or use a unique id if one already exists) to not only display the UI faster but skip fetching duplicate notes that already exist in local data cache.

cc @miljan

nostr:note1cd6l3gntmfv8yhmkw855ae9xvyy2jc4ufwk849tqap7kxfv6zumscjp6tu