# Waku Object - Notes

### 2023-07-07
As a followup to the PR discussion, we agreed on the following:
PR: https://github.com/logos-innovation-lab/waku-objects-playground/pull/156
- Attila will finish the Waku backend as part of the PR, but the rest of the tasks will be done later as separate PRs
- Todos:
- fix knip ignore
- https://github.com/logos-innovation-lab/waku-objects-playground/blob/main/knip.ts#L8
- in the `onMessage` callback
- rename `updateBalance` => `checkBalance`
- change the `amount` to 0 in the `token` argument
- add `try .. catch` and `console.error` for rudimentary error handling
- in `sendTransaction` send only the tx hash
- that will trigger reading a transaction, needs to be added to the interface
- Further discussion topics:
- firebase backend architecture
- maybe change `formatTokenAmount` precision to 4, discuss with @David

### 2023-06-10
Philippe's summary about the two approaches of object isolation:
https://hackmd.io/JU9waVPnRtCTW-ySFBXVOg

### 2023-06-06
#### Object interface
- Filoozom and Attila should build the functionality and not necessarilly worry about ui and svelte part (we got this with Barbara)
- It could work the same way as the app adapter mechanism. The adapters should either be colocated adapters or passed in as props.

##### Backend
- I think we can just provide wallet and adaptor that mostly handles hooks and state.
- Here are some example of hooks for the **Send Tokens** waku object
- `onObjectCreate`
- `onTransactionSend(amount, token, fee)`
- `onStateChange(state, ...)`
- `getFee(amount, token)`

##### Frontend
- Here we would have each object exporting list of states and handler instantiating it
- The routing would be `/chat/[id]/object/[name]/[state]` and based on the `name` correct object would be instantiated in some `state`

##### Not sure how to do
- syncing object between users especially if there is a pending action (blockchain should always be source of truth though)

##### Brainstorming
- get inspired with Redux where we separate view from logic
- Accessing chain directly and waku directly
- packaging of waku objects?
- npm module with svelte?
- WO message format

    {
        id: 
        name: send_tokens,
        state: 
        other: {
            chain:
            txs:
            
        }
    }

##### Actions
- Attila to work on a restrictive interface
- Philippe research a non-restrictive mechanism
- Vojtech to continue to work on the UI
2023-06-05
==========
- Decisions we made
- Attila to work on a restrictive interface
- Philippe research a non-restrictive mechanism
- Vojtech to continue to work on the UI
- Brainstorming
- get inspired with Redux where we separate view from logic
- Accessing chain directly and waku directly
- packaging of waku objects?
- npm module with svelte?
- Current approach
- Backend
- I think we can just provide wallet and adaptor that mostly handles hooks and state.
- Here are some example of hooks for the **Send Tokens** waku object
- `onObjectCreate`
- `onTransactionSend(amount, token, fee)`
- `onStateChange(state, ...)`
- `getFee(amount, token)`

- Frontend
- Here we would have each object exporting list of states and handler instantiating it
- The routing would be `/chat/[id]/object/[name]/[state]` and based on the `name` correct object would be instantiated in some `state`

2023-06-05
==========
- Decisions we made
- for now we don't abstract the UI library, just build prototype objects together with the chat app, using same components from the app
- for now we don't deal with the sandboxing, but we will provide a possible implementation (or a description of it) as an outcome
- still we will use the interfaces for the communication between the objects and host applications
- as a next step we work on more diverse types of waku objects instead of group chat with splitting money
- it seems that we can learn more if we try to implement different objects as opposed to splitting money in a group chat, which we see as a generalisation of the one-on-one transactions

- Default wallet assumptions
- treat it like pocket money: only keep an amount in it that you are not afraid to lose (e.g. 10-100 EUR equivalent)
- transactions are quick (typically in the range of seconds, not minutes or hours)
- transactions typically cost orders of magnitude less than the amounts transacted (< 0.1 EUR)

