good way of getting inbox into the UI

Iris Lightshard commented

2024-04-28 17:37:16 +00:00

Owner

Currently the Adapter.getInbox() method signature doesn't return anything, so relies on side effects to populate the UI.

Probably, we don't want to populate the UI directly from this method. Thinking we will sideload message objects into a message store (or return them, if I can figure out a good way to do it on the nostr side), and poll that store regularly from the UI to render the messages appropriately.

UI side

check store for messages
cross check against current UI view and messages therein
for messages that belong in the UI, figure out where they are supposed to go (thread, etc)
clear the store? will have to develop a good heuristic to know what's safe to discard

adapter side

retrieve messages of the appropriate criteria
translate them into a common UnderBBS format
put them into the store if they aren't there already (or if they've been updated/edited since last put there)

Currently the `Adapter.getInbox()` method signature doesn't return anything, so relies on side effects to populate the UI. Probably, we don't want to populate the UI directly from this method. Thinking we will sideload message objects into a message store (or return them, if I can figure out a good way to do it on the nostr side), and poll that store regularly from the UI to render the messages appropriately. ## UI side - check store for messages - cross check against current UI view and messages therein - for messages that belong in the UI, figure out where they are supposed to go (thread, etc) - clear the store? will have to develop a good heuristic to know what's safe to discard ## adapter side - retrieve messages of the appropriate criteria - translate them into a common UnderBBS format - put them into the store if they aren't there already (or if they've been updated/edited since last put there)

migs commented

2024-06-19 03:46:20 +00:00

Collaborator

i concur lets create some type of variable that holds the messages

on the nostr side can underbbs store notifications for other kinds of note kinds (not just kind 14's (private messages as defined in nip 17)

maybe notifications for emoji reactions on clients that implement custom emojis like Amethyst

https://github.com/nostr-protocol/nips/blob/master/25.md

i concur lets create some type of variable that holds the messages on the nostr side can underbbs store notifications for other kinds of note kinds (not just kind 14's [(private messages as defined in nip 17)](https://github.com/nostr-protocol/nips/blob/master/17.md) maybe notifications for emoji reactions on clients that implement custom emojis like Amethyst https://github.com/nostr-protocol/nips/blob/master/25.md

Iris Lightshard commented

2024-06-19 15:33:18 +00:00

Author

Owner

Yeah this issue is pretty old, but with the current state of the backend we can start experimenting and reframing it.

Current idea is to have 2 ways to get data from the backend:

subscription: when opening the websocket (uses the DefaultSubscriptionFilter) or posting to the subscription endpoint for the adapter, we tell the backend what kinds of data we're interested in, and it will automatically stream on the socket.
fetch: for data not in the subscription filter (maybe individual profile data, etc), we can request it directly. it could either be returned from the fetch endpoint or perhaps just be injected into the websocket from the adapter

Then yeah we'll have a frontend object that should reflect the message threads as closely as possible, and notifications will be part of this.

Yeah this issue is pretty old, but with the current state of the backend we can start experimenting and reframing it. Current idea is to have 2 ways to get data from the backend: - subscription: when opening the websocket (uses the DefaultSubscriptionFilter) or posting to the subscription endpoint for the adapter, we tell the backend what kinds of data we're interested in, and it will automatically stream on the socket. - fetch: for data not in the subscription filter (maybe individual profile data, etc), we can request it directly. it could either be returned from the fetch endpoint or perhaps just be injected into the websocket from the adapter Then yeah we'll have a frontend object that should reflect the message threads as closely as possible, and notifications will be part of this.

Iris Lightshard commented

2024-07-05 02:33:08 +00:00

Author

Owner

We're almost there. Seems AdapterElement is building threads but trying to render them before any have been built. Pretty strange.

Iris Lightshard referenced this issue

2024-07-05 02:44:41 +00:00

client: thread view #7

Iris Lightshard commented

2024-07-06 18:20:56 +00:00

Author

Owner

What we ended up doing was:

streaming data from the adapter to the client via the websocket
when the client handles websocket messages, it switches on their type, stores them in a repository; depending on the currently active adapter in the UI, we update its data-latest attribute with the ID of the data that came in
the adapter web component will take the data from data-latest and fetch it from the repository it will place the data appropriately in its own internal data structures, and if the UI needs to be updated it will do that as well

Supposedly, the callbacks for custom elements are synchronous, so when we make subsequent changes to the same data-latest, the connectedCallback and attributeChangedCallback calls in progress and pending are completed before the next one is run. I will test this before marking this issue closed.

What we ended up doing was: - streaming data from the adapter to the client via the websocket - when the client handles websocket messages, it switches on their type, stores them in a repository; depending on the currently active adapter in the UI, we update its `data-latest` attribute with the ID of the data that came in - the adapter web component will take the data from `data-latest` and fetch it from the repository it will place the data appropriately in its own internal data structures, and if the UI needs to be updated it will do that as well Supposedly, the callbacks for custom elements are synchronous, so when we make subsequent changes to the same `data-latest`, the `connectedCallback` and `attributeChangedCallback` calls in progress and pending are completed before the next one is run. I will test this before marking this issue closed.

Iris Lightshard closed this issue

2024-07-06 18:42:51 +00:00

good way of getting inbox into the UI #1

UI side

adapter side