Ah, but we probably DO want yarn build on prod. As @varun said:

Did we make sure this passed keyserver Docker build before landing?

Left a note about the error-handling on the Swift side, definitely let me know if there's something I'm missing. I think we should just be able to match what we're doing on the Android/Kotlin side?

Did we make sure this passed keyserver Docker build before landing? Just want to make that sure that running build:debug before we run build doesn't break build (doubt it)

(To your queue and off my mine while you figure things out with @kamil)

Oops, This is a duplicate of D6994 - I'll sync with @kamil and we'll decide what to do

don't install ci-deps for non-debug

• Updated diff description
• Added CI
• Removed lint-staged for desktop and native > On native we have only one dummy test which is failing

Not an expert in C++ but your code follows the pattern I used when writing the C++ message spec for reactions. Would be helpful to get a second pair of eyes here

fix yarn build:debug to include install-ci-deps step

I think we should consider if we also need shimUnsupportedMessageInfo and unshimMessageInfo. These functions will help us support older native clients that haven't been updated yet.

This is more related to this task: https://linear.app/comm/issue/ENG-2712/we-dont-run-tests-in-web-and-native-in-precommit-hook
So I'd rather do that when adding the hook

Now that they're working, can we update this diff to include them in CI?

Accepting, but if what I suggested doesn't take too long might be worthwhile to update

Thanks for fixing these tests. Now that they're working, can we update this diff to include them in CI?

Seems reasonable

For additional context, fd3 is used by direnv dump to "export the inner bash state at the end of execution." Here's the source from the direnv repo:

In D7009#208076, @tomek wrote:

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?

I still prefer selecting by hand, but this approach is also correct

Removed 'hasBeenEdited' variable from 'RobotextChatMessageInfoItem'

Add 'hasBeenEdited' to code for native to be able to access the variable

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?

One thing not mentioned by @varun is that the current AUTH_TOKEN hack we use for keyserver is implemented on a per-service basis. So we can roll out a new service without "authorization headers", while maintaining the current keyserver paradigm.

Ahh sorry that was a bad misreading on my part, I get what you mean about user IDs now.

Huh wait a user should know their userID, did you guys discard of the concept of a userID entirely because you didn't see it in the whitepaper?

we can deprecate the original service (the one being renamed here)

the set of RPCs that devices will call is different than the set that ashoat's keyserver can call today. also, the actual messages are slightly different, as the linear issue i linked explains. we think it makes more sense to just have a separate service for devices, rather than introduce a bunch of conditional logic in the current service. of course, both services will be served by the Identity Service (this is pretty simple). eventually, when we switch to the identity service being the source of truth for user info, we can deprecate the original service (the one being renamed here)

In D7001#208029, @ashoat wrote:

I'm more confused as to why are we're separating the protos / services out at all

I'm more confused as to why are we're separating the protos / services out at all

1. Huh wait a user should know their userID, did you guys discard of the concept of a userID entirely because you didn't see it in the whitepaper?
2. I don't understand why we're separating into two services, can you explain that?

how about identity.general? identity.client feels weird

how about identity.general? identity.client feels weird

Hmm are we using usernames as an identifier? Ideally we use user IDs for that

This honestly feels like bike-shedding… I’d love if we could start out the work on this project with a focus on derisking the big risks, rather than renaming things