Makes sense! Thanks for clarifying and answering the questions!

In D6924#211911, @rohan wrote:

In D6924#211756, @tomek wrote:

It seems like I wasn't clear enough in my comment, so let me explain it differently. Correct me in any place where I'm wrong. So on the client side we would want to display three things:

1. A robotext message in a thread telling that a message was pinned
2. A pin indicator next to a message
3. A list of pinned messages

As far as I understand, what you're describing handles only the 1st point. How do we plan to handle 2nd and 3rd?

Ah I understand now, sorry. Yeah you're right, those are the three things we want to display client side.

1. Robotext: Will be handled by introducing a new message type and spec
2. Pin indicator: I think this is the one I'm a little unsure on since I've not begun working on the client-side yet so I wasn't sure on the best way to handle this. I'm not sure if updating RawMessageInfo to support something like RawPinnedMessageInfo and MessageInfo to support PinnedMessageInfo is the best way
3. A list of pinned messages: D7110 and D7112 should handle this, I can call the endpoint to retrieve all of the pinned messages for a given thread.

I don't think doing input validation for SQL results is necessary – the any is fine here. It would probably have been more clear how / why you're using any if these utility functions were introduced in the same diff where they are used.

In D7147#211972, @bartek wrote:

How do you obtain the SHA-256 fingerprint? From what I understood from the diff description, it is copy-pasted from Play Console, right?

In D7146#211968, @bartek wrote:

The new ID looks correct

IIRC @ashoat did some linking long time ago so there are leftovers across the codebase (e.g. here)

In D6924#211575, @rohan wrote:

In D6924#211499, @tomek wrote:

How the pinning will be saved on client's side? Do we plan to have it included in a message info? If that's the case, do we plan to update all the message infos saved on all the clients?

I'm currently introducing a new message type and a message spec for pinned messages, so we'd have messageContentForClientDB. From my understanding, I can support both content for server and client, but feel free to correct me if I'm wrong.

How the pinning will be saved on client's side? Do we plan to have it included in a message info? If that's the case, do we plan to update all the message infos saved on all the clients?

In D7059#210217, @atul wrote:

Specifically adding @tomek as reviewer since he seemed to have some thoughts during the Encryption Sync (that might've been discussed offline?)

Do we know how this diff corresponds to https://linear.app/comm/issue/ENG-3322/fix-stale-cache-error-for-olmwasm#comment-d1aabe3d? Maybe this will somehow improve the experience about the path's configuration?

In D6963#209487, @kuba wrote:

I don't know how to test message shimming yet, so for now it isn't tested.

Looks ok - it doesn't seem necessary to do a migration.

Have you checked if Redis and MariaDB work correctly after this change? Are we sure that closing this descriptor doesn't cause any issue for a process that opened it?

We persist messageStore.messages and threadStore in SQLite on the native client, and it would probably make the most sense to store pinned_messages in the SQLite threads table instead of introducing a whole new table and set of “ops.” That would introduce inconsistency between the MariaDB and SQLite database… which isn’t the end of the world, but could be avoided if we stored pinned_messages in the threads table?

In which way does it affect the database on the keyserver side?
It's really hard for me to find some advantages of having denormalized pins column on the server. It will make any querying based on pins a lot harder than it should be.

Improve parsing and error handling

Haven't figured out how to send a request from host, but verifying that is the next step.

Not sure what you exactly mean, but docker-compose exposes the service port to host, so you should be able to simply

yarn run-feature-flags-service-in-sandbox
# in a separate terminal
curl "http://localhost:50055/features?platform=..." # etc

The issue was caused by a fact that I was using localhost instead of 0.0.0.0. When running the service locally, there's no difference. But when a service is run within a container, the localhost doesn't work properly.

Bind to 0.0.0.0

Rebase

Rebase

Rebase

Rebase

Rebase

Rebase

Rebase

Rebase

Update cargo dependency