- Waku Objects Design & Architecture
- Guiding principles
- objects are limited applications that exist inside a sandbox provided by a host application
- users trust the host application (and therefore the creators of the host application) that defines which objects are available in it
- objects have limited information about user data - only have access to necessary information based on feature and context (privacy)
- objects can share information with the same type of object in connected user's chat context (off-chain)
- objects may initiate transactions through the user's wallet
- objects may subscribe to updates and changes in their state through host interface
- objects may have a linked, first-class application version (e.g. website) and users may be able to access different views of their data stored in the objects through that if they connect with their account
- User Interface
- objects may use UI components from a pre-defined set provided by the host application
- therefore the host application may control the view and behavior of the components appropriately to the platform it is running on
- customisation of objects is limited and if necessary can be provided by the linked first-class application
- Architecture
- Host application provides interfaces for
- wallet
- balances
- rates
- prepare tx
- cancel
- sign/confirm
- subscriptions/history
- chat
- context
- username
- peer
- structured messages
- objects are identified uniquely and can only see messages from the same object types
- UI components
- primary/secondary buttons
- labels
- success/failure indicator
- detail view
- logo
- customizations

2023-05-29
==========
- The current protocol uses the following topics:
- The topic is formed as `/wakuobjects-playground/1/${contentTopicName}/${id}`
- All the stored objects are JSON serialized utf8 encoded strings
- Private messages are posted under `contentTopicName` `private-message` and `id` is the address of the user
- These are the incoming messages from other users
- Invites currently are not handled separately, if the user receives a message from another user who is not in the contact list then a new chat is created
- The format of the message is defined here: https://github.com/logos-innovation-lab/waku-objects-playground/blob/8677905d53898662bd4d51080cbba5f6117ae2a6/src/lib/stores/chat.ts#L4
- `fromAddress` identifies the sender
- Therefore currently there are no protection against message spoofing, also the messages are not encrypted
- The user profile is saved under `contentTopicName` `profile` and `id` is the address of the user
- The profile is defined here: https://github.com/logos-innovation-lab/waku-objects-playground/blob/8677905d53898662bd4d51080cbba5f6117ae2a6/src/lib/stores/profile.ts#L3
- Every time there is a profile change a new profile is saved
- When loading the profile the last profile is loaded
- Chats are saved under `contentTopicName` `chats` and `id` is the address of the user
- Because the chat information is stored in a [Javascript `Map` type](https://github.com/logos-innovation-lab/waku-objects-playground/blob/8677905d53898662bd4d51080cbba5f6117ae2a6/src/lib/stores/chat.ts#L25), it cannot be automatically serialized to JSON. Because of this only the `chats` property of the `ChatData` is serialized as `Array<[string, Chat]>`
- Every time the chat state changes (e.g. on each message) the chat store is serialized and saved on Waku. On startup the last state is loaded.
- This obviously won't scale well and it's also redundant, because the individual chats messages are recorded as `private-messages`. Aggregating them is not trivial unless all of the messages are loaded, so this logic can be quite complex and therefore not yet implemented. Group chats can be also done this way.
- The user information is saved under the `all-users` `contentTopicName`, the `id` is empty. This is a global space and it is a workaround for contact discovery until the invite system is done.
- When logging in all the users are read, then every user tries to find them in the global database and if not found they publish their own information.
- There is a topic for saving contacts under the `contact` `contentTopicName`, the `id` is the address of the user
- Currently this is not used, because the way the chats and user information is stored, as mentioned above.
- Known issues with the current implementation:
- Waku store is used extensively for storing all information, including potentially critical data and ephemeral data. The limitations are not well understood and it may happen that because of excessive use of updates some critical data may be lost.
- There is no protection against malicious attacks. If someone knows someone else's address then they can write any updates, including data that potentially crashes the browser or impersonates other users.
- Some ideas to mitigate this could be to encrypt the data, sign the data and obfuscate/encrypt the topics as well