`common` was a grab-bag with no domain: the issue's own preamble names
it as the kind of package that must not exist. Every symbol moves to the
package that owns it, and the directory is deleted.
common/dbsetup -> internal/db/dbsetup
common/devices.go -> internal/platform
common/pausable*.go -> internal/pausable
LogOnPanic -> internal/panics
TruncateWithDot(N) -> internal/logutils
RecoverKey, ValidateDisplayName, display-name errors -> protocol/common
IpfsGatewayURL -> internal/ipfs.GatewayURL
Archives/TorrentTorrentsRelativePath, MainnetEthereumNetworkURL -> params
StatusService -> pkg/backend/node
ErrBigIntSetFromString -> services/wallet
IsNil, Ptr -> inlined at their call sites
IsENSName -> deleted, it had no callers
Notes:
- LogOnPanic gets its own package rather than living in logutils. It
reports to Sentry, and logutils is imported by nearly everything: put
the guard in logutils and the Sentry SDK lands in every dependency
graph in the tree (213 -> 250 packages). internal/panics imports
logutils and sentry, which is the direction root `common` had.
- TruncateWithDot is log redaction, not string formatting: every one of
its 121 call sites is inside a log or error message, so it belongs
next to the logger.
- Moving RecoverKey and ValidateDisplayName into protocol/common removes
the common -> protocol layering inversion; all their callers were
already inside protocol/.
- Makefile lint-panics target follows LogOnPanic to its new path.
refs #7067
Part of https://github.com/status-im/status-app/issues/21462
- Open existing app and wallet SQLCipher databases concurrently, while preserving sequential initialization for new or legacy databases.
- Speed up account selection by preloading the profile keypair and decrypting only the chat private key instead of the full extended key.
- Defer token manager startup until after login completes and run it asynchronously outside the critical startup path.
- Load cached leaderboard market data asynchronously, waiting only when the data is accessed or the service stops.
Before: about 2.15 s for the backend login request
After: about 0.47–0.50 s
Improvement: roughly 1.65–1.70 s saved
Relative reduction: about 77–78%
Speed multiplier: approximately 4.3–4.5× faster