♟ tomek

[lib] Fetch keys only when a session is missing

[lib] Introduce additional logging

[lib] Confirm a message after processing it unconditionally

[lib] Broadcast account deletion message after verifying the password

Keep checking if the socket exists

[lib] Remove shouldPerformSideEffectsBeforeSendingMessage flag

[lib] Choose a protocol based on thread ID

[lib] Choose thread ID behavior in the initial state gate based on the specs

[lib] Replace some usages of `thick` property

[lib] Move joining threads to a spec

[lib] Move deleting messages to a spec

[lib] Delete threadTypeIsThick function

[lib] Move creating permission blobs to a spec

[lib] Split thread permissions

[lib] Create a flag determining a thread search header

[lib] Move thread creation to a spec

[lib] Move determining pending thread types to a spec

[lib] Move freezing behavior to a spec

[lib] Use a protocol flag when determining unread status updates

[lib] Refactor pending to realized thread selector to use the protocol

[lib] Rename thread-actions

[lib] Rename metadata upload parameter

[lib] Move creating pending threads to a spec

[lib] Move fetching messages to a spec

[lib] Replace the protocol array with a function

[lib] Move converting DB threads to a spec

[lib] Create a flag telling if we should use DM activity handler

[web] Display thread icon based on the specs

[lib] Create a flag telling if pending threads are descendants of genesis

[native] Display thread ancestry based on the spec

[lib] Add a flag telling if messages are stored on a server

[lib] Create a flag determining message side effects behavior

[lib] Fix sharing initial state

In D14634#407366, @angelika wrote:
I don't understand why iconCreationFunction is introduced. Can't we just have chatThreadListIcon in specs that is lock, server or something else in the future (depends on the protocol)?

lib doesn't know and doesn't care about actual icons and components as it should

native does <Icon name={iconName} size={12} style={iconStyle} /> where iconName comes from specs (as it does now)

web does
const icon = iconName === 'lock' ? lock : server;
...
<FontAwesomeIcon size="xs" className={iconClass} icon={icon} />
where iconName comes from specs

In D14631#406147, @angelika wrote:

LGTM but I wonder if those side effects and deciding when to call them should be included in the protocol and handled in sendTextMessage(...) method. Then every protocol (dm/keyserver/other) has just "sendTextMessage" method and protocol decides when side effects should be performed. Also in useCreationSideEffectsFunc there are also conditionals threadTypeIsThick so the side effects can be different for different protocols.
Or in other words: Imagine a user of the protocol who wants to send a text message. I think it's way easier to use if a protocol is just "sendTextMessage and I'll take care of the side effects and when to call them" instead of "call this sendTextMessage but before that use this boolean to check whether you should apply those side effects first or last".

tomek (Tomasz Palys)
User

Projects

User Details

Recent Activity
View All

Yesterday

Wed, Jun 11

Tue, Jun 10

Mon, Jun 9

Fri, Jun 6

Thu, Jun 5

Wed, May 28

Tue, May 27

Mon, May 26

Fri, May 23

Thu, May 22

tomek (Tomasz Palys)User