open-chat-labs / open-chat Goto Github PK

make sure that regardless of the machine that we are in, errors are handled correctly.

Make sure that errors are logged appropriately and that the user is informed in an appropriate way either via error page or toast.

The performance seems relatively good on the main chat list at the moment. But, it is unbounded and that's never a good thing. If the user loads a lot of messages and then tries to switch back and forth between chats, then all the messages need to be re-rendered and that can get a little bit laggy (will obviously be a lot worse on mobile).

We would like to be able to only render the slice that the user is actually looking at. There are solutions to this available, but we have some interesting additional requirements. We need to be able to support:

• reverse infinite scroll with async lookup of new messages.
• adding messages to either end of the list.
• scrolling programmatically to any point in the list
• modifying the underlying list without losing scroll position
• having at least a somewhat meaningful scrollbar ideally

Whether or not we can come up with a solution that covers all of these requirements is uncertain.

Currently using svelte-markdown. Don't know how big the lib is.

The advantage of this lib is that it does not use @html so it should be xss safe out of the box. But it might be big and it might be slow. We could use some other markdown lib and combine it with dompurify to avoid xss.

This could help with #190 et al.

I consider it a 'best practice', especially when used with console.debug, so your js console will still be empty to non-devs who haven't opted into debug logging.

we can indirectly select a chat (via participant click or message click) when that chat is scrolled out of view in the left panel. We should make sure that the selected chat is always scrolled into view.

There are several different scenarios to consider.

Anticipated errors received from the api e.g. username already exists etc
Half-anticipated errors from the api e.g. 403 / 401
Unanticipated errors from the api e.g. 500
Unhandled errors in the front-end outside of api calls.

Need to make sure that errors are always caught and that they are recorded somehow. We should probably use some sort of client side error logging framework for this e.g.

• sentry
• bugsnag
• rollbar
• firebase

I'm not sure if #187 was due to code in open-chat or dfx

We create user canisters before the username has been specified.

Until we hear from the user_index canister that the username is specified we should reject all incoming requests using 'inspect_message'.

this is not all that trivial sadly. We might be able to find a third party solution that is reasonable or we might be able to take some inspiration from articles like this: https://andrejgajdos.com/how-to-create-a-link-preview/

This isn't needed to unblock demo, but is relevant to gobengo/ic-whoami#3

Particularly for phone use, it's not very friendly to just reject images that are too big. We should just resize them on the fly if they are too big.

@hpeebles just showed me in a meeting how they are running into the dfx deploy 2Mb file size limit when trying to deploy this application once they started to emulate the wallet integration I described in slack.

@hpeebles

• This is a front-and-center blocker right now, right? Any known workarounds?
• Will you please link to a git commit that this can be reproduced on? e.g. could be a temporary branch we can use to repro and try different candidate solutions to fix

Started using some slightly hefty images which are nice, but need optimising.

Adding to home screen does work to a degree but the icon does not work. Perhaps this is something to do with the fact that we are using an svg? Have not tried it on Android.

Also, signing into the IC does not work on my phone when it is done from the app saved to home screen - which is weird.

it switches to the new group and then scrolls to the bottom in a visible way which is ... not nice.

In my circle of friends we almost always organise events via WhatsApp and it would be nice to provide a better UX for this.

Users could create events, which at first would just need a title + start date (+ optional end date), then participants can mark themselves as yes/no/maybe.

We can then show an app level calendar with all of your events.

Currently we load the data for all media and file messages when the message itself is loaded and place it in indexdb. This keeps things simple but it is not optimal since we then load data that the user may never interact with. We should instead lazy load everything but images.

when signing out and back in as another user, the in memory state from the previous user hangs around.

registration steps should be forms so that you can press enter to hit the cta

when you hit lets go, it goes into a horrible janky loop - figure out why and fix it (the reason why is that we alternate between loading_user which does not display the register component and register_user which does - until the canister is ready. Not sure what the best solution is)

