Samuel Stroschein

> This also means that to avoid storing our ids in resource files from plugins, we won't prompt for ids for new messages yet. @jldec but how do human readable...

**EDIT:** even if the IDs are derived from the message key, the problem of changing IDs that users reference in code exists and even introduces a new problem: There is...

@martin-lysk read my edit. using the key only is even worse. we risk multiple messages with the same id now and again using message ids in something like paraglide js...

we introduced the derivation of message ids from existing keys **to avoid migration merge conflicts**. after the migration, the ID "system" was supposed to take over and ensure uniqueness and...

**Call with @martin-lysk & @jldec (who joined later)** 1. we will ship this PR opral/monorepo#2108 and follow up https://github.com/opral/monorepo/issues/1585 and https://github.com/opral/monorepo/issues/1844 behind feature flag "is opral owned project" 2. nothing...

@jldec assigning you to make sure this issue will be resolved

> using solid signals for an sdk is kind of crazy lol. > surprised it managed to live for this long 😅 The SDK has the odd requirement that close...

Some research over the holidays: - we need an async runtime/state management/reactive (async) programming solution - scala has multiple e.g. https://typelevel.org/cats-effect/ and https://zio.dev/ - JS ecosystem seems empty handed except...

i just got off a call with Datner regarding effect ts , see his comment [here](https://www.reddit.com/r/typescript/comments/16w3iwn/comment/k42tu1h/?utm_source=share&utm_medium=web2x&context=3) - effect ts solves most problems but is not fully stable yet, requires full...

### New hard requirement: The solution should not "leak reactivity" to consumers. This requirement has been forgotten but was a large driving force for Signals. The SDK should work in...