WIP [#393] Resolve "signalc: register a number and send a message from it (1-shot)"
Closes #393 (closed)
context
- we are introducing signalc slowly but surely!
- this MR provides a CLI proof-of-concept that uses signalc to register and verify a phone number passed from the command line with signal, then send an arbitrary number of messages
- it does NOT YET receive messages or persist keystore material across sesions
changes
signalc
-
add
SignalcProtocolStore
- implements all methods on SingalProtocolStore using in-memory hashmaps for storage
- provides unit tests that provide clean seam for swapping out in-memory impl w/ postgres and keeping things green!
-
add
Account
model- has
RegisteredAccount
andUnregisteredAcount
variants - each is represented as an immutable data class with properties to lazily convert them to classes needed by the signal protocol: a
CredentialsProvider
and anAccountManager
- by "lazily convert" we mean construct these other representations in a memoized/once-only that prevents further memory alllocation from reconstructing and blocks the possibility of mutation)
-
RegisteredAccount
s lack uuids, which prevents theregister
andverify
steps from producing authentication errors by usingCredentialsProvider
s constrcuted with them -
RegisteredAccount
s have uuids (received from the server as a result of registration).MessageSender
s can only be constructed fromRegisteredAccount
s, which prevents them from erroring by thrying to authenticate with a phone number instead of a UUID
- has
-
add
Messaging
module- takes a
SignalServiceMessageSender
provided by aRegisteredAccount
and uses it to construct a data message and send it
- takes a
testing
- provide nice unit tests with lots of mocks for all 3 modules above! :)
dev env tooling:
- consolidate all test container configs into
docker-compose-text.yml
- instead of hard-coding different entrypoint scripts in different
docker-compose files, use same file and inject different
entrypoints in calling script as argument to
run
- bonus: add an
.env.test
file!
- instead of hard-coding different entrypoint scripts in different
docker-compose files, use same file and inject different
entrypoints in calling script as argument to
- run db setup, migrations for dev & test envs in different (dev & test) containers
- requires substantial overhaul of bash scripts!
- create test configs and scripts for signalc
- modify make scripts to allow for
sb
tests andsc
tests
gitlab cit tooling
- add signalc test job
- add sibnalboost- and signalc-specific cache keys (use latter to cache gradle build output)
- add reusable anchors for:
- rule to make jobs only run on MRs
- jobs that run in signalboost or signalc
- jobs that use postgres
- introduce build and test stages (use build stage to install npm packages and pass them to test phase. )
tooling to run and package signalc
- add
docker-compose-sc.yml
to wrap signalc docker container - add
make sc.run
andmake sc.package
, which run and package signalc inside container provided by docker-compose - customize build.gradle.kts to accomodate
run
by:- declaring main class name (necessary to run in
application
mode) - specifying STDIN for java exect tasks (so that it doesn't read from empty stream instead of user input [!!!])
- declaring main class name (necessary to run in
- tweak build.gradle.kts to accomodate
package
by:- importing
shadowJar
plugin (builds a "fat jar" w/ all external dependencies included) - providing main class to jar manifest
- importing
Edited by aguestuser