Using multiple clients (mostly iris.to) and the alby chrome extension to login. Messages are just blank and won't load, follower and like counts are constantly disappearing and reappearing.
Am I running into some kind of relay issue or something?
In order for things to work smoothly clients need access to pull in as much data from relays as possible and as quick as possible. It can end up generating hundreds of thousands of events that the client might have to display which can take a chunk of memory and cpu time.
The further back in the sequence of events the client has to look based on its query, the more it will struggle to display it quickly. No matter how you query relays this always seems to be the case. Relays need to be way less dumb than they are.
So this morning you make a post about enjoying a nice cup of Coffee. Everyone from the void responds and you get comments and likes from somewhere. Crazy!! You log out for the day so you can really consider what just happened.
You log back in the next day to see if anyone has left you notifications or messages or anything. No messages are showing! You leave it idle for a few minutes and suddenly you're getting notifications for something that happened hours ago.
The client has to work harder in order to retrieve that historical data. I think relays will need to be less "dumb" because there are a few ways to query a relay but nothing in a way that makes it easy for the client to manage memory, state, and the flow of data.
Here is a challenge I noticed with managing data.
Suppose I have a batch of posts. Each post has a pubkey. This pubkey represents the entity that created the post. I want to find out if this pubkey has a username or nick name.
In my code, I might have a query to a relay or multiple relays like this:
{kinds:[0,1], limit:500}
This will ask the relay for two event types. Event type 0 contains profile information and event type 1 will contain posts. You must match the pubkey of one event to the pubkey of another. Easy!
That query will query 500 of the past events based on current date/time in total. If there are 400 posts events and 100 user events, the chances of the username being in that batch of events is not likely. Even if you have 500 post events and 500 profile events that won't matter if the entity has created a profile that happened 600 events ago then you're not going to get that event and the post will not have an associated username.
I can only speak from the perspective of someone who barely does development stuff until I find projects I think might be fun like Nostr. I know some Javascript and that is about it but can wing it most of the way.
I can tell you that from my own experience most things fall apart once you test your client at scale. It is why I keep iterating and I just feel like I am making no progress at all when I see all these other clients that are beautiful and amazing. Even though they have similar problems. I do think a lot of devs who rely on frameworks are in for a rude awakening. Anyone who builds native clients in languages like C or builds clients from scratch in JavaScript without stuff like Vue or React will end up building the better experiences.
I could only dream of ever building one of the few successful clients out there. I don't even have the financial resources to eat so I have no idea why I am putting any time towards this at all
If there are any companies out there trying to build a client with more resources than I have please reach out. Would love to be able to continue to do this.
For what I have experienced and observed trying out a bunch of different clients, I believe that Iris shows events (notes or else) as it receives them from relays. To (give the impression of) being fast and responsive, it uses placeholders for events and later, when it receives the contents, it places them on those place holders. The firs impression is that of a very fast and responsive client, but a little later you realize that the experience is horrible overall, as you describe.
Other clients, like Astral or Coracle take a very different approach. They start showing the most recent events and keep going backwards. I guess that regardless of the order they get them, they check (cryptographically) all events but don't show their contents until their time to be shown comes. The result is that they seem to be slower and less responsivethan Iris, but the experience is much more pleasant.
I'm not a developer myself, but I tend to agree with @PROTOPHREAK in that relays could be a little less dumb (not too much, since the protocol tries to be simple enough for the clients to be the ones in control) and be able to relay events to clients in a better fashion. Perhaps it should be enough if they'd relay events in "chronologically reversed order", that is the more recent events first.
I think it'd also be convenient if clients queried for less events at a time, for example the ones posted during the last hour, and after a little while, queried for the ones from the previous hour, and so on, until a certain number of "chunks" (hours), and keep going later when the user somehow (clicks or scrolls or use a gesture, etc.) "asks" for older events (if they ever do).
Also, if clients had a way to discard older events one that newer ones arrive, the amount of memory and processor power used could be dramatically reduced. Having to clear the browser cache or close and reopen the browser tab to get that effect, which is what we're currently doing, are both a little inconvenient.
Anyway, that'd be my 100 ⚡, the ones of an user who understands only a little of software development. I've been dragging my feet to start learning any JS. Perhaps its time for me to start doing something about it, because as @PROTOPHREAK, nostr is giving me the itch for trying things. 😂
Hit me at nostr: ama
(npub1ttk90a6kkphe9h0dys9mqy38wxa7t4t7g39vys76f4cglqr49rgqh6xxpx).
{kinds:[0,1], limit:500}