currently we store messages (well events) and media / data in indexdb. We can also store chat summary objects themselves. That way, after the initial load by the user (on a particular device) we will always have a last updated timestamp and we can just load the diff rather than needing to load the initial data.

This is useful for general feedback on successful operations and also for alerting on any error that occurs.

Feels like this is just a really simple writable store and a global component with a transition.

Fairly straightforward enhancement. Might as well have all the ways to post an image / file.

Currently the context in an xstate machine has a single shape regardless of the state that the machine is in. This is ok, but leads to some woolliness in the types. In fact, the rules of the machine should guarantee that certain properties of the context are available in certain states.

Typestates are designed to help us express this: https://xstate.js.org/docs/guides/typescript.html#typestates

We want to make a start on a proper build process. Step one is to build the front end including linting and unit tests, when attempting to PR to master.

See here - https://m3agh-3qaaa-aaaab-aahba-cai.ic0.app/

The style sheet at document.head.children[8] isn't ours and messes up our styling.

We should update config values in the index canisters and then have them propagate to the child canisters.
Config values can include things such as -

• LOW_CYCLES_BALANCE_THRESHOLD
• MAX_STORAGE
• MARK_ACTIVE_DURATION
• Notification canister Ids

doesn't seem to be quite working at the moment and we also have some annoying duplication between the group and user client.

This will allow us to exclude unauthorized message pre-consensus therefore using up far fewer cycles (it may even cost 0 cycles).

if a chat is selected and then it is removed, the chat still appears selected in the middle panel and this is because the chat actor (stored in the home machine) still exists. It needs to be removed as part of the merge process when receiving updates. We could also clean up the messages from indexdb though that's not really necessary.

This is not strictly required, but it will increase confidence that the recording will go smoothly.

Add an indexDB layer in between the UI and the front end service to get chat messages. Messages are immutable so we want to store them all on the client if we possibly can. This should greatly reduce the load on the back end. And it will also allow us to throw away messages from the UI when switching between chats. This should ease any performance issues with the main chat list and remove the need to virtualise the list which would be quite a complex endeavour.

Uncaught (in promise) Error: Query failed:
Status: rejected
Message: IC0502: Canister sadjp-vqaaa-aaaab-qaipa-cai trapped: heap out of bounds

Once it becomes available...

Allow the targeting of a specific user in a group chat using the @megrogan @hpeebles thing.

adding participants to an existing group is done one by one at the moment which is pretty slow if you want to add several.

We should change it to add multiple at the same time if desired, like when we create the group. Ideally we can just created shared UI for multiple user selection and do it that way.

on mobile the chat list is still being rendered (and updated behind the scenes) when we are looking at a specific chat on mobile. This is inefficient and I can see if causing cpu spikes in the performance trace.

Conversely we should also ensure that the middle panel is not rendered at all when the use is looking at the left panel. This should also deal with the glitch on mobile when the left and middle panels seems to be half visible at the same time.

Also seems like there is a possibility that the markdown parser is contributing to performance degradation on large lists.

All of this would go away with a virtual list so I still think that should really be a priority.

Certainly via file upload but also ideally via recording.

When in China I noticed people doing this all the time - particularly taxi drivers just because it's easier than typing.

To make OpenChat behave a bit more like an app we need to set up a proper manifest fine with app icon etc.

We need to consider the scenario where multiple different users use the same device. In this scenario we need to ensure that the cached data on the client is a) isolated and b) secure. For this the data must be sharded according to some unique property of the user e.g. their Principal and it must also be encrypted (how to do that - TBD).

Looks like we might be able to encrypt index db using dexie and dexie-encrypted.

Note, that it is probably not necessary to shard messages / events since they are keyed by chatId anyway. We will need to shard chats by userId though. Both stores still need to be encrypted though.

The registration process is somewhat complicated and also includes a bundle of country telephone code info. A user only needs all this stuff once so it's worth trying to remove it from the main bundle, just so we can keep things as light as possible.

need to understand why there is a block and unblock on the group canister as well as the user canister